Repadmin is the tool used to troubleshoot replication in an Active Directory forest.. commands like repadmin /replsum (to view replication summary) or repadmin /showutdvec (to view USN per domain controller).. are common commands.. it get’s tougher when we want to create or modify links during troubleshooting.. then we use /add to add replication links between two servers..

But aren’t replication links the what we see in Sites & Services?
Actually no.. the links are the actual replication agreements between the two servers, each partition of the AD has it’s own replication link per server.. to view them we can use repadmin:

So in the above text we have DC1 that has a replication object to DC2` .. within that replication object multiple links exist. As you can see, it replicates ForestDnsZones,DomainDnsZones,Configuration and Domain.. and i can hear you asking What about the schema partition? That actually uses the configuration link to replicate and is therefore not shown.

So you can see the Connection Object (what you see in sites and services) as the container that holds multiple links..

Now ay we have a large forest with a lot of troubles.. DC1 and DC2 do not replicate and the KCC is going nuts about .. well are there is.. then we can do the following: We can disable the KCC, delete the connection objects and create the connections ourselves.. initiate replication and enable the KCC again to figure it out on its own again..There is one advantage to this above the KCC.. the KCC uses as you see in the above output: not the actual servername, but the DN field of the NTDS object of the target server.. using the repadmin /add command you can specify the server based on FQDN or Hostname. Basically disconnecting the referral process within AD for replication and using normal name lookup mechanisms. If you DNS is okay, your servers should be able to find each other and replicate normally.

Now the expert command has two options for adding replication links.. the Repadmin /add command and the Repadmin /addRepsTo Command..
the question raised is.. what’s the difference.. can’t I just use one and reverse the inbound outbound DC?

The answer is no.. the two different attributes we are referring to in this blog is are Reps-From and Reps-To in the connection objects.
The Reps-From is always used (remember AD is pull mechanism, not push). The Reps-To attribute is only used when a change notification is enabled on the link.. a connection object with a Reps-To in his connection object will tell the source DC to notify the To Partner.. and that partner will use the Reps-From attribute to find his DC to GET the data from..

Basically .. when you have disable replication notification for a connection object in a normal situation connection object does not have a Reps-To attribute. Now note that the RepFrom and RepTo attribute are the actual links below a connection object..

When the KCC is switched on again all values will be overwritten and Reps-From and Reps-To are overwritten..since a new connection object is created.. this new connection object created by the KCC uses the fromServer:CN=NTDS,SERVER… attribute for the connection object.. Notification is switched on or off through the options of the connection object. (in BITS format.. ) not on the connection link..

The Repadmin /add and /AddrepsTo is usually used during crisis situations or when trying to remove lingering objects..