Desktop Remoting capability might break once you upgrade to Windows 7 SP1

Once upon a time A Windows 7 virtual machine that I always accessed remotely happily sat on on an ESX server. As per the recommended settings by the evil empire to the north, I had kept auto update settings in place and that would periodically update my virtual machine. Heedless of the common adage, "Don't fix it if its not broken", I caved in to that occasional itch of having my software(s) to the latest and greatest patch level. I decided to upgrade my virtual machine to Service Pack 1.

Once the upgrade was done, my RDP window froze which I had to kill ofcourse. The rest was history. Any client on any machine would just refuse to open a remote connection to my virtual machine without giving any valid explanation. Rounding up the usual suspects of  remote settings on desktop, permissions, et al did not help as the upgrade process did not touch those settings. The silver bullet solution of restarting the computer that is known to have fixed unfathomable issues in windows also failed. That was the last straw!

The solution had to be found. After much googling (and binging too!) I found that upgrading from Windows 7 to Windows 7 SP1 does result in breaking remote desktop capability under specific circumstance. A microsoft security patch KB2667402 was found to be the culprit. Restoring remote access was fairly simple after that.

One way is to uninstall this patch and then upgrade to Service Pack 1. If you already have upgraded to SP1 like I did, just uninstall this patch and Remoting should be restored. Since its a security update, and If it matters to you, then re-apply the patch once upgrade to SP1 is complete.

This may have ramification in VDI deployments. A VDI administrator may upgrade the master image to SP1 and sync all virtual desktops to the current image with SP1. If RDP is the protocol in use, this may break everyone's remote access (might result in a day off!!). All VDI administrators may have to do is to remove this patch, upgrade master image to SP1 and re-apply this patch and other important updates and then refit all desktops to this image.

Trapped while migrating from a standard vSwitch to DVS

Something really interesting happened while configuring my management virtual machines to use a DVS (Distributed virtual switch) from a pre-configured standard vSwitch. There is a general rule of thumb to segregate virtual machines on a distinct ESX hosts that run your vCenter Server and database server. However, while doing a phased maintenance ...

An ESX host was configured to have a DVS with the right set of physical adapters, virtual switches configured with the right VLAN tags. In order to do maintenance, we moved VMs running database, vCenter VMs and a few others to this host. All of a sudden the VM running vCenter VM froze, nothing seemed to work and VI client became unresponsive. Amusing as it may be, with windows (and since we were doing maintenance), our first line of defense is rebooting the machine. That did not help and the VM was pretty much unresponsive. Logging into the VM console directly from the ESX host and killing vCenter server helped as much, but only to a point where we could click on start menu and really something like windows start up menu would show up. Since this virtual machine was exclusive to vCenter Server for a large scale deployment, having vCenter Server laid to rest did not fit in the grand scheme of things.

Taking a step back, we moved all the VMs to the pre-configured standard vSwitch with the same VLAN tag but with a different vNIC with the visibility in the network identical to that of the newly configured DVS. It was spring time for VC, database and everything came back to life. Little surprise that this prompted a 'scratch your head' reflex action in me and a few others. Moving just the database VM in to the newly configured DVS broke down the VC as we observed it lost the connection to the database.

In order to move virtual machine hosting a vCenter Server is not as straight forward. The classic divide and rule did the trick. We had a spare host with the right DVS configuration. Migrating the virtual machine hosting database to this server's DVS did not disrupt the vCenter Server. The secret is, although the DVS and standard vSwitch are available to the virtual machine's vnic to choose, these two cannot talk to the same VLAN. If we have database and vCenter VMs co-hosted and either of them moves to the DVS, the VC loses its connectivity to the database.

Moving vCenter Server VM to the DVS became a non issue as DVS and standard vSwitch with its VLAN tag had visibility into DVS of the host that hosted the database VM. Now you can keep them separate or move the Database VM back here to co-host with VC or on second thoughts, why fix it when its not broken?