Crossposting this. For MCS-provisioned VDAs on VMw...
# _hypervisor
n
Crossposting this. For MCS-provisioned VDAs on VMware, how the hell do you get snapshots from a master image to actually retain either the Precision Clock device or this time setting? None of the provisioned VDAs have the clock, nor do they have the periodic entry checked, and we're dealing with time sync issues. This is on ESX 8.0 U2. Also seeing this if I use the VM itself as the master image.
t
Check if your ESX servers have the correct time. The VM will get the time from the hosts during power on. Once the VM is powered on it should constantly receive the time from an AD controller. If you set the marked icon vmware tools will inject the ESX times and fight against the times from the Windows Time service. https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings?tabs=config
n
Time is correct on the ESX hosts. Now I'm trying to figure out why NTP is pointed to time.windows.com in the VDAs. It's not configured via GPO, so I have no idea why it's pointed there. Domain joined devices, too.
Since it's pointed to time.windows.com, ZScaler is screwing us because it requires logging into it before it'll hit the internet. Can't login if the VM can't register because of the time skew.
j
It's possibly a timing issue. This is what I do as a good practice in every build. I also link to a Microsoft document in this post that verifies it too: https://www.jhouseconsulting.com/2019/05/16/best-practice-for-the-windows-time-w32time-service-for-rdsh-and-vdi-workloads-1948
time.windows.com is the default Windows time setting in every Windows OS, but it's not used if it's Domain Joined.
n
That's why I think there's an issue with the DC, because it's reverting to time.windows.com, which is the default behavior when there are problems.