AD Replication stops after changing the motherboard of a DC

http://blogs.technet.com/b/andym/archive/2008/12/10/ad-replication-stops-after-changing-the-motherboard-of-a-dc.aspx

 

Ususally an Exchange man but currently working to expand cross platform knowledge I came accross this....

When the motheboard of a DC is replaced (in a simple power down, swap, power up scenarie ie no backups/restores of AD) we can hit an issue where AD replication to replication partners is stopped.

After some digging this turned out to be down to when the replaced motherboard DC came back up the system time made the machine outside the TSL (tombstone lifetime) and this all replication partners not speaking to the DC any more. Despite the system time being changed back to correct.

In a repladmin we see something lke:

 ==== INBOUND NEIGHBORS ======================================

DC=domain,DC=com

    Default-First-Site-Name\DC1 via RPC

        DC object GUID: DCguid

        Last attempt @ 2008-12-08 12:43:33 failed, result -2146893022 (0x80090322):

            The target principal name is incorrect.

        4278 consecutive failure(s).

        Last success @ 2008-12-03 11:31:47.

 

To get around this we:

1) Verify that the time between the domain controller which had the motherboard replaced and the rest of the domain is in synch.

2) Add the registry key below to direct replica partners of the domain controller which had the motherboard replacement (be sure to set the value to 0 and restart that DC once the issue is resolved) then restart that domain controller for the value to take affect:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner
DWORD value of 1

Then restart DC. 

3) Monitor the AD replication with repadmin /showrepl command. The AD replication for transitive replica partners should take place without the need for the "Allow Replication With Divergent and Corrupt Partner" registry value once AD replication for those that have that value succeeds.

4) When this is setup and when replication appears to be running again we can go back to DC and disable this registry key (set to 0) and then restart again.

5) Monitor replication again.

 

Really if we speculate that this sort of issue is occuring then it should be a case of make a call to MS CSS to help establish that this is the issue and not go in with a sledhammer to crack a nut as it could be a number of other issues. Interesting issue though....