Windows Time Service (W32Time) Troubleshooting for AD Domains (2026): PDC Emulator, Kerberos Skew & Hyper-V VMICTimeProvider Fixes

Updated: August 12, 2026

The Windows Time Service (W32Time) synchronises clocks across an Active Directory forest by chaining every domain member up to the PDC Emulator of the forest root, which is the one machine you point at an external NTP source. When that chain breaks, Kerberos authentication starts failing with the dreaded five-minute skew error, and users get locked out for reasons the ticketing system usually files under "IT weirdness". This guide walks through the AD time hierarchy, the w32tm commands I run every week, the Hyper-V VMICTimeProvider trap, and the W32Time event IDs (47, 50, 129, 138, 142) that actually explain what's wrong. Honestly, once you internalise the hierarchy rule, 80% of the "weird auth" tickets stop being mysterious.

• Only the forest-root PDC Emulator should sync from an external NTP source; every other DC and client must stay on NT5DS (domain hierarchy).
• Kerberos rejects tickets with a clock skew over 5 minutes (MaxClockSkew), so drift equals lockouts, not just log noise.
• Virtualised DCs on Hyper-V need VMICTimeProvider disabled so the host clock doesn't override the AD hierarchy.
• Event 47/129/138 mean "no NTP peer reachable" (usually UDP 123 blocked, DNS failure, or a bad manual peer list).
• Event 50 means the client saw a large offset for 15 minutes and refused to correct it; you'll need to relax MaxAllowedPhaseOffset or step time manually.
• Event 142 means the PDC Emulator has stopped advertising as a time source because its own sync source is unreachable, and the whole domain will drift within an hour.

How the AD time hierarchy actually works

Active Directory has one source of truth for time, and it lives on a single FSMO role holder: the PDC Emulator of the forest-root domain. Everything else in the forest (every child-domain DC, every member server, every laptop) walks up that chain. Child-domain DCs sync from the PDC of the forest root. Member servers and clients pick any DC in their own domain via domain hierarchy discovery (NT5DS). Nothing in that hierarchy should be reaching out to a public NTP pool except the one machine at the top.

Getting this wrong is the single most common cause of "why do our clocks disagree" tickets I see. Someone thinks it's a good idea to pin a random member server to pool.ntp.org, or to put a manual peer list on a branch DC "for redundancy", and now that machine is authoritative for anyone downstream of it while also disagreeing with the actual PDC. Two clocks, both claiming to be right, and Kerberos fails intermittently as tickets are issued by DCs that don't agree.

Confirm the role holder before you touch anything:

# Which DC holds the PDC Emulator role?
netdom query fsmo

# Or in PowerShell (cleaner output)
Get-ADDomain | Select-Object PDCEmulator, DomainMode, Forest

The machine returned by "PDC" is the only one that should ever be pointed at an external time source. Write it on a whiteboard. Tattoo it on interns. Related reading: our Active Directory replication troubleshooting guide covers what happens when FSMO placement and replication topology get out of sync more broadly.

Why 5 minutes of skew locks out your users

Kerberos ticket validation checks the timestamp inside the authenticator against the KDC's clock. If they differ by more than MaxClockSkew (default: 300 seconds, i.e. 5 minutes), the KDC returns KRB_AP_ERR_SKEW and refuses to issue or validate a ticket. From the user's perspective, this looks like:

• Password prompts that keep re-appearing after apparently correct entries
• Outlook stuck on "trying to connect"
• Group Policy processing failures at logon
• Mapped drives disconnecting and refusing to re-connect
• Domain-joined workstations that can log on with cached credentials but nothing "network" works

The scary part is that a 5-minute skew doesn't require a broken clock. It just requires drift over time on a system that has stopped syncing. A laptop that has been in a drawer over a long weekend can absolutely hit this. So can a virtual DC that's been paused and resumed via a snapshot. If you're chasing Kerberos-adjacent errors, our Kerberos troubleshooting guide covers the ticket flow end-to-end; the point here is that time is a Kerberos prerequisite, not a nice-to-have.

Because the skew check happens on both the issuing KDC and the target service, a domain with drift between DCs can produce truly baffling symptoms. Authentication succeeds against DC1 but fails against DC2 for the same account, the same second. If you see intermittent Kerberos failures that "clear up if I try again", the first diagnostic should always be w32tm /monitor /domain, not a packet capture.

Configuring the PDC Emulator with an external NTP source

Once you've confirmed which machine holds the PDC role, this is the sequence to point it at a reliable external source. I always give it at least two peers so a temporary outage of one doesn't leave the whole forest drifting:

# Run from an ELEVATED PowerShell / cmd on the PDC Emulator only

# Set the manual peer list; 0x8 flags = client mode (sane default)
w32tm /config /manualpeerlist:"time.windows.com,0x8 time.google.com,0x8 time.cloudflare.com,0x8" /syncfromflags:MANUAL /reliable:YES /update

