Monitor Forest-Wide Replication
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2
Maintaining the health of enterprise-wide directory replication is very important so that the users, services, machines, and applications that rely on it can operate successfully. The Windows Server 2003 version of repadmin has enhanced functionality that makes it easier to monitor forest-wide directory replication and it is compatible with Windows 2000 domains.
Repadmin /replsummary summarizes the replication state and relative health of an Active Directory forest by inventorying and contacting every domain controller in the forest, collecting information such as replication deltas and replication failures.
It will also identify any domain controllers that could not be contacted and would report the failure reason (for an example, see Figure 3.1.4).
Syntax
Repadmin /replsummary <DC_LIST> [/bysrc] [/bydest] [/errorsonly] [/sort:{delta | partners | failures | error | percent}]
Parameters |
Definition |
<DC_LIST> |
Specifies the host name of a domain controller or a list of domain controllers separated by a space that the object will be replicated to. For details about <DC_LIST>, see repadmin /listhelp. |
/bysrc |
Shows the output of repadmin /replsummary, from the perspective of the replication source (outbound domain controller), in the form of a table. This means that a given source directory server is "pulled on" by multiple client domain controllers. The table is sorted in order of the source domain controllers that are having the most problems, across all the clients in the configuration set. This parameter does not display the destination domain controller. |
/bydest |
Shows the output of repadmin /replsummary, from the perspective of the replication destination, in the form of a table. This means that a given replication destination (inbound domain controller) is pulling the changes from one or more replication source(s). The table shows the inbound domain controllers and what problems they are having with their partners. The table is sorted in order of the inbound domain controllers that are having the most problem with inbound replication, across all the possible partners in the configuration set. This parameter does not display the source domain controller. |
/errorsonly |
Shows only the domain controllers where the partner error is not zero. |
/sort:{delta | partners | failures | error | percent} |
Sorts the replsummary table by the specified column heading. |
Note
The /bysrc and /bydest parameters may be specified at the same time. If they are specified at the same time, repadmin displays the /bysrc table first and the /bydest table next. If the parameters /bysrc and /bydest are both absent, repadmin picks the best one and displays the one with the least number of partner errors.
Simple usage of repadmin /replsummary
.gif "repadmin /replsummary")
How to interpret the output
The output of repadmin /replsummary is organized by destination and source domain controllers. You should focus on the destination domain controllers first, because the replication model is pull-based. Replication between domain controllers does not use a "push" mechanism. If the replication is within a site, a domain controller (DC1) notifies another domain controller (DC2) that it has updates, and then the DC2 pulls the updates from DC1. If the replication is between sites, a domain controller requests updates at a scheduled time and if updates are available, the domain controller pulls the updates from a domain controller in the other site.
Fields of interest |
Definition |
….. |
Each dot after the first three represents a domain controller, with not more than 50 dots per line. So, if you have two lines full of dots, it indicates 97 domain controllers (100-3). In figure 3.1.1, there are nine dots, which relates to six domain controllers (9-3). |
Destination DC |
Replication destination. A single destination might be pulling data from one or more sources. In figure 3.1.1, we are focusing on ROOTDC01. |
Source DC |
Replication source. Multiple destinations might be pulling from a single source. In figure 3.1.1, we do not yet know the source domain controller. |
Largest delta |
Denotes the longest replication gap amongst all replication links for a particular domain controller. In figure 3.1.1, the largest delta is 45m:47s. |
Total |
Replica links for a particular domain controller (one for each naming context on each domain controller). Please note that this is not the connection objects or replication partners per domain controller. In figure 3.1.1, we have seven replication links. |
Fails |
Total number of replica links failing to replicate for one reason or the other. This will never be greater than the Total field. No failures in our example. |
Percentage |
Percentage of failures in relation to the total replica links on the domain controller. |
How to make more sense of some of the fields
We ran repadmin /showrepl against ROOTDC01 to get detailed replication status. Always focus on inbound neighbors because replication is inbound.
If you notice Figure 3.1.1, the time replsummary taken was 22:36:30. Now, if you look at the schema naming context replication time, 21:49:44 from figure 3.1.2, the difference is 45m:47s, which relates to the largest delta.
Interestingly, 45 minutes is relatively high in our example because our partners belong to the same site. This is because the default periodic replication frequency is once per hour within a site and because the schema naming context did not have any changes, periodic replication took place only at 21:49:44 as opposed to other partitions that replicated in response to change notifications from its partners.
We also see seven replica links, one for each naming context on each domain controller.
.gif "repadmin /showreps")
Common factors that influence the largest delta field
Periodic intrasite replication frequency.
Intersite replication schedule and frequency.
Redundant replication paths with staggered replication schedules.
Intrasite and intersite change notifications; first and subsequent replication notification delay values.
Where do REPADMIN /REPLSUMMARY read replication status information?
Similar to /showrepl, Repadmin /replsummary gathers this information from the Reps-from and Repsto multivalued attributes stored at the root of each directory partition replica (also known as naming contexts) stored on the domain controller. It is local to the domain controller and not replicated.
The Repsfrom attribute contains configuration and persistent state information associated with inbound replication from each source replica of that directory partition.
The Repsto attribute contains outbound change notification partners. Typically this list would be your intrasite partners.
Wild card and other parameter usage
The following example uses a wildcard character to show the replication summary for all of the domain controllers in the forest that have a name that begins with ‘ROOT’.
.bmp "repadmin /replsummary")
Important
Replsummary reporting failures
The following example reports replication failure and a domain controller that could not be reached, with the error codes and reasons.
.gif "repadmin /replsummary sorted by delta")
C:\>net helpmsg 58
The specified server cannot perform the returned operation.
C:\>net helpmsg 1722
The RPC server is unavailable.
In our example, the following occurred:
We could not reach BRANCH2 and hence the error 58.
“RPC server is unavailable” being reported by BRANCH-HUB-BH co-relates to the above finding. It could mean that BRANCH2 domain controller is either down or not reachable due to communication link problem.
We also used /homeserver:rootdns to demonstrate that sometimes you have to specify a server (/homeserver:<domain controller name>) if you are not running the command from a domain controller.