Partager via

Granular Active Directory replication for advanced troubleshooting scenarios

  • Article

This post introduces an advanced functionality of repadmin.exe which allows us to initiate replication between domain controllers that do not share a connection object. This is useful when you need to be able to predict where a domain controller will replicate from. Think of any scenario where you know you have a 'good' copy of a naming context on one server, and you need to sync that naming context to another server. You don't want to change your Active Directory topology, or introduce manual objects, you just want two domain controllers to talk to each other in an effort to bring one of them up to date.

Short Version

1. Stop the KCC from cleaning up after you while you get replication sorted: Repadmin /options <DC-Name> +disable_ntdsconn_xlate

2. Add a replication connection (not to be confused with connection object) for the naming context we want to get from another server: Repadmin /add <Naming Context> <Dest DSA> <Source DSA> [/readonly] [/selsecrets] (You should see output like: One-way replication from source:DC1.contoso.com to dest:DC2.contoso.com established.)

* The other tip here is to always pull the config partition first. So even if its the domain partition you need, create a connection to the configuration partition and replicate it first.

3. Begin the synchronisation: "Repadmin /replicate <Dest_DSA_LIST> <Source DSA_NAME> <Naming Context> [/force] [/async] [/full] [/addref] [/readonly] "

4. Turn the KCC back on so it can do its thing. Repadmin /options <DC-Name> -disable_ntdsconn_xlate

 Long Version

Just to be clear here. We are not building connection objects like those shown in the GUI. See the example below. What we are doing instead is messing with the replication connections on each partition that needs to be replicated by a domain controller. Specifically, we are modifying the repsFrom and repsTo attributes of a partition.

 

A quick overview of what this example achieves is best explained by this diagram:

I've only kept the relevant info in here, there are actually more connection objects in play than we see in the diagram but you can hopefully see that DC3 is pulling its changes from DC2.

In this example we have decided that we need to pull changes from DC1 to DC3. Lets say DC1 has the "good" copy of a partition we are cleaning up for lingering objects in a forest. We are trying to achieve this:

 

The first thing to know, is that the knowledge consistency checker (KCC) isn't going to love what we are doing here, and it is going to automatically clean up the replication connections that have no corresponding connection object.So what do we do? We tell the KCC to stay out of it, just for this domain controller and just for now. We can do that using this command:

Repadmin /options <DC-Name> +disable_ntdsconn_xlate

In our example:

Then, we get on with building a direct replication connection (not a connection object) between the domain controllers we need to replicate. We do the configuration partition first, then any other partition we need:

Repadmin /add <Naming Context> <Dest DSA> <Source DSA> [/readonly] [/selsecrets]

In our example (configuration partition) :

(domain partition)

Now we have direct replication connections to the domain controller we want to pull changes from. Notice that nothing changed as far as connection objects are concerned - there is still just the one, replicating from DC2:

What we get instead is a new entry in the "reps-from" attribute on the partitions we are trying to replicate:

The repsFrom and repsTo attributes are what the domain controller actually uses to perform the replication (Remember AD replicates per partition, not per server - so it makes sense that we can have different values here for different partitions).

Notice if I look at the Schema partition (which I didn't add a replication link for) there is only one entry still:

Ok, so now we have the replication link set up for both configuration and domain partitions - lets pull the data across:

Repadmin /replicate <Dest_DSA_LIST> <Source DSA_NAME> <Naming Context> [/force] [/async] [/full] [/addref] [/readonly]

In our example:

(we are pulling both the domain and config partitions)

You can trust the output in the last screenshot where it says that "Sync from dc1.contoso.com to dc3.contoso.com completed successfully". Or you can view your handy-work with repadmin /showreps. Note the extra replication connections you see for the domain and configuration partitions (just a single for the schema and the dns partitions).

 

Almost done -> remember we disabled the KCC so that it wouldn't mess with our manual replication attempt? We need to turn that on:

Repadmin /options <DC-Name> -disable_ntdsconn_xlate

In our example:

And just to show that the KCC will be ruthless with our connection, we can run - repadmin /kcc (kicks off the kcc now rather than waiting 15 mins).

Now note that our replication connections are taken away by the KCC and we are back to a single source for all naming contexts.

And that's it.

I hope this has been useful for you. It is an advanced troubleshooting technique for AD replication that the CTS guys use when you are in serious replication related trouble. Its not something you would do every day, but its very handy to know when the time comes to get really granular with your AD replication to solve a serious issue.

Comments

  • Anonymous
    August 08, 2016
    You are my HERO, simply HERO. I was fighting with a intra-forest replication for 2 days and your article resolved this in 5 minutes. Wow! Thank you!