Active Directory: replication fails with error 1722, The RPC server is unavailable

Hi, it's BlueByte. A domain controller that replicated fine yesterday now answers every check with The RPC server is unavailable., and repadmin /replsummary is stacking up failures with status 1722. Nothing has crashed: RPC is reporting that it could not open a connection to the source DC, and the real fault almost always sits a layer below RPC. We'll walk through where the error surfaces, what it is actually telling you, the checks that separate the causes, the fix for each one, and how to keep a new site from landing here again.

Where 1722 surfaces, and what each tool calls it

One status, four faces. repadmin is the clearest:

C:\> repadmin /showrepl
==== INBOUND NEIGHBORS ======================================
DC=contoso,DC=com
    HQ-SITE\DC01 via RPC
        Last attempt @ 2026-09-25 09:41:12 failed, result 1722 (0x6ba):
        The RPC server is unavailable.
        7 consecutive failure(s).
        Last success @ 2026-09-24 22:10:03

repadmin /replsum, /showreps and /syncall all cite the same 1722 (0x6ba), with /syncall phrasing it as a network error. dcdiag fails its Replications test and adds DsBindWithSpnEx() failed with error 1722. Replicate Now in Active Directory Sites and Services raises a dialog that ends by pointing at DNS lookup problems — a useful hint, because DNS is behind a large share of these. Promoting a replica DC fails at the moment it tries to create its NTDS Settings object on the helper DC. And in the Directory Service event log the same status hides behind NTDS KCC events 1311, 1865 and 1925, NTDS Replication 1960, and ActiveDirectory_DomainService 1125.

Why RPC reports 1722 when the fault is lower down

RPC sits between the network transport and the application protocol and has no special insight into failures — it maps lower-layer protocol failures into an error at the RPC layer. 1722 / 0x6ba / RPC_S_SERVER_UNAVAILABLE is logged when a lower-layer protocol reports a connectivity failure, and the common case is that the abstract TCP connect operation failed. Microsoft lists the usual sources: link local failure, DHCP failure, DNS failure, WINS failure, routing failure including blocked ports on firewalls, IPSec or network authentication failures, resource limitations, and the higher-layer protocol not running. In practice they collapse into three buckets you can test in order: name resolution, blocked ports, and a host-side setting on one of the two DCs.

Pin down which partner and which partition is failing

Start on the destination DC — that is where the failing RPC client lives:

repadmin /replsummary
repadmin /showrepl * /csv > C:\temp\showrepl.csv
nltest /dsgetdc:contoso.com /force

/replsummary gives the largest delta per DC; the CSV shows whether one partner is failing or all of them. That decides your next move: one failing partner points at the path between two specific DCs, while every partner failing points at the destination itself — its NIC, its DNS settings, or its own host firewall.

Rule out DNS before you touch the firewall

Name resolution failures cause a large share of 1722 replication errors, so test them first — the checks are cheap and change nothing:

dcdiag /test:dns /v /e /f:C:\temp\dns.log
ping -a 10.20.4.11

dcdiag /test:dns runs authentication, basic, forwarders, delegation, dynamic update and record registration groups against every DC, then prints a PASS/FAIL grid with remediation notes. ping -a catches the classic: a stale host record resolving to a machine decommissioned months ago. Replication binds to the source DC's GUID-based CNAME under _msdcs, so if that alias is missing or its glue record points elsewhere, every bind fails while ordinary client traffic looks healthy.

Check the endpoint mapper and the whole dynamic port range

The endpoint mapper listens on TCP 135 and tells the client which randomly assigned port the service is on, so opening 135 alone is never enough. On Windows Server 2008 and later the default dynamic range runs from 49152 to 65535; a mixed-mode domain with Windows Server 2003 or Windows 2000 DCs uses 1025 through 5000 instead — a standing trap for firewall rules copied out of an old runbook.

Test-NetConnection -ComputerName DC01.contoso.com -Port 135
netsh int ipv4 show dynamicport tcp

ComputerName     : DC01.contoso.com
RemoteAddress    : 10.20.4.11
RemotePort       : 135
TcpTestSucceeded : True
 
Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

135 answering while replication still fails is the signature of a firewall that permits the mapper and drops the high ports. Microsoft's portqry scans the whole range when one port is not proof enough — portqry -n DC01 -r 49152-65535 — though it is a separate download. If opening the range is not acceptable, the supported alternative is restricting AD replication to a specific port with the documented registry value, rather than narrowing the dynamic range itself.

Two host-side causes the network tests will not catch

If DNS resolves and the ports are open, turn to the DCs themselves. First, the RPC client protocols. Under HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc, the ClientProtocols key must exist and hold four REG_SZ values — ncacn_http, ncacn_ip_tcp, ncacn_np and ncacn_ip_udp — each pointing at rpcrt4.dll. If the key or any of the four is missing, import it from a known good server.

Get-ItemProperty "HKLM:\Software\Microsoft\Rpc\ClientProtocols"

Second, SMB signing mismatches between DCs produce the same symptom. The documented remedy is consistent settings pushed from the Default Domain Controllers Policy under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options, rather than machine-by-machine edits that drift apart again. Two more belong on the list: UDP fragmentation, which surfaces as replication errors that look like RPC failures — LSASRV events 40960 and 40961 are the tell, and forcing Kerberos onto TCP is the documented response — and bad NIC drivers, so a recent driver update belongs in your timeline of changes.

A worked example: a new branch site behind an old firewall rule

A branch DC is promoted into a new site on Thursday. Promotion succeeds, but by Friday repadmin /replsummary shows 1722 against both hub DCs while the branch DC authenticates users normally. Every partner failing points at the destination, so DNS goes first: dcdiag /test:dns passes and ping -a resolves both hub DCs correctly. Test-NetConnection -Port 135 succeeds too, which is what makes this one confusing — the mapper answers, so the firewall looks innocent. Then netsh int ipv4 show dynamicport tcp reports a start port of 49152 on both ends, while the site-to-site rule, copied from a 2012-era document, permits only 1025–5000. Widening it to 49152–65535 both ways fixes it, and the next repadmin /syncall /AdeP converges in a minute.

Confirm replication converges, then write the ports down

Verification is one command and one follow-up:

repadmin /syncall /AdeP
repadmin /replsummary

/syncall /AdeP pushes changes across all partitions and reports per-partner results, and /replsummary should show the largest delta dropping toward zero on the next cycle rather than climbing. Re-run dcdiag /test:replications for an independent pass. Prevention is mostly documentation: record the dynamic range your DCs actually use, write DC-to-DC firewall rules against 49152–65535 rather than a range inherited from an older domain, and put repadmin /replsummary into your monitoring. A replication outage is quiet by nature, and quiet outages are the expensive kind.

How 1722 differs from the KCC topology events and a broken trust

If the KCC logs 1311 or 1865 with no 1722 anywhere, that is topology rather than transport — the KCC could not build a complete spanning tree because site links or subnets are misconfigured, and no firewall work will help. If the complaint comes instead from a member server saying its trust relationship with the domain failed, that is a machine account password problem on one computer, not a DC-to-DC path problem — and no repadmin output will mention it.

Next time replication stalls on 1722, walk these checks back in order: which partner and partition repadmin names, whether DNS resolves the source DC's _msdcs alias to the right host, whether 135 and the dynamic range are open in both directions, and only then start looking at the DCs themselves.