Fix Windows Server Time Sync: w32time Troubleshooting 2026

Okay, let me be real with you — I just wrapped up a two-day chase over a Windows Server clock that kept drifting no matter what we threw at it, and when I finally cracked the case, I actually laughed out loud. The fix was stupidly simple. And here’s the best part: the same 15-minute routine resolves about 90% of the time sync problems I see across our entire VPS fleet. I’m genuinely pumped to walk you through it!

Here’s the scene from last week. One of our client servers was showing six minutes of drift. Kerberos auth was failing, users couldn’t log in, and the app team was already pointing fingers at the network. Sound familiar? Yeah, I thought so. Turned out it wasn’t the network at all — the Windows Time service had silently given up syncing ages ago, and nobody had bothered to check. That’s it. That’s the whole story. Six minutes of chaos over a service that takes a couple of commands to fix.

Why a Drifting Server Clock Is a Way Bigger Deal Than It Looks

So here’s the thing about time on Windows Server — it is absolutely not cosmetic. Push a clock past five minutes of skew and Kerberos authentication falls over completely. Domain logons fail, service accounts stop talking to each other, RDP starts rejecting you, and TLS certificates suddenly look invalid even though they’re perfectly fine. Scheduled jobs fire at the wrong hour and wreck your automation. Nobody thinks about time until everything stops working. And by then, the ticket is already on fire.

It gets worse in a domain environment, too. Every member server pulls its time from the domain controller holding the PDC Emulator role. If that single DC drifts, the whole domain drifts with it. I like to describe it like a neighborhood where everyone sets their watch by one big clock tower in the square. If the tower is wrong, every appointment in town is wrong. That’s your Active Directory on a bad day.

In my experience, the usual suspects are always the same handful of culprits: (1) the Windows Time service never actually ran, or got kicked sideways after a Windows Update, (2) the NTP source is misconfigured or blocked on UDP 123, (3) the PDC Emulator isn’t marked as a reliable time source, (4) the timezone was wrong from day one, or (5) the hypervisor’s time sync (VMware Tools or Hyper-V Integration Services) is fighting w32time for control of the clock. If even one of those rings a bell, keep reading — this guide is exactly what you need, and honestly, the fix part is fun once you see how clean it is.

Let’s Fix It: Step-by-Step w32time Configuration

Alright, sleeves up. Every command below runs from an elevated Command Prompt or PowerShell — skip the admin part and you’ll get nothing but permission errors. And before you start, pick a couple of solid public NTP servers. You’ll want more than one, and I’ll explain why in a minute.

Step 1: Diagnose Before You Touch Anything

I can’t stress this enough: check first, change second. Jumping straight into reconfiguration without knowing your current state is how you end up deeper in a hole than when you started. Run these three commands:

w32tm /query /status
w32tm /query /source
w32tm /query /peers

A healthy output looks something like this:

