You’ve completed a new build of a Windows 7 master image desktop for XenDesktop 5.6 and proceed with creating the new desktop catalog and add the desktops to a desktop group. Once the desktops have been deployed, you continue by connecting a desktop in the pool but noticed that you receive the following prompt with the following message:
You must restart your computer to apply these changes
Before restarting, save any open files and close all programs.
You’ve confirmed that your master image does not prompt you for a restart but noticed the desktops in the pool always do.
This issue was new to me because throughout all of the deployments I’ve done with XenDesktop, I’ve never encountered this. The only difference between this deployment and all of the others is that this one is built on vSphere 5.1 with vCenter build 947673 and ESXi build 1065491 hosts (my previous deployments are either 4.1 or 5.0). A quick search on Google reveals the following Citrix KB:
Case Study: MCS-Created Windows 7 VDAs Display 'You must restart your computer to apply these changes' Error Message when Starting
While the environment described in this article does not directly match mine (especially because the hypervisor is Microsoft Hyper-V 2008 R2), I went ahead and tried using the instructions to see if it would correct my problem. The following are the steps I performed:
- Shutdown master image
- Add an additional disk by using an existing identity disk from another desktop in a pool
- Power on master image
- Restart the master image a few times
- Shutdown master image
- Remove identity disk
- Create a new snapshot for the master image
- Update catalog with new snapshot
The Good News:
One of the unexpected behaviors I noticed was that I did not receive a prompt asking me to restart after adding the identity disk to the master image but I can confirm that after performing these steps, the desktops in the pool no longer prompted me to restart the desktop as if it had found and installed new hardware.
The Bad News:
This was great news until I logged into the master image and noticed that the name of the master image was now the name of the desktop that owned the identity disk I used to attach to the desktop. I didn’t think too much about this being issue as I figure it probably copied the identity information from the desktop in the pool but what I noticed was that as soon as I changed the name of the master image back to the original, removed it from the domain and restarted, the radio button to join the desktop to the domain would be grayed out:
What makes it more strange is that if I change it back to the same name as the desktop that I used the identity disk and reboot, the option will be available again:
This was definitely an odd behavior and I wasn’t about to go live with such an issue. After trying various operations with the master image without any luck, I went ahead and reverted back to a snapshot prior to attaching the identity disk. Seeing how it appears adding the disk to the master image and booting it up caused Windows to assume the identity provided by the identity disk, I proceeded to try adding the disk without booting up with it. With the master image powered on, I went to the master image’s virtual machine settings and performed a hot add of the identity disk:
I continued by clicking OK to apply the changes, went to the console of the master image to confirm that identity disk shows up and then went ahead to remove the disk from the master image:
Once the disk was removed, I restarted the master image a few times, created a new snapshot then updated the desktop catalog. Once the update to the base disk was complete, I noticed that the virtual desktops in the pool no longer prompted for a restart as if new hardware was found and installed.