Why is my Windows clock not syncing?

On a domain-joined machine the cause is almost always the Active Directory time hierarchy, not a bad NTP server. Members sync from a domain controller, DCs from the PDC emulator, and the forest-root PDC emulator from an external source. If any link in that chain is broken — a misconfigured PDC, a DC that lost contact, or a member wrongly set to an external NTP server — the clock drifts. Run 'w32tm /query /status' and 'w32tm /query /configuration' to see which link failed. On a standalone machine, check that the Windows Time service is running and that outbound UDP 123 is open.

What does w32tm /query /status show?

It prints the live sync state: Leap Indicator, Stratum (1-15 valid, 0 means unspecified/unsynchronized in W32Time output), Precision, Root Delay, Root Dispersion, ReferenceId (the source the clock is locked to), Last Successful Sync Time, Source, and Poll Interval. A healthy member shows a Source pointing at a domain controller and a recent Last Successful Sync Time. A stale Last Successful Sync Time, or Source 'Local CMOS Clock' / 'Free-running System Clock', means the machine is not actually synchronized.

How do I set the PDC emulator time source?

Only the PDC emulator of the forest-root domain should point to an external source. Configure it with 'w32tm /config /manualpeerlist:"ntp1 ntp2 ntp3" /syncfromflags:manual /reliable:yes /update', then restart the Windows Time service. /reliable:yes marks it as a reliable time source for the domain. Every other DC and every member should stay on the default NT5DS (domain hierarchy) type, not a manual peer list.

Why does w32tm /resync say no time data was available?

'The computer did not resync because no time data was available' means the time provider could not get a usable sample. Three usual causes: (1) the configured source is unreachable — UDP 123 blocked by a firewall, or DNS failed to resolve the peer; (2) the machine is set to NT5DS but cannot reach a domain controller; (3) the source replied but was rejected as out of tolerance. Check the source with 'w32tm /stripchart /computer: /samples:5 /dataonly', verify port 123, and look at the System event log for W32Time errors.

Can Windows Time reach 1 millisecond accuracy?

On Windows Server 2016 and later, Microsoft supports 1 ms accuracy, but only under tight conditions: a short, low-latency path to the time source, a shallow stratum, few network hops, and the high-accuracy registry tuning applied. Out of the box, default domain time is bounded by the Kerberos 5-minute skew rather than a tight SLA; 50 ms and 1 ms are documented high-accuracy targets on Windows Server 2016+ that require deliberate engineering. Pre-2016 operating systems have no sub-second guarantee at all.

Windows Time Troubleshooting | Fix W32Time, PDC Emulator & AD Sync

1. Why Windows time is different from a Linux daemon

Three differences trip up admins who come from chrony/ntpd:

W32Time is not an NTP daemon by default. On a domain member it runs as the NT5DS provider, following the domain hierarchy, not a server list you chose. It speaks the NTP wire protocol but its policy is Active Directory.
Time has a security role. Kerberos rejects authentication when the client and server clocks differ by more than the allowed skew — 5 minutes by default (MaxClockSkew). A drifting clock does not just mis-stamp logs; it locks users out.
There is a designated source of truth. The PDC emulator of the forest-root domain is the authoritative clock for the entire forest. Everything else chains back to it.

2. Decode `w32tm /query /status` field by field

> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0312500s
Root Dispersion: 7.7902343s
ReferenceId: 0xC0A80001 (source IP:  192.168.0.1)
Last Successful Sync Time: 6/19/2026 9:14:02 AM
Source: dc01.corp.example.com
Poll Interval: 10 (1024s)

Field	What it tells you
`Leap Indicator`	Leap-second warning state. `0(no warning)` is normal; `3(not synchronized)` means the clock is unsynchronized — a red flag.
`Stratum`	Distance from the reference clock. A member is typically stratum 3–5. Stratum `0` in W32Time output means unspecified/unsynchronized — the machine has no source.
`Precision`	Clock resolution as a power of two seconds. Informational; not a fault signal on its own.
`Root Delay` / `Root Dispersion`	Round-trip delay to, and accumulated error bound from, the root reference. A large, growing Root Dispersion signals a degrading or lost source.
`ReferenceId`	The source the clock is locked to, as an IP or a 4-char code. `LOCL` / `0x4C4F434C` ("Local CMOS Clock") means it gave up and is free-running.
`Last Successful Sync Time`	The single most useful field. If it is hours or days old, the machine is not currently synchronized, whatever the config says.
`Source`	Who it is syncing from. Should be a DC (on a member) or your external NTP (on the PDC emulator). `Free-running System Clock` or `Local CMOS Clock` = not synced.
`Poll Interval`	Seconds between polls (shown as a power of two). On NT5DS this is managed; a stuck small value can indicate repeated re-sync attempts.

