When Active Directory replication breaks, IT is in trouble. PowerShell comes with a few cmdlets that allow you to test if Active Directory replication is working properly.

Adam Bertram

Adam is a Microsoft Cloud and Datacenter Management Most Valuable Profressional (MVP) who specializes in Windows PowerShell. You can reach Adam at adamtheautomator.com or on Twitter at @adbertram.

When one domain controller (DC) is down or only certain partitions can be replicated to one or more DCs; a number of other problems will usually crop up from this. Therefore, it's important to ensure DC-DC replication is always working.

There are a number of different ways to monitor Active Directory replication: using graphical tools like AD Sites and Services, the replmon tool, and so on. These work but require your input. Wouldn't it be nice if code could run these checks for you? Let's see how to use a PowerShell script to ensure our Active Directory DCs are replicating successfully.

First of all, you will need the Active Directory PowerShell module. If working directly on a DC, you will already have this module. Otherwise, if you're working on a domain-joined client, ensure that Remote Server Administration Tools (RSAT) are installed for your operating system and that the module is enabled.

Windows features

Windows features

Once this is done, you will have many cmdlets available. By using the Get-Command cmdlet, I can view all the cmdlets related to replication that are available.

Commands inside Active Directory Module

Commands inside Active Directory Module

For this article, we're going to cover a few of the most useful cmdlets when testing AD replication. The first and most obvious command is Get-ADReplicationFailure. This does exactly what you'd think. It will retrieve any known recent failures for a given DC. In order to use this command, at a minimum, use the Target parameter to point at a particular DC.

If no failures are detected, this command will not output anything. Otherwise, you will see one or more objects get returned outlining the failure and the reasons.

Next, is the Get-ADReplicationPartnerMetadata cmdlet. This cmdlet allows you to dive into any problems that Get-ADReplicationFailure may have returned. This command returns lots of great information about the replication status of a given DC. You can see below that by running this command against one of my DCs, I can retrieve the last time replication happened and if it was successful.

Example output from Get-ADReplicationPartnerMetadata

Next, is the Get-ADReplicationAttributeMetadata cmdlet. The previous cmdlets showed overall replication statistics. This is a cmdlet that's useful to get more granular and dive down into the actual objects themselves.

Example output from Get ADReplicationAttributeMetadata

Example output from Get ADReplicationAttributeMetadata

Here you can get down to the individual AD attribute level. Hopefully, you will never have to get this granular, but it's always good to know that, if necessary, PowerShell can provide this kind of information.

Finally, another great cmdlet to test AD replication is Sync-ADObject. Although not technically a replication cmdlet, this command gives you the ability to forego any regular replication intervals and force replication for a single object. This command is useful when the necessary troubleshooting has been done, and you'd like to confirm with your own eyes that a user, OU, or perhaps a computer account can be created on one domain controller and that it will show up on another in a short amount of time.

By using each of these commands inside the Active Directory PowerShell module, you can now build a PowerShell script that can be executed via a scheduled task or improved upon to develop a custom report showing replication status over time and more besides.

Win the monthly 4sysops member prize for IT pros

Share
4+

Users who have LIKED this post:

  • avatar
  • avatar

Related Posts

4 Comments
  1. Marc 10 months ago

    Don't ask how I know but the DC's need to have the AD Web Service running which isn't standard before 2008R2...

    0

    • Author
      Adam Bertram 10 months ago

      LOL. I suppose I should have mentioned that. Yea. For any of the AD cmdlets to work ADWS must be installed on older DCs. I guess I assumed everyone was at least on 2012R2 DCs. 😉

      1+

  2. michael la bara 3 months ago

    how do i limit the command to only my domain and not the forest?

    0

    • Luc Fullenwarth 3 months ago

      @michael la bara,

      You can use the -Scope parameter with Domain, Forest, Server or Site as value.

      0

Leave a reply

Your email address will not be published. Required fields are marked *

*

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2017

Log in with your credentials

or    

Forgot your details?

Create Account