Hotfix Lets W32time Sync with Very High Precision NTP Servers

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

7 thoughts on “Hotfix Lets W32time Sync with Very High Precision NTP Servers

  1. Mark Berry

    Thanks for that link. In this context, “very high precision” just means any server with a precision less than -30 (since it’s negative, a value less than -30, e.g. -31, indicates higher precision). Probably more likely in the NIST/Level 1 servers, but theoretically any server could return very high precision.

  2. Mark Berry

    A few times this past week, a server has been reporting that it couldn’t get time from nist1.symmetricom.com (W32Time Warning Event ID 47). I found this helpful link of which servers are busy:

    http://tf.nist.gov/tf-cgi/servers.cgi

    nist1.symmetricom.com is not listed as busy, but the other server mentioned in the original article, time-b.timefreq.bldrdoc.gov, is listed as VERY busy. I also see that there is a server in Los Angeles, even closer to my San Diego location. So I’m changing my time servers using these commands:

    w32tm /config /manualpeerlist:”nist1-la.WiTime.net,0x8 nist1.symmetricom.com,0x8″ /syncfromflags:MANUAL
    net stop w32time
    net start w32time
    w32tm /resync

  3. Rick

    I am also getting events 38 and 47 with many different time servers on my 2003 server. This just started happening last week. I tried using…

    w32tm /config /manualpeerlist:”206.112.100.146,0×8 69.25.96.13,0×8″ /syncfromflags:MANUAL /reliable:yes

    which is the last setting you are using Mark with IPs instead of names. Now, when I do a resync, I get “the computer did not resync because no time data was available. I have used IPs before so it’s not that. What has changed the past week or so?

  4. Rick

    Just an update. I addeed /update to the command…

    w32tm /config /manualpeerlist:”206.112.100.146,0×8 69.25.96.13,0×8″ /syncfromflags:MANUAL /reliable:yes /update

    and it works better now.

  5. Mark Berry

    Rick, have you applied the hotfix? If the servers you are using recently upgraded to very high precision, that could explain the sudden errors.

  6. Rick

    Mark, we haven’t applied the update so I don’t know what caused the errors all of a sudden. I did check to see that we have “later” versions of the hotfix files. Since I added the /update to the config statement it is working fine. Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.