VDI, PVS (Provisioning Services), MCS, and Daylight Savings Time (DST)
Did you ever arrive at work just to discover a lot of your virtual desktop users are unable to log in?Well, this may occur at certain points in the year, namely those points involving daylight savings time. I encountered this with a client on Citrix XenDesktop with MCS, and another client leveraging PVS in the past.
Some users could log in and work without distractions while others were unable to even get a virtual machine assigned. After numerous attempts the login eventually worked. At this point I was notified of such instances, and noticed some interesting items in during my research. Odds are, if you were to review your event logs, you would see the log on the erroneous system illustrate that the group policy client had loaded before the Windows time Service. On the working machine this would be the other way around. So, why does the order in which services are loaded affect if a user could work with that machine? The master image of the virtual desktop machines is write protected and boots with or without DST active. Depending on when the image was last made writable. If the Windows time service kicks in before the group policy Client everything is fine as the time is updated before any communication with Active Directory happens but when the group policy client loads first the authentication fails because of the incorrect time which corrupts the Kerberos handshake, and leaves the machine in an unauthenticated state. The fix for this should be quite simple. You need to update the master image, ensure it has the valid time, then update your catalogs accordingly. If PVS is in the mix rather than MCS, than you would need to run through the following CTX article: ://support.citrix.com/article/CTX200058 I’m sure that this could be scripted, but the best method would be to plan accordingly prior to these time changes. The outcome of this potential script would depend on both windows time service and the group policy client to be loaded. When both are running, the script would then resynchronize the time and run gpupdate /force to get the Kerberos ticket recreated. The time would theoretically be correct now regardless of when the machines were last writable. In the case of PVS, vDisk maintenance would still be a factor during this time.