Blake,

Here's an article that provides an overview of the Windows 2000/XP/2003 implementation of SNTP. You should review how time synchronization is carried out on your network, as well as what clients are used to implement it. In the article, note especially the section about how the SNTP client implementation works. As you'll see, it's not particularly robust about the ways it uses to bring a client into synchronization.

UDP (the so-called User Datagram Protocol) is normally used to implement NTP on a network. There can be very little error checking associated with NTP queries, and all of it must be supplied by the SNTP/NTP client. I've not found any discussion of how the XP SNTP client (which runs as a service) reacts to a corrupted NTP packet.

As a troubleshooting step, you might want to download and run Tardis as the NTP client service on the troubled systems. Note that you'll need to disable the Microsoft "Windows Time Service" to replace it with Tardis. Set up Tardis as a client, and point it explicitly at your domain's time server (or servers). Tardis is very stable NTP client that's widely used. You should be able to use its logging facilities to determine what's leading these machines astray. Note that XP's Service Pack 2 firewall needs to be configured explicitly to handle the NTP protocol. There's a very good description of that in a link from the Tardis home page.

Jim

Thanks for the replies. I just had it happen again on a Precision 370 this morning. It suddenly decided it was the evening of October 5, 2005. It's the first time this problem has occurred on that particular workstation. Interestingly, it doesn't seem to happen on login; I think it happens on application launches. Specifically, today it seemed to happen when launching Outlook 2003. (I'm not sure at this point if it happens with other applications or not. The problem won't appear for weeks sometimes, so testing these hypotheses is difficult.) I've been unable to find anything in anyone's knowledge base (particularly Microsoft's or Dell's) that suggests what the problem could be.

I installed Tardis on the offending machine today and selected the logging functions that seemed appropriate. I'll see if it tells me anything. Thanks for the advice.

Blake

Yes, it's always been set to sync with a local time server called "RDC" (which is the PDC emulator and is set to get the time from an external source). Using "net time /querysntp" has always shown that result. None of the other machines on the network get incorrect time from that server, though. So far, it's only been four computers out of about 40 or so.

Interestingly, we just recently did a bunch of server upgrades. The time server is now on new hardware and went from Windows 2000 Server to Windows Server 2003. The problem existed both before and after the server upgrades.

Blake

"today it seemed to happen when launching Outlook 2003."

Blake,

That makes one wonder if Outlook forces a system time synchronization, perhaps for the calendar function, when it starts. I haven't been able to find any information about such a feature, though. My suspicion is that there's a "rogue" (possibly meaning incorrectly configured) time server involved. Given that Tardis attempts to keep the workstation time much closer to the NTP server's time than the Microsoft client does, it may tell the story - as long as it's asking the same NTP server as the Microsoft client would have! You should be able to find out what server's being interrogated using the "net time /querysntp" command from a cmd.exe window.

Jim

Just found out something else interesting I didn't know: While Windows 2000 uses SNTP, Windows Server 2003 and Windows XP use NTP. See TechNet under "How Windows Time Service Works". Of course, NTP is downward-compatible with SNTP, so this shouldn't be an issue.

Blake

---

If you filter the capture so it's only collecting NTP, that should be OK...unless it turns out that the client is polling at a high frequency, which would be both interesting and unexpected!

---

It had better not be! :-) Good point, though. I guess I'll plan on installing both Tardis and Ethereal on the next one that (re)exhibits the problem. Thanks for the suggestions.

Blake

Not a bad thought on packet sniffing. My only worry there is that I might need to capture weeks worth of data before anything happens. I think I'll wait for it to happen again first, then see if I can replicate it with Ethereal active. There actually have been a couple of times I've seen the time jump forward again immediately after fixing it. In fact, it happened today!

Blake

Blake,

If you filter the capture so it's only collecting NTP, that should be OK...unless it turns out that the client is polling at a high frequency, which would be both interesting and unexpected!

Jim

Blake,

Sounds like an entirely correct setup. And you'd expect that if something "poisoned" the NTP server on "RDC", everything in the AD domain would be affected.

Since the statistics are so unfavorable, it's going to take a long time to determine whether a different NTP client will have any impact on the situation. I don't know whether Microsoft's client listens for NTP broadcasts, as well as NTP packets coming from the server it's configured to use. If it did, another speculation about the "rogue" server is that it's sending NTP packets to the network's broadcast address. But as to why it happens so infrequently, and only to certain systems, I haven't been able to come up with any sort of hypothesis that makes sense.

If you're able to set up a sniffer either on one of the machines that exhibits the symptom, or on another machine that can capture all NTP traffic from the network port of one of the machines that exhibits the symptom, that might add more badly needed data.

Jim