Start by checking the source Windows has actually selected:

w32tm /query /source

Then check the status and effective configuration:

w32tm /query /status
w32tm /query /configuration

The configured peer list shows what Windows has been told to use. The source shows what it is using now. Those are not always the same thing.

What should the source be?

The expected source depends on the role of the computer:

  • Domain workstation or member server: normally a domain controller selected through the Active Directory hierarchy.
  • Domain controller: normally another suitable domain controller through the hierarchy.
  • Forest root PDC Emulator: an approved external NTP source or deliberate internal reference.
  • Standalone server: one or more manually configured NTP peers.
  • Standalone workstation: the Windows default Internet source or another deliberate source.
  • Virtual machine: normally the same source expected for its Windows role, unless host time is intentionally part of the design.

The Windows default: time.windows.com

A standalone Windows client or server is normally configured to use:

time.windows.com,0x1

There is nothing inherently wrong with time.windows.com. It is a valid default for a home PC or an unmanaged standalone system with reliable Internet access.

In managed environments, however, many administrators replace it. Typical alternatives include:

  • The NTP Pool Project.
  • An approved public NTP service.
  • An internal Windows Server.
  • A firewall, router or NAS providing NTP.
  • A Chrony server.
  • A GPS-backed local source.

The reason is usually not that time.windows.com is inaccurate. Administrators often want a source they control, can monitor, can use consistently across Windows and network devices, or can retain during an Internet outage.

Changing the default should therefore be a deliberate design choice rather than a reflex. For a single home computer, the Windows default may be entirely adequate. For a business network, using one documented organisational source is usually easier to support.

Use a stable organisational name

Where an organisation has its own preferred time service, publish it through a stable DNS name such as:

time.example.com

Configure clients with that name rather than the hostname of a particular Windows Server, Linux host or appliance.

If the underlying implementation changes, only the DNS record needs updating. This avoids revisiting every workstation, server, hypervisor, switch, firewall, UPS and other device that uses the service.

The DNS name can initially point to a local Chrony or Windows server and later be changed to another internal host or, where appropriate, an external NTP service.

Local CMOS Clock

If Windows reports:

Local CMOS Clock

the computer does not currently have a usable network time source.

This may appear briefly after startup while Windows Time Service is finding a source. If it remains in place, check:

  • Whether the configured peer names resolve.
  • Whether UDP port 123 is available.
  • Whether the peer answers NTP requests.
  • Whether the system is configured for NTP or NT5DS as appropriate.
  • Whether Group Policy is overriding the local settings.

On the forest root PDC Emulator, a persistent local-clock source should be treated as a configuration fault.

Free-running System Clock

Free-running System Clock also indicates that Windows is not currently synchronising with a usable external or domain source.

The system continues advancing its own clock, but drift will accumulate. Check the same areas as for Local CMOS Clock: source configuration, DNS, network access, service state and event logs.

VM IC Time Synchronization Provider

This source indicates that a Hyper-V integration provider is influencing the guest clock.

That may be intentional on a standalone virtual machine. On a domain member or virtual domain controller where Active Directory should be authoritative, it usually means the Hyper-V time synchronisation settings need reviewing.

See Windows Time on Hyper-V.

VMware Tools or another hypervisor source

VMware Tools may correct guest time periodically or after lifecycle events such as startup, migration, resume and snapshot restoration.

If the guest is domain joined, ongoing VMware Tools synchronisation is normally disabled under the design used throughout this site. Windows Time Service should then report a domain source.

Other hypervisors use different mechanisms. Proxmox VE relies on QEMU/KVM and the QEMU Guest Agent, while XCP-ng and XenServer use Xen guest tools. Do not assume that one platform's setting has an exact equivalent on another.

An unexpected domain controller

A domain member does not have to report the nearest server by name, and it does not need to report the forest root PDC Emulator directly.

Windows selects a suitable domain source through the hierarchy. An unexpected domain controller is not automatically wrong if the resulting path still leads upwards to the authoritative source.

Investigate when:

  • The reported server has been decommissioned.
  • The source belongs to the wrong or an unreachable site.
  • The member has retained a manually configured peer.
  • The source does not itself follow the domain hierarchy.

To return a domain member to automatic hierarchy discovery, run:

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

An old manual peer

A machine may retain a manual peer from an earlier role or configuration. This is common after:

  • A standalone server is joined to a domain.
  • A former PDC Emulator loses the FSMO role.
  • An old Group Policy remains linked.
  • A server is rebuilt or repurposed.
  • A time appliance is decommissioned.

Check the effective configuration to determine whether the value comes from the local registry or Group Policy:

w32tm /query /configuration

If the value is supplied by policy, local w32tm /config changes may not remain in effect.

The PDC Emulator is using a domain source

The forest root PDC Emulator cannot continue upwards through Active Directory because it is already at the top of the hierarchy.

If it reports another domain controller, the local clock or a virtualisation provider, configure it with the approved external or internal reference:

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

Restart the service where appropriate, request a resynchronisation and verify the selected source afterwards.

See Configuring the PDC Emulator for the full procedure.

The source name resolves to the wrong server

Where clients use an organisational name such as time.example.com, confirm that DNS still points to the intended service.

A stale A record, CNAME or split-DNS entry can silently direct clients to an old server. Check resolution from the affected computer rather than relying on the DNS console alone.

After changing DNS, allow for caching and then test the name directly:

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

Change a standalone system to another source

To replace time.windows.com on a standalone system, configure a deliberate peer list:

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

Use the organisation's own approved sources where they exist. Do not copy a list of public servers from an old article without confirming that they still welcome the intended use.

Verify the correction

After changing the source, run:

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

Confirm that:

  • The selected source matches the intended design.
  • The last successful synchronisation is recent.
  • The effective type is NT5DS for a normal domain member or NTP for a standalone/manual configuration.
  • No Group Policy setting is silently restoring the previous value.

Microsoft documentation

Related information