Domain Controller Time Problems

Active Directory uses a hierarchy rather than configuring every computer with the same NTP server. Domain members obtain time from domain controllers. Domain controllers obtain time through the domain hierarchy. At the top, the PDC Emulator in the forest root domain uses an approved external or internal reference.

A fault at the top can therefore spread throughout the forest. Equally, one badly configured domain controller can affect only the clients that select it, making the problem appear intermittent or site-specific.

Identify the forest root PDC Emulator

Do not assume that the oldest domain controller or the server normally used for administration still holds the role.

Run:

netdom query fsmo

In a multi-domain forest, there is one PDC Emulator in every domain. The important server for the top of the time hierarchy is the PDC Emulator in the forest root domain.

A child-domain PDC Emulator normally follows a suitable source in the parent domain. It should not usually be configured with public NTP peers.

Check the forest root PDC Emulator first

On the forest root PDC Emulator, run:

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

Confirm that:

The selected source is one of the approved upstream peers.
The last successful synchronisation is recent.
The effective synchronisation type is appropriate for a manual source.
The peer list contains valid, reachable servers.
The server is marked as reliable where required by the design.

A forest root PDC Emulator that reports Local CMOS Clock, Free-running System Clock, a hypervisor provider or another domain controller requires investigation.

The PDC Emulator is using the local clock

If the server reports:

Local CMOS Clock

or:

Free-running System Clock

it has no usable upstream source.

Check the manual peer list, DNS resolution, UDP port 123 and whether the upstream servers are themselves synchronised.

A typical configuration is:

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

Use the organisation's approved peers rather than copying these examples without review.

After applying the configuration:

w32tm /resync /rediscover
w32tm /query /source
w32tm /query /status

A successful configuration command does not prove that the selected source has changed.

Event ID 12 on the PDC Emulator

The Windows Time service can log Event ID 12 when the forest root PDC Emulator is configured to use the domain hierarchy.

That configuration is not valid because the server is already at the top of the forest hierarchy. It needs a deliberate upstream source instead.

Correct the source on the forest root PDC Emulator rather than attempting to make another domain controller authoritative.

Other domain controllers should use the hierarchy

On every other domain controller, the normal configuration is:

Type: NT5DS

The selected source should normally be another suitable domain controller, often in the same site or the parent domain.

Return a non-root-PDC domain controller to the hierarchy with:

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

Do not hard-code every domain controller to the forest root PDC Emulator. Windows Time Service includes source-selection logic that considers site, reliability and the domain hierarchy.

The source is an unexpected domain controller

An unexpected source is not automatically wrong.

A domain controller can select another reliable domain controller according to its location and position in the hierarchy. The source does not have to be the nearest server by name, and every domain controller does not need to point directly at the forest root PDC Emulator.

Investigate when:

The source has been decommissioned.
The source is in the wrong forest or an unreachable site.
The source is not itself synchronised.
The domain controller has retained an old manual peer list.
The resulting path creates a cycle or never reaches a reliable root.

Review all domain controllers together

Use:

w32tm /monitor

This provides a quick comparison of the domain controllers and their measured offsets.

Look for:

One domain controller with a much larger offset than the others.
A server that cannot be contacted.
A domain controller that reports no valid reference.
Differences between sites or domains.

w32tm /monitor is a useful overview, but it does not replace checking the source and effective configuration on each affected server.

The domain controller is not advertising time

Domain members must be able to discover domain controllers that advertise the required services.

Run:

dcdiag /test:Advertising

If the output reports that a domain controller is not advertising as a time server, check:

The Windows Time service is running.
The domain controller has a usable source.
The NTP server provider is enabled.
The effective configuration has not been damaged by an upgrade or policy.
Netlogon and Active Directory health are otherwise normal.

Microsoft has documented cases where Windows Time settings were not preserved correctly after an in-place upgrade. If the problem started immediately after an upgrade, compare the effective configuration with the expected domain-controller defaults before making unrelated changes.

