This message was deleted.

RUN VDA Health Check

Yes, healthy 🙂 . We have a bunch of machines that haven't been used in ages (failover DC) and these work fine when booted (they have been shut down for months). Also if I rename a machine from within PVS it succesfully registers again. Just recreating the machine account solve the domain trust relationship but the machine is still showing up as unregistered. The VDA health check says it's registered however

Are the DDCs on the VDA configuration the correct ones? https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/manage-deployment/vda-registration.html

Solved with Citrix support, the SIDs on the DDC did not match the SIDs in the AD. Recreating the machine accounts, removing VDA's from Delivery Groups and Machine Catalogs and then adding them again solves our issue. Still a DST issue since it originated when the servers were rebooted after the DST change this weekend. Now I know why it says that the DST issue has been solved in most of the cases in the Citrix KB article 🙂

You should always disable scheduled reboots so your PVS targets dont reboot when there is a DST change. Then on Monday create a new Vdisk version and run w32tm /resync before sealing and shutting down and promoting to prod and then rebooting your targets

@Michiel Roos If SID of DDC didnt match then how come VDA Health Check Tool was showing everything Healthy for you? 😉🤔

what is the best practice in Daylight Saving Time for non persistent pvs mcs vm? 🙄

This caught us by surprise since this customer did not have any problems with DST previously. The customer team supporting this customer also found the bios time in VMWare gets set to the current time after shutdown so they think this also is contributing to a loop. Just making a new image with DST and resetting machine accounts did not solve it (or maybe because the VDAs already rebooted). According to Citrix support the health check tool only checks on the VDA if the registration succeeded. So the VDA finds a DDC and reports it registered successfully but afterwards the DDC realizes that the SID does not match and does not report this back to the VDA (that's how I understood it). We have all the VDAs configured to connect to both DDCs). Disabling the reboot script and rebooting the VDAs only when there is a new image with DST changes (w32tm /resync) should have worked. Last couple of years and this year for all our customers (except this one) we did nothing special for DST.