# Restart the service so the new config takes effect
Restart-Service w32time

# Force an immediate sync (skip the "gentle" gradual correction)
w32tm /resync /rediscover

# Confirm the new source and status
w32tm /query /source
w32tm /query /status

A few notes on the flags most people get wrong:

• /reliable:YES tells the W32Time service on this machine that it's an authoritative time source for the domain. Set this only on the PDC Emulator.
• 0x8 on each peer means "act as a client to this peer". Do not use 0x1 (symmetric active) with public NTP servers; most will just drop the packet.
• The whole peer list must be one space-separated string inside quotes; the parser is finicky.
• UDP port 123 outbound must be open through your firewall. It's astonishing how often this is the whole problem.

Verify with a stripchart before you walk away. This is the single most useful diagnostic w32tm has:

# Show 10 samples, 2 seconds apart, without actually changing the clock
w32tm /stripchart /computer:time.windows.com /samples:10 /dataonly

# Same thing against your own PDC from a member server
w32tm /stripchart /computer:pdc01.corp.local /samples:10 /dataonly

If /stripchart shows "0x800705B4: This operation returned because the timeout period expired", the port is blocked. If it shows steadily growing offsets, you have jitter on the path and you may want to add closer or more accurate peers.

Configuring member servers and workstations (NT5DS)

Every non-PDC machine (child-domain DCs, member servers, workstations, that one legacy Windows Server 2016 file server in the back cupboard) should be configured for NT5DS (domain hierarchy). If someone previously fat-fingered a manual peer list onto them, this resets them:

# On the misconfigured member/DC (NOT the PDC Emulator)
w32tm /config /syncfromflags:DOMHIER /reliable:NO /update
Restart-Service w32time
w32tm /resync /rediscover

# Sanity check (should return a DC name, not an internet NTP server)
w32tm /query /source

If /query /source returns "Local CMOS Clock" or "Free-running System Clock", W32Time hasn't found a peer at all. Check DNS, check that the machine can actually talk to a DC on UDP 123, and check that it's still joined to the domain. Machines that have fallen off the domain frequently show this symptom. New-build workstations that have never successfully authenticated will also show it until they complete their first domain login.

Decoding W32Time event IDs 47, 50, 129, 138 and 142

The System log is where W32Time actually tells you what's wrong. Learn to read these on sight. Running Get-WinEvent -LogName System -FilterHashtable @{ProviderName='Microsoft-Windows-Time-Service'} -MaxEvents 50 will surface them without hunting through Event Viewer:

Event 47: No valid response has been received from manually configured peer

NtpClient sent a request to a manual peer and got nothing back. On the PDC, this almost always means UDP 123 outbound is blocked, DNS cannot resolve the peer, or the peer itself is down. On a non-PDC machine that logs this, someone previously set a manual peer list and you should re-run the NT5DS config above.

Event 50: Time difference of greater than 5000 milliseconds for 900 seconds

W32Time saw an offset larger than MaxAllowedPhaseOffset (default: 1s on servers, larger on clients) sustained across a 15-minute window. Rather than slew the clock, it logs the discrepancy and does nothing. You'll need to either step the clock manually (w32tm /resync /force), fix the offending peer, or if the offset is legitimate, temporarily raise MaxAllowedPhaseOffset. See Microsoft's guidance on configuring W32Time against huge time offsets for the full registry procedure.

Event 129: NtpClient was unable to set a domain peer because of discovery error

Domain hierarchy discovery failed. The machine can't find a DC to sync from, which is really a Netlogon or DNS problem, not a time-service problem. Confirm with nltest /dsgetdc:corp.local; if that fails, W32Time will keep failing regardless of what you do to it.

Event 138: Time service is now synchronising the system time

This is the "back to normal" message. On its own it's informational, but a machine that logs Event 138 every few minutes is losing its sync and re-establishing it. Usually because a firewall or antivirus is intermittently killing the outbound port 123 traffic, or because a virtual host is spiking CPU steal high enough to make the guest miss NTP replies.

Event 142: Time service has stopped advertising as a time source

This is the emergency one. Event 142 fires on the PDC when its own upstream source has been unreachable long enough that it no longer trusts its own clock, so it stops advertising to the rest of the domain. Within an hour every downstream DC will start logging Event 129 because there's no authoritative source in the hierarchy. Fix the PDC's external NTP path immediately. Microsoft's Event 142 troubleshooting article covers the specific registry sequence to restart advertising once the upstream is healthy again.

Virtualised domain controllers: the VMICTimeProvider trap

