Daylight saving

[Morten Norgaard1709152422]

Daylight saving

Acording to this there are no daylight saving issues with PVS server 6.x and above. http://support.citrix.com/article/CTX123336

We are running version 6.1.16.1204. and are still having the problem.

What can we do to ensure this will not happen again?

[Carl Fallis]

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:

 

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BnDevice\Parameters

 

DisableTimeZone DWORD 0

 

(Sorry forgot to add Parameters to the registry path)

[shocko]

Looks like a Citrix issue not an MS one:

 

• http://support.citrix.com/article/CTX200188

 

They have published this in relation to the issues outlined here on the forums. 

[Arnstein Sondrol]

We had the same Issue today. Had to update the vDisk. Running PVS 6.1 with the latest patches.

[Peter Ansink]

We have the same issue here. We use PVS 6.1 and policies where not applying because of the time difference. After testing with an updated Vdisk according to CTX123336 problems where gone.

[Olivier Patiny1709152744]

Hello,

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

[Morten Norgaard1709152422]

Hi all

We are using XenServer 6.2 as the hypervisor and are only streaming XenApp 6.5 servers.

How about You?

best regards

Morten

[Olivier Patiny1709152744]

Hi,

We're using ESX 5.0 and we're streaming only XENAPP 6.5 servers.
The NTP server is the Domain Controler but it seems that the time synchro is occuring too late in the boot process.
I am wondering if I have to check the "Time Synchronization between the virtual machine and the ESX server'" option in the VMWare Tools.

Regards

[Peter Ansink]

Esx 5.0 Update 2 with Xendesktop 5.6

[Carl Fallis]

Are targets running The same version of PVS and have you rebooted the targets not that you should have to reboot them?

Edited by: Carl Fallis on Oct 30, 2013 3:20 PM

[Morten Norgaard1709152422]

Hi Carl

In our case, the target is the same version as the PVS.

Yes. The servers were rebooted. Actually, the problem did only show after a reboot. The targets did run for almost 24 hours after daylight saving without problems. Then rebooted and got wrong time.

best regards

Morten

[Peter Ansink]

We are using Xendesktop and yes the desktops where rebooted. The agent in the desktops is the version 6.1 agent.

The problem is at the moment solved because we have updated the image, but in half a year we will problably have the same issue.

[Carl Fallis]

So are you all running on Xenserver?

[David Morris]

We also had this issue. We are running:

XS 6.2 HF4
PVS 6.1.17 on server and clients
XD 5.6
XA 6.5 RU1

It looks like our XenApp desktop users were fine, just eh XD5.6 users were in trouble.

We opened the image up, let it update and closed it again and it all was fine.

[Morten Norgaard1709152422]

I did ask that question a couple of days ago.

It´s a mix of XenServer 6.2 and ESX 5 as far as I can see.

[Olivier Patiny1709152744]

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

[Carl Fallis]

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

[Peter Ansink]

Our guests on the ESX environment are getting their time from the domain not from the host. But even in that case our hosts are off max 1 minute from the domain time (i believe they have the same time source) which should not be a problem for kerberos.

[Carl Fallis]

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!

[RON KROGEL]

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.

[Carl Fallis]

We do rely on the OS to do the right thing, we just try to make sure that the settings are consistant.

[Morten Norgaard1709152422]

Our XS´ are getting time from NTP. They all had the right time when the problem occurred.

[Matthew Francis1709152434]

Issue has been seen using PVS 7.x and XS 6.2.0 at this time. Forcing a update of the time in the VM using the w32tm commands is reported work around at this time. http://support.citrix.com/article/CTX123336

[Audun Skogheim Jensen]

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.

Symptom:
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?

[William Fulmer]

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 - 6.1.16.1204 - 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

[Magnus Söderberg]

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