from Microsoft again. Often we see situations where the forest root domain PDCE is configured to acquire time from a specified authoritative NTP source but cannot due to issues outside of the local network (IE: DNS, Routing). Typically the first signs of an issue are errors like
Event ID 29:
“The time provider NtpClient is configured to acquire time from one or more time sources; however none of the sources are currently accessible. No attempt to contact a source will be made for 14 minutes. NtpClient has no source of accurate time.”
This is because the computers cannot reach the NTP server. What would be an easy resolution usually turns into unnecessary changes being made internally (usually registry configurations or topology) in attempts to fix the issue, making a bad situation worse. In an effort to avoid these scenarios there is a method to configure environments to have alternate NTP time server specified for fault tolerance to the W32Time service. Let’s first see what the default settings are and how they work….
Primary Domain Controller Emulator settings
Note here we have selected “tick.usno.navy.mil” and have added/changed our flags according to the Windows Time Service Tools and Settings article :
By making the primary NTP server flag 0x9, we made it “Client 0x08 + SpecialInterval 0x01” and as for the second NTP time server.
By making the secondary NTP peer flag 0xa, we made it “0x08 Client + 0x02 UseAsFallbackOnly”.
Now the PDCE has two sources to poll and acquire time from. If we were to see issues here in the future, we can set up time debug logging from KB Article 816043 we would see the following in the w32time.log:
SPECIAL NOTE HERE:
On initial sync during service startup the polling interval time is zero which will not match the special polling interval that our 0x01 flag requires. This being the case w32time will use the Fallback server as its primary choice until the special polling interval arrives then it will use the intended primary server. The specialpollinterval setting is discussed in
KB Article 816042
In the referenced KB article the “ FileLogName ” has a path to point to “ C:\Windows\Temp\w32time.log ” but some may chose to log somewhere else like the common path “ C:\Windows\Debug\w32time.log ” . If done, it will never actually log anything. This is because the w32time.log will not write to the debug folder without modifying the debug folders’ permissions, so I recommend instead using the default (this should only be done for troubleshooting regardless, not turned on forever).
So that’s it. If the secondary NTP server was not configured prior to the real problem, an administrator could run into more complications by thinking the issue is internal and makes premature changes which might complicate things. Hopefully this helps you in the future!
- Bob Drake
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.