No time data was available

If a domain controller returns:

The computer did not resync because no time data was available.

check the problem in this order:

Confirm the intended source.
Test DNS resolution.
Test the peer with w32tm /stripchart.
Check UDP port 123 in both directions.
Confirm that the upstream source is synchronised.
Confirm that domain controllers are advertising correctly.

See Windows Time Synchronisation Fails for the full procedure.

Group Policy is overriding the settings

A local change can appear to work and then be replaced when Group Policy refreshes.

Review:

w32tm /query /configuration

The output identifies settings supplied by policy.

A Group Policy used to configure the forest root PDC Emulator should be scoped so that it applies only to the current role holder. Applying the same external NTP configuration to the entire Domain Controllers OU removes the hierarchy and creates several competing authoritative servers.

The PDC Emulator role has moved

Transferring or seizing the FSMO role does not automatically move a manually configured NTP peer list or a narrowly scoped Group Policy.

After a role change:

Configure the new forest root PDC Emulator with the approved upstream peers.
Mark it as reliable where required.
Return the former role holder to domain hierarchy synchronisation.
Verify the source on both servers.
Run w32tm /monitor across the domain controllers.

On the former role holder:

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

Role transfers are a common reason for finding an old PDC Emulator still using public peers months or years later.

The PDC Emulator is offline

Active Directory time synchronisation is not designed so that every computer stops immediately when the forest root PDC Emulator is unavailable.

Domain members and domain controllers continue using available sources and their local clocks. However, without a valid root source, drift eventually accumulates and the hierarchy loses its connection to an authoritative reference.

Restore or transfer the role promptly, then verify that the new top of the hierarchy uses the approved source.

Child domains

In a multi-domain forest, the PDC Emulator in a child domain normally synchronises upwards to the parent domain.

Do not configure every child-domain PDC Emulator with public peers unless there is a deliberate, documented design that requires separate roots.

If a child domain has time problems, verify:

The child-domain PDC Emulator follows a parent-domain source.
Sites and Services contains correct subnet and site information.
DNS and firewall rules permit communication with parent-domain controllers.
The parent hierarchy ultimately reaches the forest root PDC Emulator.

Virtual domain controllers

A virtual domain controller should follow the same Windows hierarchy as a physical domain controller.

The preferred configuration used throughout this site is to avoid ongoing host-to-guest time synchronisation competing with Windows Time Service. The hypervisor hosts must still maintain accurate time because startup, resume, migration and recovery can involve the host clock.

Check whether the affected server has recently:

Moved to another host.
Resumed from suspension.
Been restored from a checkpoint or snapshot.
Had guest tools upgraded or reconfigured.

See Virtual Domain Controllers and Windows Time.

Do not restore snapshots casually

Restoring a domain controller snapshot affects more than the displayed clock.

Modern supported hypervisors and Windows Server versions include VM-Generation ID safeguards, but a snapshot is not an ordinary rollback point. Use supported backup and recovery procedures and verify Active Directory, replication and time afterwards.

Check replication and DNS as well

Time problems can coexist with wider Active Directory faults.

Useful checks include:

dcdiag
repadmin /replsummary
repadmin /showrepl
ipconfig /all

A domain controller with broken DNS registration, failed replication or an incorrect site assignment may also select an unexpected time source or fail to advertise correctly.

Avoid unregistering W32Time too early

The commonly copied reset procedure:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

can remove deliberate configuration and should not be the first response to a domain-controller time problem.

Use it only when the hierarchy, source, policy, advertising and network path have been checked and there is evidence that the service registration itself is damaged.

A complete verification sequence

Once the fault has been corrected:

Identify the forest root PDC Emulator.
Verify its approved upstream source.
Check the last successful synchronisation.
Verify that other domain controllers use hierarchy-based sources.
Run w32tm /monitor.
Run dcdiag /test:Advertising.
Check representative domain members.
Confirm that the original authentication or application problem is resolved.