Clock drift on virtualized domain controllers

Question

Virtualized Domain Controllers

Clock drift occurring within the guest operating system

Windows Time Service (w32time)

w32time enters a spike state and refuses to adjust system time

The time offset exceeds the configured MaxAllowedPhaseOffset threshold

How can we reset the phase offset limits and force a proper time synchronization on these controllers ?

Answer 1

First reset the Windows Time Service configuration and clear the condition that is causing W32Time to remain in a spike state. On the affected DC, run an elevated Command Prompt and execute: w32tm /config /update /manualpeerlist:"" /syncfromflags:DOMHIER. Then restart the service with net stop w32time followed by net start w32time.

Next, force the controller to rediscover the domain time hierarchy and synchronize: w32tm /resync /rediscover. If it reports that the computer did not resync because no time data was available, check w32tm /query /source and w32tm /query /status to verify that the DC is using the expected domain time source. On a domain controller, you generally want the PDC Emulator to obtain time from a reliable external source, while the other DCs synchronize through the domain hierarchy.

If the large offset is causing W32Time to reject the correction, you can temporarily increase the allowed phase offset rather than permanently changing the domain's normal time behavior. The relevant registry value is MaxAllowedPhaseOffset under HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config - it is measured in seconds. After changing it, restart W32Time and run w32tm /resync /rediscover. Once synchronization succeeds, return the value to your normal policy/configuration rather than leaving an excessively large threshold in place.

For virtualized DCs check the hypervisor's time synchronization integration. The domain time hierarchy should be authoritative for the guest, and you should avoid having both the hypervisor integration service and W32Time independently correcting the DC's clock. For a PDC Emulator in particular, establish a reliable external NTP source and let the remaining domain controllers and domain members follow the AD time hierarchy. Finally, verify the result with w32tm /query /status and w32tm /query /source - repeatedly large offsets usually indicate an underlying VM pause/resume, hypervisor time-sync, host clock, or virtualization configuration problem rather than simply a W32Time threshold issue.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 2

For virtualized domain controllers, first stop host-to-guest time sync, then return the DCs to normal domain hierarchy synchronization, and finally force W32Time to rebuild and resync if the clock remains stuck.

1. Disable Hyper-V host time synchronization for each virtualized domain controller:
   • Open Hyper-V Manager
   • Select the VM, then Settings
   • Open Integration services
   • Clear Time Synchronization
   • Restart the server
   This is required because a domain controller should use the Windows Time Service domain hierarchy, not both the host clock and domain time sources.
2. Reconfigure the DC to sync from the domain hierarchy:

      w32tm /config /syncfromflags:domhier /update
      net stop w32time
      net start w32time
   

3. If W32Time is stuck because of bad state or phase-offset handling, clear and rebuild the W32Time registration, then force a resync:

      net stop w32time
      w32tm.exe /unregister
      w32tm.exe /register
      net start w32time
      w32tm.exe /resync /force
   

4. Check the current configuration and status:

      w32tm /query /configuration
      w32tm /query /status /verbose
   

   w32tm /query /status /verbose shows values such as the poll interval and clock rate, which are used when W32Time decides whether to slew the clock or set it directly.
5. Review the phase-offset thresholds if large offsets are being rejected:
   • MaxAllowedPhaseOffset controls the maximum offset, in seconds, for which W32Time adjusts the clock gradually. If the offset exceeds this value, W32Time sets the clock directly.
   • MaxPosPhaseCorrection and MaxNegPhaseCorrection control the largest positive and negative corrections the service accepts. If a required correction exceeds those values, the service can log an event instead of correcting time.
   • Default values differ by role:
     • MaxAllowedPhaseOffset: 300 seconds for domain members
     • MaxPosPhaseCorrection and MaxNegPhaseCorrection: 172,800 seconds for domain controllers

Important: changing W32Time registry values is a registry operation and can cause time-sync instability if set incorrectly. Back up the registry before modifying these settings.

If the issue is specifically event IDs 24, 29, and 38 on a virtualized DC, disabling Hyper-V Time Synchronization and letting the DC use the default W32Time domain hierarchy is the documented resolution.

---

References:

• You receive Windows Time Service event IDs 24, 29, and 38 on a virtualized domain controller
• Windows Time service tools and settings
• Windows computer clock resets to a previous date and time
• How to configure the Windows Time service against a large time offset