Time service diagnosis

Follow the source before changing the clock

Most domain members use the AD time hierarchy (NT5DS). The forest-root PDC emulator is normally configured to use a reliable external or designated organizational source. Check the effective configuration rather than assuming the role holder’s registry is authoritative.

w32tm /query /computer:dc1.contoso.com /source
w32tm /query /computer:dc1.contoso.com /status /verbose
w32tm /query /computer:dc1.contoso.com /configuration /verbose
w32tm /query /computer:dc1.contoso.com /peers

Look for the actual source, last successful synchronization, stratum, poll interval and whether Group Policy supplied a setting. A configured peer is not proof of successful synchronization. How Windows Time works explains source selection through the hierarchy.

Follow the chain from the affected member to its source, then that server’s source, until you reach the intended authority. Investigate Local CMOS Clock, free-running state or an old successful-sync time even if the clock looks right now. Stratum describes distance in the time hierarchy; it doesn’t tell you whether the upstream clock is trustworthy or accurate.

Compare domain controllers

w32tm /monitor /domain:contoso.com
w32tm /stripchart /computer:dc1.contoso.com /dataonly /samples:10

Monitor is useful for comparing DCs; stripchart estimates the offset from the machine where you run it. Compare both the affected member and its time source. A single offset says little about drift over a day.

A successful stripchart does not prove the service’s network path works. Stripchart uses an ephemeral UDP source port; the W32Time NTP client uses UDP 123 as its source port. A firewall can allow one and block the other. The W32Time command and network reference documents that distinction.

Time zone and clock synchronization are different

AD replication and Kerberos work with absolute time. Two machines can display different local times because their time zones differ while their clocks agree in UTC. Compare UTC or explicit offsets when reviewing logs. Changing the time zone does not repair an incorrectly synchronized clock.

Clock errors affect Kerberos’s allowable skew, certificate validity and forensic timelines. Replication conflict resolution also uses originating timestamps after the attribute version, so a bad clock can make a bad write difficult to reason about. Do not infer convergence from matching wall-clock displays.

Check virtual machine time providers

A virtual DC can receive time through a virtualization integration provider as well as W32Time’s domain hierarchy. Inspect the effective source and the hosting platform’s current guidance. Avoid a circular arrangement where the host depends on a guest DC that takes its clock from that same host. See virtual DCs for the separate VM-GenerationID safeguard.

Resynchronization changes the machine

After correcting the source or network problem, an elevated administrator can request rediscovery and resynchronization:

w32tm /resync /rediscover

This is a change. Keep the original status and configuration, and investigate a large offset before allowing a large step. Check what that step could do to authentication, scheduled work, certificate checks and timestamp-based applications.

Choose phase-correction bounds from the system’s role and current guidance. Fixed values from a historical deployment may be inappropriate for a different role or Windows release. Also check Microsoft’s Secure Time Seeding recommendations when investigating unexplained jumps on relevant releases.

Know which correction limit rejected the sample

MaxAllowedPhaseOffset participates in the decision between gradual clock correction and an immediate step. MaxPosPhaseCorrection and MaxNegPhaseCorrection limit corrections that the service will accept in the respective directions. Spike detection and hold periods add another decision. These are different settings; increasing one blindly may not fix the reason a sample was rejected.

Read the verbose status/configuration and Time-Service events around the first incorrect sample. Compare the peer’s time with an independent source before deciding which clock should move. A forward jump followed by a corrective backward jump can disturb applications even if the final UTC is accurate.

Keep the setting’s units with its value

Check the current parameter and registry definitions before translating a value between a command, policy editor and raw registry. A value copied with the wrong unit can change spike rejection or polling by orders of magnitude. The same reference separates current algorithms from earlier Windows correction behavior; an old step-versus-slew rule is not a version-independent formula.

Use the correction settings to work out what happened before changing them. Be clear about the accuracy you need: millisecond alignment for an application is a different requirement from staying within Kerberos’s allowed skew. Check it over a busy day; a healthy stratum or one successful sample won’t establish either.

Configure the intended authority deliberately

The following is an example configuration change on the selected forest-root PDC, using three organization-approved NTP servers. Replace the names; do not apply this to every DC:

w32tm /config /manualpeerlist:"ntp1.contoso.com,0x8 ntp2.contoso.com,0x8 ntp3.contoso.com,0x8" /syncfromflags:manual /reliable:yes /update

The 0x8 peer flag requests client mode. Adding the special-poll flag would introduce a separate polling configuration; it is not needed merely to use a manual peer. If Group Policy owns the settings, update that policy rather than relying on a local command that the next refresh will replace. Microsoft’s authoritative-time procedure covers the chosen source and role.

For a DC that should return to ordinary hierarchy synchronization, the intended configuration change is different:

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

After changing the source, request resynchronization and repeat /query /source, /status /verbose and the domain comparison. Look for a new successful sample from the intended source. The configuration command can succeed before any synchronization has happened.

When the PDC role moves

Include time configuration in the role-transfer procedure. A policy scoped to a particular computer may keep the old holder pointed externally and leave the new holder following a hierarchy that now leads back to itself. Verify both role holders’ runtime configuration and actual synchronization after the move.

Include these checks in the FSMO transfer procedure. During a clock investigation, keep the role owner at the time of failure as well as the current owner. A later transfer can otherwise make the historical trace look inconsistent.