Sometime on the morning of April 3, Microsoft's Network Time Protocol (NTP) servers went haywire. At first, Microsoft's NTP server (time.windows.com) reported the time being an hour later than it should have been. Then, the site went offline. Finally, 24 hours later, the time server came back online with the right time.
What happened? We don't know, and Microsoft isn't saying. Microsoft has yet to return emails about the matter.
Here's what Microsoft's NTP server looked liked at first using the Linux ntpdate command:
The telltale sign that's something's badly wrong is "stratum 16". This tells an NTP administrator that the NTP server isn't synchronized with a clock. As you might imagine, if you're trying to set your computer time without a clock, you're in deep trouble.
Later, Microsoft switched time.windows.com to a new domain address. That didn't work out well either.
3 Apr 10:50:13 ntpdate: no server suitable for synchronization found
By the EDT afternoon, Microsoft had fixed whatever the root problem was and the time was being set correctly.
In the aftermath, you may see a variety of errors on your Windows systems ranging from fouled-up log posts to oddball email date and time stamps. So, if you see some odd time errors in your other programs, you can blame time.windows.com for the foul-ups.
To prevent this kind of bug from messing up your systems, I suggest not relying solely on time.windows.com for your network time-keeping. You can do this from Windows' cmd interface with the following commands on your domain controller (DC):