AD Replication Error 1722 and 8453: Fixes

Replication errors 1722 and 8453 account for a large share of unhealthy domain controllers. Error 1722 means the destination DC could not even open an RPC connection to its partner, so it is a network, DNS or firewall problem in almost every case. Error 8453 means the connection worked but the partner refused the replication request, which points at permissions, a broken secure channel between the DCs, or a time difference large enough to break Kerberos. Both show up in repadmin /showrepl, in Directory Service Event IDs 1925, 2087 and 1655, and in dcdiag’s Replications test. These steps apply to Windows Server 2019, 2022 and 2025.

Short answer: For 1722, confirm the source DC name resolves correctly on the destination (nslookup against the DC’s own DNS), that TCP 135 and the dynamic RPC range 49152–65535 are open between them (Test-NetConnection and portqry), and that the RPC and Netlogon services are running. For 8453, reset the secure channel between the DCs with netdom resetpwd, check the clocks are within five minutes, and confirm “Enterprise Domain Controllers” still has the replication rights on the affected partition. Then force replication with repadmin /syncall /AdeP and watch Event ID 1206 confirm success.

Identify exactly which pair is failing

Start on the DC that reports the error:

repadmin /showrepl * /csv > repl.csv
repadmin /replsummary
repadmin /showrepl DC02 /errorsonly

The CSV lists every source and destination pair with the naming context, last success time and error number. Note whether the failure is one direction or both, and whether it affects every partition or only one. A single partition failing with 8453 is almost always a permissions issue on that partition; every partition failing with 1722 from one DC is connectivity.

Fix 1722: RPC server is unavailable

Work through the layers in order on the destination DC, targeting the source:

nslookup DC02.corp.example.com
nslookup -type=CNAME <objectGUID>._msdcs.corp.example.com
Test-NetConnection DC02 -Port 135
Test-NetConnection DC02 -Port 389
portqry -n DC02 -e 135

The GUID CNAME is what the KCC actually uses; find the GUID with repadmin /showrepl DC01 (DSA object GUID). If it does not resolve, the _msdcs zone is stale or the DC is pointing at the wrong DNS server; make every DC use another DC as primary DNS and itself as secondary, then run ipconfig /registerdns and restart Netlogon. portqry -e 135 lists the endpoints the RPC mapper returns; if the DC advertises an address the partner cannot reach, for example a backup NIC, disable that interface’s registration. Firewalls between sites must allow TCP 135, 389, 636, 3268, 445, 88, 53 and the dynamic range 49152–65535, or you can pin replication to one port:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "TCP/IP Port" /t REG_DWORD /d 50000 /f

Restart the DC after pinning the port and open it on the firewall. Also check the source DC’s services: Get-Service RpcSs, Netlogon, NTDS, KDC, DFSR should all be Running.

Fix 8453: Replication access was denied

Confirm the clocks first, because a skew over five minutes fails Kerberos silently:

w32tm /monitor
w32tm /stripchart /computer:DC02 /samples:3

Correct time using configure NTP time sync for the PDC emulator if needed. Next, reset the secure channel between the two DCs. Stop the KDC on the failing DC so it does not use stale tickets, reset, then start it again:

Stop-Service KDC
netdom resetpwd /server:DC02 /userd:CORP\Administrator /passwordd:*
Start-Service KDC
klist purge
repadmin /syncall /AdeP

If that does not clear it, check the partition permissions. The “Enterprise Domain Controllers” group needs “Replicating Directory Changes” and “Replicating Directory Changes All” on the naming context, and the DC’s computer object must be in the Domain Controllers OU and the group. Verify with:

dsacls "DC=corp,DC=example,DC=com" | findstr /i "Replicating"

A missing entry can be restored in ADSI Edit under the partition’s security tab, or, for the Default Domain Controllers Policy having been damaged, by running dcgpofix as described in reset the Default Domain Policy with dcgpofix. Also confirm the User Rights Assignment “Access this computer from the network” on the DCs still includes Enterprise Domain Controllers and Authenticated Users; a hardening GPO that removed them causes 8453 on every DC at once.

Verify

After the fix, force and confirm replication:

repadmin /syncall /AdeP
repadmin /replsummary
Get-WinEvent -LogName "Directory Service" -MaxEvents 20 | Where-Object Id -in 1206,1925,2087

Event 1206 with “successfully completed” and a /replsummary with zero failures mean the pair is healthy. Run a broader check with the tests in check domain controller health with dcdiag and repadmin, because a DC that has been isolated for days may also have SYSVOL backlog to clear. A common pitfall is a DC that was offline longer than the tombstone lifetime (180 days by default), which produces error 8614 instead; that DC cannot be repaired and must be demoted with /forceremoval and re-promoted.

AD replication error 1722 at a glance

Official documentation: Active Directory Domain Services docs, Windows Server documentation.

Related guides: Transfer and seize FSMO roles with PowerShell and ntdsutil · Change a domain controller’s IP address without breaking replication · Fix “The trust relationship between this workstation and the primary domain failed”.

Frequently asked questions