We have a Windows domain network with 2 Hyper-V hosts. On these hosts, there are several Hyper-V VM clients. Two of these clients are Domain Controllers.
The Hyper-V hosts are both clients of that domain. This brings one to a common time synchronization issue, as the hosts will try to sync their time with the PDC emulator and the domain controllers sync their time with the Hyper-V host.
While working on that issue, I didn't realize that the firewall in the network does not allow outgoing traffic on port 123. Which lead to several (failed) reconfiguration attempts.
Switching the time source
Once the problem was understood, I set the hosts up to sync to a reliable, on-site time source and wanted the DCs to simply use the VM IC Time Synchronization Provider again (so that they would sync the time with the host).
But one of the DCs is refusing to switch to the VM IC Time Synchronization Provider, it still uses the Local CMS Clock source (which, to my understanding, is not desirable).
What failed so far?
I tried disabling the Time Synchronization component for that VM in the Hyper-V Manager, then rebooting the machine, restarting the w32time service a couple of times, re-enabling the Time Synchronization component. That didn't work. I also tried other permutations of this process that didn't help either.
I tried changing the
Enabledvalues in the registry (HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders) for the different time providers.I re-installed the Hyper-V integration package in the client.
The best practice for time sync on Hyper-V is:
For Domain Controllers: Disable Hyper-V time sync inside the guest, but leave Hyper-V time sync enabled on the virtual machine configuration in the Hyper-V management console. This way Hyper-V sets the clock when the guest boots or resumes from a pause, but during normal operation the guest is responsible for its own clock. Use this command on the guest to stop it from using VM IC:
(For a domain controller, it is important that it be responsible for its own time sync because AD needs to know the quality of the time. If the guest is managing the clock, it has access to the quality indicator of the network time. But if Hyper-V is managing the clock, then the guest sees the clock as an authoritative clock and always assumes it's correct, even when it's not.)
For all other guests: Use the Hyper-V guest additions to sync the clock. If the guest does not have additions installed then use the hardware clock, which the Hyper-V hypervisor will emulate.
Since in your case you've monkeyed with the time sync settings on your DC guests, I suggest that you reset your w32time settings first, then reinstall the guest additions, and finally apply the registry setting above.