Microsoft offers guidance on Windows Server Year 2000 time-rollback issue

Microsoft offers guidance on Windows Server Year 2000 time-rollback issue

Summary: Microsoft has posted guidance for Windows Server users affected by USNO.NAVY.MIL hiccup that resulted in system time reverting to the year 2000.

SHARE:

While some of us were enjoying our tofurkey over the past week-plus, others were combatting a thorny Windows Server time-rollback issue.

Some Windows Server users are still recovering a recent problem caused by time servers at USNO.NAVY.MIL incorrectly provided time samples that listed 2000 as the current year.

contosodaterollback

 

Microsoft officials have been responding to help requests from those affected by the issue since November 19, 2012, the day some customers began noticing Active Directory replication and other time-sensitive operations failing in their environments.

According to a late-night November 19 post on the Microsoft "Ask Premier Field Engineering (PFE) Platforms" blog, Microsoft began seeing customer reports that some Active Directory Domains times were reverting to November 2000. Microsoft support began working with customers to try to sort out the issue without knowing at the time that the USNO.NAVY.MIL time samples were at fault.

In a subsequent post on November 23, the Softies provided a detailed explanation of the cause, symptoms and mitigation path for those affected. In that post, officials noted that the Active Directory forests most impacted by the time rollback shared two traits: The forest root primary domain controller) or master time servers lacked time-jump protection -- probably because they were running Windows Server 2003; and/or the forest contained Windows Server 2003 domain controllers.

"If system time moved back to year 2000 on November 19th between the hours of 21:07 UTC and 21:59 UTC (16:07-16:59 EST), it’s a pretty safe bet you were affected by the time rollback as USNO.NAVY.MIL," blogged Microsoft Premier Field Engineers Mark Morowczynski, Justin Turner and A. Conner."It’s also possible that your domain moved from current time back to November 19th 2000 then back to current time."

First and foremost, the blog authors warned those affected by the time-jump issue not to reboot immediately.

"AD Replication, Kerberos and possibly secure channels on trusts and computer accounts could be impacted by the time jump. A reboot may trigger the reading of invalid time on OS shutdown or on subsequent OS startup, especially on virtualized guest computers," they said.

The authors offered detailed, step-by-step instructions for repairing the issue, adding that "recovering from a time rollback is a complex situation so read each step carefully and don’t skip ahead or you’ll make the problem worse."

Those still stymied should contact Microsoft Commercial Technical Support for help, they said.

Topics: Networking, Microsoft, Servers, Windows

About

Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • Amusing bug

    Well, maybe not for the ones affected by it. Every OS has some strange issues, it seems. Not too long ago, the leap second bug caused problems for Linux.
    Smalahove
  • This hurt!

    My corporate network got hit by this. Turned into a pretty messy situation. AD replication began failing, but luckily didn't have to reboot anything - look up the trick to reset kerberos caches. My advice would be to make sure that you have the registry settings in place to prevent a time value that is way out of acceptable ranges (detailed in link above) from crashing your network.
    miguelcrush
  • Is this even possible?

    Aren't most NTP clients configured in such a way that they ignore differences of more than 2 hours? Any good NTP client should know time doesn't suddenly go back 12 years...
    Evert Meulie
  • yes, it's possible

    MS has tightened that up with Win2K8 on, but believe me when I tell you it created a massive mess in my company on a Win2K3 forest. It's easy to say 'upgrade, then,' but I wish things were that simple.
    lkjlkjadf