Time Server Upgrades Expose W32Time Bug 

Some time ago, I set up two NTP time sources for my Windows 2003 / SBS 2003 domain controllers:  time-nw.nist.gov in Redmond, Washington, and time-a.nist.gov in Gaithersburg, Maryland.

I noticed that the machines don't ever seem to sync with time-nw.nist.gov. I keep getting W32Time errors:

Event ID: 38
"The time provider NtpClient cannot reach or is currently receiving invalid time data from time-nw.nist.gov"

Event ID: 47
"No valid response has been received from manually configured peer time-nw.nist.gov,0x8 after 8 attempts to contact it."

However, my second source, time-a.nist.gov, usually works, so the servers' times are still in sync:

Event ID: 37
"The time provider NtpClient is currently receiving valid time data from time-a.nist.gov"

I tried replacing  time-nw.nist.gov with a couple other servers from the NIST's list of public servers, but the other two options failed as well. What's going on here? Only one clock in the country works? Finally I came across this thread on a Channel 9 forum.

On April 25, 2007, "PeterInSydney" turned on w32time logging (here's how), and discovered that the w32time client was rejecting time with a "precision" value of -31. A Microsoft employee in Redmond, Matthew van Eerde, confirmed that this is a bug in the w32time client:  "The w32time client incorrectly rejects packets with precision < -30." Van Eerde followed up on April 27 with a very helpful summary of what situations are broken (basically any XP or Win2003 machine trying to talk to a "very high-precision" server). The April 27 post mentions that, "Recently (March time frame) time.nist.gov became 'very high precision.'" The workaround is to use a lower-precision server.

Sure enough, when I turned on w32time debugging on my server, I see that time-nw.nist.gov is also returning a -31 precision, whereas time-a.nist.gov is still "only" -30. That explains why only time-a.nist.gov is working.

Pardon the pun, but isn't this a time bomb waiting to explode? So far I haven't been able to find a list of which servers offer what level of precision. But if the NIST servers are gradually being upgraded to higher precision, won't the Windows machines that rely on them eventually be left high and dry?

The Hotfix 

Fortunately, reading further in the (four-page) Channel 9 thread, on September 4, Microsoft's van Eerde announced that a hotfix for Windows Server 2003 is available:

The Windows Time service in Windows Server 2003 does not synchronize time with a time server if the precision value of the NTP response is less than -30
http://support.microsoft.com/kb/940742

So I submitted an online hotfix request, and in under two hours, the hotfix instructions arrived. Once applied and rebooted, time is now syncing properly with very high precision servers.

Still Getting Errors 

Even though the Windows servers will now sync with very high precision NTP servers, I still sometimes get the 38 and 47 errors. Examing the debug log, this time it is due simply to the NTP server not responding to a query:

Polling peer time-nw.nist.gov (ntp.m|0x8|192.168.1.2:123->131.107.1.10:123)
Sending packet to time-nw.nist.gov (ntp.m|0x8|192.168.1.2:123->131.107.1.10:123) in Win2K detect mode, stage 1.
No response from peer time-nw.nist.gov (ntp.m|0x8|192.168.1.2:123->131.107.1.10:123).
Logging information: NtpClient cannot reach or is currently receiving invalid time data from time-nw.nist.gov (ntp.m|0x8|192.168.1.2:123->131.107.1.10:123).

So even though Windows is now able to handle high precision servers, you still have to find servers that are responsive. I never got time-nw.nist.gov to respond, and time.nist.gov was intermittent. Maybe w32time made too many requests and was blocked by the servers. In any case, I finally found two geographically separated NIST servers that are responding well. Here's how I set them up (commands adapted from KB 875424):

w32tm /config /manualpeerlist:"nist1.symmetricom.com,0x8 time-b.timefreq.bldrdoc.gov,0x8" /syncfromflags:MANUAL
net stop w32time
net start w32time
w32tm /resync