How to Fix Active Directory Replication Error 1722: The RPC Server Is Unavailable

Few errors make a domain administrator’s stomach drop quite like opening repadmin /showrepl and seeing a wall of red 1722 results. Replication has stopped, the clock is ticking on your tombstone lifetime, and the message — “The RPC server is unavailable” — is about as vague as Windows errors get.

The good news: error 1722 is almost always a network or name-resolution problem, not a sign that Active Directory itself is corrupt. Work through the causes in the right order and you can usually find it in a few minutes. This guide walks through that order, from the most common cause to the least.

What error 1722 really means#

1722 is a generic Remote Procedure Call (RPC) error. It is not specific to Active Directory — you will see the same code from print spoolers, WMI, and other RPC-based services. In the context of replication, it means one domain controller tried to open an RPC channel to another DC and could not.

Replication between DCs rides on RPC. Before any directory data moves, the source DC has to:

1. Resolve the partner DC’s name to an IP address (DNS).
2. Reach the RPC endpoint mapper on TCP port 135.
3. Get back a dynamic port to use for the actual replication traffic.
4. Open a connection on that dynamic port.

Break any one of those steps and you get 1722. So the troubleshooting is really about finding which step is failing.

flowchart LR
A["Source DC"] -->|1. DNS lookup| B["Resolve partner FQDN<br/>+ GUID._msdcs record"]
B -->|2. TCP 135| C["RPC Endpoint Mapper<br/>on target DC"]
C -->|3. returns dynamic port| D["Dynamic RPC port<br/>49152-65535"]
D -->|4. replicate| E["Target DC"]

First, confirm and locate the failure#

Before changing anything, get a clear picture of which DCs and which directions are failing. Run these from an elevated prompt on any healthy DC:

repadmin /replsummary
repadmin /showrepl

replsummary gives you a quick table of largest deltas and failures. showrepl lists every inbound replication partner and the last result per naming context. Note exactly which source DC is throwing 1722 and for which partner — you will test that specific path.

Cause 1: DNS (check this first, always)#

The single most common cause of 1722 is name resolution. A DC locates its partners using special records in the _msdcs zone, keyed by each DC’s object GUID. If those records are missing, stale, or pointing at an old IP, the source DC tries to talk to the wrong host — or no host — and RPC fails.

From the destination DC, test DNS health:

dcdiag /test:dns /v
nltest /dsgetdc:yourdomain.local

Then confirm you can resolve the partner’s GUID-based CNAME. You’ll find the GUID in repadmin /showrepl output. The record looks like:

<DC-GUID>._msdcs.yourdomain.local

Resolve it explicitly:

nslookup <DC-GUID>._msdcs.yourdomain.local

If DNS is wrong, fix it, then force replication and re-test:

repadmin /syncall /AdeP

Roughly half of all 1722 cases end right here. If DNS is clean, move on.

Cause 2: Firewall blocking RPC#

If names resolve correctly but RPC still won’t connect, suspect a firewall — the Windows firewall on a DC, or more often a hardware firewall between sites. The trap is that ping and basic LDAP can succeed while RPC is still blocked, because RPC needs the endpoint mapper and a high dynamic port.

These are the ports AD replication needs:

Test the endpoint mapper and the dynamic range from the destination DC toward the source. The PortQry tool is purpose-built for this:

portqry -n <source-DC> -e 135

A healthy result lists the RPC services and the dynamic ports they’re listening on. If port 135 is filtered, or the returned dynamic port is unreachable, you’ve found your firewall problem.

If you need a predictable port range across a restrictive firewall, you can pin the AD replication RPC port. Plan that change carefully and apply it consistently across all DCs, as it requires a reboot to take effect.

Cause 3: Services, time, and secure channel#

If DNS and firewall both check out, look at the target DC itself.

Services. Confirm these are running on the source DC: Active Directory Domain Services, DNS Server, Kerberos Key Distribution Center, RPC Endpoint Mapper, and Netlogon. A hung service produces 1722 even on a perfectly healthy network.

Time skew. Kerberos rejects authentication when clocks differ by more than five minutes (default). Severe time skew shows up as replication and authentication failures together. Check with:

w32tm /monitor

Secure channel. A broken machine secure channel can also masquerade as RPC failures. Verify it:

nltest /sc_verify:yourdomain.local

Putting it together: the fast path#

When you hit 1722 under pressure, this is the order that finds it quickest:

1. repadmin /replsummary and /showrepl — pinpoint the failing source → destination pair.
2. From the destination, resolve the source’s A record and its GUID._msdcs CNAME.
3. dcdiag /test:dns on both DCs.
4. portqry -e 135 against the source — confirm the endpoint mapper and a reachable dynamic port.
5. Check services, time skew, and secure channel on the source.
6. Fix the cause, then repadmin /syncall /AdeP and re-run /showrepl.

Wrapping up#

Active Directory replication error 1722 looks intimidating but it’s really a connectivity puzzle with a short list of suspects: DNS first, firewall and RPC ports second, then the target DC’s services, time, and secure channel. Work them in that order, confirm each layer before moving on, and you’ll resolve the vast majority of cases without touching the directory database itself.

If you maintain more than one or two domain controllers, it’s worth building these checks into a routine health script so you catch replication drift before it becomes a red wall of 1722.