Re: Repadmin output vs. replmon
- From: Scott Lowe <me@xxxxxxxxxxx>
- Date: Mon, 8 Aug 2005 16:47:48 -0400
On 2005-08-08 16:04:03 -0400, Claus Witjes <Claus Witjes@xxxxxxxxxxxxxxxxxxxxxxxxx> said:
Can you be more specifiy? Which AD partiton is affected? At which directory partition do you look with Replmon?
Repadmin doesn't report the partitions. At least, not with the switches that I'm using. With Replmon, I can view all the partitions and see that all of them are replicating on a regular basis. This includes the current child domain, two other child domains, the root domain, DomainDnsZones, ForestDnsZones, and the Configuration and Schema partitions.
I have noticed today, in reviewing Replmon, that replication between two DCs in the same domain for that domain's naming context in the same site is quick (occurs every few minutes), but between two DCs in the same domain and in the same site for a naming context that is not for their domain (say, for the root domain), it is much longer (upwards of 30 minutes so far).
I do not know what causes the different ouput between both tools in your case, but I can tell you what the "largest delta" is (as far as I know) ;).
"largest delta" denotes the longest replication gap amongst all "replication links" for a particular domain controller.
Common factors that influence the repadmin "largest delta field" are:
• Periodic Intra-site replication frequency (1 hour by default).
• Inter-site replication schedule and frequency.
• Redundant replication paths with staggered replication schedules.
• Intra-site and inter-site change notifications; first and subsequent replication notification delay values.
We use a geographically based hub-and-spoke topology, and all our site links replicate on the same time intervals. So, even for a remote branch office in Europe, I could expect to see a delay of N (where N is the replication frequency) for changes to replicate back to Europe's hub. Then, another delay of N to replicate from Europe's hub to the US hub. If I am viewing the repadmin output for a DC at the US hub, then I would expect to see largest deltas (if replication is occurring on a regular basis) of 2*N. Right?
The exception to this would be if there was a delay introduced in the replication from the Europe branch office to the Europe hub but all other replication was normal. In that case, the repadmin output would, quite properly, reflect the delays experienced in getting that information to the Europe hub, yes?
Can you run a repadmin /showrepl <dcname> /verbose against the domain controller in question to get the replication status and post the data?
I'll run this command and see what it reports. If I post it, I'll (obviously) have to sanitize the output first, but I think based on your earlier statement that I am beginning to understand exactly what repadmin is reporting. If I am seeing a "latency" of 9 hours for a DC in the Europe hub when running repadmin from a DC in the US hub, that doesn't necessarily mean that there is an 9 hour delay between the Europe hub and the US hub. Instead, that just means that at some point along the path, there was a 9 hour latency for changes to get to that particular Europe hub DC. Right?
In the output under INBOUND NEIGHBORS, Repadmin.exe shows the Lightweight Directory Access Protocol (LDAP) distinguished name of each directory partition for which inbound directory replication has been attempted, the site and name of the source domain controller, and whether it succeeded or not, as follows:
• Last attempt @ YYYY-MM-DD HH:MM.SS was successful. • Last attempt @ [Never] was successful.
If Repadmin.exe reports any of the following conditions, further investigation is required:
• The last successful inter-site replication was prior to the last scheduled replication.
• The last intra-site replication was longer than one hour ago.
• Replication was never successful.
Like I said in my original posting, we're not seeing any operational indications that replication is not working as expected. Instead, I'm just trying to make sure that we fully understand the output of these tools so that we can make sure that AD is working at its optimal level.
Thanks.
-- Scott Lowe
.
- References:
- RE: Repadmin output vs. replmon
- From: Claus Witjes
- RE: Repadmin output vs. replmon
- Prev by Date: Re: XP Browsing issue
- Next by Date: Domain Admin Group membership / Domain Security policy
- Previous by thread: RE: Repadmin output vs. replmon
- Next by thread: Extending Schema
- Index(es):
Relevant Pages
|
