A Windows Server NTP client looks like the easy half of time sync: one w32tm /config line and you’re done. In practice the client is where most of the drift tickets come from, because Windows quietly decides which source wins. A domain member that still carries a manual peer list mixes pool servers in with its domain controller, a Group Policy value overrides whatever you typed, and a workgroup server whose clock is 20 hours out refuses to correct at all.
This guide covers only the client side. You’ll configure a workgroup server with a w32tm manual peer list and see what changes once the server joins a domain. Then you’ll open UDP 123 on a strict egress firewall and verify everything with w32tm /query /status and /stripchart, followed by the errors we hit on purpose. If you need a Windows box to serve time to others, that’s the Windows NTP server guide. The behavior described here was checked on Windows Server 2025 and Windows Server 2022 lab VMs in November 2026, with a Windows Server 2025 domain controller as the PDC emulator.
How a Windows Server picks its time source
The Windows Time service (w32time) decides where to get time from one registry value, Type, under HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters. The other settings only matter in the context that Type selects, which is why the same NtpServer string can be active on one machine and completely ignored on the next. These are the values you will actually meet on a client:
- NTP: the workgroup default. The client polls the servers listed in
NtpServerand nothing else. - NT5DS: the domain member default. The client finds a domain controller through the AD hierarchy and syncs from it, and
NtpServeris ignored. - AllSync: both at once. Windows uses the domain hierarchy and the manual peers together, and whichever sample looks best wins. We’ll see below how a member ends up here by accident.
- NoSync: the service runs but never synchronizes. A client set to this keeps whatever time its hardware clock has.
Each entry in NtpServer carries a hex flag after the comma, and the flags change how that peer is polled. Microsoft documents them in the Windows Time service tools and settings reference: 0x1 polls at SpecialPollInterval, 0x2 makes the peer a fallback only, 0x4 sends symmetric active requests, and 0x8 sends plain client mode requests. They add up, so 0x9 is client mode on a fixed interval and 0xa is a client mode fallback. For a server pointing at a public pool or a Linux chrony box, 0x8 is the safe choice because some non-Windows servers answer nothing else.
What a Windows Server NTP client does by default
A fresh workgroup server already syncs, just not from where you want it to. Run these from an elevated PowerShell window, because w32tm /config later on needs administrator rights and it is easier to stay in one session. Every command here ran in the built-in Windows PowerShell 5.1 (the PowerShell 7 vs 5.1 comparison covers what differs if you have moved to 7):
w32tm /query /source
w32tm /query /configuration | Select-String 'Type|NtpServer:|SpecialPollInterval|MinPollInterval|MaxPollInterval|MaxPosPhase|MaxNegPhase|AnnounceFlags'On both Windows Server 2025 (build 26100) and Windows Server 2022 (build 20348) the client came up pointed at time.windows.com,0x8 with a 64 to 1024 second polling range:
Two numbers in that output matter later. MaxPosPhaseCorrection and MaxNegPhaseCorrection are 54000 seconds, so a standalone server refuses to move its clock by more than 15 hours in one go. And the values don’t match Microsoft’s own registry reference, which still lists a stand-alone default of time.windows.com,0x1 with a 604800 second SpecialPollInterval and a 1024 to 32768 second polling range. Both of our builds shipped 0x8, 1024 and 64 to 1024 instead, so do not trust any default table, ours included, over what /query /configuration prints on your own server. The (Local) suffix on every line also tells you no Group Policy is in play yet.
How to set a manual peer list on a workgroup server
On a server outside a domain, the manual peer list is the whole configuration. We gave it three pool servers in client mode and kept time.windows.com as a fallback with 0xa, so the box still has a source if the pool names stop resolving. Swap the pool names for your own NTP servers if you run them:
w32tm /config /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8 2.pool.ntp.org,0x8 time.windows.com,0xa" /syncfromflags:manual /update
Restart-Service w32time
w32tm /resync /rediscover
w32tm /query /status/syncfromflags:manual is what sets Type to NTP, and /update tells the running service to reread its settings. The restart is not strictly required, but it clears peers the service resolved under the old list. The status that came back shows a working client:
Read it from the bottom up. Source names the peer that was picked, Last Successful Sync Time is a few seconds old, and Stratum: 4 means the pool server we hit is itself at stratum 3. Root Dispersion near 7.8 seconds looks alarming but is normal right after a resync, since Windows starts with a conservative error estimate and narrows it with every poll. To see every peer and not just the winner, query the peer table:
w32tm /query /peersTwo peers went active straight away, while 1.pool.ntp.org and 2.pool.ntp.org sat in Pending with a retry roughly 15 minutes out:
Pending here is not a firewall problem. A few minutes later the System log recorded event 135 for 1.pool.ntp.org, saying the same time source was already in use as 0.pool.ntp.org. Pool names rotate through a shared set of servers, so two of them can land on one machine, and w32time refuses to add a source twice: it backs off and retries after 15 minutes. That’s harmless, and the duplicate peer error gets a full write-up on the server side. A peer that stays pending with no event 135 needs a look at the other Time-Service events in the System log, which name the peer and the reason it failed. Ignore PeerPoll Interval: 17 (out of valid range) too, since that’s the remote server’s advertised value and Windows only uses HostPoll Interval.
Why SpecialPollInterval looks ignored
If you use the 0x1 flag to poll on a fixed schedule, the interval comes from SpecialPollInterval in seconds. We switched the first peer to 0x9, set the interval to 3600 for an hourly poll, ran w32tm /config /update, and the service kept reporting 1024. The registry held the right value, so this was not a typo:
w32tm /config /manualpeerlist:"0.pool.ntp.org,0x9 time.windows.com,0xa" /syncfromflags:manual /update
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient -Name SpecialPollInterval -Value 3600 -Type DWord
w32tm /config /update
w32tm /query /configuration | Select-String 'SpecialPoll|MaxPollInterval'The service clamps the value to the polling range:
MaxPollInterval: 10 (Local)
SpecialPollInterval: 1024 (Local)MaxPollInterval is a power of two, so 10 means 1024 seconds, and on both 2025 and 2022 that ceiling silently wins over SpecialPollInterval. The tools and settings reference linked above states it plainly: starting with version 1703, SpecialPollInterval is contained by MinPollInterval and MaxPollInterval. Raise the ceiling to 12 (4096 seconds) and the configuration accepts the hourly value:
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config -Name MaxPollInterval -Value 12 -Type DWord
w32tm /config /update
w32tm /query /configuration | Select-String 'SpecialPoll|MaxPollInterval'Now the configuration reports the value you asked for:
MaxPollInterval: 12 (Local)
SpecialPollInterval: 3600 (Local)Right after the change /query /status still printed Poll Interval: 6 (64s), so check it again after a few polls before you trust the new interval. The higher MaxPollInterval also lets ordinary 0x8 peers back off as far as 4096 seconds. Most servers don’t need this at all. Plain 0x8 lets the service adapt between 64 and 1024 seconds on its own, which holds a LAN client within a few milliseconds. We’d only reach for 0x1 when a metered or rate limited upstream asks you to poll less often.
How to verify sync with w32tm /query /status and /stripchart
/query /status tells you what the service believes. /stripchart measures the offset against any NTP server right now, independent of the service, which makes it the better check when you suspect the service is lying. Run it against the source you configured, once in data mode and once with the graph:
w32tm /stripchart /computer:0.pool.ntp.org /samples:5 /dataonly
w32tm /stripchart /computer:time.windows.com /samples:3The pool server sat within 2.5 to 11 milliseconds of the client, and time.windows.com agreed to within 3 milliseconds:
In the graph view, d: is the round trip delay and o: is how far the remote clock is ahead of yours. The 194 ms delay to time.windows.com is just distance from our lab, and NTP cancels most of it by assuming the path is symmetric, so any error left over from an uneven path is bounded by half the round trip. What matters is that o: stays small and steady between samples. A client whose offset keeps growing across runs several minutes apart is drifting and not being disciplined, and a single spike like the 11 ms sample above is network jitter you can ignore.
What Windows Firewall needs for UDP 123
On a default install the client needs no firewall rule at all. Every profile reported BlockInbound,AllowOutbound in netsh advfirewall show allprofiles firewallpolicy, and the replies from the NTP server get back in because the firewall tracks the outbound request. Server side rules for inbound UDP 123 only matter on a machine that serves time. Things change on a hardened server where outbound traffic is blocked by default. We reproduced that on the lab client with the command below. Treat it as a demonstration, not a step: on a real server it also cuts DNS, Windows Update and, on a domain member, LDAP and Kerberos to the domain controllers. If your servers already run a default outbound block, skip straight to the rules after it.
Set-NetFirewallProfile -All -DefaultOutboundAction Block
w32tm /resyncThe resync fails with The computer did not resync because no time data was available. The fix is an outbound rule scoped to the W32Time service, so nothing else on the box gets UDP 123 out. We also allowed DNS, which a real egress baseline already does:
New-NetFirewallRule -DisplayName 'NTP client (W32Time) out' -Direction Outbound -Protocol UDP -RemotePort 123 -Service W32Time -Action Allow
New-NetFirewallRule -DisplayName 'DNS out' -Direction Outbound -Protocol UDP -RemotePort 53 -Action Allow
w32tm /resyncWith the W32Time rule disabled and only DNS allowed, the resync failed again, so the service rule is the one that matters. With both rules in place the resync worked, but /stripchart still failed:
That split is the mechanism worth remembering. The service always sends from source port 123 inside svchost.exe, so the service scoped rule matches it. w32tm /stripchart runs as w32tm.exe from a random high port, which the rule doesn’t cover. It times out with 0x800705B4 even while the client syncs fine. If you want the diagnostic tool to work on a locked down server, add a second rule for the program:
New-NetFirewallRule -DisplayName 'NTP stripchart (w32tm.exe) out' -Direction Outbound -Protocol UDP -RemotePort 123 -Program '%SystemRoot%\System32\w32tm.exe' -Action AllowWith that rule the stripchart returned offsets of 0.3 ms. If you only reproduced the block to test this, put the default back with Set-NetFirewallProfile -All -DefaultOutboundAction NotConfigured, which returns every profile to AllowOutbound, and delete the three test rules with Remove-NetFirewallRule -DisplayName 'NTP client (W32Time) out','DNS out','NTP stripchart (w32tm.exe) out'. Do not read a failing stripchart on a hardened box as proof the client is broken: check w32tm /query /status first, because the two tools take different paths through the firewall. The same 0x800705B4 also shows up when a network firewall between you and the server drops UDP 123, which a host rule can’t fix.
How domain members get their time
A domain member should not have a peer list at all. With Type set to NT5DS it asks AD for a domain controller, syncs from it with signed packets, and the domain controllers in turn follow the PDC emulator. That chain keeps every member inside the Kerberos clock skew limit of 5 minutes, which is why Microsoft warns that pointing a member at an outside source can break authentication. If logons start failing with clock skew errors, the Kerberos and NTLM guide explains what Kerberos checks. Only the PDC emulator of the forest root should talk to the internet, and its setup lives in the NTP server guide.
A clean join, with no peer list configured beforehand, switches the client to NT5DS on its own, as the server guide shows for its 2022 member. The trap is a server you configured in a workgroup and joined to the domain later. We left the manual peer list from the earlier step in place, joined the box to a corp.lan domain and rebooted it. The configuration didn’t flip to NT5DS. It became AllSync, the member kept the pool servers next to the domain controller, and w32tm /query /source reported 1.pool.ntp.org. The join did raise both MaxPosPhaseCorrection and MaxNegPhaseCorrection to 4294967295, the member default that lets a member correct any offset. Put the member back on the hierarchy and restart the service:
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
w32tm /resync /rediscover
w32tm /query /sourceThe source switches to the domain controller and Type reads NT5DS again:
Check this on every server that lived in a workgroup before it was joined, and on any VM template you clone servers from, because a peer list baked into the template follows every clone into the domain. The reset is harmless on a member that’s already correct, so it’s safe to run across a batch of servers.
What a healthy domain member looks like
Our first status check on the member said it was synced, at stratum 2 from NODE-A.corp.lan, with a root dispersion of 18 seconds. Stratum 2 was the clue: it means the domain controller claimed stratum 1, the level of a reference clock, which a lab VM is not. The PDC emulator had just been promoted and nobody had given it an upstream, so its own w32tm /query /source said Local CMOS Clock. The member was faithfully following a domain controller that followed nothing. We pointed the PDC at the pool and checked the member again about 13 minutes later:
w32tm /query /status
w32tm /query /status /verbose | Select-String 'State Machine|Time Source Flags|Last Sync Error'
w32tm /stripchart /computer:NODE-A.corp.lan /samples:4Stratum went to 5, one level below the PDC at 4, root dispersion dropped to 0.15 seconds, and the verbose output confirms the sample was signed by the domain controller:
Time Source Flags: 8 (SignatureAuthenticated) is the part a manual peer list can never give you, because public NTP servers don’t sign anything. The 25 ms offset is not a finished result. Right after the PDC change the member’s stripchart showed about 40 ms and growing, a minute later about 100 ms and shrinking, and 13 minutes later 25 ms and shrinking by under 1 ms per sample. The PDC itself was still 54 ms off the pool at that point, because Windows slews a clock gradually instead of stepping it, so a fresh chain takes a while to settle. The direction is what you watch: an offset that keeps shrinking is being disciplined, while one that keeps growing for many minutes means the member is drifting. A member that’s really in sync passes three checks:
- Source:
w32tm /query /sourcenames a domain controller, never a pool server. - Stratum: one higher than the controller it follows, so 5 below a PDC at stratum 4.
- Upstream: the PDC emulator’s own source is an external server, not
Local CMOS Clock.
The third check runs on the PDC, not the member, and it’s the one people skip. If you manage many members, pushing these settings with the Group Policy setup you already use is cleaner than touching each box.
Why Group Policy overrides w32tm /config
w32time reads two places, and the policy key under HKLM\SOFTWARE\Policies\Microsoft\W32Time beats the service key every time. w32tm /config only writes the service key, so on a server with a time policy the command reports success and changes nothing. We reproduced it on the Windows Server 2022 VM by writing the policy values a GPO would create, then running the usual peer list command:
The registry holds 0.pool.ntp.org,0x8, yet the service syncs from time.windows.com,0x9, and the (Policy) suffix in /query /configuration says why. When a setting refuses to stick, look for that suffix before anything else, then change the GPO (Computer Configuration, Administrative Templates, System, Windows Time Service, Time Providers, Configure Windows NTP Client) instead of the server. Microsoft’s reference says Windows removes the policy registry entry when the setting is removed, so on a real GPO set it to Not Configured and run gpupdate /force on the server. Our lab had no GPO behind the key, so after we deleted the policy key, ran w32tm /config /update, restarted the service and ran w32tm /resync /rediscover, the local peer list took over again.
Where NTP client sync breaks down
Every error below came from the lab VMs, mostly by breaking the client deliberately. The first stop for any of them is the System log filtered to the Microsoft-Windows-Time-Service provider, which names the peer and the reason more precisely than w32tm does.
“The computer did not resync because the required time change was too big”
We pushed the workgroup client 20 hours ahead with Set-Date and asked it to resync. It refused, and the log explained why:
Event 34 says the needed change of 71999 seconds is over the 54000 second cap from MaxNegPhaseCorrection, the guard against a bad source dragging a server days off. Domain members rarely hit this because their cap is effectively unlimited, while domain controllers stop at 48 hours. On a workgroup server, either set the clock close by hand with Set-Date and resync, or lift the cap once, let the service correct, and put the cap back:
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config -Name MaxNegPhaseCorrection -Value 0xFFFFFFFF -Type DWord
w32tm /config /update
w32tm /resync
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config -Name MaxNegPhaseCorrection -Value 54000 -Type DWord
w32tm /config /updateIn our run the clock was already corrected by the time /config /update returned, so the /resync right after it printed “no time data was available” while the service rediscovered its peers. A second w32tm /resync a few seconds later completed normally. Our clock was running fast, so it needed a negative correction and MaxNegPhaseCorrection was the cap in the way. For a clock running behind, the event reports a positive change, and you lift MaxPosPhaseCorrection the same way.
“The computer did not resync because no time data was available”
This means the service sent requests and got no usable answer from any peer. On the client it appeared in three situations:
- Explicit block rule: an outbound rule dropping UDP 123 for everything on the box.
- Strict egress profile: default outbound block with no rule for the W32Time service.
- Rediscovery: the few seconds after
/config /updatewhile the service drops and re-adds peers.
The third one clears itself, so run w32tm /resync once more before digging. If it persists, run w32tm /query /peers. Every peer stuck in Pending with no event 135 in the log points at the network path, and the server guide’s troubleshooting section covers the server end of the same message.
“error: 0x800705B4” from w32tm /stripchart
0x800705B4 is a timeout. Our explicit outbound block rule produced it, and so did a strict egress profile that only allowed the W32Time service. In the second case the client was syncing fine, because the stripchart tool uses its own process and port. Allow w32tm.exe out on UDP 123 as shown earlier, or test from a machine you know can reach the server.
“The service has not been started. (0x80070426)”
Any w32tm /query fails this way when w32time is stopped. Start it with Start-Service w32time and check that the start type is Automatic with Get-Service w32time | Select-Object Status,StartType,Name. On a server that keeps finding the service stopped, look for a hardening script or baseline that disabled it, since every client query depends on the running service.
Source: Local CMOS Clock
w32tm /query /source returns Local CMOS Clock (or Free-running System Clock) when the service has no working external source and is trusting the hardware clock. On a client right after a restart it can show for a few seconds before the first sync. If it persists, the peers are not answering. When the member is fine but its domain controller reports this, the controller was never given an upstream, which is the stratum 2 situation from the domain member section and a server side fix. If you’re building that controller from scratch, the Windows Server 2025 install guide gets you to the point where the server side NTP steps take over.