3. Decode `/query /configuration` — Type and flags

w32tm /query /status tells you the live state; /query /configuration tells you the intended policy. The decisive field is Type:

Type	Meaning
`NT5DS`	Follow the Active Directory domain hierarchy. Correct for every domain member and every DC except the forest-root PDC emulator.
`NTP`	Use the explicit `NtpServer` manual peer list. Correct for the forest-root PDC emulator, and for standalone (non-domain) machines.
`NoSync`	The service runs but never synchronizes. Almost always wrong unless deliberate.
`AllSync`	Use all available providers (NTP and domain hierarchy). Rare; usually a sign of confusion.

The NtpServer entry carries per-peer flags appended as ,0x…. They combine bitwise:

Flag	Name	Effect
`0x01`	SpecialInterval	Poll at the fixed `SpecialPollInterval` instead of the adaptive interval.
`0x02`	UseAsFallbackOnly	Only use this peer if the others fail.
`0x04`	SymmetricActive	Use NTP symmetric active mode (peer, not client).
`0x08`	Client	Use NTP client mode — the normal value for an upstream server.

A typical PDC emulator line reads time.nist.gov,0x9 — that is 0x08 (client) + 0x01 (special interval): client mode, fixed poll.

4. The Active Directory time hierarchy & PDC emulator

This is the model that explains 80% of "domain time is wrong" tickets. Time flows down a fixed chain:

   ┌─────────────────────────────────────────────┐
   │  External UTC source (GNSS / NTP / NTS)       │
   └───────────────────┬───────────────────────────┘
                       │  Type=NTP, /reliable:yes
                       ▼
   ┌─────────────────────────────────────────────┐
   │  PDC emulator — FOREST ROOT domain            │  ← the one authoritative clock
   └───────────────────┬───────────────────────────┘
                       │  domain hierarchy (NT5DS)
                       ▼
   ┌─────────────────────────────────────────────┐
   │  PDC emulator — each child domain             │
   └───────────────────┬───────────────────────────┘
                       │  NT5DS
                       ▼
   ┌─────────────────────────────────────────────┐
   │  Other domain controllers                     │
   └───────────────────┬───────────────────────────┘
                       │  NT5DS
                       ▼
   ┌─────────────────────────────────────────────┐
   │  Member servers & workstations                │
   └─────────────────────────────────────────────┘

The golden rule. Configure an external source on the forest-root PDC emulator only. Every other machine — including other DCs — must stay NT5DS. Pointing a random member or a child-domain DC at an external NTP server is the most common self-inflicted cause of domain time chaos. /reliable:yes is only meaningful on a domain controller; setting it on a member does nothing useful.

5. Diagnose by symptom (decision tree)

Symptom	Most likely cause	Where to go
"No time data was available" on resync	Source unreachable, or member can't reach a DC	§9 stripchart + firewall / port 123
One member drifting, rest fine	Member wrongly set to `NTP` type or pointing externally	§3 — reset to NT5DS (§8)
Whole domain wrong by the same offset	Forest-root PDC emulator source is wrong or unreachable	§4 + §8 PDC fix
Source shows `Local CMOS Clock`, stratum 0	No usable source at all — unsynchronized	stratum 16 / no-sync diagnosis
Time jumps, recovers, jumps again (VM)	Hypervisor host-sync fighting W32Time	§5 VM note below

The VM trap (Hyper-V & friends). A Windows guest under Hyper-V gets time from the Hyper-V Time Synchronization integration service and from W32Time — two authorities fighting. On a domain controller running as a Hyper-V guest this is especially toxic. Disable the "Time synchronization" integration service for DCs, leaving W32Time as the sole authority. Proxmox/KVM guests can see the same effect from kvm-clock — keep one time authority, not two. The same conflict on Linux guests is covered in the VM & hypervisor gotchas.

