{"id":921,"date":"2026-10-24T23:25:56","date_gmt":"2026-10-24T23:25:56","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/w32time-hierarchy-drift-pdc-emulator-time-sync\/"},"modified":"2026-10-24T23:25:56","modified_gmt":"2026-10-24T23:25:56","slug":"w32time-hierarchy-drift-pdc-emulator-time-sync","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/w32time-hierarchy-drift-pdc-emulator-time-sync\/","title":{"rendered":"w32time Hierarchy and Drift: Keeping Windows Server Time Accurate"},"content":{"rendered":"

Run w32tm \/query \/status<\/code> on a newly provisioned Windows Server VM and the first three lines report the source, the stratum and the poll interval. On a standalone instance the source is usually VM IC Time Synchronization Provider<\/code> — a Hyper-V synthetic clock with no independent verification. For an IIS-only host that is tolerable; for a machine issuing Kerberos tickets or validating certificates it is not.<\/p>\n\n

How the w32time hierarchy actually resolves<\/h2>\n\n

Windows time is not a single service call. The W32Time<\/code> service runs in two modes: a client layer that samples one or more upstream time sources, and a server layer that answers NTP requests from downstream machines on UDP port 123. Domain members hold the client role; the PDC emulator of the forest root domain should hold the server role, and every other domain controller points at it. In a single-server deployment on a Windows VPS with full administrator access<\/a> the same machine is frequently both client and NTP server, which makes the configuration easier to reason about but no less necessary.<\/p>\n\n

The hierarchy is driven by HKLM\\SYSTEM\\CurrentControlSet\\Services\\W32Time\\Parameters<\/code>. The value Type<\/code> selects the role: NT5DS<\/code> means follow the AD domain hierarchy, NTP<\/code> means use a manual peer list, NoSync<\/code> disables inbound correction, and AllSync<\/code> does everything. A standalone IIS box using NT5DS<\/code> with no domain to talk to will fall back to local clock and drift; check with w32tm \/query \/configuration<\/code> and look at the Type:<\/code> line before blaming the hypervisor.<\/p>\n\n

Each hop adds error: a stratum-1 source is directly attached to a reference clock, and a stratum-2 server carries the accumulated jitter of its parent. Keep the hierarchy shallow (strata 2 to 4) and never chain five or six internal relays.<\/p>\n\n

Configuring an external peer list correctly<\/h2>\n\n

Point a standalone server or the PDC emulator at a real NTP pool, never at time.windows.com<\/code> alone — it is rate-limited and often unreachable. Use a vendor pool or your own GPS-backed relay. This sequence sets three peers, enables reliable mode and restarts the service:<\/p>\n\n

w32tm \/config \/manualpeerlist:\"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8 ntp.example.net,0x8\" \/syncfromflags:manual \/reliable:yes \/update\nnet stop w32time && net start w32time\nw32tm \/resync \/force\nw32tm \/query \/status\nw32tm \/query \/peers<\/code><\/pre>\n\n
The 0x8<\/code> flag requests client mode; the default is symmetric active, which makes the client also try to serve time. The selection algorithm discards falsetickers, so four sources from different operators beat four hosts from one provider. \/reliable:yes<\/code> marks the machine as a trustworthy source for downstream clients.<\/p>\n\n
After the resync, verify with w32tm \/monitor<\/code>. On a domain controller it prints the offset of every reachable domain controller against its own clock; large positive or negative values on one branch of the tree point at that specific DC’s upstream, not at the whole domain. The Stratum<\/code> and Offset<\/code> columns are the two to watch.<\/p>\n\n
Reading the status output and the registry<\/h2>\n\n
Command \/ value<\/th>Location<\/th>What it tells you<\/th><\/tr><\/thead>
w32tm \/query \/status<\/td>CLI<\/td>Source, stratum, poll interval, last successful sync, clock offset<\/td><\/tr>
w32tm \/query \/peers<\/td>CLI<\/td>Every configured peer with state and offset<\/td><\/tr>
w32tm \/stripchart \/computer:host<\/td>CLI<\/td>Live offset samples against a named peer<\/td><\/tr>
Type<\/td>HKLM\\SYSTEM\\CurrentControlSet\\Services\\W32Time\\Parameters<\/td>NT5DS, NTP, NoSync or AllSync<\/td><\/tr>
NtpServer<\/td>same key<\/td>Manual peer list used when Type = NTP<\/td><\/tr>
MaxPosPhaseCorrection<\/td>same key<\/td>Largest forward step allowed (default 48h, in seconds)<\/td><\/tr>
Event ID 35<\/td>System log, W32Time<\/td>The time service is not able to synchronize<\/td><\/tr>
Event ID 37<\/td>System log, W32Time<\/td>The time provider has not been able to reach a source<\/td><\/tr>
Event ID 50<\/td>System log, W32Time<\/td>Time service is using a fallback source<\/td><\/tr><\/tbody><\/table><\/figure>\n\n
A poll interval of 1024 seconds (about 17 minutes) is normal for a stratum-3 client; the service starts at 64 seconds and backs off as the clock proves stable. Source: Local CMOS Clock<\/code> with a stratum of 0 means no sync has ever succeeded.<\/p>\n\n
Event ID 129 in the System log is worth grepping for on virtual machines: it reports a time service adjustment that was too large to be a normal correction. On Hyper-V guests this usually means the synthetic clock and the NTP client are fighting. Disable the VM time integration component or the guest vmictimesync<\/code> device and let exactly one mechanism own the clock.<\/p>\n\n
Measuring drift instead of guessing at it<\/h2>\n\n
Run a stripchart against two independent peers for a few minutes and compare the offset pattern. A steady ramp of milliseconds per minute is ordinary crystal drift; steps of hundreds of milliseconds are a scheduling problem — a host whose vCPUs are overcommitted falls behind while descheduled, then jumps forward.<\/p>\n\n
w32tm \/stripchart \/computer:ntp.example.net \/samples:10 \/dataonly\n# Output: 12:04:11, +0.0038s   12:04:13, +0.0041s ...\n# A ramp of ~0.3ms\/min is normal; steps >100ms indicate CPU steal.<\/code><\/pre>\n\n
If you are testing a host before you commit to it — for instance when comparing Windows Server plans<\/a> — a ten-minute stripchart at idle and again under a compile or IIS load test is a more honest measure of timer quality than any spec sheet. Servers with a stable, low offset curve are the ones that will not produce mysterious Kerberos or TLS failures six months later.<\/p>\n\n
Kerberos, TLS and the 5-minute window<\/h2>\n\n
Domain authentication fails when the client clock and the KDC’s clock differ by more than Maximum tolerance for computer clock synchronization<\/code> — 5 minutes by default, under Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy<\/code> in Group Policy. The error surfaces as STATUS_TIME_DIFFERENCE_AT_DC (0xC0000133) or a misleading “security database does not have a computer account” prompt.<\/p>\n\n
TLS validation compares NotBefore<\/code> and NotAfter<\/code> against the local clock, so a host three days behind rejects a fresh certificate as not yet valid and one a day ahead rejects it on expiry day. Both report SEC_E_CERT_EXPIRED<\/code> (0x80090328) in the Schannel logs.<\/p>\n\n
Making the PDC emulator authoritative<\/h2>\n\n
In an AD domain only the PDC emulator should go to the internet; every other DC and member uses NT5DS<\/code>. On the PDC emulator, set \/reliable:yes<\/code> and confirm that AnnounceFlags<\/code> under W32Time\\Config<\/code> is 5 (always reliable + time server enabled). Otherwise downstream DCs may ignore it in favour of a machine closer in the AD topology.<\/p>\n\n
If the PDC emulator role moves, the time configuration does not follow it: the new holder keeps NT5DS<\/code> and starts syncing from itself. Re-apply the peer config on the new role holder, then run w32tm \/resync \/rediscover<\/code> on every DC.<\/p>\n\n
A short verification checklist<\/h2>\n\n