Leap Indicator: 3(not synchronized)
Stratum: 2 (secondary reference - syncd to (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0624813s
Root Dispersion: 0.0294113s
ReferenceId: 0x0A000001 (source IP: 10.0.0.1)
Last Successful Sync Time: 2026-08-03 07:15:22
Source: 10.0.0.1 (PDC)

Now here’s what to look for. If you see Leap Indicator: 3(not synchronized), or worse, Source: Local CMOS Clock or Source: VM IC Time Synchronization Provider, your server is not getting time from any real NTP source. “Local CMOS Clock” means the box is keeping time with its own little battery clock and hoping for the best. I see it on VPS servers all the time. That’s your problem right there, in plain sight.

Oh, and do yourself a favor — check the timezone while you’re in there:

tzutil /g

You’d be shocked how many “clock drift” tickets turn out to be a wrong timezone from a server that was provisioned abroad. If it’s wrong, fix it with a single command:

tzutil /s "SE Asia Standard Time"

Step 2: Stop the Hypervisor From Wrestling With w32time

This is the sneakiest one, and it only shows up when your Windows Server is a VPS or a VM. VMware Tools and Hyper-V Integration Services both sync the guest clock on their own, completely separate from w32time. Neither knows the other exists, so they keep yanking the clock back and forth. The worst part? It doesn’t show up as a clear error in Event Viewer. You just see clock jumps and weird drift, and it’s so easy to misdiagnose.

Here’s the principle, and it’s dead simple: pick one timekeeper and switch the other off. If w32time is the boss — which I recommend for domain-joined servers — disable the hypervisor sync. On Hyper-V, turn off “Time Synchronization” under Integration Services. On VMware, disable host time sync from the guest properties or set these two options in the VMX file:

time.synchronize.tools = FALSE
time.synchronize.resume.disk = FALSE

And honestly, some teams do it the other way around — disable w32time and let the hypervisor own the clock. That’s totally valid for standalone VPS boxes. Just don’t run both. Both-on is where the madness lives. You’ll be chasing your tail for days wondering why the clock keeps bouncing.

Step 3: Point w32time at Real NTP Servers

For standalone servers, set external NTP peers. This is the command I type in my sleep now:

w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual /update

Quick note on the 0x8 flag, because nobody ever explains it. It tells w32time to talk to that peer in NTP client mode instead of symmetric active mode. Public NTP servers often reject symmetric mode, so skipping 0x8 is a classic way to make sync fail for no obvious reason. Don’t be that person.

Now bounce the service and force a resync:

net stop w32time
net start w32time
w32tm /resync /rediscover

This restart only touches the time service — it won’t disturb anything else running on the box. Still, if you can, do it outside peak hours so you have room to breathe if anything looks off.

Then verify the source changed:

w32tm /query /source

If it no longer says “Local CMOS Clock” and shows a real NTP hostname or IP, you’re on the right track. Honestly, that exact moment when you see the source flip is the most satisfying thing in this whole job. Small wins, right?

Step 4: In a Domain? Make the PDC Emulator the Time Boss

In Active Directory, time flows in two layers. The PDC Emulator syncs from an external NTP source, and every other server syncs from the PDC. So on the PDC Emulator, make sure it announces itself as a reliable source:

reg add HKLMSYSTEMCurrentControlSetServicesW32TimeConfig /v AnnounceFlags /t REG_DWORD /d 5 /f
reg add HKLMSYSTEMCurrentControlSetServicesW32TimeParameters /v NTPServer /t REG_SZ /d "time.windows.com,0x8 pool.ntp.org,0x8" /f
w32tm /config /syncfromflags:manual /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /reliable:YES /update
net stop w32time && net start w32time
w32tm /resync /rediscover

And on every other member server, tell it to sync from the domain hierarchy instead of chasing external servers on its own:

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /resync /rediscover

Don’t get this backwards. PDC goes out to the world, members go inward to the PDC. I’ve walked into environments where someone set every member server to sync from different external NTP pools, and surprise surprise — servers ended up disagreeing with each other because they were chasing sources with different drift. Trust broke down across the domain and everyone blamed the network. It was the time config all along.

Step 5: Don’t Forget UDP 123

NTP lives on UDP port 123. If anything between your server and the NTP server blocks that port — Windows Firewall, your VPS provider’s firewall, an iptables rule on the hypervisor — w32time fails silently. It’s one of the most overlooked causes out there, precisely because there’s no screaming error. It just quietly refuses to sync.

Windows Firewall usually ships with a “Windows Time Service” rule for UDP 123. If it’s missing or disabled, add it manually:

netsh advfirewall firewall add rule name="NTP Outbound" dir=out action=allow protocol=UDP remoteport=123
netsh advfirewall firewall add rule name="NTP Inbound" dir=in action=allow protocol=UDP localport=123

Then test the actual NTP path with my absolute favorite debugging tool — stripchart. It’s simple, and it tells you everything:

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

If you get timeouts or ICMP errors on every sample, the network path to the NTP source is your problem. Check firewalls and routes. If you see tiny offsets like +0.01s, your connectivity is perfect and the issue is configuration — so keep going with the next steps.

Step 6: The Nuclear Option — Full Service Reset

SECURITY WARNING: Backup Before Proceeding — Before we go here, let’s be careful: this step unregisters the w32time service. It only stores state in the registry, so the risk is low, but a backup takes ten seconds and saves you from a bad afternoon. Export the key first:

reg export HKLMSYSTEMCurrentControlSetServicesW32Time C:backupw32time-registry-backup.reg /y

Verify the file actually exists and looks right. If anything goes wrong later, a double-click on that .reg restores everything in seconds. Never skip this verification step — it’s cheap insurance.

Now the full reset:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual /update
net stop w32time && net start w32time
w32tm /resync /rediscover

This clears out any corrupted service state — like a service that got stuck after a Windows Update, or stale registry settings from a config you changed months ago. Honestly, this one move fixes most of the stubborn cases I see. It’s become my go-to whenever the polite steps fail.

Step 7: Tune the Sync Interval (Optional)

If everything works but the clock still drifts a little, tighten the polling interval. Here’s a fun fact: the default UpdateInterval on Windows Server is 300,000 seconds — but don’t panic, that only controls how often w32time samples the offset from its peers, not how often it polls the NTP server. The real polling is governed by SpecialPollInterval, which defaults to 3,600 seconds (one hour). For servers that need tight time, drop it:

reg add HKLMSYSTEMCurrentControlSetServicesW32TimeParameters /v SpecialPollInterval /t REG_DWORD /d 3600 /f
reg add HKLMSYSTEMCurrentControlSetServicesW32TimeConfig /v UpdateInterval /t REG_DWORD /d 300 /f
net stop w32time && net start w32time
w32tm /resync /rediscover

SpecialPollInterval of 3600 means polling every hour; 900 means every 15 minutes. Don’t go lower than that against public NTP pools, or operators will quietly stop serving you. And leave UpdateInterval alone unless you really know what you’re doing.

Reading W32Time Event Logs Like a Pro

If you’ve done all of the above and something still feels off, read the logs. W32Time writes to Event Viewer, System log, with the source “W32Time”. Here’s a sample of what I run into constantly:

Level: Warning, Event ID 36
Provider: W32Time
The time service has not synchronized the system time for 86400 seconds
because none of the time providers has been able to provide a usable
time stamp. The system time is not synchronized.

Level: Error, Event ID 50
Provider: W32Time
The time service encountered a serious problem and was forced to shut down.
The error code was: 0x80070005

Level: Warning, Event ID 12
Provider: W32Time
The time provider NtpClient is configured to acquire time from one or more
time sources, however none of the sources are currently accessible.

Level: Information, Event ID 35
Provider: W32Time
The time service is now synchronizing the system time with the time source
192.0.2.10 (ntp.example.net).

Let me walk you through how I read these, top to bottom:

• Event ID 12 (Warning): the symptom. NtpClient can’t reach any time source. The usual culprits: firewall blocking UDP 123, DNS failing to resolve the NTP hostname, or the NTP server being down.
• Event ID 36 (Warning): the pattern. It’s been 86,400 seconds — a full 24 hours — since the last successful sync. The drift has been compounding the whole time. This is Event ID 12’s evil sequel.
• Event ID 50 (Error): the root cause when it appears. 0x80070005 is access denied, meaning w32time is running with the wrong permissions — usually a bad service account or a heavy-handed security policy.
• Event ID 35 (Information): the good news. The server is syncing again. If this shows up after your fix, you’re done. Pop the champagne.

You can also enable w32time’s debug log for a deeper look:

w32tm /debug /enable /file:C:WindowsTempw32time.log /size:10000000
w32tm /debug /disable

Then read C:WindowsTempw32time.log to see exactly which provider failed and why. It’s a great way to close tickets with actual receipts instead of “I restarted it and hoped for the best.”

Quick Troubleshooting Reference Table

Symptom	Likely Cause	Fix
w32tm /query /source shows “Local CMOS Clock”	No NTP source ever configured	Set manualpeerlist + /syncfromflags:manual, then resync
Event ID 12 keeps appearing	UDP 123 blocked or NTP DNS failing	Check firewall, verify with w32tm /stripchart
Drift keeps growing over time	w32time not running or polling inactive	Reset service and tune SpecialPollInterval
Clock bouncing back and forth on a VM	Hypervisor time sync fighting w32time	Disable VMware Tools / Hyper-V time sync
Member servers disagree with each other	All set to sync external sources	Switch to /syncfromflags:domhier, sync from PDC
Event ID 50 with 0x80070005	Wrong service account or permissions	Check service logon, export registry, reset service
w32tm /resync keeps failing	NTP source down or unreachable	Swap NTP source and verify with stripchart

Pro Tips From the Field

After handling hundreds of these cases, I’ve collected a few small things that make a huge difference. Here they are, free of charge:

• Never use the VPS hardware clock as a time source. The RTC on a virtual machine is shared and drifts almost by definition. Always point to real NTP.
• Configure at least two NTP sources. If one dies, you still have a fallback. But don’t overdo it — two or three is plenty.
• Log your config changes. This is the secret to painless root cause analysis. If the clock drifted on day X and you changed the firewall on day X-1, the connection is obvious.
• For KVM VPS, make sure the virtio agent or vendor package isn’t overriding time. Every vendor behaves a little differently — check their docs.
• Add a time check to your post-reboot checklist. After patch Tuesday or any maintenance, run w32tm /query /status. Drift loves to appear right after a reboot because of service start order.

Oh, and while you’re on the server anyway, if it’s also fighting high load or you’re blind without monitoring, check out our high load VPS troubleshooting guide and the Netdata and Grafana monitoring article. These three topics love to show up in the same ticket, trust me.

Related Articles

For more depth, these are all part of the same server-management family:

• Safe Backup and Restore for Windows Server
• PowerShell Scripting Basics for Server Admins
• Step-by-Step High Load VPS Troubleshooting
• Server Monitoring with Netdata and Grafana

FAQ: Windows Server Time Sync and w32time

Alright, go try it! Trust me, when you run that resync and watch the source flip from Local CMOS Clock to a real NTP server, you’ll grin. And while you’re at it, check the other servers in your fleet — I guarantee you’ll find at least one box quietly drifting. This is the good stuff. Let’s keep those clocks honest!