If you’re in a small Active Directory (AD) environment, replication is usually not a big headache. But as the environment grows and more sites are added, replication challenges raise. Repadmin is the perfect tool to troubleshoot replication issues and know what went wrong.
Not a reader? Watch this related video tutorial!Repadmin is a vital tool in any AD administrator’s tool belt that allows you to view and troubleshoot AD replication topology from each domain controller (DCs) perspective. This tutorial will take you through a smooth and fun learning path to master the Repadmin tool.
Let’s get going!
Prerequisites
If you’d like to follow along with the demos in this tutorial and ensure they apply to your environment, ensure you have:
At least two replicating DCs running Windows Server 2008 or greater – This tutorial uses the following. All DCs are in a forest/domain called test.local with the Active Directory Domain Services (AD DS) role installed.
- DC01 – A Windows Server 2019 server in an AD site called Site1.
- DC02 – A Windows Server 2019 server in an AD site called Site1.
- DC03 – A Windows Server 2016 server in an AD site called Site2.
If you still have an older DC running Windows Server 2003, download the Windows Server 2003 x86 Administration Tools.
Starting The Repadmin Tool
Before starting wrangling AD replication with repadmin, you need to start it up first and get acquainted. To use repadmin, you must either be connected via RDP to a DC or have the Remote Server Administration Tools (RSAT) package installed on a domain-joined computer. This tutorial will be performing all demos directly on a DC and will show the most used repadmin commands.
On any available DC:
1. Open a command prompt as administrator.
2. Run repadmin with no parameters to get a feel for what you’re up against. Repadmin returns a full help text with all supported parameters.
Summarizing Replication Health (repadmin /replsummary)
If you’re just beginning your AD replication troubleshooting journey, you should start wide and work your way down. The replsummary parameter is a great parameter to start with since it returns a great summary of overall replication health.
The replsummary parameter provides an overall view of the health of AD replication. When you run repadmin /replsummary, you’ll see an output similar to below.
The output consists of, for each DC:
- Source DSA – Stats on outgoing replication.
- Destination DSA – Stats on incoming replication.
- Largest Delta – The longest replication gap amongst all site links for a particular domain controller.
- Fail – The number of times a failed replication links.
- Total – The total number of replication links.
- %% – The percentage of failed replication links out of the total.
- Error – Displays any replication error along with the error code, such as
(1722) The RPC Server is unavailable.
Replication Summary Start Time: 2021-07-26 23:35:41
Beginning data collection for replication summary, this may take a while:
......
Source DSA largest delta fails/total %% error
DC01 44m:47s 0 / 10 0
DC02 38m:32s 0 / 5 0
DC03 14m:47s 0 / 5 0
Destination DSA largest delta fails/total %% error
DC01 38m:32s 0 / 5 0
DC02 44m:47s 0 / 10 0
DC03 11m:38s 0 / 5 0
Inspecting Replication Neighbors (repadmin /showrepl)
In a multi-DC AD environment, each DC replicates with another DC known as its partner or neighbor. When troubleshooting replication issues, knowing the replication topology is a critical piece of information to know about.
To discover information about replication partners, run repadmin /showrepl. This command reads the local AD database and provides you with lots of great information about each DC’s last time trying to replicate its neighbor’s AD partition, also known as a naming context or replication context.
You can read a remote AD database’s replication information by specifying the DC hostname as the last argument, e.g.,
repadmin /showrepl DC02.
The /showrepl parameter shows various information such as:
- The neighboring DC to replicate from.
- Whether or not the DC is a Global Catalog.
- How the DC is replicating via IP or SMTP.
- The site links for each naming context.
- The site link GUID.
- The last time the DC attempted replication and the status
Monitoring Replication Queues (repadmin /queue)
Depending on the replication schedule, a DC can sometimes get behind its neighbor. When it does, its queue begins to increase. The queue is the number of items pending to be replicated to it from its source neighbor.
The DC’s queue should be zero indicating fully-replicated partitions, but sometimes, the queue can begin increasing on a congested network.
To view the queue, run repadmin /queue, as shown below. In this instance, you’ll see the DC is fully replicated with its neighbor.
If you notice the queue is slowly incrementing, this situation may indicate a problem. If so, be sure to troubleshoot the following:
- CPU usages on the DC (Source replication partner).
- Too many concurrent replication partners.
- Slow network connection.
- Too many changes in Active Directory objects.
Checking Inbound Replication Topology (repadmin /kcc)
To calculate replication topology, each DC runs a Knowledge Consistency Checker (KCC). The KCC is responsible for ensuring a particular DC is aware of who its inbound neighbor is. By default, the KCC runs every 15 minutes, but you can invoke it manually if required.
If, for example, you remove a site link or change the replication configuration in some manner, it’s helpful to run the KCC manually to reevaluate the replication topology. To do so, run repadmin /kcc, as shown below.
You’ll see that the KCC returns the site the DC you’re running it on along with if the check was successful or not.
Repadmin /kcc DC01
You can also trigger the KCC on all DCs in a site using the
siteparameter likerepadmin /kcc site:Site1.
Manually Invoking a Partition Replication (repadmin /replicate)
Even though partitions typically stay in sync, it’s sometimes helpful to manually force a replication when troubleshooting. Forcing replication process between DCs allows you to get quick feedback on if replication is actually working or not.
Trigger a manual replication using the /replicate parameter, as shown below. The /replicate parameter needs at least three arguments, with others being optional:
- The destination DC to replicate to.
- The source DC to replicate from.
- A naming context to replicate.
Find the naming context by running
repadmin /showrepl.
Repadmin /replicate <Destination_DSA> <Source_DSA> <Naming Context>For example, replicating the Schema partition from DC01 to DC02 would look like the command below.
repadmin /replicate DC02 DC01 CN=Schema,CN=Configuration,DC=test,DC=local
Sync from DC01 to DC02 completed successfully.Manually Invoking Replication for All (repadmin /syncall)
If the /replicate parameter replicates a single partition, the /syncall parameter is the nuclear approach. The /syncall parameter has the ability to sync all partitions on all DCs.
The /syncall parameter is great for times when you want to test the entire replication topology as a whole or even mimic the behavior of the /replicate parameter, as you’ll see below.
Replicating a Single Naming Context for DCs in the Same Site
The /syncall parameter requires only a single argument, the DC, to test replication to/from. For example, if you wanted to test replication to/from a DC called DC01, you’d run the command below. This command would test replication of the Configuration directory partition only.
By only specifying the DC to test replication to/from, repadmin will only invoke replication to/from DCs within the same site.
Repadmin /Syncall DC01 /d
Replicating All Naming Contexts for DCs in the Same Site
But what if you need to replicate all naming contexts to/from a particular DC within the same site. In that case, you’d use the /A argument. You’ll see below the output now includes all naming contexts.
Repadmin /Syncall DC01 /d /AUse the
/eargument to force replication across all DCs in all sites.
Note that all arguments are case-sensitive!
Pushing Replication
By default, DC replication is a pull operation, but you can also configure replication to push. For example, perhaps you need DC01 to send updates to DC02 instead of DC02 pulling changes from DC01. To do so, add the /P argument to change the direction of replication.
You’ll now see below replication happens from DC01 to DC02.
Repadmin /Syncall DC01 /d /P
Getting Granular: Replicating a Single Object
In the above examples, you were replicating all changes, but repadmin can also get granular and replicate a single AD object. Using the /replsingleobj parameter, you can select a single object and control its full replication from source to destination DC.
To demonstrate, let’s replicate a user object named User1 from DC02 to DC01.
This demonstration will use PowerShell and the Active Directory module to find the user object distinguished name (DN), but PowerShell is not required to use the
/replsingleobjparameter.
To replicate a domain user object, first, find the DN of the user object. The example below is assigning the DN to the PowerShell variable $UserDN. Once you have the DN, run repadmin /replsingleobject specifying the source (DC01) and destination DC (DC02) to replicate that object from/to.
If successful, you’ll see that DC01 replicated the user object to DC02.
$UserDN=(Get-ADUser user1).DistinguishedName
repadmin /replsingleobj DC01 DC02 $UserDN
Discovering Sites for all DCs
So far, you’ve learned a few handy parameters to help troubleshoot AD replication issues. But did you know that repadmin also includes some basic and nice reports too? One of the most useful reports repadmin provides is the inter-site topology report.
When you specify the /istg parameter, repadmin generates a basic report about the inter-site topology, which shows you what sites each DC is in. Adding the asterisk argument (*) forces the discovery to go through all domain controllers in the enterprise.
repadmin /istg *
Finding DC Bridgehead Servers
When DCs replicate between sites, AD requires every site to contain a DC that receives and sends all incoming and outgoing replication requests known as a bridgehead server. Knowing which DCs are bridgehead servers and the status of each naming context is helpful when troubleshooting.
To discover bridgehead DCs and return replication information about each server, use the /bridgeheads argument, as shown below.
repadmin /bridgeheads /verboseThe
/verboseparameter is an optional parameter that lists more details about the replication attempts and whether or not it was a success.
To display bridgehead servers and all other DCs, provide an asterisk as an argument to the
/bridgeheadsparameter, e.g.,repadmin /bridgeheads * /verbose.
Conclusion
Repadmin is an older but still powerful tool to manage and monitor Active Directory replication. Repadmin has many parameters and options to manage and review replication across a wide range of situations.
Have you used repadmin in the past? If so, do you have any useful parameters that have helped you solve a difficult replication issue?
