Why we need a solution
Like in Belgium, lots of regions (mostly Europe and North America) use Daylight Saving Time (DST), also known as summer and wintertime. This twice a year time change can cause issues within environments where Citrix Provisioning Services (PVS) is used. Citrix has a nice article about this issue: CTX200058 – Provisioning Services and Daylight Saving Time but some extra info might be useful.
As stated in the Citrix article, the improvements Citrix made, do not tackle all the issues. If you are using startup scripts, you will still experience problems. The reason for this is that when a Target Device (TD) is started using a vDisk that is not reflecting the correct time, it needs a few moments to adapt to the new time. Before this happens, Windows already tried to apply the policies for the first time, but this failed because of a time difference with the domain controller. Not a big deal you think because group policies are applied on a regular basis (by default every 90 minutes). However startup scripts are only executed during the first policy cycle after startup. This means it “would” be executed if the first policy cycle was not failing.
So if you use a startup script to copy certain applications to the TD after startup or import AppV packages, this will cause the machine unusable after DST
Citrix recommends to not reboot the machines when DST changes until an administrator can update the vDisk. Since DST changes in the weekend this is not always easy to do. A lot of companies also have DTAP environments where such a change needs a while to be effective in production. A more DST independent solution is needed.
How to solve the issue
Like Citrix recommend, updating the vDisk after DST is the way to go, but I think I have a solution that does not require the change directly after DST and before the first reboot.
Most issues occur with the change from summer to wintertime where the first policy update is failing. Winter to summertime normally does not cause issues with startup scripts. To have a solution that never has issues with startup scripts, you can use a couple scheduled tasks as a replacement without loosing the flexibility of a startup script.
Things you need to know
The scripts you normally would start, using a startup script can still be used and don’t need to be modified
There is a difference in normal behavior depending on the time of the year
- Wintertime to summertime change
- Startup script = OK
- First GPO processing on startup = OK
- Scheduled task triggered on startup = NOK
- Scheduled task triggered on creation = OK
- Summertime to wintertime change
- Startup script = NOK
- First GPO processing on startup GPO = NOK
- Scheduled task triggered on startup = OK
- Scheduled task triggered on creation = OK
Two scheduled tasks to create
Scheduled task 1, inside the vDisk
The first scheduled task you need to create is in the vDisk itself, to force a GPUpdate on startup (this is needed for summer to wintertime transition because the first GPO processing is failing but a scheduled task on startup is working).
- Task is running as System with highest privileges
- Trigger is at system startup with 1 minute delay
- Action is gpupdate with /force as parameter
Scheduled task 2, dynamically created when target device is started
The trick with this scheduled task is to not start it at system startup (this would not work when going from winter to summertime) but when the task is created. So you need to configure the Group Policy Preference (GPP) to only apply once, otherwise the task would be triggered during every policy refresh.
When going from summer to wintertime, the previously created scheduled task that runs on startup with the GPUpdate will trigger the GPO and create the task so it will run (on creation). When going from winter to summertime, the normal group policy evaluation will create the task and causing it to start.
- Apply GPP only once
- Task is running as System with highest privileges
- Trigger is when the task is created or modified (but only once)
- Action is the script you would start using the normal startup script way
So two scheduled tasks that can be created using group policy preferences, 1 on the master image and 1 during startup on your target devices, can replace a normal startup script and work perfectly in DST situations.