Quick fix for a non-replicating DC

While it doesn't come up every day, one of the most frustrating experiences for an AD administrator is to try to fix a non-replicating DC. Expert Gary Olsen breaks down the process step-by-step to make troubleshooting your next non-replicating DC a snap.

Here is a handy little trick that you may want to stick in your back pocket for a rainy day. You may not use this...

a lot, but when you need it, it will be invaluable.

One of the most frustrating experiences for an Active Directory administrator is to try to fix a non-replicating DC. But when it replicates in one direction but not the other (i.e. inbound but not outbound), you really are left scratching your head. This condition can happen to a newly promoted DC or to an existing one. If replication was broken in both directions you might look at a broken network connection or a DNS problem, but being broken in only one direction is hard to troubleshoot.

NOTE: All Replication is inbound. "Outbound replication" refers to the replication operation where another DC pulls from a DC. For instance, If DC1 and DC2 are replication partners, DC1 replicates inbound from DC2. In turn, DC2 replicates inbound from DC1. Outbound replication for DC1 refers to DC2 pulling replication from DC1.

Problem description

This problem is normally seen when you promote a new DC into the domain. There are no errors up to the reboot, but the Netlogon and SYSVOL shares are never created. However, this can also occur on active DCs. Clues to a non-replicating DC usually produce errors that show up in DCdiag output, in the Repadmin/showreps report, or by observing errors in the DS Event log. Other indicators include:

  • No automatically generated connection object from the original to the broken DC.
  • Replicate Now on inbound objects on original DC works from the broken DC.
  • Replicate Now on objects on the broken DC from the original DC all say, "Naming context is in the process of being removed or is not replicated from the specified server."
  • Check replication topology operation on the broken DC fails with the error, "AD property not in cache."


Many times you might be tempted to perform a manual demotion on the broken DC and re-promote it. However there is a very simple repair for this condition that, in my experience, has a high degree of reliability and is preferable to manual demotion. That process involves using the Repadmin command to add a low level connection link that will permit the KCC to then generate a proper connection object.

The process is fairly simple. First, you must identify the DC with the problem, and a known good DC. In the step-by-step procedure described here, DC1 is a known good DC, while DC2 is a DC that can only replicate inbound from DC1, but DC1 cannot replicate from DC2. (Of course you will need to replace "Corp.net" domain name here with your domain name).

1. We will use the Repadmin /add command which requires us to refer to the Server GUID of DC1 and DC2. Therefore, we first need to determine each Server's "Server GUID". This can be done by running the command Repadmin /showreps on each server. One of the first lines in the output of this command specifies the "objectGUID" as shown here:

ATLANTA\ATL-DC01 DSA Options : IS_GC objectGUID : 1388A125-9318-4992-AA53-1A0519E24D0A

The objectGUID is to be used in the Repadmin/Add command.

2. The domain name for this example is Corp.net. The server GUIDs for the two DCs are: DC1 server GUID = 1388A125-9318-4992-AA53-1A0519E24D0A DC2 Server GUID = A8413FDA-3131-4F0D-AFE0-C1E110321D25

In the sites and services snap-in, go to DC2 (The bad DC) and delete all connection objects - manual and automatically generated.

3. Create a new connection from the broken DC to the good DC, using the Repadmin command line utility located in the Support Tools on the Windows 2000 and the Windows 2003 Server CDs. Again, in this example, DC1 is a known good DC and replication from DC2 to DC1 is failing.

C:\>repadmin /add "cn=configuration,dc=Corp,dc=net" 1388A125-9318-4992-AA53-1A0519E24D0A._msdcs.corp.net A8413FDA-3131-4F0D-AFE0-C1E110321D25._msdcs.corp.net

Note that we listed the GUID of the good DC first (destination) and the GUID of the broken DC last (source). This creates a link from the broken DC to the good DC.

During this procedure using Repadmin/add, if you get error 8441: distinguished name already exists, then the connection is already there - proceed to the next step.

4. Execute a full replication sync across the connection just built:

C:\>repadmin /sync cn=configuration,dc=enterprises,dc=compaq,dc=com DC1 A8413FDA-3131-4F0D-AFE0-C1E110321D25/force /full

In this case, the name of the good DC is listed first (destination) and the GUID of the broken machine (source) is listed last. This will force a synchronization across the connection just made. A success notice should appear.

5. Validate that Replication works.

In Sites & Services, check to make sure there are automatically generated connection objects from the broken machine to the good one (root) and make sure Replicate Now works on that object without error. Also right click on the NTDS Settings object for each DC, go to All Tasks - Check Topology. Make sure it executes without error.

6. Check the Directory Services, System and Application event logs for related errors.

To ensure that replication is working, create a new site in Sites and Services on the broken machine and see if it replicates to the good one (remember to focus the snapin on each machine to see it's view of the world). Also create a user account on the broken machine in the Users and Computers snapin and see if it replicates to the good machine. This tests the schema and configuration naming contexts (site creation) and the domain naming context (the user account).

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers

This was last published in March 2006

Dig Deeper on Microsoft Active Directory Tools and Troubleshooting



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Thank you so much! Your resolution just saved me!
does this apply for usn rollback error, whem domain controller on vmware is restored from snapshot ??
phyoewaipaing, you should NEVER snapshot a Domain Controller. If you absolutely must, make sure the NIC is removed before you take a snapshot and then shut it down before you bring it back on the network. Otherwise you are just asking for trouble.