Windows Time Synchronisation Fails

The most familiar error is:

The computer did not resync because no time data was available.

This message means that Windows Time Service did not obtain a usable time sample from any available source. Restarting the service may cause another attempt, but it does not correct an invalid peer, a blocked network path or a broken Active Directory hierarchy.

Check the current source and configuration

Begin with:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

If the source is Local CMOS Clock, Free-running System Clock or another unexpected provider, the synchronisation failure may be a symptom of the wrong configuration rather than a temporary network problem.

Check whether the computer should be using:

NT5DS for the Active Directory hierarchy.
NTP for a manual peer list.
A hypervisor integration provider by deliberate design.

Confirm the peer name

For a manually configured system, inspect the peer list in:

w32tm /query /configuration

Check for:

Misspelled hostnames.
Old server names.
Missing spaces between multiple peers.
Peer lists not enclosed in quotation marks.
Incorrect or unexplained flags.
A DNS name that now points to the wrong server.

A valid multiple-peer configuration looks similar to:

0.uk.pool.ntp.org,0x8 1.uk.pool.ntp.org,0x8 2.uk.pool.ntp.org,0x8

Check DNS resolution

Confirm that the affected computer can resolve the intended peer:

nslookup time.example.com

Where split DNS is used, test from the affected system rather than checking only the DNS console. The client may be receiving a different answer from another DNS server or retaining a cached address.

If the organisation uses a stable name such as time.example.com, confirm that its A, AAAA or CNAME record still leads to an active NTP service.

Test the NTP server directly

Use w32tm /stripchart to test whether a server responds:

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

If responses are received, the server is reachable and answering some form of NTP request. This does not prove that the normal Windows Time client can use it, but it helps separate DNS and basic reachability from configuration problems.

If the command times out, investigate DNS, routing, firewall rules and whether the target actually provides NTP.

Check UDP port 123

Windows Time Service uses UDP port 123 for normal NTP synchronisation.

Check:

Windows Defender Firewall on the client.
Host-based security software.
Perimeter firewall rules.
Inter-VLAN access controls.
Cloud network security groups.
Whether the NTP server permits the client's network.

Because UDP is connectionless, a simple port scan is not always conclusive. A packet capture is often the clearest test. Look for an outbound request to UDP 123 and a reply from the server.

Windows Time Service normally uses UDP 123 as both its source and destination port. A firewall rule that permits only arbitrary high source ports may therefore allow other NTP tools while blocking Windows Time Service.

Confirm that the server is synchronised

An NTP server can respond to requests while refusing to provide usable time because it is itself unsynchronised.

On another Windows server, check:

w32tm /query /source
w32tm /query /status

On a Chrony server, useful checks include:

chronyc tracking
chronyc sources -v

A server reporting stratum 16, an unsynchronised leap indicator or no selected source should not be expected to provide valid time to clients.

Domain-joined computers

A normal domain member should use the Active Directory hierarchy rather than a manual public peer.

Return it to hierarchy discovery with:

w32tm /config /syncfromflags:domhier /reliable:no /update
w32tm /resync /rediscover

If that fails, identify the domain controller being used and confirm that the domain controller is itself synchronised and advertising correctly.

Check domain controllers from the top down

Begin with the forest root PDC Emulator:

Confirm that it holds the PDC Emulator role.
Confirm that it uses the intended external source.
Confirm a recent successful synchronisation.
Check that other domain controllers use the domain hierarchy.
Check the affected member computer last.

Useful commands include:

netdom query fsmo
w32tm /monitor
dcdiag /test:Advertising

If a domain controller is not advertising correctly, domain members may be unable to discover it as a valid time source.

The PDC Emulator has no usable source

If the forest root PDC Emulator cannot synchronise, the rest of the domain may eventually follow an inaccurate or free-running clock.

Check its peer list, DNS resolution and UDP 123 access. Then test each configured peer directly.

A typical configuration is:

w32tm /config /manualpeerlist:"0.uk.pool.ntp.org,0x8 1.uk.pool.ntp.org,0x8 2.uk.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update

Do not apply this command to every domain controller. It belongs only on the forest root PDC Emulator under the normal Active Directory design.

Check the Windows Time service

Confirm that the service is present and running:

sc query w32time

Restart it if appropriate:

net stop w32time
net start w32time

Then request rediscovery:

w32tm /resync /rediscover

If the service stops again on a standalone workgroup computer, check its trigger configuration:

sc qtriggerinfo w32time

Group Policy may be restoring the wrong settings

A local configuration change may appear to work and then disappear because Group Policy reapplies another peer list or synchronisation type.

The output from:

w32tm /query /configuration

shows whether many values come from local configuration or policy.

Where policy is the source, correct the Group Policy Object rather than repeatedly issuing local w32tm /config commands.

Peer mode and flags

Some public NTP servers expect Windows to send requests in client mode. The 0x8 flag explicitly selects that mode:

time.example.com,0x8

Old examples often use 0x1, which enables the special polling interval. Flags can also be combined, but they should not be copied without understanding their effect.

If a server answers stripchart but Windows Time Service still receives no usable data, peer mode is one of the items to review.

Large clock differences

A source can be reachable and valid while Windows refuses a very large correction because of phase-correction limits.

Check the offset first:

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

If the difference is extremely large, investigate why before changing MaxPosPhaseCorrection or MaxNegPhaseCorrection. Common causes include an incorrect hypervisor clock, restored snapshot, failed CMOS battery or a machine that has been disconnected for a long time.

Virtual machines

Where the affected system is virtual, verify the hypervisor host clock and review whether the guest tools are also correcting time.

A guest may report a valid Windows source but then be changed by Hyper-V, VMware Tools or another guest agent. Conversely, a resumed VM may start so far behind that Windows cannot immediately recover.

Use the relevant platform guide:

Review the event logs

Check:

Windows Logs > System, filtered for Microsoft-Windows-Time-Service.
Applications and Services Logs > Microsoft > Windows > Time-Service > Operational.

Look for repeated failures to resolve a peer, receive a response, select a source or advertise time. A single warning during startup is less important than a fault that continues for hours or days.

Avoid unregistering the service too early

The following sequence is widely copied as a general repair:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

This resets the Windows Time service registration and can remove deliberate configuration. It should not be the first response to a failed synchronisation.

Use it only after the source, network path, policy and service configuration have been checked and there is evidence that the service registration itself is damaged.

Verify the result

After correcting the cause, run:

w32tm /resync /rediscover
w32tm /query /source
w32tm /query /status
w32tm /query /configuration

A successful outcome requires more than the resync command completing. Confirm that the intended source has been selected and that the last successful synchronisation is recent.