Active Directory Health Check using PowerShell Tools (Repadmin)

Active Directory Health Check using PowerShell Tools (Repadmin). IT admin have to monitor constantly the health of their Active Directory environment. This is imperative to ensure your AD performance is optimized and the IT team are not overwhelmed with  help desk calls. Let’s talk about AD replication.

Replication is usually not complicated if you’re in a small Active Directory (AD) environment. But replication challenges arise as the environment grows and more sites are added. The ideal for identifying the cause of replication problems is the Repadmin tool.

Any AD administrator’s toolkit must include Repadmin, which enables you to observe and debug AD replication topology from the viewpoint of each domain controller (DC). This article will guide you through a thorough and easy learning process of the Repadmin tool via this article.

Active Directory Health Check Using Repadmin


If you want to use the commands in this article and make sure they apply to your surroundings, make sure you have:

It’s time to look at the repadmin tool in our article blog Active Directory Health Check using PowerShell Tools.

Overview of the Repadmin Tool

Repadmin must be started and familiarized with before you can manage AD replication using it. You need to be either RDP connected to a DC or have the Remote Server Administration Tools (RSAT) package installed on a domain joined machine to utilize repadmin. We will demonstrate the most common repadmin commands and carry out all demonstrations directly on a DC.

Once the RSAT package has been installed on the DC, run the following steps:

1. As an administrator, launch a command prompt.

2. Run repadmin without any parameters to get a sense of your challenges. Repadmin returns a complete help text with all accepted arguments.

Summarizing Replication Help Using Repadmin

Start broad and work your way down if you’re starting with AD replication issues. Since it provides an excellent summary of the overall replication health, the replsummary option is essential. The replsummary parameter gives an overall assessment of the state of AD replication. For instance, you will see an output similar to the one below when you run repadmin /replsummary.

The output consists of the following attributes:

  • Source DSA – Outgoing replication statistics.
  • Destination DSA – Incoming replication statistics.
  • Largest Delta – Site connection with the most extended replication channel.
  • Fail – How frequently replication links fail.
  • Total – Number of overall replication links.
  • %% – The proportion of full replication links that failed.
  • Error – Displays the error code and any replication errors that occurred.

The outputs looks something like this:

					Source DSA          largest delta    fails/total %%   error
WIN2K12_DC01        31m:11s          0 /  2    0
WIN2K12_DC02        27m:56s          0 /  3    0
WIN2K12_DC03        15m:43s          0 /  3    0

Destination DSA     largest delta    fails/total %%   error
WIN2K12_DC01        12m:35s          0 /  2    0
WIN2K12_DC02        24m:16s          0 /  2    0
WIN2K12_DC03        09m:29s          0 /  4    0

Inspecting Replication Neighbors Using Repadmin

Each DC duplicates with a different DC known as its partner or neighbor in a multi DC AD scenario. Therefore, understanding the replication topology is a crucial piece of knowledge when solving replication problems. Run repadmin /showrepl to learn more about replication partners. Known sometimes as a naming context or replication context, this command scans the local AD database. It offers detailed information about each DC’s most recent attempt to replicate its neighbor’s AD partition.

Here is an example of the output of the Show Replication command:

Monitoring Replication Queues Using Repadmin

Depending on the replication schedule, a DC may occasionally lag behind its neighbor. When it does, its queue begins to rise. This is because the quantity of objects waiting to be duplicated from their source neighbor makes up the queue.

The DC’s queue should be 0, signifying fully replicated partitions, but occasionally, on a busy network, the backlog can start to grow. Run the repadmin /queue command as shown below to view the queue. You can see that the DC and its neighbor are precisely reproduced in this case.

This situation may indicate a problem if you notice the queue is slowly incrementing. If so, make sure to troubleshoot the following possible causes:

  • CPU usage on the source DC replication partner
  • Too many concurrent replication partners
  • Slow or degraded network connection
  • Too many changes in the Active Directory in a small period of time

Checking Inbound Replication Topology Using Repadmin

Each DC performs a Knowledge Consistency Checker (KCC) to determine replication topology. A specific DC must be aware of its inbound neighbors, which is the KCC’s responsibility. The KCC runs automatically every 15 minutes, but you can manually start it if necessary.

Run the KCC manually to reassess the replication topology if, for instance, a site link is removed or the replication configuration is altered somehow. For example, we run repadmin /kcc, as shown below, to accomplish this.

The KCC returns the location of the DC you are running it on and whether the check was successful or not.

Manually Invoking a Partition Replication Using Repadmin

Even though partitions usually remain in sync, forcing a replication manually can occasionally be helpful when troubleshooting. For example, you may quickly determine whether replication functions by pushing the replication process between DCs. Use the /replicate argument to start a manual replication, as displayed below. Three arguments are required for the /replicate parameter, with the following others being optional:

  • The destination DC to replicate to.
  • The source DC to replicate from.
  • A naming context to replicate. As previously mentioned, to find the naming context, run repadmin /showrepl.
					Repadmin /replicate   