Every time I inherit a broken AD environment, this is where the bodies are buried. Hyper-V ships a time-sync integration service (VMICTimeProvider) that pushes the host's clock into the guest OS. On a member server, that's fine and preferable. On a domain controller (and especially on the PDC Emulator), it means the guest is being fed time from two independent sources at once: Hyper-V, and W32Time via domain hierarchy or external NTP. They'll fight each other and log Kernel-General event 1 every time either one wins.

I hit this exact bug on a migration a couple of years back: PDC virtualised on Hyper-V, external NTP configured "correctly", and yet w32tm /monitor showed the PDC drifting by 400ms every few hours. The host was NTP-synced but the guest was arguing with it, and both were winning intermittently. The fix is to disable the VMICTimeProvider on all virtualised DCs. From an elevated prompt inside the guest:

# Disable the Hyper-V time provider (keeps the integration service installed
# so you can still shut down / heartbeat, but stops it feeding time)
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0 /f

# If it's the PDC Emulator, also point it at external NTP (see earlier section)
# For all other virtualised DCs, keep it on domain hierarchy:
w32tm /config /syncfromflags:DOMHIER /reliable:NO /update
Restart-Service w32time
w32tm /resync /rediscover

Two footguns to know about with virtual DCs:

1. Snapshots and saved states. Restoring a DC from a snapshot rewinds its clock. On Server 2012 R2 and later this is handled by VM-GenerationID, but only if the hypervisor supports it and only for one type of rollback. Never revert a DC snapshot as a shortcut. Export the config or rebuild instead.
2. Nested virtualisation. A guest-in-a-guest inherits time drift from every layer. If you must run this way for a lab, expect to babysit the clocks manually.

Azure VMs and the VMICTimeSync provider

Azure VMs use a similar-but-different provider called VMICTimeSync, backed by the Hyper-V host clock in the Azure fleet. For most workloads you should leave it alone; it delivers sub-second accuracy without any configuration. For domain controllers running as Azure VMs, Microsoft's guidance has stabilised with Windows Server 2022 and 2025: keep VMICTimeSync enabled but let W32Time still run in NT5DS mode for domain-joined member servers, or with an explicit peer list for the PDC. Don't disable the provider entirely on Azure, or you lose the safety net that catches large offsets on VM start-up when the host and guest clocks disagree by many seconds. See the Azure VM time sync documentation for the current supported configuration matrix.

One Azure-specific behaviour that catches people out: Azure VMs deallocate their clock state when stopped (deallocated), so a VM that's been off for a week comes back with a big initial offset that W32Time may not correct if you've tightened MaxAllowedPhaseOffset. Either accept the default offset tolerance, or add a boot-time task that runs w32tm /resync /force.

The w32tm commands I actually use

These are the ones on the tier-1 cheat sheet. Comments are for anyone new to the tool:

# --- Diagnostics (safe, read-only) ---

# What is my current source? (returns hostname or "Local CMOS Clock")
w32tm /query /source

# Detailed status: stratum, last sync, poll interval, root delay/dispersion
w32tm /query /status

# Show configured peers and their reachability
w32tm /query /peers

# Live measurement against a peer without changing anything
w32tm /stripchart /computer:pdc01.corp.local /samples:10 /dataonly

# Poll every DC in the domain and print offset from PDC
w32tm /monitor /domain:corp.local


# --- Corrective actions (require elevation) ---

# Gentle re-sync (uses configured source and slews the clock)
w32tm /resync

# Force step the clock immediately (jumps, doesn't slew)
w32tm /resync /force

# Re-discover a domain peer (use if source is stuck on CMOS)
w32tm /resync /rediscover

# Restart the service after any /config change
Restart-Service w32time


# --- One-liner health check I paste into every incident ticket ---
# Returns hostname, current source, stratum, and last successful sync
$s = w32tm /query /status
$src = (w32tm /query /source).Trim()
$stratum = ($s | Select-String 'Stratum').ToString().Split(':')[1].Trim()
$last = ($s | Select-String 'Last Successful Sync').ToString().Split(':',2)[1].Trim()
"$env:COMPUTERNAME  source=$src  stratum=$stratum  lastsync=$last"

If you're staring at an unfamiliar environment for the first time, run w32tm /monitor /domain before anything else. It shows every DC's offset from the PDC in one table, which usually tells you within thirty seconds whether you have a hierarchy problem, a single-DC problem, or a firewall problem.

Managing W32Time through Group Policy

This is where I get opinionated. The correct way to manage W32Time settings at scale is through Group Policy under Computer Configuration → Administrative Templates → System → Windows Time Service, targeted with a WMI filter that only matches the PDC Emulator. That way the config survives rebuilds, is auditable, and doesn't rely on someone remembering to re-run w32tm /config after every DC promotion.

The two policies you'll actually use:

• Global Configuration Settings: sets MaxAllowedPhaseOffset, MaxPosPhaseCorrection, and other tuning knobs. Leave the defaults alone unless you have a documented reason.
• Configure Windows NTP Client: sets the NtpServer, Type (NT5DS / NTP / AllSync), SpecialPollInterval and so on. This is the one that goes on the PDC-targeted GPO.

