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.
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.
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:
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.
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:
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.
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 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.
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.