I’ve blogged about checking Windows Time Settings and how sometimes Windows Time Stops Even When Set to Start Automatically. But what if you just need a basic setup for a domain controller or for a computer that is not joined to a domain?
Here are the commands I use (from an administrative command prompt) for a computer based in the United States. This is only for setting up a domain controller or a non-domain computer. Do not use these commands for domain members!
w32tm /dumpreg /subkey:Parameters w32tm /dumpreg /subkey:TimeProviders\NtpClient w32tm /config /manualpeerlist:"0.us.pool.ntp.org,0x1 1.us.pool.ntp.org,0x1 2.us.pool.ntp.org,0x1 3.us.pool.ntp.org,0x1" /syncfromflags:MANUAL net stop w32time && net start w32time w32tm /dumpreg /subkey:Parameters w32tm /dumpreg /subkey:TimeProviders\NtpClient time /t
What the Commands Do
1. Display several time service registry values.
2. Set the time source to a /manualpeerlist consisting of the four U.S. pool servers from the ntp.org Pool Project. (See that site for servers in other parts of the world.) The peer list appears in the NtpServer registry value (see screen shot).
Also set /syncfromflags:MANUAL which tells it to use use the peers from the manual peer list. This sets Type to NTP (see screen shot).
3. Restart the time service.
4. Display the time service registry values again.
5. Display the current time. Make sure this is correct!
Sample output of steps 2 through 4:
SpecialPollInterval
The last line in the screen shot shows the SpecialPollInterval.
Note the 0x1 after each server entry in the manual peer list. This SpecialInterval tells Windows Time to check the time every SpecialPollInterval seconds. If your SpecialPollInterval is already 3600 (1 hour) as shown above, that should be fine for a physical server. If your server is virtualized and thus subject to more clock skew, you may want to reduce that, e.g. to 900 (15 minutes). There is no command to do that; you must edit this registry value:
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\SpecialPollInterval
The meanings of the registry values are documented on TechNet (Server 2003/2008/2008R2).
Update August 23, 2018 and May 4, 2023
The TechNet registry values documentation has been updated for Server 2012 through 2022. Under SpecialPollInterval, I stumbled across this new tidbit:
New for build 1703, SpecialPollInterval is contained by the MinPollInterval and MaxPollInterval Config registry values.
Strange wording. I guess it means that SpecialPollInterval should or must be between MinPollInterval and MaxPollInterval. I’m still on the main 1607 release of Server 2016, so this is probably not enforced yet, but better check it now.
To see the Min and Max: w32tm /dumpreg /subkey:Config
This arcticle (formerly KB3205089) explains things better. On two example computers in my office:
Server settings (new Server 2022):
MinPollInterval = 0x6 (== 2^6 seconds == 64 seconds or 1 minute)
MaxPollInterval = 0xA ( == 2^10 seconds == 1024 seconds or 17 minutes)
Workstation settings (older Windows 10):
MinPollInterval = 10 = 0xA (== 2^10 seconds == 1024 seconds or 17 minutes)
MaxPollInterval = 0xF ( == 2^15 seconds == 32768 seconds or 9.1 hours)
So my SpecialPollInterval of 900 (15 minutes) is already in between those numbers.
The interesting thing in that article is Workaround 2: If you leave the flag set to 0x8, it should automatically adjust the interval as needed between from “MinPollInterval all the way up to MaxPollInterval if the client machine keeps fairly accurate time.” So on the new Server 2022 above, time will sync every 1-17 minutes. The NtpServer is set to time.windows.com,0x8. I used to always change that to pool.ntp.org, I think because time.windows.com was unreliable. Hopefully they’ve fixed that; I’m going to leave the default and see.
AnnounceFlag
Regarding this key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags
another nugget, buried in the depths of KB816042:
- If an authoritative time server that is configured to use an AnnounceFlag value of 0x5 does not synchronize with an upstream time server, a client server may not correctly synchronize with the authoritative time server when the time synchronization between the authoritative time server and the upstream time server resumes. Therefore, if you have a poor network connection or other concerns that may cause time synchronization failure of the authoritative server to an upstream server, set the AnnounceFlag value to 0xA instead of to 0x5.
- If an authoritative time server that is configured to use an AnnounceFlag value of 0x5 and to synchronize with an upstream time server at a fixed interval that is specified in SpecialPollInterval, a client server may not correctly synchronize with the authoritative time server after the authoritative time server restarts. Therefore, if you configure your authoritative time server to synchronize with an upstream NTP server at a fixed interval that is specified in SpecialPollInterval, set the AnnounceFlag value to 0xA instead of 0x5.
Basically, if things aren’t always peachy, set AnnounceFlags to 10 (0xA) instead of 5. I actually had 10 already (not sure how that was set) but after using the Fix it from that KB article, it changed to 5. Since my server seems to be struggling to get remote time servers to answer, I’m setting it back to 10.
Debugging
I’ve been trying to figure out why a virtual domain controller often shows “Local CMOS Clock” as when I run w32tm /query /source. Haven’t cracked it yet but a few tidbits I’ve learned:
You can turn on Windows Time Service debug logging.
When the time source ends in 0x1, Windows Time sends “NTP version 3, symmetric active” packets (as described in WireShark with display filter “ntp”). The packets coming back are “NTP version 3, symmetric passive”. If they come back.
When the time source ends in 0x8, Windows Time sends “NTP version 3, client” packets and (hopefully) receives “NTP version 3, server” back.
If you run w32tm /monitor /computers:<time server IP>, Windows Time sends and receives “NTP version 1” packets, which always seem to work.
This post suggests changing from 0x1 to 0x8 if you’re having trouble with symmetric packets, but that didn’t fix my issue.
To watch NTP packets on the WAN side of a UniFi USG router, SSH in and use this command:
sudo tcpdump port 123 -i eth0 -n
To watch NTP packets on the LAN side coming and going to a specific internal IP address:
sudo tcpdump host 192.168.1.55 and port 123 -i eth1 -n
There’s a helpful tcpdump tutorial with examples here.