w32tm is the command line front end to the Windows Time service. It reports where a machine gets its time, how far off it is, and whether the last synchronisation actually worked. On a standalone PC none of that matters much. In a domain it decides whether Kerberos issues tickets at all.
Time problems rarely announce themselves as time problems. They arrive as logons that fail on one server, a scheduled task that runs an hour early, replication errors with code 8453, or a workstation that suddenly cannot find the domain. By the time someone checks the clock, the trail is cold.
The syntax is well documented. What is not documented is how to read the output, which line actually tells you the machine is not syncing, and why a domain controller running on a hypervisor can report a perfectly healthy state while drifting with its host. That is what this page is about.
Applies to: Windows 10 / 11 and Windows Server 2016 / 2019 / 2022 / 2025
Quick answer
Three commands answer the first three questions: is this machine synced, is anything in the domain drifting, and can I force it to catch up right now.
rem What this machine thinks about its own clock and its source
w32tm /query /status
rem Offset of every DC in the domain, measured from here
w32tm /monitor
rem Force a resync, rediscovering the source first in case the old one is gone
w32tm /resync /rediscoverAll three run from an elevated prompt. The first two change nothing. /resync only asks the service to synchronise now, which is safe on any machine.
How time flows in a domain
Everything else in this article makes sense only against this hierarchy. Windows time in an Active Directory forest is a chain, and every machine has exactly one correct place in it.
| Role | Correct time source | Configured with |
|---|---|---|
| PDC emulator of the forest root domain | External NTP server or a hardware clock | /syncfromflags:manual |
| Other domain controllers | The domain hierarchy | /syncfromflags:domhier |
| Member servers and workstations | Their authenticating DC | Default, nothing to configure |
| Virtual machines on Hyper-V | The domain hierarchy, not the host | Integration service disabled |
One machine at the top talks to the outside world. Everything else follows the chain. When someone configures an external NTP server on a random member server “to be safe”, they have created a second, competing source, and that is the cause of a surprising share of time incidents.
What w32tm does
w32tm does not keep time itself. It queries and configures the W32Time service, which does. These are the parameters that carry the work.
| Parameter | What it gives you | Read or write |
|---|---|---|
/query /status | Source, stratum, last successful sync, current offset | Read |
/query /source | Just the source, one line, ideal for scripts | Read |
/query /configuration | Every effective setting and where it came from | Read |
/query /peers | Configured peers and whether each one is active | Read |
/monitor | Offset of every DC in the domain, measured from here | Read |
/stripchart | Repeated offset samples against one named computer | Read |
/resync | Synchronise now instead of at the next poll | Write |
/config | Set the source, the peer list and the reliability flag | Write |
/register, /unregister | Reinstall the service and its default configuration | Write |
Practical examples
1. Is this machine synced, and to what?
The problem: Users on SRV-APP01 are getting intermittent access denied messages against a file share. You suspect time, but the clock on screen looks right.
The solution: /query /status shows the source and the last successful synchronisation. The clock looking right is not evidence of anything, because a machine can hold a correct time and still have stopped syncing weeks ago.
w32tm /query /statusLeap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0312500s
Root Dispersion: 7.7757617s
ReferenceId: 0x0A0A0A05 (source IP: 10.10.10.5)
Last Successful Sync Time: 04/09/2026 21:14:03
Source: SRV-DC01.corp.local
Poll Interval: 10 (1024s)Three lines carry the answer. Source should name a domain controller on a member server. Last Successful Sync Time should be within roughly one poll interval. Stratum should be one higher than the source’s stratum.
Local CMOS Clock or Free-running System Clock, the machine is not synchronising with anything and never will on its own. The service is running, nothing is logged as an error, and the clock drifts quietly until Kerberos gives up.
2. Which machine in the domain has drifted?
The problem: Logon failures are reported from several sites but not all. You need to know which domain controller is the odd one out before touching anything.
The solution: /monitor queries every DC in the domain and prints the offset of each one relative to the machine you run it from.
rem No arguments means the current domain; the PDC is marked with an asterisk
w32tm /monitorsrv-dc01.corp.local *** PDC ***[10.10.10.5:123]:
ICMP: 0ms delay
NTP: +0.0000000s offset from srv-dc01.corp.local
srv-dc02.corp.local [10.10.20.5:123]:
ICMP: 12ms delay
NTP: -0.0138900s offset from srv-dc01.corp.local
srv-dc-br1.corp.local [10.10.30.5:123]:
ICMP: 31ms delay
NTP: +284.9021500s offset from srv-dc01.corp.localOffsets in milliseconds are healthy. The branch DC at 284 seconds is four minutes and forty-four seconds out, which is inside the five minute Kerberos tolerance today and outside it tomorrow. That is the machine to fix.
3. Measure the offset before you change anything
The problem: You are about to reconfigure a time source and want a number you can compare against afterwards, not an impression.
The solution: /stripchart samples the offset against one computer repeatedly. Ten samples take twenty seconds and give you a before and after you can put in the ticket.
rem /dataonly drops the ASCII graph, which is unreadable in a log file anyway
rem /samples:10 stops after ten measurements instead of running until Ctrl+C
w32tm /stripchart /computer:SRV-DC01.corp.local /samples:10 /dataonly/stripchart speaks NTP over UDP 123. If it returns an error while ping to the same host works, the port is filtered somewhere in between, which is a firewall finding rather than a time finding.
4. Point the PDC emulator at an external source
The problem: The whole forest is internally consistent but forty seconds behind real time, because the PDC emulator has never been given an external source.
The solution: Configure a manual peer list on the PDC emulator only, mark it as a reliable source for the domain, and restart the service so the change takes effect.
rem 0x9 = SpecialInterval + Client: poll on a fixed interval, act as an NTP client
rem /reliable:yes tells the domain this DC is an authoritative time source
w32tm /config /manualpeerlist:"0.pool.ntp.org,0x9 1.pool.ntp.org,0x9" /syncfromflags:manual /reliable:yes /update
rem The service has to restart before the new peer list is used
net stop w32time && net start w32time
rem Confirm the change took, then check the peers are actually answering
w32tm /query /source
w32tm /query /peers5. Put a machine back on the domain hierarchy
The problem: Someone configured an external NTP server on a member server years ago. It is now the machine that disagrees with everyone else.
The solution: Clear the manual configuration and hand the machine back to the domain. This is the undo for example 4, and it is the fix for most single-machine drift.
rem An empty peer list plus domhier returns the machine to the default behaviour
w32tm /config /manualpeerlist:"" /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /resync /rediscover
w32tm /query /statusIf the configuration is badly tangled, or the service refuses to start, the clean reset is to unregister and register it. That rebuilds the registry configuration from the defaults.
rem Last resort: removes the service configuration and rebuilds it from defaults
w32tm /unregister
w32tm /register
net start w32time
w32tm /resync /rediscover/query /status names a domain controller as the Source and shows a Last Successful Sync Time within the last few minutes. That is the state to confirm before closing the ticket.
Hidden gems
A healthy service is not a synced clock. W32Time reports no error when it has no source. The only reliable evidence is the Source line and the Last Successful Sync Time in /query /status. Monitoring that checks whether the service is running is monitoring the wrong thing.
/resync without /rediscover reuses a dead source. The classic failure is “The computer did not resync because no time data was available”, on a machine whose old source was decommissioned. /rediscover makes it re-detect the network configuration and find a current source instead of retrying the ghost.
A virtualised domain controller can be lying to you. If the hypervisor time synchronisation integration service is enabled, the guest can be nudged by the host clock while W32Time still reports a clean domain sync. On Hyper-V, disable time synchronisation in the VM integration services for domain controllers, and let the domain hierarchy own the clock. This is worth checking first on any DC whose offset moves without explanation.
/query /configuration tells you where a setting came from. Each value is annotated as Local or Policy. That single word settles the argument about whether a Group Policy object is overriding the local configuration, which otherwise takes twenty minutes of guessing.
Stratum is a sanity check. A machine should sit exactly one stratum below its source. A member server showing the same stratum as its DC, or a stratum of 0, is not really synchronising through the hierarchy no matter what the Source line says.
PowerShell equivalent
There is no PowerShell module for the time service, so w32tm stays the tool. PowerShell is still the better wrapper when you need to ask the same question of many machines at once.
# Collect the source and last sync from a list of servers in one pass
$servers = "SRV-APP01","SRV-APP02","SRV-FILE01"
Invoke-Command -ComputerName $servers -ScriptBlock { w32tm /query /status } |
Select-Object PSComputerName, @{n='Line';e={$_}} |
Where-Object Line -match 'Source|Last Successful'
# Compare wall clocks directly, which catches a machine whose service is stopped
Get-CimInstance Win32_OperatingSystem -ComputerName $servers |
Select-Object PSComputerName, LocalDateTime
# The service itself, when you need to confirm startup type as well as state
Get-Service w32time | Select-Object Name, Status, StartTypeWhere this matters
- Kerberos authentication failures. Five minutes of skew is the default ceiling. Past it, tickets are refused and the symptom looks like a permissions problem.
- Active Directory replication errors. Replication authenticates with Kerberos, so a skewed DC fails with 8453 against several partners at once. Check time before digging into the repadmin output.
- Certificate validation. A clock ahead of real time rejects a certificate that is not yet valid; a clock behind accepts one that has expired.
- Log correlation during an incident. Events from three servers cannot be put in order if their clocks disagree, and nobody discovers this until they are trying to build the timeline.
- Backup and scheduled task windows. A job that fires an hour early against a system that is not ready is a time problem wearing a scheduling costume.
Tips and limitations
- Every
/configchange needs an elevated prompt, and the service must be restarted before a new peer list is used./updatealone is not always enough. - NTP uses UDP 123 in both directions. A firewall that allows outbound but drops the reply produces a machine that looks configured and never syncs.
/monitorcovers domain controllers only. To check member servers you need/stripchartagainst each one, or a remote/query /status.- Time zone and clock are separate concerns.
w32tm /tzshows the zone; a machine can hold perfect UTC and still display the wrong local time. - The System log source Time-Service carries the useful events. Event 36 warns that the time service has not synchronised, 47 that no response came from a peer, and 50 that the clock was corrected by a large amount.
- Group Policy under Computer Configuration, Administrative Templates, System, Windows Time Service overrides local settings silently.
/query /configurationis the fastest way to see it.
Official documentation
- Windows Time Service Tools and Settings | Microsoft Learn
- w32tm /resync fails with no time data available | Microsoft Learn
Related tools
- nltest Command Builder: builds the query that tells you which DC holds the PDC emulator role, which is the machine the time hierarchy hangs from.
- Windows Event Log Analyzer: for pulling the Time-Service events out of a System log export instead of scrolling Event Viewer.
- Network Diagnostics Tool: confirms an external time source is reachable at all before you spend an hour on W32Time configuration.
Related guides
- Active Directory Troubleshooting Cheat Sheet: every command on this page, plus the rest of the AD toolkit, on one printable sheet.
- klist in Windows: read and clear the Kerberos ticket cache: the ticket cache that a clock more than five minutes out stops Windows from filling.
- repadmin in Windows: check, read and force Active Directory replication: the tool you reach for once time is ruled out and replication is still failing.
- DCDiag: how to diagnose and fix Active Directory problems: includes the tests that flag a domain controller as an unreliable time source.
- How to fix the trust relationship between a workstation and the domain: another authentication failure that starts somewhere other than authentication.
- nltest command in Windows: domain controller discovery and trust diagnostics: for confirming which DC a machine actually authenticates against.