Event ID 129: NtpClient cannot resolve a domain peer to use as a time source

Fix it now

The time service went looking for a domain controller to synchronise with and could not resolve one, so it has no peer and is falling back on the local clock. The published text says it will try again in 15 minutes and double the interval after that. The fault is in name resolution or the domain controller locator records, not in the time service.

w32tm /query /source
nltest /dsgetdc:contoso.com
ipconfig /flushdns
w32tm /resync /rediscover

1. Read the answer from w32tm /query /source. A local clock means the machine has no peer at all, which matches the event.
2. If nltest /dsgetdc also fails, this is a DNS problem showing up as a time problem. Check that the machine points only at internal DNS servers – a public resolver will never return your domain controller records.
3. If the locator works but no domain controller advertises as a time server, ask for one specifically: nltest /dsgetdc:<domain> /timeserv.
4. On the domain controller side, re-register the records with nltest /dsregdns, and confirm it advertises correctly with dcdiag /test:Advertising.

Event ID 134 is the manual-peer version of the same message. If you see 134, someone configured a named peer on this machine, and it is that name that is not resolving.

If w32tm /query /source now names a domain controller, you are done. The next section covers the checks that decide whether the peer exists at all.

Why it happens

A domain member does not get time from a name you configure. It asks the domain controller locator for a domain controller and then synchronises with it, authenticating the exchange with the computer’s Kerberos session key. That dependency is the whole story here: if the locator cannot answer, the time service has nowhere to go, and it says so in terms that sound like a time fault.

The published text is specific about the retry behaviour: NtpClient was unable to set a domain peer to use as a time source, it will try again in 15 minutes, and it will double the reattempt interval thereafter. That doubling is why a transient DNS problem in the morning can leave a machine unsynchronised all afternoon even though DNS recovered, and why forcing a resync by hand is worth doing after you fix the underlying fault.

Event 134 is worth separating from 129 before you start. 134 says NtpClient was unable to set a manual peer, with a DNS resolution error on the name – in the published example, time.windows.com. A machine logging 134 has been given a named peer by somebody, and the fix is that name or the firewall in front of it, not the domain controller locator.

Full reference

Two events that read alike and mean different things

Events that travel with these

Microsoft documents events 24, 29 and 38 together, as the set logged on a virtualised domain controller that is synchronising both from the hypervisor’s integration service and from the domain hierarchy. If you are seeing those three on a virtual domain controller, the fix is on the host: disable the time synchronisation integration for that guest, and let it follow the domain hierarchy. Microsoft’s stated reason is worth the trouble – a domain controller whose system time jumps can leave lingering objects in caches and can stop replication.

Checks in the order that saves time

1. w32tm /query /source on the client. A local clock confirms there is no peer.
2. nltest /dsgetdc:<domain>. If this fails, stop and fix DNS.
3. nltest /dsgetdc:<domain> /timeserv. If this fails while the previous one works, the problem is on the domain controllers.
4. dcdiag /test:Advertising on a domain controller.
5. w32tm /monitor to see the offsets across the domain controllers once a source exists.
6. w32tm /resync /rediscover on the client, because the backoff means it will not retry promptly on its own.

What has to be open

• UDP 123 between the client and the domain controller, in both directions. The NTP client can only use UDP 123 as its source port.
• The usual domain controller locator path, since the time service depends on finding a domain controller before it can synchronise at all.
• Nothing else. If UDP 123 is open and the locator works, remaining failures are configuration on the domain controllers rather than the network.

The registry values you may need to read

Every code this article covers

Confirm the fix worked

1. w32tm /query /source names a domain controller rather than a local clock.
2. nltest /dsgetdc:<domain> /timeserv returns a domain controller.
3. w32tm /query /status shows a recent successful synchronisation and a sensible stratum.
4. No new 129 or 134 events after a reboot.
5. w32tm /monitor shows this machine’s offset in line with the domain controllers.

Questions people ask about this