A domain controller whose clock keeps sliding back to the same wrong time — no matter which NTP servers you point it at — is almost certainly being re-set by the hypervisor. The host machine's clock is the one that is fast; the guest's time-synchronization integration service periodically stamps the VM with the host's time, undoing every correction W32Time makes. The fix is to disable hypervisor time sync for that virtual machine, correct the host's own clock, and let W32Time be the sole authority on the guest clock.
Why the error keeps coming back
Two time mechanisms are fighting each other. W32Time pulls the DC to the correct time from your NTP peers, and a few minutes later the hypervisor's integration service notices the guest clock differs from the host and "corrects" it back — to a host clock that is roughly 54 seconds fast. From inside the guest it looks like the NTP configuration is broken, but the NTP side is working: your status output shows a healthy stratum, a near-zero phase offset, and no sync errors because it is sampled right after a successful correction. The drift simply reappears between samples.
Hyper-V's Time Synchronization service behaves this way by design: it applies the host clock when guest drift exceeds an internal threshold, and it always applies the host clock when the VM resumes from a paused or saved state. VMware Tools' periodic sync does the same. On ordinary workloads this is harmless; on a domain controller, where W32Time is supposed to own the clock, it causes exactly this symptom.
Confirm the host is the culprit
- On the host, compare its clock to an authoritative source:
w32tm /stripchart /computer:pool.ntp.org /samples:5 /dataonly. An offset near 54 seconds confirms the host clock is the problem. - On the guest, run
w32tm /query /source. If it reportsVM IC Time Synchronization Provider, W32Time is chained to the hypervisor instead of your NTP peers. - Check the System event log for Kernel-General event ID 1 entries showing frequent, unexplained time jumps — the fingerprint of an external agent resetting the clock.
Disable guest time synchronization
On a Hyper-V host, turn off the integration service for the domain controller:
Disable-VMIntegrationService -VMName "DC01" -Name "Time Synchronization"You can also clear the Time Synchronization checkbox under the VM's Integration Services settings in Hyper-V Manager. On VMware, untick "Synchronize guest time with host" in the Tools options (or set tools.syncTime = "FALSE" in the VMX) and review any sync-on-resume or sync-on-snapshot settings. Then force the guest back to the correct time and verify the offset:
w32tm /resync /force
w32tm /stripchart /computer:pool.ntp.org /samples:5 /dataonlyAlso fix the host itself by pointing the hypervisor at reliable NTP servers. Even with guest sync disabled, resume events and every other VM still depend on an accurate host clock.
Put the W32Time configuration right
Two details are worth correcting while you are here. First, only the PDC emulator should use manual external peers; every other domain controller should follow the domain hierarchy:
w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32timeSecond, a manual peer list must be comma-separated with no spaces. A list like "0.uk.pool.ntp.org, 1.uk.pool.ntp.org" can leave a stray comma in the parsed source name — visible as a trailing comma in w32tm /query /source. Use:
w32tm /config /manualpeerlist:"0.uk.pool.ntp.org,1.uk.pool.ntp.org,2.uk.pool.ntp.org,3.uk.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /updateThe 0x8 suffix forces client mode for each peer, and /reliable:yes is appropriate when the machine is the PDC.
Verify and prevent a recurrence
After the change, watch the offset for a few hours with w32tm /stripchart; it should stay within tens of milliseconds. A 54-second error does not break Kerberos (the default tolerance is five minutes), but it degrades log timestamps, certificate validation, and scheduled tasks, and it will only grow. Document that domain controller VMs must have hypervisor time sync disabled, audit new VMs during build, and keep the other integration services enabled and updated — only the time-sync component should be off.
Frequently Asked Questions
Does a 54-second drift break Active Directory authentication?
Not yet. Kerberos tolerates up to five minutes of skew by default, so logons keep working. The drift is still a real problem for audit trails and scheduled jobs, and it will eventually cross the Kerberos threshold if left uncorrected.
Why did every NTP server I tried behave the same way?
Because the peers were never the problem. Each resync corrected the clock, then the integration service re-applied the host's fast time on its next sample or resume, so the identical error reappeared regardless of which server you configured.
Should I disable Hyper-V time synchronization on all my VMs?
No. Standalone servers without a managed time service often benefit from host sync. The guidance is specific to domain controllers and any machine where W32Time is deliberately configured: those systems should own their clock exclusively.
I disabled the integration service but the clock is still fast. Now what?
W32Time corrects small offsets gradually and may not have caught up. Run w32tm /resync /force for an immediate correction, then confirm with a stripchart. If drift persists, look for a second time agent, such as VMware Tools, or a startup script setting the clock.
Can I just fix the host clock and leave guest sync enabled?
You can, and the guest would then receive accurate time, but periodic host-set corrections still conflict with W32Time's adjustments and can cause backward time jumps that confuse Kerberos and logging. For domain controllers, the supported design is hypervisor sync off with W32Time fully in control.