通过

I renamed my WS2008 Domain Controllers and now replication is not working.

  • 项目

 

Symptoms;

When I saw this replication was totally failing to some tail sites. Upon further investigation I noticed that when I forced a replication between two servers they didn’t update even though the replication was successful. The successful replication was due to the server replicating with its old partner. I was also seeing other DC fail replication completely.

DFSR logging had the following entries

20081205 09:45:58.351 2168 CFAD 6915 [ERROR] Config::AdSnapshot::ReadReplicationTopolgy Failed to BuildGlobalSettingsTree(). memberDn:<DN Member Info> Error:

+ [Error:13(0xd) Config::AdSnapshot::BuildGlobalSettingsTree ad.cpp:6253 2168 W The data is invalid.]

+ [Error:13(0xd) Config::AdSnapshot::BuildTopologySubTree ad.cpp:6434 2168 W The data is invalid.]

System Event Log had Event ID: 6002

The DFS Replication service detected inconsistent msDFSR-Subscriber object while polling for configuration information. The object at <Object> references another object at <Another Object> that does not exist.

Using DSquery.exe some of the msDFSR-MemberReferences would be blank or incorrect

C:\Windows\Debug>dsquery * "<Another Object> " -attr msDFSR-MemberReference

  msDFSR-MemberReference

<Blank>

Why did this happen?

This was all caused by the DFS Replication Member Objects not being correct after a bunch of Domain Controllers were renamed. Some still had member objects that identified them as their old names; others were missing member object references entirely. The Domain Controllers were renamed using netdom but the DFS Replication Member Objects were never updated https://technet.microsoft.com/en-us/library/cc794759.aspx

 Unfortunately this isn’t done automatically or pointed out in the netdom rename article.

How to fix:

This was fixd by using Adsiedit connecting to each DC and validating the msDFSR-MemberReference, msDFSR-ComputerReference, distinguishedName, and creating new objects as needed if they were missing. It could have been avoided by using https://technet.microsoft.com/en-us/library/cc794759.aspx after the DC rename

Comments