There are other utilities out in the wild that can be used to give a comprehensive test of AD replication, but few are as definitive as REPADMIN /SHOWREPL command in the CSV format.
I'm willing to bet there are some folks who just read that statement and are thinking that it sounds pretty silly. I promise you'll be believers after using this tool, particularly those folks out there who are new to the environment they administer or that may work as consultants and so get confronted by new environments all the time.
Here’s the skinny on this from REPADMIN help:
/showrepl [DC_LIST [Source DC object GUID]] [Naming Context] [/verbose]
[/nocache] [/repsto] [/conn] [/all] [/errorsonly] [/intersite]
And here's a synopsis of what this command puts at your fingertips:
· replication status (programmatic error code) for a naming context(s)
· last success and failure times
· number of last success and failures
· network transport used for the replication (nearly always RPC)
· source and destination DCs
· source and destination AD sites
The above doesn’t sound like much until you put it into practice. Let’s talk about doing that.
REPADMIN /SHOWREPL * /CSV >resultfile.csv
The above command will run on all DCs in the forest and gathers the latest replication status codes for all naming contexts (NCs) present. I probably don’t need to say this, but in case I do: NCs are the containers such as your default Configuration and Schema partition, as well as every domain partition in your forest. In my test case we have the Thatsnotright, the Wackiness, and the Silliness domains adding to the default partitions of Config and Schema. The above command will get the replication status for all of these, on every DC.
Key points to keep in mind around this are:
-not every DC will have a copy of every NC; only Global Catalogs will
-Not every site may host a DC for every domain; it just depends on what was deployed there
-This command does not indicate whether a hosted NC is read only (such as in the case of a GC hosting it) or writable (a domain partition).
-This command does not indicate OS version. You could add or get that separately, but that’s important stuff to know in lingering object and other scenarios.
-This command does not display whether a DC is set for strict or loose replication consistency
-The number zero (0) indicates success, no failure present.
So, once you run the command above you need to open and use the file. Here are the steps to do that using Microsoft Excel:
So now you have a selectable spreadsheet which details your AD replication status as of the moment the report was completed. You can select a single error code, or do a filter for multiple (such as 1722 and 1753). The ways you can reselect this data are infinite, so it is very customizable for any environment, problem and need.
The selected data below is an example of a selection of all DC which show the 8606 error in a test environment:
Destination DC Site
Source DC Site
Number of Failures
Last Failure Time
Last Success Time
Last Failure Status
So, you’re probably saying to yourself “Self, how do I tell what this error number really means?”. Good question, O Reader. These error codes are the programmatic error codes from winerr.h, they are not the same as what you will see in a fully fleshed out event in the event log. As a result, they are lacking in every detail since this code is used to trigger (ultimately) that event to appear in the event log.
But there’s a way to see the comment associated with that error code, and thereby get a better understanding or more info on it. That is the ERR.EXE tool which can be downloaded from this link:
This is command line tool which can take the Windows (not just DS, all Windows error codes) error number as an argument and provide the comment for it. Here’s the example for our “Last Failure Status” above.
C:\ > Err.exe 8606
# for decimal 8606 / hex 0x219e :
# Insufficient attributes were given to create an object.
# This object may not exist because it may have been deleted
# and already garbage collected.
# 1 matches found for "8606"
So, we’ve have a pretty good overview of a REPADMIN.EXE technique that can save some time and ease some general “is this domain replicating or what?” questions. I’m still deciding on the next post (slated for about a week or so from now) so if anyone has a special request just let me know.
Thanks for sharing your knowledge on this stuff.
I have a request regarding the replication latency on my Forest.
Is there a way to see in a real time that a change made on an AD object is replicatd to all my DCs in my forest ?
Example: i make a change on a object (say the sn), i'd like to see,in real time, this change replicated on all my DCs, in order to measure the time of synchronisation in my forest.
Could this be done with repadmin ? replmon ? or else ?
All of our tools check status at the time they are ran. As opposed to continually updating by requerying the destination DC, they check once-when you run that command.
Repadmin is a good way to go. You can judge for a specific attribute by using the /showobjmeta command and track by USN. Alternatively, you can use the /showattr command to check the actual value to compare and see if it arrived at destination DCs or not.
The showobjmeta command was detailed in a prior post. Let me know if that doesn't help out or not.
PingBack from http://jeftek.wordpress.com/2006/09/10/custom-list-windows-resources/
I want to point out an excellent resource for an administrator out there who is responsible for Active