Attempting to decommission an Exchange 2003 server throws the error: “The component “Microsoft Exchange Messaging and Collaboration Services” cannot be assigned the action “Remove” because: - One or more users currently use a mailbox store on this server. These users must be moved to a mailbox store on a different server or be mail disabled before uninstalling this server.”

As many Exchange 2003 to 2007 and 2010 migrations I’ve done over the years, I think the part of the migration I dread most is the end of the migration when the Exchange 2003 server needs to be decommissioned.  Other than making sure that all the mailboxes are moved, public folders fully replicated and moved over, and all of your legacy routing connectors are recreated for large organizations that still have Exchange 2003 servers, I find that I almost always receive errors when I try to use the Add and Remove Programs wizard to uninstall Exchange.

Just when I thought I’ve seen all of the possible reasons why an uninstall would fail, one of the recent Exchange 2003 migrations threw me the following new error:

The component “Microsoft Exchange Messaging and Collaboration Services” cannot be assigned the action “Remove” because:
- One or more users currently use a mailbox store on this server. These users must be moved to a mailbox store on a different server or be mail disabled before uninstalling this server.

This was the last error of the 3 I fixed (the other ones being routing members and routing groups) and while I’ve seen something like this before where various users weren’t visible by browsing the mailbox stores on the Exchange 2003 servers via the System Manager console, so you had to use the following KB:

Error message when you try to remove Exchange Server from a mailbox server that no longer hosts mailboxes: "One or more users currently use a mailbox store on this server"
http://support.microsoft.com/kb/924170

To launch Active Directory Users and Computers, use the Find tool to search for users via the Exchange tab while checking:

• Show only Exchange recipients
• Users with Exchange mailbox

Then use the View tab to select the Choose Columns… option:

Then add the column Exchange Mailbox Store:

… then finally use the Exchange Home Server tab to sort the users and locate the mailboxes that are still associated with the Exchange 2003 server you are trying to decommission:

This has always worked for me but not for the last migration because no matter which domain I searched, I could not locate any mailboxes that are associated with the server I was trying to decommission:

After triple checking all the domains, I proceeded back to Google to see if I could find something that would help and that was when I came across this post:

http://social.technet.microsoft.com/Forums/exchange/en-US/2758744e-ab92-45af-bc01-5a1280887230/one-or-more-users-currently-use-a-mailbox-store-on-this-server?forum=exchange2010

So apparently there was another way to try searching for these mailboxes and that is to select the Custom Search option in the Find drop down menu:

Select the Advanced tab:

In the Enter LDAP query textbox, type in:

objectClass=User

Searching with this method finally revealed the mailboxes I was looking for:

Proceeding to select the accounts with the mailboxes and then using Exchange Tasks… enabled me to remove these mailboxes and proceed with the uninstall:

Once the mailboxes in question have been removed, proceed with restarting the uninstaller and the error should go away:

Attempting to connect to a Citrix XenDesktop 5.6 VDI via the Web Interface portal fails

Problem

You attempt to connect to a Citrix XenDesktop 5.6 VDI via the Web Interface portal but nothing happens and the Desktop Viewer doesn’t launch:

Logging onto the VDI and reviewing the Application logs reveal the following:

Level: Error

Event ID: 9032

Source: Citrix ICA Service

Description: Citrix ICA could not configure Thinwire and switch to the remote ICA display. Rebooting the workstation or logging in at the console will fix this.

Solution

Citrix actually has a KB article for this issue that can be found at the following URL:  https://support.citrix.com/article/CTX118864

The reason why the connection fails is because the Citrix Display Driver (Citrix Systems – WDDM) display driver for her VDI was overwritten by the VMware version named VMware SVGA 3D.  Here’s a screenshot of what the desktop’s Device Manager may look like:

… and here is what it should look like:

One of the reasons why this would happen is if the VMware Tools of the virtual machine hosted on the ESXi server has been recently upgraded or was installed after the Citrix VDA agent was installed overwriting the display driver.  To correct the issue, simply reinstall the Citrix VDA agent to get the correct display driver back on.

Automatically displaying published applications on Citrix XenDesktop 7 StoreFront portal

As some administrators who have deployed Citrix XenDesktop 7 may know, the Web Interface has now been replaced with the new StoreFront server and out of the box, the portal looks as such:

While the interface is intuitive enough to lead the user to click on the + button to browse applications, some administrators prefer to publish the application more like the classic XenApp 6.5 with Web Interface look.  Although I have yet to figure out how to configure the StoreFront to display the classic look, I did find the following:

