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

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.

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:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

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

Mark “Party Like Its 1999” Morowczynski