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:
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:
The meanings of the registry values are documented on TechNet (Server 2003/2008/2008R2).
Update August 23, 2018
The TechNet registry values documentation has been updated for Server 2012/2012R2/2016. Under SpecialPollInterval, I stumbled across this new tidbit:
New for build 1702, 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.
KB3205089 is relevant but I believe the default values are incorrect. On my server:
MinPollInterval = 0x6 (== 2^6 seconds == 64 seconds or 1 minute)
MaxPollInterval = 0xA ( == 2^10 seconds == 1024 seconds or 17 minutes)
So my SpecialPollInterval of 900 (15 minutes) is already in between those numbers. The default 3600 would not be between those numbers. Huh.
Regarding this key:
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.
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.