Jump to content
Welcome to our new Citrix community!
  • 0

Daylight saving

Morten Norgaard1709152422


Recommended Posts

  • 1

Starting with PVS 6.1.21 and 7.1.3 the target will retrieve the time zone information from the PVS server (which also has to be at the same version ) and set the target to the time zone of the PVS server.  It will then perform a  w32tm /resync /nowait.  The vdisk image must be configured properly for w32tm to work properly, refer to http://technet.microsoft.com/en-us/library/w32tm.aspx on how configure w32tm.


You can disable this if you do not want the targets to set the time zone by setting the following registry key:




DisableTimeZone DWORD 0


(Sorry forgot to add Parameters to the registry path)

  • Like 3
Link to comment
  • 0


I has exactly the same problem. Also using PVS6.1.
The first indication was a licensing issue : The licenses required by this edition of Citrix XenApp are not present on the license server
But I figured out that it was not a licensing issue but the Daylight Saving change of this WE : Kerberos error, Group policy error, etc...

Is there another way to fix this than updating the Master Image ?

Thanks in advance

Link to comment
  • 0

I am running on ESX 5.0. I am using PVS 6.1 and streaming XA6.5 servers.

One more strange thing since this Daylight Saving : I have a policy that sets the XENAPP PRODUCT MODEL.
It was set to XENDESKTOP USER DEVICE and all the servers were OK
Since this Daylight Saving change, the servers report an error message : "The licenses required by this edition of Citrix XenApp are not present on the license server "
If I change the XENAPP PRODUCT MODEL to XENAPP, all is fine
A GPUDATE /FORCE and a restart of the IMA service does not fix the problem.

On the other hand, if I update the image with the correct time, then I can use the initial policy with the XENAPP PRODUCT MODEL set to XENDESKTOP USER DEVICE

Link to comment
  • 0

I just noticed the ESX 5.0, this is the only ESX issue we have seen, there are a number of XS cases. The main thing I want to know is what does the ESX server and XS machines have for a time, the guests do get the time from the hosts and if they are off then the guests are off.

If the times are off between the server and the target then policies probably will not get applied.

Edited by: Carl Fallis on Oct 31, 2013 9:12 AM

Link to comment
  • 0

So I am trying to find out the environmental issues that could be causing this, our code sets the daylight savings time Bias of the PVS server it has booted from. That should take care of it if the OS you are using is upto date with the latest Daylight settings information, you can get the updates from Microsoft at http://support.microsoft.com/gp/cp_dst along with the latest news.

So can I get an idea of what could be causing this issue, there are a lot of factors that could cause an issue:

OS you are running on the targets

Are they physcal or virtual and it appears these are all virtual so wo what hypervisor, so far ESX 5.0 and XS have been reported here but we have only had XS cases

Is a NTP sever being used

what ever you can tell me to help me out here I would appreciate it!

Link to comment
  • 0

As far as I am concerned daylight savings time is a Microsoft problem a bit more then a Citrix one. But in PVS it does affect me since we use a lot of policies in AD. The provisioned server comes up and tries to run poliices but fail due to time not being in sync yet. Policies don't fire and some apps do not work. I get around this by doing a maintenance disk twice a year for my vDisks, I watch the time change and promote the disk to production so the registry offset is already correct and my policies fire at boot. All servers that are up change time and those that are booting on schedule go to the newer version with the right time offset. This is a pain but works for me. I think in a perfect world a server booting would sync time in AD _before_ trying to fire policies. Good luck with getting that fixed by Microsoft. I have seen where Citrix hotfixes are also supposed to address this but to me part of this is the Microsoft OS design.

  • Like 1
Link to comment
  • 0

Im also having the same problem with PVS 6.1 hotfix 18, with target devices running on Xenserver 6.02 hotfix 026, and with PVS 7.0 with target devices running on Xenserver 6.2 with hotfix 004.

I've been doing some troubleshooting, and to me it looks like the solution to the DST problem is simply to disable Automatic adjustment of DST in the vDisk.

1. vDisk is produced in "summer time", mid october,and everything was smooth
2. October 27th, DST kicked in, everything is OK untill target devices reboot
3. Domain authentication and GPO fail to run during boot because system time is one hour off. 3 minutes after GPO fails to run, NTP syncs the system time, and domain authentication works again. 60min later GPO is triggered again (gpo runs default every 60 or 90 min?), and target device is production ready.
4. Target device reboots again, and target device system time is 1 hour off again. Happends indefinately untill vDisk is opened in private mode, and DST "winter time" is written to the vDisk.

Xenserver VM timeoffset parameter.
1. When the Xenserver VM is in prodcution, and system time is NTP synced, timeoffset: 3601
2. When the Xenserver VM is booting up Windows and GPO fails to run, timeoffset: 1 <-- Windows DST setting ******* up?
3. When the Xenserver VM has NTP synced the clock after startup: timeoffset: 3601

Im concluding the target device is getting the correct system time from the Xenserver host during boot, but the Windows vDisk insist on summer time, so it messes up the system time, untill Windows resync the clock with the domain controller/NTP. So why have Automatic DST enabled at all? If your domain controller (which i presume is not a PVS target device) has Automatic DST adjustment, your target devices will get synced using NTP. The Xenserver system time (which also should be NTP synced) and VM timeoffset setting will ensure you get the correct system time regardless of DST.

Any thoughts?

Link to comment
  • 0

Same issue here at one of our clients.

Many clients with PVS 6 no issue.
This one

XenDesktop 5.6 fp1
PVS 6.1
Server - - Hotfix 16
Target Device - 6.1.1082 Hotfix 001
Hypervisor - VMware vSphere 5.1u1

Using standard domain time services, nothing configured.
Installation of Workstation Agent using silent command line and no controller specified.
Controllers defined in GPO and due to time skew, GP not applying, thus machines in an unregistered state.

vDisk has been updated as of this morning with manual time sync.

Going to look into computer startup script to run command until we can assure this is truly fixed.
w32tm /config /update; w32tm /resync

Link to comment
  • 0

Hi. We have the same environment an and I talked to one of our Vsphere guys. He sad that even if the ESX servers had the right time the actual virtual machine can take up to an hour before it gets the right time. So
I checked one machine that did not worked in bios and the time was wrong. I changed it manually restarted and everything worked. So until a solution is made we do it like this.

Open up the image and let it registrar the new time.

power on all machines (VDI) for an hour so the time is set in bios.

After that everything works fine

So the only thing to do is to mark your calendar and do it

Regards Magnus

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...