Integrating StoreFront into Your Environment
http://support.citrix.com/proddocs/topic/dws-storefront-12/dws-integrate.html

… describing how using keywords can perform the following:

Keyword: Featured

By adding the word Featured in the Description and Keywords field of the Application Settings as such:

… the application would be displayed as such in the StoreFront portal:

Keyword: Auto

By adding the word Auto in the Description and Keywords field of the Application Settings as such:

… the application would be displayed as such in the StoreFront portal:

Note that users can still right click on the application and remove it:

What I’ve noticed is that if a user removes the application, it will not reappear on the front page regardless of whether they log off and back in, or if you remove the keyword for the application settings then add it back in.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

The following is a screenshot of what the applications look like with the keywords added:

Attempting to access Citrix XenDesktop 7.x published applications through the StoreFront web portal displays the message: “There are no apps or desktops assigned to you at this time.”

Problem

You’ve just completed a new deployment of XenDesktop 7 and have created new:

• StoreFront portal
• Machine Catalog containing a Windows Server virtual machine with installed applications
• Delivery Group with the above Machine Catalog
• Published applications in the Delivery Group

Proceeding to access Citrix XenDesktop 7.x published applications through the Storefront web portal (http://storefrontURL/Citrix/CitrixSiteNameWeb) but notice that upon logging in, you get the following message:

There are no apps or desktops assigned to you at this time.

 

Solution

The reason why the Citrix XenDesktop 7.1 StoreFront web portal would display this message is because the Transport type of the Store configured on the StoreFront server is configured to communicate with the Delivery controllers via HTTPS.  This is the default when you create a new store in the StoreFront administration console yet the Delivery controllers are configured to listen on port 80 by default as per the following Citrix KB:

How to Change Ports for XenDesktop 7
http://support.citrix.com/article/CTX138918

To correct this, you either have to configure the delivery controllers to listen on a different port as per the KB above or change the StoreFront store to use HTTP port 80 as per the following instructions:

Log onto the StoreFront server, navigate to Stores, select the store in question and click on Manage Delivery Controllers:

Select the Controller and click on the Edit button:

Proceed by changing the Transport type from HTTPS to HTTP:

Hit the refresh button on the StoreFront portal and you should now see a Add your Favorite Apps option:

You should now be able to launch an application:

 

I remember always pushing to use HTTPS as it’s supposed to be more secure since the traffic would be encrypted but this obviously increases administration overhead as you need to managed certificates.  I find most of the clients tend to leave towards using regular HTTP and their justification is that their server VLAN is a secured VLAN.

Configuring an Active Directory GPO to force enable Remote Assistance and Remote Desktop

I get asked the question about creating a GPO to enable the following 2 settings quite often:

1. Remote Assistance
   Allow Remote Assistance connections to this computer
2. Remote Desktop
   Allow connections from computers running any version of Remote Desktop (less secure)

 

As I know I’ll get asked about this in the near future, this blog post will serve to demonstrate the configuration settings required to achieve this.

Remote Assistance
Allow Remote Assistance connections to this computer

To enforce this setting on a server or desktop, create a GPO and navigate to:

Computer Configuration –> Policies –> Administrative Templates –> System –> Remote Assistance then enable the following settings:

Solicited Remote Assistance

Offer Remote Assistance

Once this setting is configured, the Remote Assistance section in the Remote tab of System Properties will look as such:

Note how the Allow Remote Assistance connections to this computer is now grayed out.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Remote Desktop
Allow connections from computers running any version of Remote Desktop (less secure)

To enforce this setting on a server or desktop, create a GPO and navigate to:

Computer Configuration –> Policies –> Administrative Templates –> Windows Components –> Remote Desktop Services –> Remote Desktop Session Host –> Connections then enable the following setting:

Allow users to connect remotely using Remote Desktop Services

Once this setting is configured, the Remote Desktop section in the Remote tab of System Properties will look as such:

Note how the Don’t allow connections to the computer is now grayed out.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

In addition to the configuration settings above, if you’d like the domain firewall to be disabled, navigate to:

Computer Configuration –> Policies –> Administrative Settings –> Network –> Network Connections –> Windows Firewall –> Domain Profile then disable:

Windows Firewall: Protect all network connections

Effects of losing a vCenter 5.1 server used by a VMware Horizon View 5.3 environment and then deploying a new vCenter 5.5 server

I’ve lately had to upgrade a lot of VMware vSphere vCenters from 5.1 to 5.5. and as many of the clients I work with use Citrix XenDesktop or VMware View at some capacity, I’ve always recommended to upgrade rather than build new if they do not intend on recreating their desktop pools.  Upgrading vCenter has never been a preference of mine and with the changes to the SSO component in 5.5 (goodbye RSA SQL database), I would much rather perform a fresh install.  With that said, I’ve been reluctant to build new vCenters for various clients who use VDI because I came across a situation in the past when I had to remove a host connection from a XenDesktop 5.6 environment then quickly came to realize that all of my catalogs were broken.  It was then that the fear of breaking the connection between a VDI server and vCenter became embedded in my head.

Fast forward to just this last weekend, I had the opportunity to perform an upgrade of a vCenter 5.1 to 5.5 used by a VMware Horizon View 5.3 environment with only 2 pools of 200 floating assignment desktops.  Seeing how I had a 6 hour window over a weekend to do this and I could easily create these non persistent desktops, I went ahead and uninstalled vCenter 5.1 from the server, deleted the database then started a vCenter 5.5 from scratch pretending I had lost the vCenter with no backups.  What I noticed was that various desktops in the View environment would go into the problematic status’ such as:

• Customizing (missing)
• Provisioning error (missing)
• Provisioning error (missing)
• Unknown (missing)

I went ahead and ignored the errors and continued the deployment of the vCenter.  Once I completed the installation of vCenter 5.5 and added the desktop ESXi hosts back to the vCenter using the same datacenter, cluster and folder names, I proceeded to restart the VMware View Connection servers and within a few minutes, the desktops slowly began going into healthy status’.

So there you have it, if you were to lose a vCenter 5.1 with no backup, it is possible to install a new vCenter 5.5, let your View environment reattach to it and still be able to maintain your pools without having to recreate them.  I haven’t had a chance to try this with XenDesktop but there is a 7.1 environment currently latched onto a “to be upgraded” vCenter 5.1 so I may be able to write another post of the experience I get with that environment.

Automatically refreshing VMware View 5.x virtual desktops in “Already used” and “Agent Disabled” status

Administrators who have had to managed large floating pooled desktops in VMware View 4 and later could probably relate when I saw it’s quite the administrative burden to check on these large pools every so often, sort by status and refresh desktops that have the Status as Already used or Agent disabled:

I recall spending quite a bit of time 2 year ago trying to see if there was a way to automatically refresh these desktops while working with a 500+ seat deployment that seemingly had 10 or more desktops in such a state every few weeks.  The research didn’t go too far and I got busy so left it till last year when I had to upgrade a View 5.0 pool to 5.1.2 and as I read the release notes, the following was what I noticed:

VMware View 5.1.2 Release Notes
https://www.vmware.com/support/view51/doc/view-512-release-notes.html?ClickID=dkhs0xbx0kzhztss2ynnshxsykxz2zhozybk

In View 5.1.2 and later releases, you can add a View LDAP attribute, pae-DirtyVMPolicy under OU=Server Groups, DC=vdi, DC=vmware, DC=int, and set the following values for the attribute. The pae-DirtyVMPolicy values provide the following options for the Refresh on logoff policy:

• pae-DirtyVMPolicy=0. Mark virtual machines that were not cleanly logged off as 'Already used' and block user access to them. This is the default behavior in View 4.6 and later releases.
• pae-DirtyVMPolicy=1. Allow virtual machines that were not cleanly logged off to become available without being refreshed. View Client users can access these desktops.
• pae-DirtyVMPolicy=2. Automatically refresh virtual machines that were not cleanly logged off. View Client users can access these desktops after the refresh operation is completed.

 

Another public VMware KB about his configuration can be found here:

The View virtual machine is not accessible and the View Administration console shows the virtual machine status as "Already Used" (1000590)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1000590

This was definitely a welcomed feature and as promised by VMware, it does just as it says.  The following are some screenshots I took last year while configuring the parameter.

Log onto your View Connection server, open the run prompt and launch adsiedit.msc:

From within the ADSI Edit console, click on Action and then Connect to...:

Within the Connection Settings window, enter the following for these fields:

Name:
View Adam Database

Select or type a Distinguished Name or Naming Context:
DC=vdi,DC=vmware,DC=int

Select or type a domain or server: (Server | Domain [:port]):
localhost

Navigate to ADSI Edit –> View Adam Database [localhost] –> DC=vdi,DC=vmware,DC=int –> OU=Server Groups:

Notice that your desktop pools are listed.  Proceed with right clicking on the pool you would like to edit and select properties:

Scroll down to the pae-DirtyVmPolicy and configure a value of either 0, 1 or 2 as described above:

There you have it, an easy way to handle desktops in the Status as Already used or Agent disabled.