Introduction#

In Active Directory, time synchronization is a foundation for almost every authentication process.

Kerberos, Active Directory replication, certificates, Group Policy, and many other components all depend on accurate time.

The recommended domain time hierarchy is not complicated:

1
Internet NTP
2
     │
3
     ▼
4
PDC Emulator
5
     │
6
     ▼
7
Other Domain Controllers
8
     │
9
     ▼
10
Domain Members

However, we encountered an unusual issue in our environment:

• The PDC Emulator was already configured to use public NTP servers

• The Domain Controllers could communicate with one another

• DNS was working

• Active Directory was healthy

• The Secure Channel was healthy

Yet some Domain Controllers continued to use:

1
Local CMOS Clock

The final investigation showed that the issue was not with the public NTP servers, DNS, basic network connectivity, or Active Directory itself. The fault was isolated to the local Windows Time Service configuration or service state on the affected Domain Controller.

This article documents the complete troubleshooting process and the reasoning that proved most useful along the way.

NTP Fundamentals in an Active Directory Domain#

Before troubleshooting, it is important to understand how time synchronization works in a Windows domain.

In a workgroup environment, each Windows device can synchronize directly with a specified public NTP server. In an Active Directory environment, however, Windows normally relies on the domain hierarchy provided by Windows Time Service.

The Windows Time Service is named:

1
W32Time

It maintains the Windows system clock and provides the time foundation required by Kerberos, Active Directory, certificate validation, and other time-sensitive services.

1
Public NTP Server
2
        │
3
        ▼
4
Forest Root Domain PDC Emulator
5
        │
6
        ▼
7
Other Domain Controllers
8
        │
9
        ▼
10
Domain Member Servers and Workstations

1
netdom query fsmo

1
Get-ADDomain | Select-Object PDCEmulator

1
w32tm /config `
2
    /manualpeerlist:"time.cloudflare.com,0x8 time.google.com,0x8" `
3
    /syncfromflags:manual `
4
    /reliable:yes `
5
    /update

1
Restart-Service w32time
2
w32tm /resync /force

1
w32tm /query /configuration

1
Type

1
Type: NT5DS

1
Source: DC01.example.local

1
Source: PDC01.example.local

1
Public NTP
2
    │
3
    ▼
4
PDC Emulator
5
    │
6
    ▼
7
DC01
8
    │
9
    ▼
10
Member Server

1
w32tm /query /source

1
w32tm /query /status

1
w32tm /query /configuration

1
w32tm /query /peers

1
w32tm /monitor

1
w32tm /stripchart /computer:PDC01.example.local /samples:5 /dataonly

1
Get-WinEvent -LogName System |
2
    Where-Object {
3
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
4
    } |
