Fix STATUS_TIME_DIFFERENCE_AT_DC (0XC0000133) Fast

What Actually Triggers 0xC0000133

This error pops up when you try to join a domain or authenticate against a Windows Domain Controller and the machine's clock is off by more than 5 minutes. Kerberos checks timestamps for replay protection — if the difference exceeds the default skew, it slams the door. You'll see it on first-join attempts, after a DC migration, or when a VM's clock drifts because its host doesn't sync NTP.

30-Second Fix: Quick Time Sync

Works for: Time drift under 15 minutes, no NTP server configured.

Open Command Prompt as Admin and run:

w32tm /resync

If it says "The computer did not resync because no time data was available," skip to the 5-minute fix. Otherwise, check your clock — it should snap to the DC's time. Try reconnecting to the domain right away. The reason this works sometimes is because w32tm /resync forces the Windows Time Service to grab the time from its configured source — usually the DC if you're on a domain-joined network already, or a fallback NTP server.

5-Minute Fix: Force Sync to a Reliable NTP Source

Works for: w32tm /resync fails, or you need to set a specific time source.

1. Open an admin Command Prompt.
2. List current time service status:

w32tm /query /status

Look at "Source" — if it's "Local CMOS Clock" or blank, the machine isn't pulling time from anywhere useful.

3. Set the DC or a reliable NTP server as your source:

w32tm /config /manualpeerlist:"yourDC.yourdomain.com,pool.ntp.org" /syncfromflags:manual /reliable:yes /update

Replace the peer list with your actual domain controller's FQDN or an internal NTP server. pool.ntp.org is a fallback — fine for testing. The /syncfromflags:manual flag tells the service to use only the peers you listed, not AD topology.

4. Restart the Time Service and resync:

net stop w32time && net start w32time
w32tm /resync

5. Verify sync worked:

w32tm /query /source

You should see your DC or NTP server name. If it still shows "Local CMOS Clock," check the service isn't disabled — run services.msc, find "Windows Time," set Startup Type to "Automatic" and start it.

15-Minute Fix: Registry Deep Clean and Service Reset

Works for: Persistent drift, corrupted time service state, or after a domain re-join failure.

This is the nuclear option — it resets the Windows Time Service config entirely.

1. Open an admin CMD.
2. Stop the service and unregister it:

net stop w32time
w32tm /unregister

3. Delete the registry key that holds time configuration:

reg delete HKLM\SYSTEM\CurrentControlSet\Services\W32Time /f

Be careful — this is the whole service tree. If you've set custom NTP servers or policies, they'll be gone. But for a broken state, it's often the only way.

4. Re-register the service — it rebuilds the default registry entries:

w32tm /register

5. Start the service and configure it:

net start w32time
w32tm /config /manualpeerlist:"yourDC.yourdomain.com,pool.ntp.org" /syncfromflags:manual /reliable:yes /update

6. Resync and verify:

w32tm /resync
w32tm /query /status

If you're still hitting 0xC0000133 after this, check the client's time zone matches the DC's. A time zone offset of +5:00 vs +0:00 can cause a 5-hour gap — Kerberos sees that as a massive skew. Run tzutil /g to see your current time zone, and tzutil /l to list all zones. Change with tzutil /s "Eastern Standard Time" or whatever matches your DC.

Why This Error Happens at Scale

Virtual machines are notorious for this. If your hypervisor doesn't sync time to the host, or the host's clock drifts, every guest will eventually fall out of sync. On VMware, check that "Time Synchronization" is enabled in the VM's guest properties. On Hyper-V, ensure the guest integration services are up to date — the Time Synchronization service is part of that package.

Also check if Group Policy is overriding your local time config. Run gpresult /h gp.html and look under "Windows Time Service" — if there's a policy enforcing a specific NTP server, that takes precedence over manual settings. In that case, fix the policy, not the local config.

One more thing: firewalls. NTP uses UDP port 123. If your firewall blocks outbound UDP 123 to the DC or NTP server, the resync commands will fail silently. Test with telnet yourDC 123 won't work — it's UDP. Instead, use Test-NetConnection -ComputerName yourDC -Port 123 -InformationLevel Detailed in PowerShell. If it shows "TcpTestSucceeded: False," that's expected for UDP; but if the packet doesn't reach, you'll see no response. For UDP, better to use w32tm /stripchart /computer:yourDC /dataonly /samples:3 — that NTP-specific tool sends a proper time request and reports round-trip delay. No response = firewall block.