Fix NERR_TimeDiffAtDC (0X00000999) clock sync error
Domain controller clock out of sync with PDC. Fix is to force resync via w32tm or adjust time source. Here's the real fix.
You're staring at error 0X00000999 and your domain controller won't authenticate properly — clock's drifted too far from the PDC emulator. Let's fix that now.
The Fix: Force a clock resync from the command line
Open an elevated command prompt on the affected DC and run these in order:
w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /resync /rediscoverWhat's actually happening here is the first command tells the Windows Time service to sync from the domain hierarchy (your PDC emulator). The restart clears any stale state. The /rediscover flag forces w32tm to re-detect available time sources — crucial because it often caches a broken source.
After that, check sync status:
w32tm /query /statusLook for Source: Local CMOS Clock — that's bad. It means the DC isn't talking to the PDC. You want to see Source: DC or the PDC's hostname.
Why this works
The error code 0X00000999 (NERR_TimeDiffAtDC) fires when time difference between a DC and the PDC emulator exceeds the default skew tolerance — 5 minutes by default in Windows Server 2012 R2 through 2022. Once you cross that threshold, Kerberos authentication breaks, group policy updates fail, and replication goes sideways.
The reason step 3 (/rediscover) matters is that Windows Time service doesn't always re-evaluate its source automatically when a previous sync failed. It'll just sit there pointing at a dead source. The rediscover flag forces it to walk the domain hierarchy again from scratch.
Less common variations of the same issue
1. PDC emulator itself has the wrong time
If the PDC's clock is wrong, all DCs sync to a bad source. Check the PDC emulator first:
w32tm /query /sourceIf it shows Local CMOS Clock or an external source that's unreliable, reconfigure it to use a proper NTP pool:
w32tm /config /manualpeerlist:"pool.ntp.org,0x8" /syncfromflags:manual /update
net stop w32time && net start w32time
w32tm /resync2. Firewall blocking NTP traffic (UDP 123)
I've seen this on AWS and Azure VMs where the NSG or security group silently blocks NTP. Quick test:
Test-NetConnection -ComputerName pool.ntp.org -Port 123 -InformationLevel DetailedIf TcpTestSucceeded shows false, you've got a firewall issue. Cloud environments often require you to explicitly allow outbound UDP 123.
3. Hyper-V or VMware VM time sync fighting Windows Time service
Virtualization platforms inject time into VMs by default. This conflicts with domain time sync. The fix: disable host time sync for the VM. On Hyper-V:
Get-VMIntegrationService -VMName "YourDC" -Name "Time Synchronization" | Disable-VMIntegrationServiceDon't skip this. I've seen DCs that drift exactly 5 minutes every 24 hours because the host's hypervisor keeps overriding the PDC's time.
4. Time service not started or set to manual
Check service status:
sc qc w32time | find "START_TYPE"It should show 2 AUTO_START. If it's manual or disabled, set it:
sc config w32time start= auto
net start w32timePrevention: keep this from happening again
Set up a scheduled task that runs w32tm /resync daily on each DC. Time drift is gradual — a day is usually fine, but weekly checks catch problems early.
Also audit your PDC emulator's NTP configuration quarterly. It's the single point of failure for domain time. Use an authoritative external NTP pool like time.windows.com or pool.ntp.org, not random public servers.
Finally, if you're running virtualized DCs (most of us are), disable host time sync on every DC. It's not optional — the hypervisor's time injection breaks Kerberos in subtle ways over weeks.
Was this solution helpful?