5
    Select-Object -First 20 `
6
        TimeCreated,
7
        Id,
8
        LevelDisplayName,
9
        Message

Troubleshooting Environment#

All server names, domain names, and IP addresses in this article have been anonymized.

The affected environment was a long-running, single-forest, single-domain Active Directory deployment with four Domain Controllers:

The domain also contained multiple Windows member servers and workstations.

The expected time architecture was:

1
External NTP
2
      │
3
      ▼
4
PDC01 — PDC Emulator
5
      │
6
      ▼
7
DC01 / DC02 / DC03
8
      │
9
      ▼
10
Member Servers and Workstations

The intended configuration was:

• PDC01 uses Type: NTP

• PDC01 is the only server explicitly configured as the reliable external time source

• Other Domain Controllers use Type: NT5DS

• Member servers and workstations use Type: NT5DS

• Domain members may synchronize with another healthy Domain Controller instead of connecting directly to the PDC

Symptoms#

On the affected Domain Controller, I first checked the current time source:

1
w32tm /query /source

The result was:

1
Local CMOS Clock

I then checked the detailed status:

1
w32tm /query /status

The important values were:

1
Stratum: 1
2
ReferenceId: LOCL
3
Source: Local CMOS Clock

This meant that the Domain Controller was not using an upstream domain time source. It was relying directly on its own hardware clock.

For a non-PDC Domain Controller, this was clearly not the expected state.

Step 1: Identify the PDC Emulator#

I first confirmed all FSMO role holders:

1
netdom query fsmo

The output showed that all FSMO roles were located on:

1
PDC01.example.local

The PDC role also correctly pointed to PDC01.

I then used the PDC Locator directly:

1
nltest /dsgetdc:example.local /PDC

The result was similar to:

1
DC: \\PDC01.example.local
2
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV

This confirmed that Active Directory could correctly identify the current PDC Emulator.

Step 2: Validate the PDC External Time Source#

On PDC01, I checked the current time source:

1
w32tm /query /source

The output showed the configured public sources:

1
time.cloudflare.com,time.google.com

I then checked the synchronization status:

1
w32tm /query /status

The important values were similar to:

1
Leap Indicator: 0 (no warning)
2
Stratum: 4
3
Source: time.cloudflare.com,time.google.com
4
Last Successful Sync Time: <timestamp>

Next, I reviewed the complete configuration:

1
w32tm /query /configuration

The important values were:

1
Type: NTP
2
AnnounceFlags: 5
3
NtpServer: time.cloudflare.com,time.google.com

These results confirmed that:

• The PDC Emulator could synchronize with the external NTP sources

• Windows Time Service was running correctly on the PDC

• The external NTP configuration was not the main cause of the incident

Step 3: Inspect the Actual Configuration on the Affected DC#

Back on DC01, I checked the full configuration:

1
w32tm /query /configuration

The key result was:

1
Type: NT5DS

This meant DC01 was configured to discover a time source through the Active Directory domain hierarchy.

As a non-PDC Domain Controller, it should locate an appropriate upstream domain time source. In this single-domain environment, its time chain should ultimately trace back to the PDC Emulator.

However, another source check still returned:

1
w32tm /query /source

1
Local CMOS Clock

This revealed the first major contradiction:

• The configuration said the server should use NT5DS

• The actual runtime state showed Local CMOS Clock

For this reason, Type: NT5DS alone was not enough to conclude that the server was healthy. The configuration had to be compared with the active source and synchronization status.

Step 4: Use w32tm /monitor to Check the Entire Domain#

To determine whether the problem affected only DC01, I ran:

1
w32tm /monitor

The output showed several notable conditions:

1
DC01
2
    RefID: LOCL
3
    Stratum: 1
4
    Offset: approximately -61 seconds
5

6
PDC01
7
    RefID: external NTP source
8
    Stratum: 4
9

10
DC02
11
    RefID: another external NTP source
12

13
DC03
14
    NTP query timeout

This suggested that the environment had more than one time configuration issue:

• DC01 had fallen back to Local CMOS Clock

• DC02 might still have a historical configuration that synchronized directly with a public NTP source

• DC03 did not respond to the NTP query

• Only PDC01 matched the expected design

Although the incident was first noticed on DC01, the monitor output exposed historical inconsistencies across the domain time configuration.

Step 5: Validate the Active Directory Foundation#

Because NT5DS depends on Active Directory to discover a domain time peer, I next verified that DC01 could access the domain, locate the PDC, and maintain a healthy Secure Channel.

1
Test-ComputerSecureChannel -Verbose

1
True

1
nltest /sc_verify:example.local

1
NERR_Success

1
nltest /dsgetdc:example.local /PDC

1
DC: \\PDC01.example.local

1
nltest /dclist:example.local

1
netdom query fsmo

1
nslookup PDC01

1
ping PDC01

Step 6: Review the Windows Time Service Logs#

I then reviewed Windows Time Service events in the System log:

1
Get-WinEvent -LogName System |
2
    Where-Object {
3
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
4
    } |
5
    Select-Object -First 20 `
6
        TimeCreated,
7
        Id,
8
        LevelDisplayName,
9
        Message

The log contained Event ID 129:

1
NtpClient was unable to set a domain peer to use as a time source because of discovery error.
2

