Did Your Active Directory Domain Time Just Jump To The Year 2000?



AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!


Hey y’all, Mark here providing an AskPFEPlat late night PSA. We are seeing some reports that some Active Directory Domains times reverting to November 2000. So what just happened? I thought the Mayans said this type of stuff didn’t happen until December.

UPDATE: We’ve provided more guidance around this topic, read at http://blogs.technet.com/b/askpfeplat/archive/2012/11/26/fixing-when-your-domain-traveled-back-in-time-the-great-system-time-rollback-to-the-year-2000.aspx

UPDATE: If you are unsure of these actions contact CTS, they will help you through it. We will be providing an in-depth post around this sometime in the future. Don’t wait for this future post to solve your issue today however, call CTS. 

Check where your root PDC is getting its time settings from. In your root domain run the command w32tm /monitor. You can also run the command w32tm /monitor /domain:domain for other domains.





See where mine says ContosoDC01.Contoso.com****PDC*** and then NTP saying it’s getting time from itself. I’m willing to bet you are getting it from “usno.navy.mil”. BTW my lab is wrong it should be getting from an external time source but that’s a different post for a different day. Let’s get you fixed up.

Step 1.) Run W32tm /stripchart /computer:NTPServerAddress to make sure you are getting the correct time from your new source.

Step 2.) Set the correct time settings to a known good source. I would check to make sure you are following  http://support.microsoft.com/kb/816042 but we are really focusing on step 4 in that KB to set a new source.

Specify the time sources. To do this, follow these steps:


  1. Locate and then click the following registry subkey:


  2. In the pane on the right, right-click NtpServer, and then click Modify.
  3. In Edit Value, type Peers in the Value data box, and then click OK.


    Note Peers is a placeholder for a space-delimited list of peers from which your computer obtains time stamps. Each DNS name that is listed must be unique. You must append ,0x1 to the end of each DNS name. If you do not append ,0x1 to the end of each DNS name, the changes that you make in step 5 will not take effect.


3.) Run w32tm /config /update

4.) Shake your fist at those Mayans, you are all done.

Ok so is everything replicating? Great you are done for now! If not read on.


I’m guessing you might see some Event ID 2042.


IMPORTANT: Ensure that the “Strict Replication Consistency” registry value(HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency ) has been set to the default for Server 2003 and greater value, which is 0x1 before you do.“Strict Replication Consistency” will ensure that no lingering objects will be replicated out if they really exist after we force the replication to happen.

Note: This forces the replication even if the AD replication has failed with the partner for more than the tombstone lifetime. In most cases, if the server is really having the replication failure and is not caused by this unexpected time jump issue, you would see new replication errors caused by lingering objects as long as “Strict Replication Consistency” is 0x1; then no lingering objects would be really replicated out.




We will now want to follow  http://technet.microsoft.com/en-us/library/cc757610(WS.10).aspx

On the downstream domain controller where it reported the replication error code 8614 (ERROR_DS_REPL_LIFETIME_EXCEEDED), setup the “Allow Replication With Divergent and Corrupt Partner” registry value.


  1. Click Start, click Run, type regedit, and then click OK.

  2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

  3. In the details pane, create or edit the registry entry as follows:

    If the registry entry exists in the details pane, modify the entry as follows:

    1. In the details pane, right-click Allow Replication With Divergent and Corrupt Partner, and then click Modify.
    2. In the Value data box, type 1, and then click OK.

    If the registry entry does not exist, create the entry as follows:

    1. Right-click Parameters, click New, and then click DWORD Value.
    2. Type the name Allow Replication With Divergent and Corrupt Partner, and then press ENTER.
    3. Double-click the entry. In the Value data box, type 1, and then click OK.


No restart is needed. Force replication in AD Sites and Services between the destination source and destination servers.

Remember to change the “Allow Replication With Divergent and Corrupt Partner” value back to 0x0 after the issue has been sorted out.


If you are STILL having replication issues they could have been happening BEFORE all this happened. Just call into Premier support and we’ll get you figured out.


How Did This Happen?

Well, you should really be syncing from a reliable INTERNAL time source and not one on the internet for various reasons. Also you most likely do not have the regkeys set for MaxPosPhaseCorrection and MaxNegPhaseCorrection, follow this KB http://support.microsoft.com/kb/884776.

This type of thing is also caught in our famous Active Directory Risk Assessment (ADRAP). This leads me to have a discussion about how Windows Time works while doing one. Everyone says there is no way this can happen, and yet here we are. Never had one? Contact your TAM and let them know you need one right away and this blog told you so. Not a Premier customer? Contact us here and we’ll get you in touch with the right folks. 



Thanks to Chulin Xu and Hakimuddin Wadlawala who had a very busy night

 UPDATE: We’ve provided more guidance around this topic, read at http://blogs.technet.com/b/askpfeplat/archive/2012/11/26/fixing-when-your-domain-traveled-back-in-time-the-great-system-time-rollback-to-the-year-2000.aspx

Mark “Party Like Its 1999” Morowczynski