Windows Time Service

Configure and troubleshoot Windows time

Windows includes a built-in time synchronisation service used by standalone computers, Windows servers and Active Directory domains. Once configured correctly, it normally operates without intervention and may run for years without requiring attention.

Why accurate time matters

Incorrect time can have consequences well beyond the clock displayed on the taskbar. Active Directory replication, Kerberos authentication, certificate validation, software licensing and many other Windows components rely on computers agreeing on the current time.

When time synchronisation fails, the resulting symptoms are often misleading. Authentication failures, replication errors, expired certificates and licensing problems may all be investigated before the system clock is considered.

This site provides practical information on configuring, checking, monitoring and troubleshooting Windows Time Service and the w32tm command. It covers standalone systems, Active Directory, suitable time sources, virtualisation and Linux-based Chrony servers.

Practical guides and monitoring

The following longer guides sit outside the main sections because they bring several subjects together.

Building a GPS-backed Chrony Time Server: Finding the GPS Receiver

A Linux guide written for Windows administrators, covering installation, identifying the USB receiver, GPSD and proving that valid GPS and PPS data is available.

Building a GPS-backed Chrony Time Server: Configuring Chrony

Connect GPSD to Chrony, provide NTP to the network, configure Active Directory, add TICC-DASH and verify Stratum 1 operation.

Monitoring Windows Time Services

Monitor Windows Time, Active Directory, Chrony and GPS-backed servers using built-in commands, event logs, Uptime Kuma and TICC-DASH.

Configure it correctly from the outset

Windows Time Service is often overlooked because a newly installed server appears to work without any additional configuration. In older Active Directory and Small Business Server environments, it was not uncommon to find domain controllers using an unsuitable or unavailable time source, while virtualisation hosts had never been configured at all.

An incorrectly configured virtualisation host can pass the wrong time to every new virtual machine created on it. Correcting the guest clock later may not reverse problems already caused to software licensing, certificates or other time-sensitive components.

Time source verification should therefore form part of the standard build process for a new server, hypervisor or Active Directory environment. Once the hierarchy and authoritative source have been configured correctly, the service should require very little ongoing attention.