Why sometimes I am prompted to reboot my virtual desktop immediately on login?

Optimisation Type [explain] : user experience (↑) / resource optimisation (-) / functionality (-) / administration (↑)

Have you or your users been greeted with the “You must restart your computer to apply these changes” dialogue box every so often upon login to a virtual desktop? If you choose to ignore it and click “Restart later”, things seem to work perfectly fine.

So why is Windows asking for a reboot?

What has changed?

This may not apply to all desktops in the pool, and appear to be random. It is particularly prominent in floating linked clone desktops that get refreshed each time a user logs off.

We may suspect Windows update to be the culprit, or some other automated updates making changes we don’t want. But that is less likely as those services should have already been turned off during desktop optimisation process.

I have actually never encountered this in any production deployment, but in my home lab. After some troubleshooting and verifying with some Google search, I have concluded that it was due to my cluster having different CPUs. I have a 3 node cluster in my home lab and 1 of the nodes has a different processor model than the other 2. The processors are of the same generation, just different speed.

Different in processors may first trigger you to think, enable EVC! Well, Enhanced vMotion Compatibility is already enabled in my cluster. So, that’s not the solution.

So, this actually requires a combination of things to make it a recurring annoyance.

1. a cluster of hosts with disparate hardware (particularly different CPU models)
2. SYSPREP is used to customize each desktop (can happen with quickprep too, but with chance of lesser occurrence)

Also, this is not unique to only virtual desktops, but can also happen to Windows Server virtual machines, just that it won’t be seen as much.

So, let me start of by explaining what is going on.

• Windows boots up and detects that there’s a change in CPU compared to the last boot
• Windows doesn’t have the driver installed (yes CPU has drivers too), installs the driver and prompts for reboot

So, simply put, if a virtual desktop was provisioned on a host with CPU model A, and in a future reboot it starts on a different host with CPU mode B, Windows will detect that change, and then install the necessary drivers and prompt for the reboot.

So, how do we avoid this?

First, have consistent hardware within the vSphere cluster. Oh look another reason to have homogeneous hardware in a cluster. With this, you don’t need to worry about it at all.

But what if we unavoidably have different CPU in the cluster? Then, we must make sure the parent desktop image has “seen” all the CPUs that exists in all the hosts which will run the clones. In other words, the following steps

1. Power up parent desktop image on host with CPU model A
2. look in device manager and ensure that CPU model A is active
3. shutdown, power off the VM and power up again, make sure Windows doesn’t prompt for a restart
4. shutdown the VM once more, and migrate it to another host with different CPU model B
5. Power up the VM and check that the other CPU model B is now active in Device Manager
6. shutdown, power off the VM and power up again to validate
7. Repeat the above until the VM has added all the different CPU models in Device Manager

To validate that the VM has captured all the CPU models, we need to invoke Device Manager to show hidden devices.

1. start a command prompt and type in the below command
2. > set devmgr_show_nonpresent_devices=1
3. > devmgmt.msc
4. In Device Manager, click View > Show hidden devices
5. Then scroll down and look for processors and expand it
6. You should see a number of processor models, and all but one have a washed out icon (indicating that the hardware is not present)
7. Check through the list to ensure all the different processors are in there

This address the first part where the parent image has become fully “aware” of all the processors in the cluster.

The next part is to do with the linked clones customisation.

For most cases, I normally recommend using Quickprep for customising linked clones. Now, there’s one more reason to use Quickprep. It doesn’t clean out non-present devices like sysprep. One of the actions done by sysprep is to clean out all non-present devices during customisation. It’s a good thing to keep the OS tidy, but this will mess up the work we just did to register all processors into Device Manager.

If your desktop pool is using sysprep for customisation, it is certainly a non-trivial task to change it to quickprep. So next comes a little registry hack to keep sysprep from purging non-present devices.

On the parent desktop image, make the following registry changes

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Sysprep\Settings\sppnp]
“DoNotCleanUpNonPresentDevices” = dword:00000001

Once done, you can do the necessary to recompose the linked clones with the new changes.

Here’s the VMware KB article that talks about this; Windows prompts for restart after being migrated via vMotion on a VDI cluster with enhanced vMotion compatibility enabled (2050139).