Sometimes, a routine helpdesk ticket turns into a full-scale infrastructure investigation. It started with a standard user complaint: the clock on their Windows workstation was drifting, being almost a full day behind.
Usually, in situations like this, I rely on my standard routine to reset the Windows Time Service (0x80070426). I connected to the problematic PC, unregistered and registered the w32time service, started it, and ran the final command:
C:\Windows\system32>w32tm /resync /rediscover Sending resync command to local computer The computer did not resync because no time data was available.
(Restarting the service didn’t help. The PC was essentially saying it had no one in the network to ask for the correct time.)
Diagnosing the Client
To understand why the client went blind to the network time, I checked the current status:
C:\Windows\system32>w32tm /query /status Leap Indicator: 3 (not synchronized) Stratum: 0 (unspecified) Precision: -23 (119.209ns per tick) Root Delay: 0.0000000s Root Dispersion: 0.0000000s ReferenceId: 0x00000000 (unspecified) Last Successful Sync Time: unspecified Source: Local CMOS Clock Poll Interval: 10 (1024s)
The machine had given up on finding a network source and reverted to its internal motherboard battery clock. But why? I checked the registry to ensure it was configured to look for a Domain Controller:
C:\Windows\system32>reg query HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters /v Type Type REG_SZ NT5DS
The registry was perfectly fine (NT5DS means it follows the domain hierarchy). This meant the problem wasn’t on the workstation, it was on our servers.
Investigating the Domain Controllers
I needed to check the health of the time hierarchy across the domain. Running the monitor command gave me the full, alarming picture:
PS C:\Users\admin> w32tm /monitor
DC-01.domain.local[10.0.0.11:123]:
ICMP: 2ms delay
NTP: +192.7385688s offset from DC-PDC.domain.local
RefID: (unspecified / unsynchronized) [0x00000000]
Stratum: 0
DC-02.domain.local[10.0.0.12:123]:
ICMP: 1ms delay
NTP: -234.0943929s offset from DC-PDC.domain.local
RefID: (unspecified / unsynchronized) [0x00000000]
Stratum: 0
DC-PDC.domain.local *** PDC *** [10.0.0.10:123]:
ICMP: 4ms delay
NTP: +0.0000000s offset from ntp.domain.server
RefID: 'NTP' [0x50544E]
Stratum: 3
Warning:
Reverse name resolution is best effort. It may not be
correct since RefID field in time packets differs across
NTP implementations and may not be using IP addresses.
Analyzing the breakdown:
- DC-01 and DC-02: Both show Stratum: 0. In the NTP world, Stratum 0 means the server is unsynchronized and is not a valid time source. Clients will ignore these servers entirely.
- The PDC Emulator: While it shows Stratum 3, the secondary DCs (DC-01/02) have such a massive offset (+192s and -234s) that they’ve stopped trusting it.
- The Cascade Failure: Because the DCs returned errors or Stratum 0, the workstation we started with had no choice but to revert to its
Local CMOS Clock.
To see how bad the drift was, I ran a stripchart against our internal NTP server from the different DCs. The environment was completely chaotic:
On the first Domain Controller (DC-01): C:\Windows\system32>w32tm /stripchart /computer:ntp.domain.com /dataonly /samples:5 Tracking ntp.domain.com. Collecting 5 samples. The current time is 19.03.2026 14:26:03. 14:26:03, -93.7916077s 14:26:05, -93.7916630s 14:26:07, -93.7907250s 14:26:09, -93.7917642s 14:26:11, -93.7916249s On the second Domain Controller (DC-02): C:\Windows\system32>w32tm /stripchart /computer:ntp.domain.com /dataonly /samples:5 Tracking ntp.domain.com. Collecting 5 samples. The current time is 19.03.2026 14:21:15. 14:21:15, +98.9773148s 14:21:17, +98.9772527s 14:21:19, +98.9772680s 14:21:21, +98.9774052s 14:21:23, +98.9773600s
At this point, the diagnosis was complete. The domain hierarchy had completely collapsed. The PDC Emulator was isolated, and the secondary DCs had “detached” themselves, leaving all workstations (including the one that started this ticket) stuck on their own Local CMOS Clocks.
Fixing the PDC Emulator
In an Active Directory environment, the PDC Emulator is the “Source of Truth.” I configured the PDC to strictly use our internal NTP server and declare itself as a reliable source:
C:\Windows\system32>w32tm /config /manualpeerlist:"ntp.domain.com,0x8" /syncfromflags:manual /reliable:YES /update The command completed successfully.
Even though the command was successful, the PDC refused to sync. The time was still lagging by nearly 100 seconds. Why? Because by default, if the time drift is too large, the Windows Time service ignores the external source to prevent system instability.
To break this deadlock, I had to manually set the system time on the PDC to within a few seconds of the actual time. Once the offset was “reasonable,” I ran the resync command again:
C:\Windows\system32>w32tm /resync /rediscover Sending resync command to local computer The command completed successfully.
Even after the successful resync, the time didn’t become perfect instantly. I ran a continuous stripchart and watched the PDC slowly “catch up” with the NTP server, closing the gap by about 1-2 seconds per sample:
C:\Windows\system32>w32tm /stripchart /computer:ntp.domain.com /dataonly /samples:999 14:37:26, +38.4877643s 14:37:28, +36.4536812s 14:37:31, +34.4201367s ... [5-10 minutes later] ... 14:45:12, +00.0014251s
Restoring the Secondary DCs
With the PDC finally on the move, I headed to the other Domain Controllers. I didn’t want to wait for them to figure it out on their own, so I forced a resync on each one:
C:\Windows\system32>w32tm /resync /rediscover
The secondary DCs followed the same “slewing” behavior. They recognized the PDC as a reliable source but adjusted their clocks gradually. It took about 10 minutes for the entire environment to stabilize.
I monitored the progress with w32tm /monitor until all offsets were back to near-zero:
PS C:\Users\admin> w32tm /monitor DC-01.domain.local: NTP: +0.0012451s offset from DC-PDC.domain.local DC-02.domain.local: NTP: -0.0021458s offset from DC-PDC.domain.local DC-PDC.domain.local *** PDC ***: NTP: +0.0004512s offset from ntp.domain.com
Once the DCs were healthy, I went back to the original workstation. A simple w32tm /resync there worked instantly.
The Virtualization Trap
If your Domain Controllers are running as Virtual Machines, there is a silent killer of NTP synchronization: Host Time Integration.
By default, both VMware and Hyper-V have features designed to synchronize the Guest OS clock with the Physical Host clock. In a standard environment, this is helpful. In an Active Directory environment, it is a disaster.
Windows Time Service (w32time) expects to have one “Source of Truth” (the NTP hierarchy). When the hypervisor suddenly “injects” its own hardware clock time into the VM during runtime, it creates a conflict. The DC sees a sudden jump, compares it with the PDC, gets confused, loses trust, and drops to Stratum 0.
To prevent this from happening, you must stop the hypervisor from interfering with the runtime clock. However, the method depends entirely on your hypervisor.
For VMware:
The standard approach is to disable the sync via the GUI:
- Right-click the DC VM -> Edit Settings.
- Go to VM Options tab -> VMware Tools.
- Uncheck “Synchronize guest time with host”.
For Hyper-V:
(Update: A big thank you to System Administrator BlackV from the r/SysAdminBlogs community for highlighting a critical engineering detail regarding Hyper-V time sync mechanics, referencing this classic Microsoft engineering post).
If you simply uncheck “Time synchronization” in the Hyper-V Integration Services GUI, you create a new trap. If the DC reboots or resumes from a saved state after a long downtime, it will wake up with its outdated “virtual BIOS” time. This massive time gap will immediately break Kerberos authentication before w32time even gets a chance to reach the PDC and correct it.
The recommended approach is to leave the GUI setting ON so the VM gets the absolutely correct time at boot, but disable the integration provider inside the guest OS registry so it stops interfering during runtime.
Step 1: Ensure “Time synchronization” is checked in the Hyper-V VM Settings (Integration Services).
Step 2: Run the following sequence in an elevated command prompt on the virtual DC:
PowerShell
# 1. Disable the Hyper-V time provider in the registry reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t REG_DWORD /d 0 /f # 2. Force the DC to look for the domain hierarchy (PDC) w32tm /config /syncfromflags:DOMHIER /update # 3. Restart the Time Service net stop w32time && net start w32time # 4. Force an immediate resync w32tm /resync /force
What this does:
- Registry Edit: Stops the VM from listening to the host clock while the OS is running.
- DOMHIER: Explicitly tells this DC to trust the Active Directory hierarchy (the PDC) as its primary source.
- Resync /force: Tells the system to stop “slewing” and immediately align its clock with the correct time.
Infrastructure Engineer with hands-on experience in Windows Server, Active Directory, SCCM, Exchange, and Linux environments. Concentrated on resolving production issues and keeping systems stable and reliable.