Short version: typically you don't have to pay attention to this stat. As long as number of "fails" is zero, AD replication is healthy.
Note: When you have replication fails and subsequently remedy the problem, the number of "fails" in "replsummary" report is not going to change to zeros right away. The report of this command is a snapshot of history, so it takes a bit time for all fails to disappear.
]
Repadmin /replsummary result is simple, but yet somewhat confusing. A few notes:
- If you don't specify /bysrc or /bydest, it will list status for both directions. You want to pay attention to Destination DSA as AD replication is pull-based.
- Most critical column is "fails". If there is no fails, obviously you don't have much to worry about
- Most confusing column is "largest delta". It's common misunderstanding (on the Net at least) that value in this column should be less then 1hr. However, depending on how large your AD environment is, and how frequent changes happen in a particular Naming Context, value in this column could be very large (days)
- Microsoft's official interpretation for "largest delta": longest replication gap amongst all replication links for a particular DC", which is not really helpful. I personally had hard time to understand this interpretation itself.
- This value is for the particular DC, among all its replication partners, the longest time that it hasn't replicated anything against whatever NC. This value has to be read together with /showrepl command against that DC.
First, result for
repadmin /replsummary *
Replication Summary Start Time: 2011-12-19 10:52:16
.......
Destination DSA largest delta fails/total %% error
DC1 01d.08h:57m:06s 0 / 22 0
Then result for
repadmin /showrepl DC1
DC=john,DC=lab Site1\DC2 via RPC
DSA object GUID: 5920fcb0-f184-46ef-a231-962ceb436d7e
Last attempt @ 2011-12-19 09:25:55 was successful.
Site1\DC3 via RPC
DSA object GUID: 136edad6-673a-41ab-9f80-bcd4ff61d78a
Last attempt @ 2011-12-19 10:55:27 was successful.
DSA object GUID: 5920fcb0-f184-46ef-a231-962ceb436d7e
Last attempt @ 2011-12-19 09:25:55 was successful.
Site1\DC3 via RPC
DSA object GUID: 136edad6-673a-41ab-9f80-bcd4ff61d78a
Last attempt @ 2011-12-19 10:55:27 was successful.
CN=Schema,CN=Configuration,DC=john,DC=lab Site1\DC2 via RPC
DSA object GUID: 5920fcb0-f184-46ef-a231-962ceb436d7e
Last attempt @ 2011-12-18 01:55:10 was successful.
Site2\DC3 via RPC
DSA object GUID: 136edad6-673a-41ab-9f80-bcd4ff61d78a
Last attempt @ 2011-12-19 09:25:55 was successful.
DSA object GUID: 5920fcb0-f184-46ef-a231-962ceb436d7e
Last attempt @ 2011-12-18 01:55:10 was successful.
Site2\DC3 via RPC
DSA object GUID: 136edad6-673a-41ab-9f80-bcd4ff61d78a
Last attempt @ 2011-12-19 09:25:55 was successful.
[result truncated]
In above example, DC1 has DC2 and DC3 as its inbound partner for two NCs, domain default and schema. Among all 4 replication links, the one from DC2 for Schema was last done a day before, that is why the largest delta being reported is 1 day! But is it neccessay a concern? No. For one, Schema doesn't have much changes. And if there is no notification, target DC might just decide not to trigger the pull from source. Secondly, DC1 still gets latest update from other partners, such as DC3. I.e, it didn't miss anything because of the large delta reported. (BTW, I manually force a replication from DC3 to DC1 to generate above result).
You can actually calculate the largest delta yourself:
largest delta = the time your run repadmin/replsummary - oldest "last attempt successful"