3
The error was:
4

5
The entry is not found.

This was the most important event in the investigation.

It showed that the problem was not simply that Windows had selected a time source but failed to receive time data.

More precisely, Windows Time Service failed during the domain peer discovery stage.

In other words:

• This was not merely NTP packet loss after selecting the PDC

• W32Time had failed to establish the Domain Peer it was supposed to use

That distinction changed the direction of the troubleshooting process.

Step 7: Analyze the Local W32Time Configuration#

I checked the configuration again:

1
w32tm /query /configuration

The following combination appeared:

1
Type: NT5DS
2
AnnounceFlags: 5

Type: NT5DS meant that the server should discover its time source through the Active Directory hierarchy.

AnnounceFlags: 5 is commonly associated with a server advertising itself as a reliable time source.

It is important to note that a Domain Controller acting as both a time client and a time server is not inherently a conflict. A DC can synchronize from an upstream server while providing time to downstream domain members.

The important issue was the combination of the following facts:

• DC01 was not the current PDC Emulator

• It was still marked as a reliable time source

• It was using only Local CMOS Clock

• Windows Time Service was reporting a Domain Peer discovery failure

This suggested that the local W32Time configuration or service state on DC01 might contain historical manual settings, remnants from a previous role configuration, or another inconsistent local state.

AnnounceFlags: 5 alone did not prove that it was the only direct cause of Event ID 129. However, when combined with all other findings, it was reasonable to isolate the fault to the local Windows Time Service configuration or state on DC01.

At this point, repeatedly running the following command was unlikely to help:

1
w32tm /resync

The service had not established a valid Domain Peer in the first place.

Step 8: Re-register Windows Time Service#

Instead of adding more registry settings or NTP configuration on top of the existing state, I decided to return Windows Time Service to a cleaner default state.

Stop the service:

1
net stop w32time

Unregister Windows Time Service:

1
w32tm /unregister

Register it again:

1
w32tm /register

Start the service:

1
net start w32time

Then explicitly restore the expected domain hierarchy mode for a non-PDC Domain Controller:

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

Finally, request synchronization and force domain rediscovery:

1
w32tm /resync /rediscover

Note that the following command does not exist as a standalone command:

1
w32tm /rediscover

/rediscover must be used as a parameter of /resync.

Step 9: Verify the Repair#

After the repair, I checked the source again:

1
w32tm /query /source

The result immediately changed to:

1
PDC01.example.local

This confirmed that Windows Time Service had rediscovered the correct domain time source.

I then checked:

1
w32tm /query /status

The important values to confirm were:

• Source pointed to a healthy domain time source

• Last Successful Sync Time had updated

• ReferenceId was no longer LOCL

• Stratum was no longer the local reference clock value of 1

I also reviewed the complete configuration again:

1
w32tm /query /configuration

The server still correctly showed:

1
Type: NT5DS

and the non-PDC Domain Controller was no longer configured as a reliable root time source.

Finally, I checked the recent events again:

1
Get-WinEvent -LogName System |
2
    Where-Object {
3
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
4
    } |
