Jump To: Support > KB > Citrix > PVS > DST

Clock out by an hour and GPOs not applying - Daylight Savings Time (especially with AppLayering)

When the clocks change in Autumn and Spring, provisioned machines will be an hour out when they first start when booted from a vDisk which was created before the clocks changed. After the Autumn clock change (back by an hour), the clock will be an hour slow. After a few seconds, the clock will adjust itself from the domain, but this hour's discrepency at boot time will stop Group Policies (GPOs) from initially applying. After the clock has adjusted, GPOs will apply at the next refresh, but this could take up to 90 minutes.

PC hardware has a Real-Time Clock (RTC). The issue is that Windows uses local time for the RTC (most other operating systems such as Linux and NetBSD use UTC for the RTC and then just adjust it for the current time zone to avoid this problem entirely). This means that Windows has to alter the RTC when the clocks change.

The Windows registry contains the current offset from UTC. When it boots, it checks to see what offset is currently active in the registry and, if the date has passed for the clock change, it will adjust the offset in the regisry and adjust the RTC accordingly. On a non-provisioned PC, this means the clock will be correct and when the computer is next rebooted, the offset in the registry will show the clock change has been applied already so it will not happen again. On a provisioned PC, the registry change is lost on a reboot and so it will keep adjusting the clock. In Autumn, this means the clock will be an hour slow when first booted. If you reboot quickly before the clock is adjusted from the domain, it will go back by yet another hour (and you can repeatedly reboot to make it go even further back).

In the registry, the offset is held in the ActiveTimeBias value in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

When at GMT (over the winter) ActiveTimeBias will be set to 0x00000000. When BST is in effect over the summer, ActiveTimeBias will be set to 0xffffffc4 (which is hexadecimal for -60).

To fix the time offset at boot, this registry value will need adjusting. There are multiple ways to do this:

1. Add a new maintenance version to your vDisk and boot once on the relevant hardware before shutting down. Promote and replicate the new version - this was write back the adjusted version of ActiveTimeBias once the time has been adjusted
2. Mount the vDisk within the PVS console, load the Windows\System32\config\SYSTEM hive from the vDisk drive into the registry editor and adjust the ActiveTimeBias value in ControlSet001\Control\TimeZoneInformation - you can only do this if the vDisk is not in use at all
3. If using AppLayering, in theory you can create a new version of the OS layer and check the time offset is correct in that before finalizing and re-publishing your vDisks. Unfortunately, settings in the platform layer have the highest priority, so if you have ActiveTimeBias set in your platform layer, it does not matter what you do in the OS layer