6. The accuracy you can actually expect

Set expectations honestly before promising an SLA. Microsoft's supported bounds:

Target	Condition
~1 second	The rough working tolerance of a default domain — a practical expectation, not a guaranteed SLA. Out of the box, domain time is bounded by the Kerberos 5-minute skew, not a tight one-second contract.
50 ms	A documented high-accuracy target (Windows Server 2016+) with reasonable network conditions and the Windows Time service correctly configured.
1 ms	Windows Server 2016 or later only, and only with a short low-latency path to the source, a shallow stratum, few network hops, and the high-accuracy registry tuning applied.

7. W32Time Event IDs decoder

From the System event log, source Time-Service (W32Time). The ones worth memorising:

Event	Typical meaning
`12`	Time Provider NtpClient: the machine is configured to use the domain hierarchy. On a forest-root PDC emulator this is the prompt to configure a reliable external source instead. Informational/warning, not a fault on a normal member.
`29`	NtpClient has no source of accurate time and could not reach a manually configured peer. Common after a misconfigured manual peer list.
`36`	Too much time has passed since the last successful sync; the clock is no longer reliable.
`47`	No valid response from a manually configured peer — it is not answering usably on UDP 123.
`50`	Time difference too large to correct, or loss of sync — W32Time stopped correcting.
`129`	NtpClient could not reach a domain peer / domain-hierarchy discovery error — the NT5DS chain is broken.
`134`	NtpClient could not reach a manually configured peer because of a DNS resolution failure — very common, and easy to miss: the peer name doesn't resolve.

8. Fix recipes (AD-specific)

For the full syntax of each command, see the w32tm command reference. These are the AD-specific procedures:

Reset a member wrongly set to external NTP → back to NT5DS

> w32tm /config /syncfromflags:domhier /update
> net stop w32time && net start w32time
> w32tm /resync /force

Configure the forest-root PDC emulator (the only external source)

> w32tm /config /manualpeerlist:"time.cloudflare.com,0x8 ntp.rdem-systems.com,0x8" ^
        /syncfromflags:manual /reliable:yes /update
> net stop w32time && net start w32time
> w32tm /resync /force

Full reset when the configuration is corrupted

:: Unregister and re-register the service, then reconfigure
> net stop w32time
> w32tm /unregister
> w32tm /register
> net start w32time
> w32tm /resync /force

Don't permanently widen the correction limits (MaxPosPhaseCorrection / MaxNegPhaseCorrection) just to force a stubborn machine into sync. A clock that is hours off should refuse to slam — that protects you from a compromised or faulty source. Fix the source, not the safety limit.

9. Verify the fix

Measure the offset to the intended source directly — don't trust the config alone:

:: Compare this machine's clock against its source, 5 samples
> w32tm /stripchart /computer:dc01.corp.example.com /samples:5 /dataonly

A healthy result shows small, stable offsets (tens of milliseconds on a LAN). Then confirm the server you depend on is itself answering correctly with the NTP server checker, and re-run w32tm /query /status to see a fresh Last Successful Sync Time.

Done when: Source points at the right upstream (a DC on members; your external NTP on the PDC emulator), Last Successful Sync Time is current, the stripchart offset is small and stable, and Kerberos auth stops failing. For the theory of stratum and the wider reference architecture, see the NTP stratum & architecture hub.

Related diagnostic pages:

After the fix — related sites:

Measure jitter, offset, latency → ntp-tester.eu
Produce NIS 2 / ISO 27001 audit evidence → online-ntp-validator.com
Enterprise reference architecture → ntp.rdem-systems.com

1. Why Windows time is different from a Linux daemon

2. Decode w32tm /query /status field by field

3. Decode /query /configuration — Type and flags

4. The Active Directory time hierarchy & PDC emulator

5. Diagnose by symptom (decision tree)

6. The accuracy you can actually expect

7. W32Time Event IDs decoder

8. Fix recipes (AD-specific)

Reset a member wrongly set to external NTP → back to NT5DS

Configure the forest-root PDC emulator (the only external source)

Full reset when the configuration is corrupted

9. Verify the fix

2. Decode `w32tm /query /status` field by field

3. Decode `/query /configuration` — Type and flags