Time configuration is easily overlooked because a Windows domain can appear to operate normally while every computer is following an unsuitable source. The problem may only become visible after an Internet outage, a firewall change, a domain controller replacement or a significant clock drift.
The simplest Active Directory design is usually the most reliable. The PDC Emulator in the forest root domain obtains time from approved external peers. Other domain controllers and domain members continue to use the domain hierarchy.
Configuring every domain controller with external NTP servers
A common response to a time problem is to configure the same public NTP servers on every domain controller. This may appear to provide resilience, but it bypasses the Active Directory hierarchy and creates several independently configured authoritative sources.
The domain controllers may select different external servers, receive different quality time or lose access to their peers at different times. The resulting environment is harder to understand and more difficult to troubleshoot than the standard hierarchy.
Only the forest root PDC Emulator should normally use the manual peer list. Other domain controllers should use NT5DS and obtain time through the domain hierarchy.
Applying one Windows Time policy to every computer
Group Policy makes it easy to deploy a Windows Time configuration widely. It also makes it easy to apply the wrong configuration to every system in the domain.
A policy containing a manual peer list and an NTP synchronisation type should not normally be linked so that it applies to all domain controllers or all domain members. Doing so overrides the automatic hierarchy and may also replace a correct local configuration on the PDC Emulator.
Policy values take precedence over locally configured Windows Time settings. Therefore, a command such as w32tm /config may appear to complete successfully while the effective configuration continues to come from Group Policy.
Use w32tm /query /configuration to identify whether a value is supplied locally or by policy. Correct the policy rather than repeatedly changing the local registry.
Configuring the wrong PDC Emulator
Every Active Directory domain has a PDC Emulator, but only the PDC Emulator in the forest root domain sits at the top of the complete forest time hierarchy.
In a multi-domain forest, configuring the PDC Emulator in a child domain with external peers does not correctly establish the authoritative source for the whole forest. The forest root role holder must be identified before the external configuration is applied.
Use netdom query fsmo or Active Directory PowerShell to confirm the role holder rather than relying on a server name or an old design document.
Forgetting about an FSMO role transfer
The external time configuration belongs with the PDC Emulator role, not permanently with one domain controller.
After the role is transferred or seized, the new forest root PDC Emulator should be configured with the approved external peers. The previous role holder should be returned to domain hierarchy synchronisation and should no longer be marked as a reliable manual source.
If this step is missed, the old server may continue to use the external peers while the new PDC Emulator attempts to follow the domain hierarchy. The configuration can remain unnoticed until the previous role holder is decommissioned or becomes unavailable.
Assuming that a successful command means time is synchronised
The message that a w32tm /config or w32tm /resync command completed successfully only confirms that Windows accepted the request. It does not prove that the intended server supplied a usable time sample.
Always verify the result with:
w32tm /query /source
w32tm /query /status
w32tm /query /configurationThe selected source, the last successful synchronisation and the effective configuration should all agree with the intended design.
Leaving the PDC Emulator on the local clock
A newly installed forest root PDC Emulator may report Local CMOS Clock or Free-running System Clock when no suitable external source has been configured or selected.
This can be missed because the rest of the domain still follows the hierarchy and therefore agrees with the PDC Emulator. The computers are consistent with one another, but the entire environment may be several minutes away from the correct time.
The PDC Emulator should report an approved external peer. A persistent local-clock source should be investigated rather than treated as normal.
Using a single external peer
A single peer creates an unnecessary dependency. If that service is unavailable, stops answering NTP requests or becomes unreachable because of a DNS or firewall problem, the PDC Emulator has no alternative external source.
Configure several suitable peers where possible. They should be reliable, reachable from the server and preferably not all dependent on the same underlying infrastructure.
Multiple peer names do not remove the need to monitor the selected source. Windows still needs to receive valid responses and choose a usable peer.
Using unsuitable or unverified public servers
An NTP hostname found in an old article should not automatically be treated as a permanent public service. Organisations change their access policies, withdraw servers or restrict them to specific networks.
Use an established source whose operator publishes current usage guidance. Suitable options and the differences between public pools, national time services, internal appliances and GPS-backed sources will be covered in the Time Sources section.
Omitting the correct peer mode
Windows supports several NTP association modes. When the PDC Emulator contacts a normal external NTP service, the manual peer entry will commonly use the 0x8 flag to select client mode.
An unsuitable mode can result in the remote server ignoring the request even though DNS resolution and UDP port 123 appear to be working. This is one cause of the message that no time data was available.
The required flags should be specified explicitly and consistently for each peer rather than copied from an unexplained command found in an old document.
Ignoring firewalls and name resolution
The peer list can be completely correct while the server is unable to use it. The PDC Emulator must be able to resolve the peer names and exchange NTP traffic over UDP port 123.
Check DNS resolution from the server itself. Where outbound traffic is restricted, confirm that the firewall permits the required NTP traffic. A security device performing application filtering or source restrictions may also reject requests even when a basic port rule appears correct.
w32tm /stripchart can help confirm whether a server responds, although the selected Windows Time source must still be checked separately.
Changing polling and registry values unnecessarily
Older guidance frequently recommends changing values such as SpecialPollInterval, MaxPosPhaseCorrection, MaxNegPhaseCorrection or AnnounceFlags as part of a standard setup.
These values should not be changed simply because they appear in an old configuration example. Their effect depends on the synchronisation mode, Windows version, policy and the problem being addressed.
Begin with the supported hierarchy and the normal Windows defaults. Change additional settings only where there is a documented requirement and the resulting behaviour can be tested.
Setting the clock manually instead of correcting the source
Manually setting a server's clock may temporarily remove the visible difference, but it does not repair the Windows Time configuration. The clock will begin drifting again or may be corrected unexpectedly when the service eventually finds another source.
Identify why the server is not synchronising, correct the source or hierarchy and then verify a successful sync. Manual adjustment should not become a regular maintenance task.
Ignoring the virtualisation hosts
A Windows guest can inherit an incorrect clock from its virtualisation host before it joins the domain. Guest integration services may also continue to influence the clock after Windows Time Service has selected a domain source.
The time configuration of Hyper-V, VMware, Proxmox and XCP-ng hosts should therefore be included in the platform build. A badly incorrect host can cause installation, licensing and certificate problems before the guest has had an opportunity to synchronise with Active Directory.
Virtual domain controllers require particular care so that hypervisor time integration does not undermine the intended domain hierarchy. Platform-specific guidance is covered in the Virtualisation section.
Decommissioning a domain controller without checking dependencies
Before removing a domain controller, check whether it holds the PDC Emulator role and whether any computers, scripts or policies have been configured to use it directly.
A correct domain hierarchy should allow members to discover another suitable domain controller. A manually configured server name creates a hidden dependency that may only become visible after the domain controller has been removed.
After a domain controller replacement, verify the hierarchy from the forest root PDC Emulator downwards rather than assuming that role transfer and time configuration occurred together.
Making several changes at once
Windows Time problems often lead to a sequence of registry edits, service resets, policy changes and manual clock adjustments. When several changes are made together, it becomes difficult to identify the actual cause or know which settings remain necessary.
Establish the current source and effective configuration first. Correct the smallest number of settings required, allow Windows to select a source and then verify the result before making another change.
Keep the design simple
A typical Active Directory forest does not require a complex time design:
- The forest root PDC Emulator uses several approved external NTP peers.
- Other domain controllers use the Active Directory hierarchy.
- Member servers and workstations use the Active Directory hierarchy.
- Virtualisation hosts have their own reliable time configuration.
- The source and last successful synchronisation are checked after role or infrastructure changes.
Most Windows Time configuration mistakes are departures from this model without a clear technical reason.