domain controller not replicating to member servers

[9163]

i have 2 windows 2003 servers, i recently promoted one to be a the primary domain controller and demoted the other one, after a day , all changes made on the member servers are not being replicated to the domain controller, chnages being made to the domain controller are also not being replicated to the member servers

please help me

carol
believe in all possibilities

 

[HPMatt]

Hey,

I found this whilst digging on the net, looks pretty solid might wanna give it a try?

Good luck!

- Matt

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."
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 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).

 

[Roadki11]

Not trying to be semantically here but your terminology is confusing. If the servers have AD installed then they are domain controllers or AD servers, if they don’t have AD installed they are member servers. Member servers don’t replicate AD information. My real concern here is you promoted a member server to be an AD server then demoted the AD server that was holding all the FSMO roles and didn’t transfer them to another AD server. In this case you would need to seize the FSMO roles. However I think it would be helpful if you explained your situation better so we don’t have to guess at what you mean. You should probably run a dcdiag and netdiag on one of the AD servers and post the results.

RoadKi11

"This apparent fear reaction is typical, rather than try to solve technical problems technically, policy solutions are often chosen." - Fred Cohen