ad replication delay exceeding 6hrs accross regional dc

INT66 Risla 40 Reputation points
2026-09-17T08:52:07.0633333+00:00

We are experiencing Active Directory replication delays exceeding six hours between domain controllers located in different regions. This replication latency is impacting the timely synchronization of directory changes and may indicate issues with the current replication topology, site links, or replication health.

Could you provide guidance on how to use the repadmin utility to review and validate the Active Directory replication topology? Specifically, we would like to identify the replication partners, verify replication paths between domain controllers, detect replication failures or bottlenecks, and determine whether any topology or connectivity issues are contributing to the observed replication lag.

Windows for business | Windows Server | Directory services | Active Directory
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Chen Tran 13,030 Reputation points Independent Advisor
    2026-09-17T09:40:13.25+00:00

    Hello Risla,

    Thank you for posting question on Microsoft Windows Forum!

    Based on the issue description. Well! A six-hour replication delay between regions highly probably points to the scenarios of misconfigured Inter-Site Topology Generator (ISTG) settings, restrictive site link schedules, or a massive replication queue bottlenecking your Bridgehead servers.

    The following are a few of suggested repadmin commands deemed to be useful for troubleshooting this issue.

    • repadmin /replsummary which provides a matrix of all inbound and outbound replication attempts, showing the largest delta (delay) and the percentage of failures. Look for specific DCs that have a high failure rate or a delta matching your 6-hour lag.
    • repadmin /queue <DC_Name> If the queue has thousands of items, the DC is communicating but cannot process changes fast enough (often due to disk I/O bottlenecks, anti-virus interference, or massive bulk updates). If the queue is empty but replication is delayed, it is a scheduling or topology issue.
    • repadmin /showrepl <DC_Name> which shows every replication partner (neighbor) for each directory partition. Check the Last attempt @ <date/time> and the resulting status (e.g., was successful or a specific error code like 8453 or 1722).
    • repadmin /showrepl * /errorsonly which queries all DCs in the enterprise and returns only the links that are currently failing. Note the target DC, source DC, and the Hex/Decimal error code.
    • repadmin /showconn <DC_Name> displays the KCC-generated (or manually created) connection objects. Verify that inter-site connections exist and are pointing to the correct Bridgehead servers. Manually created connections (which lack the <generated> tag) often cause topology loops or orphaned paths.
    • repadmin /bridgeheads Inter-site replication routes exclusively through Bridgehead servers. If a Bridgehead is down or in an error state, inter-site replication halts. Ensure the bridgeheads listed are online and hold the correct partitions.
    • repadmin /kcc <DC_Name> If you suspect the topology is broken, this forces the KCC to re-evaluate site links and build new connection objects. Check the Event Viewer (Directory Service log) afterward for KCC errors.

    Since your delay is specifically inter-regional, the issue frequently lies outside of standard DC health. By default, AD site links replicate every 180 minutes (3 hours). If a site link schedule restricts replication to specific off-hours, or if a single cycle is missed, a 6-hour delay is easily reached. You can view site link properties in Active Directory Sites and Services. On the other hand, if a DC was disconnected for longer than the Tombstone Lifetime (typically 180 days), it will be quarantined to prevent Lingering Objects. Event ID 1988 or 2042 in the Directory Service log will confirm this.

    You can consult the following articles for further reference.

    Hope the above information is helpful!

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-09-17T08:52:30.06+00:00

    Use repadmin to validate both replication health and whether the topology is behaving as expected.

    1. Review forest-wide replication status first. Open an elevated Command Prompt and run: 
         repadmin /showrepl * /csv > showrepl.csv
      Then open showrepl.csv in Excel and:
      • hide or delete column A and the Transport Type column
      • freeze the top row
      • enable filtering
      • sort by Last Success Time from oldest to newest
      This gives a forest-wide view of replication partners and quickly highlights domain controllers with stale or failed inbound replication.
    2. Use the repadmin /showrepl output to identify replication partners and paths. The output shows replication status for domain controllers and is the primary place to read replication errors. Reviewing all domain controllers in the forest helps identify which source DCs and destination DCs are involved in delayed replication.
    3. Look for failures and bottlenecks in the results. Focus on domain controllers with the oldest Last Success Time values or repeated failures. Replication status is a strong indicator of whether these dependencies are healthy:
      • DNS infrastructure
      • Kerberos authentication
      • Windows Time service
      • RPC
      • network connectivity
      If replication is not current, one or more of these areas can be contributing to the delay.
    4. Check the Directory Service event log on the source and destination domain controllers. Error and warning events in the Directory Service log often indicate the specific constraint causing replication failure. If an event includes corrective steps, use those steps first.
    5. Validate common causes of inter-regional replication delay. For delays across regions, review these areas:
      • Network connectivity: unavailable or misconfigured network paths
      • Name resolution: DNS misconfiguration is a common cause of replication failures
      • Replication engine: intersite replication schedules that are too short can leave queues too large to process in the available window, causing changes to stall
      • Replication topology: site links in AD DS must map to the real WAN or VPN topology; if the configured topology does not match the actual network, replication can fail
      • Authentication and authorization: can cause access denied errors between partners
      • Directory database performance: the database might not process transactions fast enough to keep up with replication timeouts
    6. Confirm firewall and RPC reachability between regions. Active Directory replication RPCs occur dynamically over an available port through the RPC Endpoint Mapper on port 135. Firewalls, including Windows Firewall with Advanced Security and any network firewalls between regions, must allow replication traffic.
    7. If a domain controller is intentionally offline, account for that before treating it as a topology problem. A staged or disconnected domain controller can generate replication errors that are expected rather than evidence of a broken topology.
    8. Use Microsoft tools to speed diagnosis. For a UI-based approach, run the Microsoft Support and Recovery Assistant tool for AD replication. A Virtual Agent is also available for common Active Directory replication issues.
    9. If deeper repadmin analysis is needed, use the Repadmin troubleshooting guidance referenced in the documentation. The Repadmin-focused guidance is specifically called out for monitoring and troubleshooting Active Directory replication in more detail.

    If the goal is to determine whether the 6+ hour lag is topology-related, the most direct path is:

    • generate the forest-wide repadmin /showrepl report
    • sort by oldest Last Success Time
    • identify the affected source/destination partner pairs
    • check Directory Service event logs on those DCs
    • verify DNS, RPC/firewall, and whether AD site links reflect the real regional WAN/VPN design

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.