AD Replication Error 1722 — The RPC Server Is Unavailable

Introduction

A health check flags that two domain controllers have not replicated in days. Passwords set on one DC are not appearing on the other; a newly promoted DC never finished building. repadmin shows the same status against every naming context: 1722, the RPC server is unavailable. The directory looks healthy on each DC individually — they simply are not talking.

The instinct is to fear directory corruption. Resist it. Error 1722 comes from the RPC layer, which sits between the network and the application, and it means only one thing: a connection that should have opened did not. RPC has no insight into why — it just reports that a lower layer, usually TCP, failed to connect. That reframing is the whole fix, because it points you at the network and name resolution instead of at the database.

What You’re Seeing

The status appears identically across the replication tools and in the Directory Service event log. It is the 0x6ba hex code you will also see quoted:

# repadmin summary - the fastest way to see who is failing
C:\> repadmin /replsummary
Source DSA          largest delta    fails/total  %%   error
DC02                      3d.02h          5 /   5  100  (1722) The RPC server is unavailable.

# Per-partner detail with the same status
C:\> repadmin /showrepl
Last attempt @ 2026-07-05 03:11:20 failed, result 1722 (0x6ba):
The RPC server is unavailable.
12 consecutive failure(s).

In the Directory Service log it surfaces as KCC and replication events — 1311 (the KCC found topology problems), 1925 (could not form a replication link), and 1865 (could not build the spanning tree) — all ultimately citing 1722.

What It Actually Means

To replicate, the destination DC resolves the source DC’s replication endpoint, contacts the endpoint mapper on port 135 to learn which dynamic port the directory service is listening on, then opens a connection to that port. Error 1722 is logged when that abstract TCP connect fails at any point in the sequence. The failure could be name resolution handing back the wrong or a stale address, a firewall dropping port 135 or the dynamic RPC range, a required service not running on the source, or a routing problem between sites.

The single most common root cause is DNS. A DC locates its replication partners through GUID-based records in the _msdcs zone, keyed to each DC’s directory GUID. If those records are missing, stale, or pointing at an old IP — after a rebuild, a re-IP, or a decommission that was not cleaned up — the source DC tries to reach the wrong host and the connection never lands. This is the same directory-and-DNS coupling covered in the replication and DNS posts.

Step 1: See the Full Picture

Before chasing any one pair, get the whole topology’s state. repadmin shows every failing partnership at once so you can see whether it is one link, one DC, or one site.

# One-line health summary across the whole forest
repadmin /replsummary

# Every inbound partner for this DC and its last result
repadmin /showrepl

# All replication errors across all DCs, machine-readable
repadmin /showrepl * /csv

# Broad AD health, including the replication tests
dcdiag /test:Replications /v

Step 2: Prove Name Resolution

Because DNS causes most 1722 errors, verify it before anything else. Confirm the source DC’s name resolves to its current IP, and that the GUID-based locator record does too.

# Microsoft's dedicated DNS health test for DCs - run this first
dcdiag /test:DNS /v /e /f:C:\Temp\Reports\dcdiag-dns.log

# Does the source DC's name resolve to the address you expect?
ping -a 10.10.0.12

# Resolve the GUID-based replication record (GUID from repadmin /showrepl)
nslookup <source-dc-guid>._msdcs.corp.example.com

# Force the source DC to re-register its DNS records
ipconfig /registerdns
net stop netlogon && net start netlogon

Step 3: Test Ports and Services

If names resolve correctly and the connection still will not open, the path is blocked or the source is not listening. Check the RPC endpoint mapper and the dynamic range from the destination against the source.

# Is the endpoint mapper (135) reachable on the source DC?
Test-NetConnection DC02.corp.example.com -Port 135

# Probe the endpoint mapper and the dynamic RPC range with PortQry
portqry -n DC02.corp.example.com -e 135
portqry -n DC02.corp.example.com -r 49152-65535

# These must be running on the SOURCE DC
Get-Service NTDS, DNS, Kdc, RpcSs, Netlogon | Select-Object Name, Status

Common Causes

The failure is almost always in this list, roughly ordered by how often it is the answer.

Working Through a Fix

Go top-down. Run repadmin /replsummary to see the shape of the failure, then dcdiag /test:DNS on the affected DCs — resolving a stale or wrong _msdcs record clears the majority of 1722 errors on its own. If DNS is clean, confirm the endpoint mapper and dynamic RPC range are reachable from destination to source, and that the source DC’s directory, DNS, KDC, and Netlogon services are all running.

Once the underlying cause is corrected, force the partners to sync and confirm the errors clear rather than waiting for the next scheduled cycle:

# Force replication of all partitions, both directions, and push changes
repadmin /syncall /AdeP

# Re-check - the failure count should reset and last success update
repadmin /showrepl

How to Prevent It

1722 is a preventable-hygiene error more than a fault. Configure every DC to use a healthy partner DC for DNS rather than pointing solely at itself, so a single DC’s DNS hiccup cannot island it. Keep DNS scavenging tuned so decommissioned and re-IP’d hosts do not leave stale locator records behind — those stale _msdcs entries are the number-one cause. Where firewalls sit between DCs, either open the full dynamic RPC range or pin replication to a fixed port and document it, so a rule change cannot silently sever a site.

Above all, monitor replication continuously. A daily repadmin /replsummary or a health report turns a silent multi-day divergence into a same-day alert — which is exactly the kind of drift that later surfaces as trust failures and stale logon records if left to fester.

Quick Reference

Final Thoughts

Error 1722 feels alarming because it stops replication cold, but it is one of the more mechanical AD faults to resolve once you accept what it is: a connection that would not open. The directory is fine. Something on the wire — a name, a port, a service — is not, and the tools point straight at it if you read them in order.

Start wide with replsummary, prove DNS, then prove the ports. Fix the one broken thing, force a sync, and confirm the counters reset. The forest that looked like it was falling apart was only ever failing to make a phone call.