WMI filter for a "PDC Emulator only" GPO, which is the exact query I paste in:

SELECT * FROM Win32_ComputerSystem WHERE DomainRole = 5

DomainRole = 5 is "Primary Domain Controller". The FSMO role can move between DCs (e.g. during a promotion or seizure), and this filter follows it automatically. Do not hard-code the current PDC's hostname. That's a landmine for whoever inherits the environment. For more on GPO scoping mistakes generally, our Group Policy not applying troubleshooting guide covers the "why did this policy not hit my machine" investigation.

A second GPO, filtered to "any DC that is not the PDC Emulator", should force Type = NT5DS so that no manual peer list can accidentally stick around. Belt-and-braces, but I've never regretted it.

High-accuracy time on Windows Server 2025

Since Windows Server 2016, W32Time has been able to hit 1 ms accuracy under tight conditions, and Windows Server 2025 keeps those improvements. But you only get that accuracy if:

1. Your NTP path is short and low-latency (ideally an on-prem stratum-1 GPS-backed appliance, not the public internet)
2. You have applied the "high-accuracy" registry tuning documented in the Windows Time Service technical reference. This changes MinPollInterval, MaxPollInterval, UpdateInterval, FrequencyCorrectRate and a few others.
3. Your VMs are running on hosts with reliable clocks (not oversubscribed, no CPU steal spikes) and PTP is enabled where the hypervisor supports it
4. You're actively monitoring for lock loss. A 1 ms configuration that has drifted to 50 ms is worse than a boring 300 ms configuration that stays put, because your dashboards will pretend everything is fine.

The overwhelming majority of shops don't need this. If you're troubleshooting Kerberos lockouts, don't go down the 1 ms rabbit hole. Just get every machine within the default 5-minute skew. High-accuracy tuning is for financial-services timestamping, distributed database quorum, and MiFID II compliance, not for making Outlook stop complaining.

Nuclear option: fully re-registering W32Time

Occasionally (usually after a botched migration, an in-place upgrade that went sideways, or a machine where someone has been "trying things" for weeks), the W32Time registry state is beyond fixing with /config. The clean-slate reset:

# Run elevated. This wipes W32Time config back to install defaults.
net stop w32time
w32tm /unregister
w32tm /register
sc config w32time start=auto
net start w32time

# Now reconfigure normally
# On the PDC Emulator:
w32tm /config /manualpeerlist:"time.windows.com,0x8 time.google.com,0x8" /syncfromflags:MANUAL /reliable:YES /update
# On everything else:
w32tm /config /syncfromflags:DOMHIER /reliable:NO /update

Restart-Service w32time
w32tm /resync /rediscover

This is safe on member machines. On a DC it's safe but disruptive: Kerberos will hiccup during the restart, so do it outside business hours and make sure you have a working second DC serving auth. It's also worth checking the System log for related noise afterwards; our Windows Event Viewer troubleshooting guide walks through the XPath filters that make W32Time events easy to isolate from everything else.

Frequently Asked Questions

How do I check what time source my Windows Server is using?

Run w32tm /query /source from an elevated prompt. It returns the hostname of the current peer, or "Local CMOS Clock" / "Free-running System Clock" if W32Time hasn't found a peer at all. Follow up with w32tm /query /status for the last successful sync time, stratum, and offset details.

Why is my PDC Emulator logging W32Time event 47?

Event 47 means the manually configured NTP peer returned nothing. Nine times out of ten it's a firewall blocking outbound UDP 123, a DNS failure resolving the peer name, or a peer name that was fat-fingered. Confirm with w32tm /stripchart /computer:<peer> /samples:5. If it times out, the network path is the problem, not W32Time itself.

Do I need to disable Hyper-V time sync on virtualised domain controllers?

Yes on the PDC Emulator, and yes on any other DC where you want the domain hierarchy to be authoritative. Disable it by setting HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider\Enabled to 0 in the guest OS, then reconfigure W32Time for external NTP (PDC) or NT5DS (other DCs).

What is the default Kerberos clock skew tolerance?

The default MaxClockSkew is 300 seconds (5 minutes). It can be tightened via Group Policy (Computer Configuration → Windows Settings → Security Settings → Account Policies → Kerberos Policy) but should almost never be relaxed. A wider window increases the replay window for stolen tickets.

Can I use pool.ntp.org as the source for my PDC Emulator?

You can, but I don't recommend it for production. The pool rotates through community-run servers of variable quality; for an enterprise domain, either use vendor NTP (time.windows.com, time.google.com, time.cloudflare.com) or an on-premises GPS-backed appliance. Always specify at least two peers with the ,0x8 client-mode flag.