Bob Drake
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….
Client settings
-
By default W32time is shipped with the operating system to point to
“time.windows.com”.
This is true for both non-domain members and domain joined computers (as seen here from an XP client machine):
- Note the setting for “NT5DS”. This setting means that the computer will follow the domain hierarchy and synchronize with a selected time source according to the time selection process as described here .
Primary Domain Controller Emulator settings
-
Providing the PDCE has been properly configured with an NTP source according to the articles (
2003
)(
2000
)(
XP
) there will be a setting as shown:
Note: Any NTP Server can be configured, pictured is the default. Here is a list of NTP servers.
-
This PDCE as shown is configured to use
“time.windows.com”
as its NTP source. For an alternate NTP configuration we can modify the
“NtpServer”
key to reflect an additional peer after selecting one from a source of your choice.
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 :
- 0x01 SpecialInterval
- 0x02 UseAsFallbackOnly
- 0x04 SymmatricActive
- 0x08 Client
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).
-
When the debug log is opened, the first section displays the configuration from the registry, and starts the providers (both client and server). A little further down it will show the peers:
Typically in a normal debug log, the machine then polls the NTP servers for time by sending a UDP NTP packet over port 123, and then gets samples from that server. Once it has samples, it will choose the “best” sample based on the NTP algorithms and pass the chosen sample to the clock discipline for time adjustment. -
Then our problem happens on the internet and we cannot reach “time.wndows.com” so we remove it as a peer:
-
Since we have configured and alternate, we can now poll our secondary peer “
tick.usno.navy.mil”
and synchronize from it:
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