For example, replicating the Schema partition from WIN2K12_DC01 to WIN2K12_DC02 would look like the command below.

					repadmin /replicate WIN2K12_DC02 WIN2K12_DC01 CN=Schema,CN=Configuration,DC=test,DC=local

Manually Invoking Replication for All Using Repadmin

The /syncall parameter is the best strategy if the /replicate parameter duplicates a single partition. We can sync all partitions on all DCs with the /syncall argument. As you’ll see below, the /syncall option is excellent for situations where you want to test the entire replication topology or even replicate the actions of the /replicate parameter.

To test replication to or from the /syncall parameter only needs one argument, the DC. For instance, if you wanted to try replication to or from a DC called DC01, you would run the below command. This operation would test only the Configuration directory partition.

Repadmin will only test replication to or from DCs located at the same site when the DC to test replication to or from is specified.

What if, however, you require the replication of all naming contexts toor from a certain DC located inside the same site? You would then use the /A argument. The output now has all name contexts, as you can see below. To force the replication across all DCs in all sites, use the /e parameter. Keep in mind that the case affects every argument.

DC replication is a pull operation by default, but you can set replication to push. If DC02 needs to get updates from DC01 rather than DC02 pulling changes from DC01, for instance, add the /P parameter to change the replication direction to accomplish this.

Replication of a Single Object Using PowerShell

In the instances above, you copied all changes. However, repadmin can be more precise and replicate only a particular AD object. You can choose a single entity and manage its complete replication from source to destination DC using the /replsingleobj parameter.

Let’s replicate User1 from WIN2K12_DC02 to WIN2K12_DC01 to see how this works. For this to successfully work, it is required that we use PowerShell. The user object distinguished name (DN) will be located in this demonstration using PowerShell and the Active Directory module; however, using the /replsingleobj argument does not require PowerShell.

To replicate a domain user object, start by locating its DN. For example, the PowerShell variable $UserDN is given the DN in the example below. Once you have the DN, use repadmin /replsingleobject to replicate the object from or to WIN2K12_DC01 and WIN2K12_DC02, respectively.

					Import-Module ActiveDirectory

$GetUserDN = (Get-ADUser user01).DistinguishedName
repadmin /replsingleobj WIN2K12_DC01 WIN2K12_DC02 $GetUserDN

If it were successful, you’d notice that WIN2K12_DC01 replicated the user object to WIN2K12_DC02.

Discovering Sites for all DCs Using Repadmin

So far, you have learned a few helpful factors to aid in troubleshooting AD replication. But did you realize that repadmin also comes with several excellent and fundamental reports? The inter site topology report, for instance, is among the most valuable pieces offered by repadmin.

Repadmin creates a simple report about the inter-site topology when the /istg argument is specified, letting you know which sites each DC is located in. The discovery must travel through every domain controller in the enterprise when the asterisk argument (*) is added.

Finding DC Bridgehead Servers Using Repadmin

Every site must have a DC as the bridgehead server for all incoming and outgoing replication requests when DCs replicate between sites. Therefore, when troubleshooting, it’s helpful to know which DCs are bridgehead servers and the current state of each naming context.

Use the /bridgeheads parameter displayed below to find bridgehead DCs and return replication details for each server. An extra argument called /verbose lists additional information regarding the replication attempts and whether or not they were successful.

Give an asterisk as an input to the /bridgeheads parameter, for example, repadmin /bridgeheads * /verbose, to display bridgehead servers along with all other DCs.

Why don’t you look at infraSOS when reading Active Directory Health Check using PowerShell Tools (Repadmin). It is Active Directory Reporting Tool and Office 365 Reports by InfraSOS where you can find out true last login of your users and run health check reports in your AD. 

Active Directory Health Report InfraSOS

Benefits of InfraSOS

Secure your Active Directory and Run compliant reports where you can identify vulnerable AD accounts. InfraSOS pros are: 

Thank you for reading about Active Directory Health Check using PowerShell Tools (Repadmin). Let’s summarize.

Active Directory Health Check Using Repadmin Conclusion

Repadmin is an older but more powerful tool to manage and monitor Active Directory replication. Repadmin has many parameters and options to manage and review replication across various situations. With all of the repadmin parameters, we can create a comprehensive report and diagnose our Active Directory properly if an issue arises.

Avatar for Marion Mendoza
Marion Mendoza

Windows Server and VMware SME. Powershell Guru. Currently working with Fortune 500 companies responsible for participating in 3rd level systems support across the enterprise. Acting as a Windows Server engineer and VMware Specialist.

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments
Would love your thoughts, please comment.x