The first check should not be the date and time control panel. It should be the Windows Time source.

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

These commands show where Windows currently obtains time, when the last successful synchronisation occurred and whether the effective configuration comes from the local system or Group Policy.

How wrong is the clock?

A difference of a few seconds is not the same problem as a clock that is several minutes, hours or years wrong.

Small offsets may indicate normal drift, an unsuitable polling interval or a source that has only recently become available. A very large difference usually points to a more fundamental problem such as an incorrect host clock, an old snapshot, a failed CMOS battery or a system that has not synchronised for a long period.

Compare the local computer with a known source:

w32tm /stripchart /computer:0.uk.pool.ntp.org /samples:5 /dataonly

Replace the pool name with the intended internal or external source where appropriate. The command measures the offset without changing the local configuration.

Check the selected source

The clock can be wrong because Windows has selected the wrong source or because it has no usable network source at all.

Common results that require further investigation include:

  • Local CMOS Clock
  • Free-running System Clock
  • VM IC Time Synchronization Provider where Active Directory should be authoritative
  • An unexpected domain controller
  • An old or decommissioned manual peer

If the reported source is wrong, use The Time Source Is Wrong rather than continuing to adjust the clock itself.

Check the last successful synchronisation

Run:

w32tm /query /status

Pay particular attention to:

  • Source
  • Last Successful Sync Time
  • Leap Indicator
  • Stratum

A recent successful sync with the intended source suggests that the problem may have been temporary. An old or missing synchronisation time indicates that Windows has not received usable time data for some time.

Request a new synchronisation

Once the source and configuration look correct, request a new synchronisation:

w32tm /resync

If the computer may have retained an unsuitable domain source, use:

w32tm /resync /rediscover

A successful message confirms that the request was accepted. Check the source and status again afterwards to confirm that a successful synchronisation actually took place.

If Windows reports that no time data was available, continue with Synchronisation Fails.

Large time differences

Windows Time Service can either adjust the clock gradually or set it directly, depending on the size of the offset and the effective configuration.

Very large differences can also be rejected by phase-correction limits. Those limits exist to prevent a faulty source from moving the clock by an unreasonable amount.

Do not immediately increase MaxPosPhaseCorrection or MaxNegPhaseCorrection. First establish why the system became so far out of time and confirm that the intended source is trustworthy.

Typical causes include:

  • A virtualisation host with an incorrect clock.
  • A restored snapshot or resumed suspended VM.
  • A failed or weak CMOS battery.
  • A computer that has been disconnected for a long period.
  • An incorrect manual peer or DNS record.
  • A local hardware clock set to the wrong date.

Virtual machines

A virtual machine can be affected by both Windows Time Service and the hypervisor.

Check whether the guest has just started, resumed, migrated or been restored. Then verify the time on the current hypervisor host as well as inside Windows.

Where the guest is domain joined, the preferred design used throughout this site is for Windows Time Service to follow the Active Directory hierarchy while ongoing host-to-guest synchronisation is disabled.

Platform-specific guidance is available for:

Domain members

A domain member should normally use the Active Directory hierarchy. Its configuration should usually show:

Type: NT5DS

If the computer reports a manual Internet peer, local clock or hypervisor provider instead, correct the source rather than adjusting the displayed time.

Kerberos authentication normally expects domain computers to remain within the permitted time skew. A sufficiently large difference can therefore cause sign-in and service authentication problems before the clock is corrected.

Standalone and workgroup computers

A standalone computer has no domain hierarchy. It should use a valid manual peer or the Windows default Internet time configuration.

On some workgroup computers, the Windows Time service is trigger-started rather than running continuously. If the service repeatedly stops and the environment requires it to run whenever the network is available, review the trigger configuration:

sc qtriggerinfo w32time

A network-based trigger can be configured with:

sc triggerinfo w32time start/networkon stop/networkoff

This should only be changed where the default workgroup behaviour is unsuitable for the system.

Check the Windows Time service

Confirm that the service exists and can run:

sc query w32time

Restart it if necessary:

net stop w32time
net start w32time

If the service will not start, check the System log and whether a policy, service-hardening change or damaged registration is involved.

Check DNS and UDP port 123

Where Windows uses a hostname, confirm that it resolves to a sensible address from the affected computer.

Then test the intended server with w32tm /stripchart. A successful strip chart shows that a response was received, although it does not prove that Windows Time Service has selected the same source.

Remember that normal Windows Time synchronisation and stripchart do not use the UDP source port in exactly the same way. A firewall can therefore allow one test while blocking the other.

Hardware clock and CMOS battery

A physical computer that repeatedly loses the date or time while powered off may have a failed CMOS battery.

Windows Time Service can correct the clock once the operating system starts and reaches a source, but it cannot prevent the firmware clock from being wrong at power-on.

Replace the battery and correct the firmware clock rather than relying on Windows to repair the same fault after every boot.

After correcting the problem

Complete the troubleshooting by checking:

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

The clock should be correct, the selected source should match the intended design and the last successful synchronisation should be recent.

Microsoft documentation

Related information