The mysterious case of broken time sync

Today was kind of weird — after having a brief conversation about time sync during OOBE that brought back a bunch of memories, touching on a blog that I did talking about the importance of time, I ran into a time sync issue of my own just a few hours later. While testing out a small change to the network connection logic being used in Tanium Provision during bare metal deployments, I noticed something odd: there was a 30-second delay in the connection logic that wasn’t there before.

Thinking that I broke something in my changes, I started investigating to see where this delay was coming from, convinced that it was my fault. After some digging around (and 45 minutes wasted), I finally found the culprit: The time sync that we do in the process (which isn’t what I changed, thank goodness) to make sure the machine has the right time, was timing out. How ironic. Where is this time sync pointing? To the standard time.windows.com NTP server. So why isn’t that working?

Some poking around the internet pointed me to the w32tm.exe utility built into Windows. You can specify some parameters to test out an NTP server. So I tried the command “w32tm /stripchart /computer:time.windows.com /dataonly /samples:5” to see what was going on. (A quick check of the NTP protocol description says that it does five tests, drops the biggest and smallest, and then averages out the other three, so five seemed reasonable for a test.) Interestingly, there were timeouts:

Trying a larger number doesn’t change much:

Interestingly, time.windows.com always returns the same IP address for me, which nslookup confirms:

So what is trafficmanager.net? That’s the Azure Traffic Manager service. Normally that would route me to a specific server to either load balance or to find something nearby. No idea how that works with non-web traffic, but whatever it’s doing, either it’s not doing it well or the servers that it is pointing me to are unhealthy.

So how do you fix that? Well, I suppose you can open a support case with Microsoft. Or, just point to a different NTP server:

There’s a whole list of servers out there. And they work…

Categories: Miscellaneous

2 replies »

  1. Thankyou so much Mike Niehaus. I’m now going to start using one of the many Time Servers listed on the link you provided. I was able to replicate 100% the problem you had using time.windows.com.


  2. For me this one solved the issue (workaround 2): https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/w32time-sync-specialpollinterval-ignored

    I opened a Microsoft case and asked if this is a documentation bug (as we have the issue with Win11 22H2, where this article does not apply to). They answered “No, any client should be set to 0x8, this is documented here: https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings”

    I do not agree that this is properly documented/recommended under any of the 2 links, but at least it works…