The Windows Time Service (W32Time)

What Is the Windows Time Service?

W32Time is the service that keeps a Windows computer’s clock accurate, using the Network Time Protocol to compare the local clock against a trusted source and correct drift before it becomes a problem. It’s implemented in W32Time.dll, installed by default in %Systemroot%\System32, and it runs on every edition of Windows and Windows Server going back to Windows 2000.

Think of W32Time as a clock inspector built into every Windows computer: it quietly checks the time against a trusted authority on a schedule and nudges the local clock back into line, so nobody ever has to notice or intervene.

The service was originally built to satisfy Kerberos V5, which requires clocks on a network to stay closely synchronized before it will authenticate a request. Since then, plenty of other things have come to depend on it too — event log timestamps, certificate validity checks, scheduled tasks, and any line-of-business application that timestamps a transaction.

How the Domain Time Hierarchy Works

A domain-joined computer doesn’t pick its own time source. Active Directory imposes a hierarchy, and by default every computer in it follows the same chain of command:

All client desktops and member servers nominate their authenticating domain controller as their inbound time partner. All domain controllers in a domain nominate the PDC emulator operations master as their inbound time partner. In a multi-domain forest, PDC emulators in child domains follow the domain hierarchy up toward the forest root. The PDC emulator at the root of the forest sits at the top of the chain and becomes authoritative for the entire organisation.

Think of it as a chain of command for the clock: everyone looks up to their nearest superior for the correct time, and only the one person at the top of the whole organisation is allowed to look outside it.

This is reflected directly in a registry value most administrators never touch by hand: Type, under HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters. Most domain-joined computers have this set to NT5DS, meaning “synchronize from the domain hierarchy.” A computer that isn’t domain-joined defaults to NTP, meaning “synchronize from the servers listed in NtpServer.”

Why Kerberos and AD Care About Time

Kerberos authentication depends on timestamps to prevent replay attacks, and it rejects requests when the clocks of the two parties involved have drifted too far apart. When that happens, it doesn’t look like a time problem from the user’s side — it looks like a failed login, a broken trust, or an application that mysteriously stopped working. There’s a dedicated troubleshooting post on karanth.ovh for exactly that symptom, Kerberos Clock Skew — KRB_AP_ERR_SKEW, which is worth reading alongside this one if you’re chasing an active authentication failure rather than trying to understand the hierarchy itself.

AD DS replication also depends on synchronized clocks to keep object metadata consistent across domain controllers, and certificate validity windows, Group Policy timestamps, and audit log correlation across a fleet of servers all quietly assume the clocks agree with each other.

Configuring the PDC Emulator (GUI and Group Policy)

Because only the forest root PDC emulator is supposed to reach outside the domain hierarchy, that’s the one machine where W32Time configuration is a deliberate, one-time decision rather than something left on the default. Windows stores this configuration as registry entries, and Group Policy is the supported way to manage it at scale rather than editing each domain controller by hand.

In the Group Policy Management Console, the relevant settings live under Computer Configuration\Administrative Templates\System\Windows Time Service. The “Time Providers” folder holds Configure Windows NTP Client (sets the peer list and sync type) and Enable Windows NTP Server (turns the computer into a source other machines can query). These policy settings write into HKLM\SOFTWARE\Policies\Microsoft\W32Time\TimeProviders\NtpClient on the target computer, which takes priority over the equivalent local registry value once applied.

To push the same configuration from PowerShell — useful for scripting a new PDC emulator’s GPO rather than clicking through the console — target that same registry path with Set-GPRegistryValue:

# Point the PDC-emulator GPO's NTP client at two external time servers
$params = @{
    Name      = 'PDC Emulator - External Time Source'
    Key       = 'HKLM\SOFTWARE\Policies\Microsoft\W32Time\TimeProviders\NtpClient'
    ValueName = 'NtpServer', 'Type'
    Value     = '0.pool.ntp.org,0x8 1.pool.ntp.org,0x8', 'NTP'
    Type      = 'String'
}
Set-GPRegistryValue @params

Configuring and Verifying From the Command Line

For a one-off change, or to verify what a GPO actually applied, w32tm covers the same ground directly. This is also the tool to reach for on a domain controller during initial promotion or recovery, before Group Policy has necessarily refreshed.

# Point this computer (the forest root PDC emulator) at external NTP servers
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update

# Restart the service so the new configuration takes effect
net stop w32time && net start w32time

# Return a computer to the default domain-hierarchy behaviour
w32tm /config /syncfromflags:domhier /update

# Restart the service again so the reverted configuration takes effect
net stop w32time
net start w32time

# Show the runtime configuration and where each setting came from (GPO vs local registry)
w32tm /query /configuration

# Show the current time source and synchronization status
w32tm /query /source
w32tm /query /status /verbose

# Force an immediate resync, rediscovering time sources first
w32tm /resync /rediscover

# Analyse a list of servers for reachability and offset without changing configuration
w32tm /monitor

# Confirm which NtpServer value is actually configured in the registry
reg query HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

Version and Requirement Boundaries

Troubleshooting Cheat Sheet

Final Thoughts

W32Time is one of those services nobody thinks about until authentication starts failing for no obvious reason. The hierarchy behind it is simple once it’s laid out — clients follow their DC, DCs follow the PDC emulator, the PDC emulator follows whatever it’s been told to trust — but it’s easy to lose track of who’s supposed to be following whom, especially after a FSMO role transfer or a DC that was manually reconfigured during a one-off fix and never reverted.

Treat the domain time hierarchy as part of the identity infrastructure, not a background utility. The forest root PDC emulator is the one machine in the environment where “just point it at an NTP server” is the correct answer; everywhere else, the correct answer is to leave it on NT5DS and let the hierarchy do its job.