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:
Solution
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...
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
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).
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:
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.