5
    Select-Object -First 10 `
6
        TimeCreated,
7
        Id,
8
        LevelDisplayName,
9
        Message

No new Event ID 129 entries continued to appear after the repair.

Step 10: Why Some Member Servers Still Synchronized with DC01#

After DC01 was repaired, I checked several member servers and found that:

1
w32tm /query /source

returned:

1
DC01.example.local

At first, this could suggest that a Group Policy had previously forced those servers to use DC01.

I then checked:

1
w32tm /query /configuration

The important values were:

1
Type: NT5DS (Local)
2
AnnounceFlags: 10 (Local)
3
NtpServer Enabled: 0 (Local)

This showed that:

• The server was not using a manually configured NTP peer

• The local NTP Server Provider was disabled

• The server was automatically selecting a source through the Active Directory hierarchy

• Selecting DC01 as its current time partner was normal behavior

The actual time chain was:

1
External NTP
2
      │
3
      ▼
4
PDC01
5
      │
6
      ▼
7
DC01
8
      │
9
      ▼
10
Member Server

As long as DC01 remained synchronized with PDC01, this was a normal and supported domain time hierarchy.

1
gpresult /h C:\Temp\gpresult.html

1
Configure Windows NTP Client
2
Enable Windows NTP Client
3
Enable Windows NTP Server

1
Type: NT5DS (Local)

Root Cause and Evidence Boundaries#

The investigation confirmed that the problem was not caused by:

• The PDC Emulator external NTP configuration

• DNS name resolution

• Active Directory DC Locator

• The Secure Channel

• Basic communication between Domain Controllers

The fault was isolated to Windows Time Service on DC01.

The DC01 configuration contained:

1
Type: NT5DS
2
AnnounceFlags: 5

This showed that the effective W32Time configuration did not fully match the server’s current role.

However, AnnounceFlags: 5 alone was not enough to prove that it was the sole direct cause of Event ID 129.

What could be confirmed was:

• W32Time could not establish a valid Domain Peer

• After re-registering W32Time and restoring domhier, DC01 immediately began synchronizing with PDC01

• The fault therefore existed in the local Windows Time Service configuration or service state on DC01

• Active Directory, DNS, the network, and the PDC Emulator were not the primary causes of the incident

Final Time Synchronization Architecture#

The domain should maintain the following design:

1
External NTP
2
      │
3
      ▼
4
PDC Emulator — the only server explicitly configured with public NTP
5
      │
6
      ▼
7
Other Domain Controllers — NT5DS
8
      │
9
      ▼
10
Member Servers and Workstations — NT5DS

The main rules are:

• Only the PDC Emulator is configured with public NTP servers

• Other Domain Controllers use NT5DS

• Domain members use NT5DS

• Member servers may synchronize with any healthy Domain Controller

• Every time chain should ultimately trace back to the PDC Emulator

Troubleshooting Approach Summary#

The most valuable part of this incident was not the final repair command. It was the process of narrowing the fault domain step by step.

When a server shows:

1
Local CMOS Clock

it is not safe to assume immediately that the public NTP service, UDP 123, or a firewall is the problem.

A better approach is to identify the server’s role in the domain hierarchy and determine at which stage the time source was lost.

1
Identify the device role
2
      │
3
      ▼
4
Confirm the PDC Emulator and FSMO roles
5
      │
6
      ▼
7
Validate the PDC external NTP source
8
      │
9
      ▼
10
Check Source, Status, and Type on the affected server
11
      │
12
      ▼
13
Use w32tm /monitor to inspect the entire domain
14
      │
15
      ▼
16
Validate Secure Channel, DNS, and PDC Locator
17
      │
18
      ▼
19
Review Windows Time Service events
20
      │
21
      ▼
22
Determine whether the failure is discovery, communication, or local configuration
23
      │
24
      ▼
25
Restore W32Time and rejoin the domain time hierarchy
26
      │
27
      ▼
28
Validate the complete synchronization chain

Command Toolbox#

1
netdom query fsmo
2
Get-ADDomain | Select-Object PDCEmulator
3
nltest /dsgetdc:example.local /PDC
4
nltest /dclist:example.local

1
Test-ComputerSecureChannel -Verbose
2
nltest /sc_verify:example.local

1
w32tm /query /source
2
w32tm /query /status
3
w32tm /query /configuration
4
w32tm /query /peers
5
w32tm /monitor

1
w32tm /stripchart /computer:PDC01.example.local /samples:5 /dataonly

1
Get-WinEvent -LogName System |
2
    Where-Object {
3
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
4
    } |
5
    Select-Object -First 20 `
6
        TimeCreated,
7
        Id,
8
        LevelDisplayName,
9
        Message

1
net stop w32time
2
w32tm /unregister
3
w32tm /register
4
net start w32time
5
w32tm /config /syncfromflags:domhier /reliable:no /update
6
w32tm /resync /rediscover

1
gpresult /h C:\Temp\gpresult.html