Active Directory Replication and topology
Diagnose replication errors by failure stage
Separate DNS and RPC failures, Kerberos identity problems, replication permissions, topology changes, and canceled requests.
Capture a failing relationship
Start with one destination, one source, and one naming context. A forest summary can hide which relationship is failing. On a DC or administrative workstation with the AD tools, collect:
repadmin /showrepl DC1 /verbose
repadmin /showrepl DC1 /errorsonly
repadmin /queue DC1
Keep the partition DN, source DSA GUID, last success, last attempt, consecutive failures, and full status. Was this scheduled replication or an administrator’s manual request? A manual request can fail because of the administrator’s token while ordinary DC replication is healthy. Microsoft’s replication error index links to the error-specific procedures below.
1722: establish which connection failed
Error 1722, RPC_S_SERVER_UNAVAILABLE, is a failure mapped through RPC. It doesn’t necessarily mean the RPC service stopped. DNS, routing, firewall state, unavailable services, and resource pressure can all produce it. The replication RPC client is the destination DC; its server is the source DC. See Microsoft’s 1722 analysis.
From DC1, verify DC2’s identity and network path:
Resolve-DnsName 'DC2.contoso.com'
Resolve-DnsName 'SOURCE-DSA-GUID._msdcs.contoso.com' -Type CNAME
Test-NetConnection 'DC2.contoso.com' -Port 135
Replace SOURCE-DSA-GUID with the NTDS Settings object GUID reported for DC2, and use the forest DNS name after _msdcs. Compare the returned address with DC2’s actual interfaces. Test each resolver when answers disagree.
A successful TCP 135 connection reaches the endpoint mapper. It does not establish a connection to the directory replication endpoint returned by that mapper. If PortQry is available, its TCP 135 query can enumerate registered RPC interfaces:
portqry.exe -n DC2.contoso.com -e 135 -p TCP
Find the directory replication interface and the endpoint it advertises. Test that port from DC1, or capture the actual replication attempt and follow endpoint mapping through the later TCP connection and RPC bind. An allow rule for 135 alone is insufficient. Use the PortQry reference and AD firewall requirements for the tools and port scope.
8524 and DNS fallback events
Error 8524 points to DNS lookup failure. Events 2087 and 2088 distinguish failure from a fallback path that allowed replication to succeed despite the GUID-based lookup problem. A successful replication attempt after fallback does not repair the missing or wrong record.
Check the source’s DSA GUID CNAME, the CNAME target’s A/AAAA records, the destination’s configured resolvers, and stale NTDS metadata. Retired DC records and reused addresses deserve particular attention. The 8524 guide explains these name-resolution dependencies.
0x80090322: verify the server that received the ticket
-2146893022, SEC_E_WRONG_PRINCIPAL, commonly means the source could not decrypt the service ticket presented by the destination. The destination may have reached the wrong host, or a KDC may hold an inconsistent copy of the source DC’s machine-account password.
dcdiag /s:DC1 /test:CheckSecurityError /ReplSource:DC2 /v
setspn -L DC2
Check name-to-address mapping before changing passwords. Then compare the DC account’s replication metadata, KDC selection, tickets, and relevant Kerberos events. A duplicate or missing SPN is one hypothesis, not the only explanation.
Microsoft’s 0x80090322 procedure includes a targeted KDC workaround and replication retry. Stopping the KDC affects authentication availability, so follow the procedure’s choice of target and steps to restore the service. Repeatedly resetting every DC account can create more disagreement and obscure the original failure.
8453: distinguish the caller from the replica
If only an interactive “replicate now” fails, inspect the administrator’s effective groups and elevation:
whoami /all
If scheduled replication also fails, inspect permissions on the affected naming-context root and the destination DC account. For an RODC, verify the forest-root Enterprise Read-only Domain Controllers group’s required replication access and the relevant preparation history. A user/group membership problem and a DC’s partition ACL problem need different corrections. The 8453 procedure separates these cases. Error 5, plain access denied, also has authentication and policy causes; use its separate diagnostic guide.
1256 can be the consequence of another failure
When a source connection fails, later partition requests to that source can be canceled and recorded as 1256. Find the earlier non-1256 error for the same source/destination and work on that dependency first. The canceled partitions may all follow from that one failure. See Microsoft’s 1256 explanation.
8452: compare topology views
“Naming context is in the process of being removed or is not replicated from the specified server” can occur while promotion, demotion, GC changes, or topology changes are still converging. Confirm that both DCs should host the partition and inspect their local replication views. A management tool operating from a third DC may have a different topology view from either endpoint. Use the 8452 guide before deleting connection or partition objects.
Quarantine errors need a different branch
Events 1988/2042 and errors involving an outdated replica require lingering-object and quarantine analysis. Repeatedly forcing synchronization or opening ports cannot make an unsafe replica current.
After fixing a known dependency, a targeted replication request changes replication activity:
repadmin /replicate DC1 DC2 "DC=contoso,DC=com"
This example is for a writable domain partition; GC partial replicas and RODCs have additional command semantics. Check for a fresh successful timestamp, then recheck every affected partition and relationship. Keep the original failure record alongside the retry.