Before I get into the actual issue and solution, let me set the stage since this is my first post (although some of the details may be irrelevant to this particular post). I’m currently working on a VDI deployment to our Brazil office running XenDesktop 7.1 (VDA version 184.108.40.20633), Storefront v2.0.17, and Netscalers (10.x in the DMZ and 9.X for the internal load balancing). The office is currently about 110 users consisting of 125 desktops or so that we’ll be taking on in our deployment. I am based out of the headquarters for our Americas region in New York/New Jersey so the Storefront, Netscalers, and DDC’s are up here in New York while the compute for the VDI desktops (blade chassis with 3 blades, 2x 10 core Intel CPUs running 512 GB of memory per blade, connected to a local storage blade) is down in Brazil. The compute for the Blade chassis will remain in Brazil for some time until we are ready to migrate their file and application infrastructure up here to NY, in which case we’ll also move the desktops here (NY) as well. I know you’re probably thinking, ??1.5 TB of memory, WHAT THE HELL? The reason for the crazy memory in the blades is because we’re leveraging an awesome technology called Atlantis ILIO (Read about it here). Without going into too many details, Atlantis ILIO allows us to run the VDI desktops essentially in memory, achieving unbelievable IOPS, as opposed to traditional spinning disk or SAN storage.
That said, in hopes of helping others with this issue, I wanted to write about an issue we encountered where the screensaver was not taking affect on the Windows 7 desktops we were provisioning. After provisioning a desktop with the XenDesktop 220.127.116.1133 VDA, we realize that the screensaver and screen lock was never kicking in that we had set via GPO (group policy). For the sake of testing, I shortened the screensaver timeout to occur every 15 seconds and launched the desktop via the VMWare console and sure enough (this became very annoying very quickly heh) the desktop was reverting to the screensaver every 15 seconds like the policy told the desktop to. My next thought was maybe somehow via some sort of magic, the policy wasn’t applying or coming down in the ICA session only (although this doesn’t really make any logical sense). So I launched the desktop and check the RSOP as well as the registry values within HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop and saw that everything was set properly:
Despite a couple hours of troubleshooting group policies, we decided to google some stuff, failed, then ultimately opened up a case with Citrix. After much troubleshooting with the Citrix engineer, we found an issue with the current version of the VDA where screen savers and the power-save option are disabled in XenDesktop sessions. The resolution was to set a particular registry key, HKLM\Software\Citrix\Graphics\SetDisplayRequiredMode = 0. This key can be set many ways, but the ultimate fix for my scenario was deploying a group policy that set this value. I used group policy preferences on the machine side to deploy the key which fixed our issue 1,2,3:
I hope this saves whoever is reading this right now some time and trouble in their deployment of XenDesktop 7.1. Feel free to comment on this post if you have any additional questions.
You can also create a .reg file with the following information and import it:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\
Citrix\Graphics] "SetDisplayRequiredMode"= dword:00000000
Special thanks to Josh Sanders @ LockStepGroup for being my moral & technical compass throughout this project. Thank you to Juan Guerra from the Citrix team in helping us find this solution. This solution has been passed along to the Citrix product management team and should be incorporated into the latest release of the 7.1.X VDA agent.
Signing out (and I hope I live up to my nick-name if you’re reading this post to solve this issue),
Tags: Xendesktop 7.1 not starting, Xendesktop screensaver not applying