Windows time synchronization investigation cheat sheet
Inspect time source, synchronization status, peer configuration and measured offset before forcing a clock change.
Windows 10/11 or Windows Server with Windows Time service. Domain hierarchy and virtualization can influence time sources.
Updated · Windows · 6 min read
| Command | What it does |
|---|---|
Get-Service W32Time | Check Windows Time service status |
w32tm /query /source | Read the currently reported time source |
w32tm /query /status /verbose | Inspect synchronization state and last success |
w32tm /query /configuration | Inspect effective time configuration and origin |
w32tm /query /peers | Inspect configured peer state |
w32tm /stripchart /computer:dc01.corp.example /samples:5 /dataonly | Sample offset against an approved reference |
Walkthrough
Use the affected machine and replace dc01.corp.example with an approved reference. Some queries need elevation; stripchart sends bounded probes. This workflow does not resync, reconfigure or set the clock.
Step 1: Check Windows Time service status
Get-Service W32Time
Record the service state on the affected host. A running service is not proof of synchronization, and a stopped service can reflect policy or trigger behavior. Correlate the state with configured time policy before proposing a restart.
Step 2: Read the currently reported time source
w32tm /query /source
Compare the source with the intended domain hierarchy or approved external reference. A local clock source may explain lack of external discipline, but its meaning depends on the host role, virtualization platform and intended design.
Step 3: Inspect synchronization state and last success
w32tm /query /status /verbose
Record last successful sync, stratum, source and any error fields. An old success time can indicate ongoing failure despite the service running. Interpret timestamps in their displayed timezone and compare with the reported incident window.
Step 4: Inspect effective time configuration and origin
w32tm /query /configuration
Review Type, NtpServer and settings attributed to policy versus local configuration. Domain members commonly follow domain hierarchy; manually setting public peers on every member can conflict with that design. Inspect first without changing settings.
Step 5: Inspect configured peer state
w32tm /query /peers
Compare peer addresses, mode, state and reachability context with the expected design. Peer presence does not prove recent successful synchronization. A domain-selected source and a manually configured peer list need not be identical.
Step 6: Sample offset against an approved reference
w32tm /stripchart /computer:dc01.corp.example /samples:5 /dataonly
Compare several offsets rather than a single measurement. Stripchart probes use their own client behavior, so successful samples do not prove that Windows Time synchronization traffic or policy is functioning. A timeout can reflect filtering or reference availability.
WORKED INCIDENT
Practical case: Authentication errors coincide with clock drift
Fictional teaching scenario; observations are examples, not captured production output.
Situation
One domain workstation reports authentication failures and its clock differs noticeably from nearby systems.
Investigation sequence
1. Check Windows Time service status
Get-Service W32TimeRecord Windows Time service status instead of immediately restarting it.
2. Read the currently reported time source
w32tm /query /sourceCompare the reported source with the expected domain hierarchy.
3. Inspect synchronization state and last success
w32tm /query /status /verboseCapture the last successful synchronization and error fields.
4. Sample offset against an approved reference
w32tm /stripchart /computer:dc01.corp.example /samples:5 /dataonlyMeasure offset against the approved reference. The example shows a persistent difference across all five samples.
Example findings
Illustrative findings: W32Time runs; the last successful sync is old; repeated offset measurements show a consistent several-minute difference.
Interpret the findings
Clock drift is supported, but the samples alone do not establish its root cause or prove every authentication failure is time-related. Investigate source selection, policy, network reachability and virtualization time integration.
Verify the outcome
After the owner restores the approved time path, confirm a recent successful sync and repeat offset samples. Retest the affected authentication flow and compare timestamps across the relevant logs.
Escalation handoff
Provide host role, source, policy origin, last sync and offset samples to the domain/platform owner. Coordinate any significant clock adjustment with application owners.