Tracking Change Replications in AD using Repadmin.exe

Posted on January 8, 2009 by Daniel Petri in Active Directory with 0 Comments

As you already know, Active Directory utilizes a multi-master replica scheme to store data. This allows AD to be used in any environment, from a Mom-and-Pop store-front to huge, global corporations. It allows the placement of domain controllers anywhere that the number of users justifies the (ever decreasing) expense of hardware and the cost of the server OS license. Administration can be centralized or decentralized, depending upon the political realities in which your network exists; changes can be made on any DC to which we can connect, and will replicate to all DCs in the domain.

In small environments, when a change is made, it is relatively easy to verify that changes have replicated out to all DCs. In a network where there are, say 5 or so DCs, you can use Active Directory Users and Computers (dsa.msc) and connect to each DC and verify that the change has taken place. Even in environments as small as 5 DCs, it can become laborious to always connect to each DC to verify that changes have taken place. In larger environments, where it is not practical nor time-efficient to attach to each DC, or when we make changes that we cannot see visibly (such as changing a password), we have to take a different tact. This is where repadmin.exe can help us quickly and easily. Repadmin.exe is a simple, yet powerful tool that is freely available in the Windows Server Support Tools package. So, let’s look at how repadmin can help us track the replication of changes throughout AD.

Adding and deleting objects from AD is a daily part of an administrator’s life. Typically, these additions are not time-sensitive; in other words, we don’t care how long it takes for the user account, that was created for a new employee who is starting next week, to replicate to all of our outlying DCs (even that one that somehow ended up on the other end of a 128k BRI ISDN line). Sometimes, though, we want to know that all DCs have received a change. For instance, let’s say that we are performing a migration into our domain and, just as we click the OK button to start the migration, we realize that we forgot to check the sIDHistory box in our migration tool. Fortunately, our migration tool allows us to undo this last migration. First, we note the DN of one of the objects that will be deleted in the undo process and then we undo the migration of the users, which succeeds with no issues. Once the undo is finished, we force out the replication with either Replmon.exe or Repadmin.exe. In our case, since we’re talking about repadmin.exe, I would be remiss to not use it. We open a command prompt and run our command. The generic form of the command to force all DCs to pull from the DC on which we’ve made changes is repadmin /replicate [dc_list] source_dc naming_context. On my network, it would look like this when issued on my hub DC:

You will see output similar to that shown below. Note that the wildcard (*) will tell your source DC to try to replicate with itself. You’ll get an error saying “The naming context is in the process of being removed or is not replicated from ths specified server.” Otherwise, for each successful replication, you’ll get “Sync from sourcedcname to destinationdcname completed successfully,” which you can see below:

So, we’ve pushed out our changes using Repadmin. Now we want to verify that the objects are deleted. Here, we can safely assume that if one object is deleted, then the others are deleted. Once again, we can use repadmin.exe to help us with relative ease. There are a couple of repadmin.exe commands that we can use in our task. There is /showobjmeta and /showattr as well as /showvalue. We will use /showattr because, as we’ll see later, we can use this command to search our domain in a more precise fashion. Before we query for an account that should not exist, we first need to see what a successful command returns when it finds the populated attribute for which we are looking on an object that does exist. The generic syntax of the command is repadmin /showattr * “DNofObject” /atts:attribute. My command looks like this:

On your screen, you will see output similar to that shown below. The account, TestUser, does in fact exist and the distinguishedName attribute is populated. If the attribute that you want returned by Repadmin is not populated, then you will see Repadmin output the DN of the object queried, but there will be no attribute listed. For the above query, you will see something similar to that below:

In our scenario, we deleted our migrated accounts and we want to verify that all DCs have replicated the deletion. The account that I deleted was named, TestUser2. Using the DN that we noted above in our scenario, we create the command is as follows:

The output that we see is shown below:

We are told that the object cannot be located, because the is “No Such Object”, which means that our account was deleted. This command makes it easy to see, at a glance, which DCs have received the changes that were made; in this case, all of my DCs received the deletion. Repadmin can return any valid attribute for any valid object in any valid namespace in AD. Since Repadmin always outputs the distinguishedName of an existing object, it may seem somewhat redundant to have Repadmin return that attribute. So, instead, lets have Repadmin return the description of our TestUser with the below command:

Below is the output when the description of a user has been modified and that modification has replicated to 2 out of 3 DCs:



As you can see, above, RockDC1 and RockDC3 have received the change to the description attribute. Since that attribute value is on RockDC2, Repadmin returns the DN of the TestUser object (the object does exist), but it returns nothing for description because that attribute is not, yet, set. This technique is very helpful, also, when you reset the password of a user, and you want to verify that this replicated to all DCs. We can easily do this by having Repadmin return the pwdlastset attribute. Thankfully, Repadmin translates the unwieldy number (representing the number of 100 nanosecond intervals that have elapsed between the time the password was last set and 1/1/1601) into a readable and understandable date and time format as shown below:

Finally, lets say that you made bulk changes to all of the users in an OU and, being the highly paid type A administrator that you are, you’re not satisfied by checking out just one user; you want to know the change was made to all of the users in the OU on all of the DCs in your environment. You certainly don’t want to take the time to run the above commands for each object on each DC; after all, the point of this article is to show you how to track a change quickly and efficiently. Also, you might not want to take the time to write a script. So, what can you do? Let me show you.

Repadmin gives you the ability to perform an LDAP query for the objects whose attributes you’d like to have returned. This command is built by adding two more arguments to the previous command. Those arguments are /subtree and /filter:. If you’ve ever written an LDAP query, then you will recall that, when we perform a query, we can do a base search, a onelevel search or a subtree search. Repadmin recognizes /onelevel and /subtree as valid arguments. The /filter: can accept any valid LDAP query filter, such as (“objectClass=User”). The generic command looks like this: repadmin /showattr * “DNofContainerToSearch” [/onelevel or /subtree] /filter:(“attributefilterexpression”) /atts:attributetoreturn. My command looks like this:

When you run the command in your environment, the output that you see will look similar to that shown below. Notice that two of my DCs have received the changes to the descriptions on the accounts in the OU, but one DC has yet to receive them.

If you don’t already know this, then you may be surprised to learn that Repadmin can accept fairly complex LDAP queries and return multiple attributes. The below command queries my whole domain, looking for user accounts (excluding computer accounts) whose names contain the “do” letter combination and returns the description and the pwdlastset attributes values. I just created a new account, named Frodo, and, you can see from the output which DCs have that change, as well as the description change to the Don account:

Below, I’m querying my whole domain, looking for user accounts (excluding computer accounts) whose names contain the “do” letter combination but excluding user accounts whose name attribute begins with “F”, and returning the description and the pwdlastset attributes values.

One final thing to note is that when you run these commands as they are written, the output will go to the console. You should pipe the output to a text file as shown below:

You can open the output file in Notepad and page quickly through or perform a search inside of it. And, of course, the file can be archived, if desired.


Repadmin.exe is a simple, yet powerful tool that any administrator can use to track the replication of changes throughout AD. Even if you have only two DCs, you can see that it is a tool that can help an administrator to stay on top of replication and to verify when changes to any specified attribute have replicated to all DCs in the domain. To find out all of the options, type repadmin at the command prompt and hit enter. To get help on the list options, type repadmin /listhelp.


Information on Repadmin and its syntax: Microsoft Technet

Information on LDAP query syntax: