Active Directory Replication Troubleshooting: Repadmin, DCDiag & Error Codes (2026)

Updated: June 12, 2026

Active Directory replication troubleshooting starts with two commands: repadmin /replsummary to find which domain controllers are failing, and dcdiag /test:replications to translate the underlying error code into a fixable cause. When AD replication breaks, authentication, Group Policy, DNS, and Entra Connect sync all start degrading within hours, so on my team we treat any inbound replication failure older than 60 minutes as a P2 incident with a 4-hour MTTR target. This guide walks through the exact diagnostic workflow I use, the eight error codes that account for most of the tickets I see, and the PowerShell I lean on to catch problems before users notice.

• Replication failures over 60 minutes degrade authentication, GPO processing, and password changes. Treat them as P2, not P3.
• Start every investigation with repadmin /replsummary and repadmin /showrepl. About 80% of root causes surface in the output.
• Eight error codes (1722, 1908, 8453, 8524, 8606, 8614, 8589, 1396) cover the majority of helpdesk-escalated cases.
• Tombstone lifetime (default 180 days on Server 2003+, 60 days on older forests) sets a hard ceiling on outage length before lingering objects appear.
• Get-ADReplicationFailure plus a scheduled task gives you proactive alerting without a paid monitoring tool.
• DNS misconfiguration, specifically the _msdcs zone and SRV records, causes more replication tickets than network outages do.

How Active Directory replication actually works

So, before I troubleshoot anything I remind whoever opened the ticket that AD replication isn't a single process. It's the Knowledge Consistency Checker (KCC) building a topology of connection objects, plus the Directory Replication Agent (DRA) pulling updated objects from partners over RPC. Within a site, the default polling interval is 15 seconds with change notification. Between sites, it's whatever the site link schedule says (15 minutes minimum, often longer). Each object change increments a per-attribute Update Sequence Number (USN), and replication metadata travels alongside the object itself.

Two facts matter for triage. First: replication is multi-master, so any writable DC can originate a change, but every DC must converge eventually. Second: convergence has a hard deadline called the tombstone lifetime, 180 days by default on any forest created on Windows Server 2003 SP1 or later. If a DC is offline longer than tombstone lifetime, it won't be allowed back in without surgical intervention because its view of deleted objects is stale.

Microsoft documents the full algorithm in the official AD DS replication troubleshooting reference, which I keep open in a second tab during every escalation.

How do I check Active Directory replication status?

Run repadmin /replsummary from an elevated command prompt on any domain controller. The output gives you a single-screen health check: each DC's largest delta (time since last successful replication), failure count, and error code. Anything with deltas in hours, or a non-zero fails column, is your starting point.

repadmin /replsummary

Replication Summary Start Time: 2026-06-12 09:14:22

Beginning data collection for replication summary, this may take a while:
  ...........

Source DSA          largest delta    fails/total %%   error
 DC01                   00m:15s         0 /   5    0
 DC02                   00m:32s         0 /   5    0
 DC03                   02h:14m         3 /   5   60  (1722) The RPC server is unavailable.

Destination DSA     largest delta    fails/total %%   error
 DC01                   00m:15s         0 /   5    0
 DC02                   00m:32s         0 /   5    0
 DC03                   02h:14m         3 /   5   60  (1722) The RPC server is unavailable.

Once you've identified the failing DC, drill in with repadmin /showrepl DC03 to see exactly which naming context (Schema, Configuration, domain partition, or an application partition like DomainDnsZones) is broken and against which partner. Add /verbose for the timestamp of last attempt versus last success. That delta tells you whether this is a transient blip or a stuck failure.

For an end-to-end forest health check, run dcdiag /v /c /e /f:dcdiag.log. The /e flag covers every DC in the enterprise, /c runs the comprehensive test set, and /f writes the output to a file you can grep. The two tests that matter most for replication are Replications and KCCEvent.

The eight error codes you will actually see

Across roughly 400 AD replication tickets I've triaged in the last three years, eight error codes account for about 92% of resolutions. Honestly, just memorize this table. It cuts diagnosis time by half.

Code	Symbolic name	Most common cause	First thing to check
1722	RPC_S_SERVER_UNAVAILABLE	Firewall blocking RPC dynamic ports, or partner DC offline	portqry -n DC03 -e 135 from source
1908	ERROR_DOMAIN_CONTROLLER_NOT_FOUND	DNS missing _msdcs SRV records	nltest /dsgetdc:contoso.com
8453	ERROR_DS_REPLICATION_ACCESS_DENIED	Kerberos clock skew, broken NTDS computer account, or missing Replicating Directory Changes permission	w32tm /monitor then netdom resetpwd
8524	ERROR_DS_DNS_LOOKUP_FAILURE	DC cannot resolve partner's CNAME alias in _msdcs	nslookup <guid>._msdcs.contoso.com
8606	ERROR_DS_OBJ_NOT_FOUND_FOR_REPL	Lingering objects on a DC that was offline past tombstone lifetime	repadmin /removelingeringobjects
8614	ERROR_DS_USN_ROLLBACK_DETECTED	DC restored from snapshot or backup older than tombstone lifetime	Demote, metadata cleanup, repromote
8589	ERROR_DS_DRA_BAD_DN	Schema mismatch or partial replication of schema NC	repadmin /showrepl DC schema
1396	ERROR_WRONG_TARGET_NAME	SPN missing or duplicated on NTDS Settings object	setspn -X to find duplicates

The pattern I want you to internalize: error codes in the 1xxx range are network or DNS, and codes in the 8xxx range are AD-internal (security, schema, or topology). That single heuristic routes the next 80% of your investigation.

Error 1722: The RPC server is unavailable

This is the most common replication error and almost always a network problem, not an AD one. RPC dynamic endpoint mapping uses TCP 135 first to ask "what port is the replication service on?" and then opens a second connection to the high port returned (49152–65535 by default on Server 2008+). If a firewall blocks the high-port range, or NAT mangles the response, replication fails with 1722.

Diagnose from the destination DC with these three commands in order:

REM 1. Confirm RPC endpoint mapper is reachable
portqry -n DC03.contoso.com -e 135 -p TCP

REM 2. Ask which dynamic port AD replication is listening on
portqry -n DC03.contoso.com -e 135 -p TCP -v | findstr "1f88aa46"

REM 3. Test that dynamic port directly (replace 49664 with what step 2 returned)
Test-NetConnection DC03.contoso.com -Port 49664

If step 1 fails, fix the firewall. That means RPC endpoint mapper (135) plus the dynamic range, or you can pin AD replication to a fixed port via the TCP/IP Port registry value at HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. If step 1 succeeds but step 3 fails, your firewall allows 135 but blocks the dynamic range. Open it, or pin the port.

Error 8453: Replication access was denied

Error 8453 looks like a security problem because the text says "access was denied," and sometimes it is. But more often, it's Kerberos. The DC's machine account ticket is invalid because clock skew exceeds five minutes, the machine account password is out of sync, or the DC's secure channel is broken.

My standard 8453 workflow:

1. Check time skew across all DCs: w32tm /monitor /domain:contoso.com. Anything above 60 seconds drift is a red flag.
2. Reset the DC's machine password against a known-good partner: netdom resetpwd /server:DC01 /userd:CONTOSO\Administrator /passwordd:*
3. Verify the secure channel: nltest /sc_verify:contoso.com
4. Confirm the broken DC has the Replicating Directory Changes and Replicating Directory Changes All rights on the domain NC. These are usually granted to Enterprise Domain Controllers, but a delegated permission cleanup can remove them.

Time is the single most common 8453 cause in environments where someone has manually configured w32tm on a DC and pointed it at an unreachable NTP source. Authentication-adjacent issues like this also surface as spurious account lockouts across the forest, so check both symptoms when triaging.

Error 8606 and lingering objects

Error 8606 means a destination DC asked a source DC for an object that the source has already tombstoned and garbage collected. This happens when a DC has been offline (or simply not replicating successfully) longer than the tombstone lifetime, which is 180 days by default. The offline DC still has the object. Every other DC has long since forgotten it exists.

By default, Windows Server 2008+ enables strict replication consistency, which blocks the inbound replication entirely rather than reintroducing the lingering object. That's the right safety default and you should never disable it, but it means you have to remove the lingering objects from the stale DC before replication resumes.

REM Find lingering objects without removing them (always do this first)
repadmin /removelingeringobjects DC03.contoso.com <ReferenceDC-GUID> "DC=contoso,DC=com" /advisory_mode

REM After reviewing the log, run the same command without /advisory_mode to remove
repadmin /removelingeringobjects DC03.contoso.com <ReferenceDC-GUID> "DC=contoso,DC=com"

You need the reference DC's invocation ID (the GUID), which you get from repadmin /showrepl DC01 | findstr "objectGuid". Run advisory mode for every naming context (domain, configuration, schema, and any application partitions like DomainDnsZones and ForestDnsZones), because lingering objects can hide in any of them.

How do I force AD replication between domain controllers?

Three options, in order of how often I use them:

1. Replicate one partner pair, one partition:

repadmin /replicate DC02 DC01 "DC=contoso,DC=com"

2. Force a full sync from all partners on one DC:

repadmin /syncall DC02 /AeD

The flags matter. A = all partitions, e = enterprise (cross-site), D = identify by DN. Add P if you want to push outbound instead of pull inbound.

3. PowerShell, when you want it scripted:

Sync-ADObject -Object "CN=jdoe,OU=Users,DC=contoso,DC=com" -Source DC01 -Destination DC02
# Or for an entire partition
Get-ADDomainController -Filter * | ForEach-Object {
    Sync-ADObject -Object (Get-ADDomain).DistinguishedName -Source DC01 -Destination $_.HostName
}

Forcing replication is a diagnostic tool, not a fix. If you have to force it routinely, you have an underlying topology, schedule, or connectivity issue. I look at the audit log every quarter. Any DC that needed a manual sync more than twice gets a deeper investigation.

DNS, SRV records, and the _msdcs zone

More replication tickets in my queue come from DNS misconfiguration than from any other root cause. The reason: DCs locate replication partners by CNAME records of the form <guid>._msdcs.<forest-root>, and they discover services via SRV records like _ldap._tcp.dc._msdcs.contoso.com. If the _msdcs zone isn't delegated correctly, or if a DC was promoted while DNS was misconfigured, the records never get registered.

Validate DNS health with these commands run on each DC:

REM Confirm _msdcs zone exists and is replicating
dcdiag /test:DNS /v

REM Verify the DC's own SRV records are registered
nltest /dsregdns

REM Look up a specific partner DC by its NTDS Settings GUID
nslookup -type=CNAME <guid>._msdcs.contoso.com

If nltest /dsregdns fails, the Netlogon service can't register records. Check that the DC's primary DNS server points to another DC (never to itself only, and never to a public resolver). For forest-wide DNS issues, the same fundamentals from our DNS troubleshooting guide apply, but with one extra constraint: every DC has to be able to resolve every other DC's GUID-based CNAME, not just the A record.

PowerShell automation: detect before users complain

Reactive replication troubleshooting is fine for one-off tickets, but my actual goal is to never see a ticket open against me for this in the first place. The ActiveDirectory PowerShell module ships two cmdlets that make this easy: Get-ADReplicationFailure and Get-ADReplicationPartnerMetadata.

Drop this script in a scheduled task that runs every 15 minutes on a management server, writes failures to Event Log, and emails or Teams-webhooks on threshold breach:

Import-Module ActiveDirectory

# Threshold: alert if any DC has not replicated successfully in > 60 minutes
$thresholdMinutes = 60
$now = Get-Date

$dcs = Get-ADDomainController -Filter *
$problems = @()

foreach ($dc in $dcs) {
    $failures = Get-ADReplicationFailure -Target $dc.HostName
    foreach ($f in $failures) {
        $age = ($now - $f.FirstFailureTime).TotalMinutes
        if ($age -gt $thresholdMinutes) {
            $problems += [PSCustomObject]@{
                Server      = $dc.HostName
                Partner     = $f.Partner
                FailureType = $f.FailureType
                LastError   = $f.LastError
                AgeMinutes  = [math]::Round($age, 0)
            }
        }
    }
}

if ($problems.Count -gt 0) {
    $body = $problems | ConvertTo-Json -Depth 3
    Write-EventLog -LogName Application -Source "ADReplMon" `
        -EventId 4001 -EntryType Warning `
        -Message "AD replication failures detected:`n$body"

    # Optional: post to a Teams incoming webhook
    Invoke-RestMethod -Uri $env:TEAMS_WEBHOOK_URL -Method Post `
        -ContentType 'application/json' `
        -Body (@{ text = "AD replication failures:`n``````$body``````" } | ConvertTo-Json)
}

The first time I deployed this in a 12-DC environment, we caught a silently failing inter-site link at 02:00, about 11 hours before anyone in that region noticed degraded GPO processing. That single early catch paid for the whole project. I've written more about the GPO knock-on effects in our GPO not applying troubleshooting guide.

Windows Server 2025 considerations

If you've started promoting Windows Server 2025 DCs into existing forests, there are three replication-adjacent changes worth knowing about. First: Server 2025 raises the functional level baseline to 2016, so you can't promote a 2025 DC into a forest still at 2012 R2 FFL. Second: the new 32k database page size schema attribute requires either a fresh forest or a one-way upgrade via dsdbutil that affects how schema-NC replication behaves during the transition. Third: Kerberos PKINIT and Negotiate now prefer AES over RC4 by default, which interacts with the broader RC4 deprecation. If your DCs lose the ability to negotiate Kerberos, replication 8453 errors spike.

The Microsoft Windows Server 2025 release notes have the full list. Practical advice: don't mix 2016 and 2025 DCs longer than your migration plan requires. Mixed-mode forests work, but every quirky replication ticket I've seen in the last 12 months traced back to a forest stuck mid-migration.

Metrics to track next month

If I were starting fresh in your environment, here are the four metrics I'd put on a dashboard before changing anything else:

• Replication MTTR. Time from first failed replication attempt to first successful one. Target: under 4 hours; world-class is under 1.
• Replication FCR (first-contact resolution). Percentage of replication tickets closed without escalation. If this is below 60%, you have a runbook gap.
• Maximum replication lag across the forest. Daily max of repadmin /replsummary's largest delta column. Should never exceed your inter-site schedule plus 30 minutes.
• Tombstone lifetime headroom. For any DC that's been offline, days remaining before lingering objects become a risk. Should never drop below 30.

Wire those up, automate detection via the PowerShell above, and you'll move from "replication is broken again" tickets to "we proactively replaced a DC last weekend" reports. That's the shift from reactive helpdesk to operations engineering, and it's what actually moves MTTR numbers.

Frequently Asked Questions

How often does Active Directory replicate by default?

Within a site, AD replicates via change notification with a 15-second polling interval after each change. Between sites, the default schedule is 180 minutes (3 hours), but most environments tune this to 15 minutes, the minimum the GUI allows, via the site link properties in AD Sites and Services.

What is the difference between intra-site and inter-site replication?

Intra-site replication runs over uncompressed RPC with change notification, optimized for low latency on fast networks. Inter-site replication uses compressed RPC (or SMTP for the schema partition only) on a schedule defined by site links, optimized to minimize WAN bandwidth at the cost of higher convergence time.

What is the tombstone lifetime and why does it matter?

Tombstone lifetime is the number of days a deleted AD object's tombstone is retained before garbage collection. It's 180 days by default on any forest created on Server 2003 SP1 or later. If a DC is offline longer than this, lingering objects appear and replication is blocked (error 8606) until the stale DC is cleaned up or demoted and repromoted.

Can I disable strict replication consistency to fix error 8606 faster?

You can, but you shouldn't. Disabling strict replication consistency lets lingering objects reinfect the rest of the forest, which is far worse than the original problem. Always remove lingering objects with repadmin /removelingeringobjects instead, and if the stale DC has been offline a long time, demote and repromote it.

Why does dcdiag pass but repadmin still shows failures?

The default dcdiag tests don't include every replication-specific check. Run dcdiag /test:replications /test:KCCEvent /test:topology /v for the full picture. Also confirm you're running dcdiag against the correct DC with /s:DC03. The local DC is the default and may not be the one with problems.