Helpdesk: "Two users were added to the Finance-Approvers group on DC1 this morning, and the branch office still can't open the approvals share. Someone ran repadmin and it says 1722, the RPC server is unavailable, from DC1 to BR-DC2. Last success was Thursday. The network team says nothing changed. A blog post says to restrict the RPC port range in the registry, force replication with /force, and if that fails, demote and re-promote the branch DC. Can we start with the registry?"
Not yet. Error 1722 isn't an Active Directory fault. It's RPC reporting that a lower layer failed: the destination DC couldn't open a connection to the source DC. Microsoft: "RPC error 1722/0x6ba/RPC_S_SERVER_UNAVAILABLE is logged when a lower-layer protocol reports a connectivity failure." And: "In the context of AD replication, the RPC client on the destination DC was not able to successfully connect to the RPC server on the source DC." Changing the RPC port range before you know which lower layer failed adds a new variable to an outage you haven't diagnosed yet. Work through it as a chain: which partnership, which direction, since when → repadmin /replsummary and /showrepl: the exact status per partner and partition → the Directory Service events → DNS: does the destination resolve the source's GUID-based CNAME to the right IP? → the NICs and DNS registration on both DCs → port 135, the RPC dynamic range, and the firewalls between them → the RPC server side: services and the endpoint the source registered → the sibling, "The target principal name is incorrect" → is the partner still a real, current DC? repadmin, dcdiag, Resolve-DnsName, PortQry, Test-NetConnection, Get-ADReplicationFailure, and Get-WinEvent are the sources for that chain. Demote and re-promote a DC behind the same firewall rule, and the new DC fails with the same 1722.
If the problem is a member computer that can't find or reach a DC at boot, read Netlogon Event ID 5719 first. It covers the DC locator, DNS, and ports from the client side. If SYSVOL or DFS-replicated folders are the ones out of date, that's DFS Replication, covered in DFS Replication Not Working. This post covers "Active Directory replication between two domain controllers fails with 1722, the RPC server is unavailable (or its sibling, the target principal name is incorrect), and you need a read-first path before you change the RPC range, force replication, or rebuild a DC."
TL;DR
- 1722 is a connection failure, mapped by RPC. Microsoft: "RPC itself has no special insight into failures but attempts to map lower-layer protocol failures into an error at the RPC layer." Find the lower layer: DNS, routing, a firewall, the NIC, or a service that isn't running.
-
DNS first. Microsoft: "Domain Name System (DNS) lookup failures are the cause of a large number of 1722 RPC errors when it comes to replication." The destination looks up the source by its GUID-based CNAME in
_msdcs. Resolve that name from the destination, against each of its DNS servers. - Then port 135 and the dynamic range. Microsoft: "The endpoint mapper (listening on port 135) tells the client which randomly assigned port a service (FRS, AD replication, MAPI, and so on) is listening on." On current Windows that range starts at 49152. A firewall that allows 135 but not the range still breaks replication.
- Neighboring codes point at different layers. 1753 means 135 answered but the replication interface wasn't registered. 1727 means the bind to the replication interface didn't finish. 8524 is a DNS lookup failure. -2146893022 is Kerberos, not the network (Step 2).
- "The target principal name is incorrect" is usually a password mismatch. Microsoft's top cause: "the KDC has an old version of the password for the source domain controller." Its fix is about the KDC, not the network (Step 8).
-
Prove it with one partnership. After a change,
repadmin /replicateone destination from one source for one partition, then/showrepland/replsummaryagain.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which destination, which source, which partition, since when, what changed | "AD replication is broken" with no DC names |
| 2. Replication status |
/showrepl names the failing partner and the exact status |
1722 on every partner, or just one |
| 3. Events | Directory Service log read on the destination | KCC events 1311, 1865, 1925 nobody has read |
| 4. DNS | The source's CNAME and A record resolve to its current IP from every DNS server the destination uses | Stale A record; CNAME missing; hosts file entry |
| 5. NICs and registration | One registered adapter per DC; DNS client settings point at internal DNS | Multihomed DC registers the wrong IP |
| 6. Ports and RPC range | 135 and the source's replication port reachable from the destination | 135 filtered; the dynamic range blocked between sites |
| 7. RPC server side | AD DS and RPC running on the source; its replication interface registered | Source DC hung at boot; services stopped |
| 8. Target principal name | The source's password matches the KDC's copy | -2146893022 after a restore or long outage |
| 9. Partner still real | The source is online, current, and inside the tombstone lifetime | A decommissioned DC still listed as a partner |
| 10. Change | Only after Steps 1-9 agree: one layer, one change | Registry ports changed, DC demoted, same 1722 |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Destination DC (the one reporting the error) | The destination is the RPC client; most reads run from its console |
| Source DC (the partner it can't reach) | The RPC server; Step 7 runs on its console |
| Partition (domain, Configuration, Schema, DNS zones) | Different partitions, same failure: the path. One partition only: points away from the network (our reading) |
| Last success time | Hours: a change. Weeks: Step 9 (tombstone lifetime) before you force anything |
| One partner or all of them? | One partner: that path or that source. Every partner: the destination's own DNS, NIC, or firewall |
| What changed? | Firewall rules, a new VLAN or site link, a new NIC or NIC driver, DNS server changes, a restored or re-IP'd DC |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| 1722 from one source, other partners fine | The path to that source, or the source itself | Steps 4, 6, 7 |
| 1722 from every source on one destination | The destination's DNS client settings, NIC, or local firewall | Steps 4, 5 |
| 1722 only across a site link | Routing or a firewall between sites, often the dynamic range | Step 6 |
| 1722 right after a DC was re-IP'd or restored | Stale A record or stale NTDS Settings object | Steps 4, 9 |
| 8524 next to the 1722 | Microsoft: "The DSA operation is unable to proceed because of a DNS lookup failure." | Step 4 |
| 1753 instead of 1722 | 135 answered, the replication interface didn't (Microsoft) | Step 7 |
| -2146893022 "The target principal name is incorrect" | Kerberos, often a password mismatch (Microsoft) | Step 8 |
| Last success older than the tombstone lifetime | Not a 1722 problem anymore | Step 9 |
Step 2: Read the replication status (read-only)
Start with a forest-wide summary, then the detail for the destination. Microsoft on /replsummary: it "Identifies domain controllers that are failing inbound replication or outbound replication, and summarizes the results in a report." Run these from an elevated prompt on a DC or a machine with RSAT:
:: Read-only. Forest summary by source and destination, worst first (Microsoft's example form)
repadmin /replsummary * /bysrc /bydest /sort:delta
:: Read-only. Inbound status for every DC, only partners with errors
repadmin /showrepl * /errorsonly
:: Read-only. The full detail for the destination DC (BR-DC2 is an example), with the source's CNAME
repadmin /showrepl BR-DC2 /verbose
Microsoft: /errorsonly "Displays replication status only for source domain controllers with which the destination domain controller encounters replication errors." And /verbose adds the "fully qualified CNAME, invocation ID, replication flags, and update sequence number (USN) values." That CNAME is the name Step 4 resolves.
For a sortable view of the whole forest, Microsoft gives a PowerShell pipe for the CSV output:
# Read-only. Microsoft's interactive table of forest-wide replication status
repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView
The ActiveDirectory module gives the same data as objects. The property names below come from Microsoft's class reference for each type:
# Read-only. Current failures for the destination, and its inbound partners (BR-DC2 is an example)
Get-ADReplicationFailure -Target BR-DC2 |
Select-Object Server, Partner, FailureType, FailureCount, FirstFailureTime, LastError
Get-ADReplicationPartnerMetadata -Target BR-DC2 -PartnerType Inbound |
Select-Object Server, Partner, Partition, LastReplicationAttempt, LastReplicationSuccess, LastReplicationResult, ConsecutiveReplicationFailures
One catch before you trust any of it. Microsoft: "The administrative workstation on which you run Repadmin must have remote procedure call (RPC) network connectivity to all domain controllers that are targeted by the DSA_LIST parameter." A 1722 against a DC can be your admin box's path, not the DCs' path. Confirm the status from the destination DC's own console (our reading).
How to read the status code. Each row is from the Microsoft article for that code:
Status in /showrepl
|
Microsoft's description | What it tells you |
|---|---|---|
| 1722 (0x6ba) The RPC server is unavailable | "The common case is that the abstract TCP CONNECT operation failed." | No connection: DNS, routing, firewall, NIC, or a service down (Steps 4-7) |
| 1753 (0x6d9) There are no more endpoints available from the endpoint mapper | The client "could contact the RPC Server (source DC) over port 135, but the EPM on the RPC Server (source DC) couldn't locate the RPC application of interest" | 135 works; the source's AD replication service isn't registered, or DNS sent you to the wrong machine (Step 7) |
| 1727 (0x6bf) The remote procedure call failed and did not execute | "More specifically, the replication partner can bind to the RPC endpoint mapper, but can't complete the DRSR RPC bind." | Firewalls, WAN optimizers, or load on the partner (Step 6) |
| 8524 (0x214c) DNS lookup failure | "The DSA operation is unable to proceed because of a DNS lookup failure." | Step 4 |
| -2146893022 (0x80090322) The target principal name is incorrect | "This error occurs when the source domain controller doesn't decrypt the service ticket provided by the destination (target) domain controller." | Kerberos, often a password mismatch (Step 8) |
Microsoft's 1727 article adds the link back: if port 135 is FILTERED, "the AD replication failure is likely to fail and return error 1722 instead."
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| One destination fails from every source | The destination's own DNS, NIC, or firewall | Steps 4, 5 |
| Every destination fails from one source | The source is down, unreachable, or registered at the wrong IP | Steps 4, 7, 9 |
| Only intersite partnerships fail | The path between sites | Step 6 |
| Status flips between 1722 and success | Intermittent network or load. Microsoft lists "Resource limitations" among the causes | Step 6, then a network capture |
| Last success is weeks old | Check the tombstone lifetime before anything else | Step 9 |
Step 3: Read the Directory Service events (read-only)
Microsoft's general guidance: "Ideally, the red (Error) and yellow (Warning) events in the Directory Service event log suggest the specific constraint that is causing replication failure on the source or destination domain controller." Read them on the destination:
# Read-only. Replication-related events on the destination DC, last 3 days (IDs from Microsoft's 1722 and replication articles)
Get-WinEvent -FilterHashtable @{
LogName = 'Directory Service'
Id = 1311, 1865, 1925, 1960, 2087, 2088, 2042
StartTime = (Get-Date).AddDays(-3)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, ProviderName, Message | Format-List
# Read-only. LSASRV 40960/40961 (Microsoft ties them to the UDP fragmentation cause; the System log is our note)
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 40960, 40961; StartTime = (Get-Date).AddDays(-3) } -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, ProviderName, Message
| Event | Microsoft's text | Points at |
|---|---|---|
| 1925 (NTDS KCC) | "The attempt to establish a replication link for the following writable directory partition failed." The event's Additional Data carries the error value | The error value: 1722, 8524, or another code (Step 2 table) |
| 1311 (NTDS KCC) | "The Knowledge Consistency Checker (KCC) has detected problems with the following directory partition." | Topology and connectivity. Read alongside 1865 |
| 1865 (NTDS KCC) | "The Knowledge Consistency Checker (KCC) was unable to form a complete spanning tree network topology." | Whole sites unreachable: the path between sites (Step 6) |
| 1960 (NTDS Replication) | "Internal event: The following domain controller received an exception from a remote procedure call (RPC) connection." | The RPC layer itself (Steps 6, 7) |
| 2087 (NTDS Replication) | Resolving the source's CNAME, FQDN, and NetBIOS name "to the IP address of the source domain controller have all failed." | Step 4 |
| 2088 (NTDS Replication) | "AD DS couldn't resolve the DNS host name of the source domain controller to an IP address, but replication succeeded." | DNS is broken even though a fallback worked (Step 4) |
| 2042 (NTDS Replication) | "Replication hasn't occurred with this partner for a tombstone lifetime, and replication can't proceed." | Step 9. Don't force it |
| 40960 / 40961 (LSASRV) | "Event ID 40960 and 40961 errors with a source of LSASRV are common for this particular cause," UDP fragmentation | The path between the DCs (Step 6) |
Microsoft on fragmentation: "UDP fragmentation can cause replication errors that appear to have a source of RPC server is unavailable". So a 1722 with LSASRV events next to it points at the network path, not at AD (our reading).
Step 4: DNS: can the destination find the source? (read-only)
Microsoft: "The destination domain controller uses the DNS alias (CNAME) resource record to locate its source domain controller replication partner." That CNAME is <DSA object GUID>._msdcs.<forest root domain>, and it points at the source's host (A) record. Get the GUID from the source's own /showrepl header (the DSA object GUID line), then resolve it from the destination against every DNS server the destination uses:
# Read-only. On the destination DC. GUID, forest root, and DC name are examples; copy the GUID from 'repadmin /showrepl DC1'
$cname = 'f8786828-ecf5-4b7d-ad12-8ab60178f7cd._msdcs.contoso.com'
$dnsServers = (Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object ServerAddresses).ServerAddresses | Select-Object -Unique
foreach ($dns in $dnsServers) {
Resolve-DnsName -Name $cname -Server $dns -ErrorAction SilentlyContinue |
Select-Object @{ n = 'DnsServer'; e = { $dns } }, Name, Type, NameHost, IPAddress
}
# Read-only. The source's A records: more than one IP, or an old IP, is the finding
foreach ($dns in $dnsServers) {
Resolve-DnsName -Name DC1.contoso.com -Type A -Server $dns -ErrorAction SilentlyContinue |
Select-Object @{ n = 'DnsServer'; e = { $dns } }, Name, IPAddress
}
# Read-only. A hosts file entry overrides DNS
Select-String -Path "$env:SystemRoot\System32\drivers\etc\hosts" -Pattern 'DC1' -SimpleMatch
Compare the IP you got with ipconfig /all on the source's console. Microsoft's quick check from the other direction is ping -a with the source's IP: "It's a simple, quick test to validate the host record for a domain controller is resolving to the correct machine." The -Server loop and the hosts-file search are our forms of Microsoft's per-DNS-server nslookup steps.
Microsoft's DNS test. Run it on both DCs and read the summary table:
:: Read-only. DNS health for one DC, verbose, to a file (DC1 is an example; /e instead of /s: tests every DC)
dcdiag /test:dns /v /s:DC1 /f:dcdiag-dns-DC1.txt
:: Read-only. Just the records DCs need: CNAME, A, LDAP SRV, GC SRV, PDC SRV
dcdiag /test:dns /DnsRecordRegistration /s:DC1
Microsoft notes that without IPv6 "you should expect the host (AAAA) validation portion of the test to fail." Ignore that row if you don't use IPv6.
The DNS client settings on the DCs. Microsoft's DNS client guidance has three rules that matter for 1722:
- ISP DNS: "Don't configure the DNS client settings on the domain controllers to point to DNS servers of your Internet Service Provider (ISP)." Netlogon then can't register the records other DCs need.
- Islands: for a new DC, Microsoft says "Do not configure the domain controller to utilize its own DNS service for name resolution until you have verified that both inbound and outbound Active Directory replication is functioning and up to date." The same page cites KB 275278, "DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain".
- Wrong answers stick: "Only a failure to respond will cause the DNS client to switch Preferred DNS servers; receiving an authoritative but incorrect response does not cause the DNS client to try another server." So one DNS server with a stale record can break replication while the others have the right one.
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| CNAME doesn't resolve on one or more DNS servers | Microsoft's 2087 causes include "The source domain controller has not registered its resource records in DNS." and "The destination domain controller is configured to use an invalid DNS server." | Step 10: register records on the source; fix the DNS client settings |
| CNAME resolves, A record has an old or extra IP | Stale record. Microsoft: "If invalid IP addresses exist in host records, investigate whether DNS scavenging is enabled and properly configured." | Step 10: fix the record, then Step 5 |
| Hosts file has an entry for the source | Microsoft's checklist says remove it | Step 10 |
| DNS servers disagree | Replication latency between DNS servers, or a non-integrated zone (our reading) | Fix the zone first |
| A DC points at an ISP or public resolver | Netlogon can't register on that server | Step 10: DNS client settings |
| Everything resolves to the right IP | DNS is not the cause | Step 6 |
Step 5: NICs and DNS registration on both DCs (read-only)
A DC with two connected adapters, or one adapter with an old secondary IP, can register an address the destination can't reach. Microsoft's DNS client guidance: "If the domain controller that hosts DNS has several network adapters installed, you must disable one adapter for DNS name registration." In a Microsoft Q&A thread about a failing replication link, the accepted answer starts: "Both domain controllers are multi-homed which will always cause no end to grief for active directory DNS." (community answer).
# Read-only. Run on the source and the destination: adapters, IPs, gateways, DNS servers
Get-NetIPConfiguration -Detailed |
Select-Object InterfaceAlias, @{ n = 'IPv4'; e = { $_.IPv4Address.IPAddress -join ', ' } },
@{ n = 'Gateway'; e = { $_.IPv4DefaultGateway.NextHop -join ', ' } },
@{ n = 'DNS'; e = { $_.DNSServer.ServerAddresses -join ', ' } }
# Read-only. Which adapters register their address in DNS
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, RegisterThisConnectionsAddress
RegisterThisConnectionsAddress "Indicates whether the IP address for this connection is to be registered." Then compare what you see with Step 4's A records.
Microsoft's 1722 article lists the rest of the NIC layer in two lines: "Bad NIC drivers" and "See network card vendors or OEMs for the latest drivers." Check the driver version against the vendor's current release before you blame AD (our reading). Its cause list also starts with "Link local failure" and "DHCP failure," so a DC that picked up an APIPA or DHCP address after a NIC change belongs here too (our reading).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| Two adapters registering in DNS | The source registers an IP the destination may not route to | Step 10: stop registration on one adapter |
| A backup, iSCSI, or management adapter with a gateway | Traffic to the partner may leave through the wrong adapter | The network team; one default gateway |
| DNS servers differ between the two DCs | Each DC may see a different answer (Step 4) | Align them to internal DNS |
| 169.254.x.x or an unexpected DHCP address | Microsoft's "Link local failure" and "DHCP failure" causes | Fix the adapter's IP configuration |
Step 6: Port 135, the RPC dynamic range, and the firewalls (read-only)
AD replication is a two-step RPC conversation. Microsoft: "Active Directory replication remote procedure calls (RPCs) occur dynamically over an available port through the RPC Endpoint Mapper (RPCSS) on port 135." The destination asks the source's endpoint mapper on 135 which port the replication interface is on, then connects to that port. Microsoft on current Windows: "The new default start port is 49152, and the new default end port is 65535." Firewalls between DCs have to allow both steps.
The DC-to-DC rows that matter here come from Microsoft's firewall article for Active Directory (Windows Server 2008 and later). Microsoft notes that "Not all the ports that are listed in the tables here are required in all scenarios." The rows:
| Server port | Service (Microsoft's table) | Why replication cares (our reading unless noted) |
|---|---|---|
| 135/TCP | RPC Endpoint Mapper | Step one of every replication bind |
| 49152-65535/TCP | RPC for LSA, SAM, NetLogon | Step two. AD replication's port is dynamic in this range unless pinned (Microsoft's 1753 article) |
| 53/TCP/UDP | DNS | Step 4's lookups |
| 88/TCP/UDP | Kerberos | Authentication for the bind (Step 8) |
| 389/TCP/UDP | LDAP | DC locator and directory reads |
| 3268/TCP | LDAP GC | Global catalog lookups |
| 445/TCP | SMB | Named pipes and SYSVOL |
| 464/TCP/UDP | Kerberos password change | Machine password changes |
| 123/UDP | W32Time | Time within Kerberos tolerance |
Microsoft's guidance on the range: "Therefore, you must increase the RPC port range in your firewalls." And: "we recommend that you reconfigure the firewalls to allow traffic between servers in the dynamic port range of 49152 through 65535."
Test the two steps from the destination. Microsoft's 1722 and 1727 articles use PortQry, a free Microsoft download. First the endpoint mapper, then the port the replication interface registered:
:: Read-only. From the destination DC: query the source's endpoint mapper and save the list (DC1 is an example)
portqry -n DC1.contoso.com -e 135 > portqry-DC1-135.txt
:: Read-only. Then test the port listed for "MS NT Directory DRS Interface" with ncacn_ip_tcp (49156 is an example)
portqry -n DC1.contoso.com -e 49156
In the saved file, find the MS NT Directory DRS Interface entries (UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2) and note the ncacn_ip_tcp port. PortQry's three answers, per Microsoft: "LISTENING: This response indicates that a process is listening on the target port." "NOT LISTENING: This response indicates that no process is listening on the target port." "FILTERED: This response indicates that the target port is being filtered."
Test-NetConnection gives the same TCP answer for a list of ports, without a download. It "Specifies the TCP port number on the remote computer," so it proves a TCP connect, not an RPC bind:
# Read-only. TCP from the destination to the source (ports from Microsoft's table; 49156 = the DRS port PortQry showed, an example)
foreach ($port in 135, 49156, 389, 445, 88, 53, 3268) {
Test-NetConnection -ComputerName DC1.contoso.com -Port $port -WarningAction SilentlyContinue |
Select-Object ComputerName, RemoteAddress, RemotePort, TcpTestSucceeded
}
Check RemoteAddress against Step 4. A successful test to the wrong IP is still the wrong DC (our note).
Has anyone changed the range or pinned the ports? On the source DC, read the dynamic range and the registry values Microsoft documents for restricting it:
:: Read-only. The source DC's dynamic port range (Microsoft's netsh form)
netsh int ipv4 show dynamicport tcp
# Read-only. On the source DC: restricted RPC range, pinned AD and Netlogon ports, firewall profiles (missing values = not set)
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Rpc\Internet' -ErrorAction SilentlyContinue |
Select-Object Ports, PortsInternetAvailable, UseInternetPorts
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'TCP/IP Port' -ErrorAction SilentlyContinue
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -Name DCTcpipPort -ErrorAction SilentlyContinue
Get-NetFirewallProfile | Select-Object Name, Enabled
Microsoft on the Rpc\Internet key: "The values (and Internet key) discussed below don't appear in the registry. They must be added manually using the Registry Editor." So if the key exists, someone added it. And: "If any entries are outside the range of 0 to 65535, or if any string can't be interpreted, the RPC runtime treats the entire configuration as invalid."
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| 135 is FILTERED | A firewall or route blocks the endpoint mapper. The 1727 article: replication then fails with 1722 | Firewall team: 135 between the DCs |
| 135 LISTENING, the DRS port FILTERED | The firewall allows 135 but not the dynamic range (our reading) | Step 10: open 49152-65535 TCP between DCs, or pin the port |
135 LISTENING, no MS NT Directory DRS Interface in the list |
The replication interface isn't registered: 1753 territory | Step 7 |
| Every TCP test succeeds, replication still fails | Name resolution to a different IP (Step 4), an intermediate device that breaks the bind (1727), or something intermittent | Microsoft's 1727 step: "Take a double-sided network capture while you reproduce the problem." |
Rpc\Internet exists with a narrow range |
Restricted RPC. Microsoft: "Computers with higher traffic may run into a port exhaustion situation if the RPC dynamic ports are restricted." | Widen it or remove it deliberately (Step 10) |
TCP/IP Port set, firewall opened only for the default range |
Microsoft: "Administrators should confirm that the communication over the specified port is enabled if any intermediate network devices or software is used to filter packets between the domain controllers." | Open the pinned port too |
| Netlogon event 5820 on the source | Microsoft: an RPC port configuration error returns "87 (0x57) ERROR_INVALID_PARAMETER" and Netlogon logs 5820 | Fix the Rpc\Internet values |
Step 7: The RPC server side: the source DC itself (read-only)
Two of Microsoft's 1722 causes are on the source: "Higher-layer protocol not running" and "Higher-layer protocol returning this error." Read the source's own state from its console:
:: Read-only. From the destination: does the source answer as a DC? (Microsoft's net view check)
net view \\DC1
Microsoft: "This command displays the Netlogon and SYSVOL shares, indicating that the server is functioning as a domain controller."
# Read-only. On the source DC: the services replication depends on (service names are our note)
Get-Service -Name NTDS, RpcSs, RpcEptMapper, Netlogon, KDC, DNS -ErrorAction SilentlyContinue |
Format-Table Name, DisplayName, Status, StartType
# Read-only. Something should be listening on 135
Get-NetTCPConnection -State Listen -LocalPort 135 | Select-Object LocalAddress, LocalPort, OwningProcess
# Read-only. Microsoft's ClientProtocols check (run on both DCs): ncacn_http, ncacn_ip_tcp, ncacn_np, ncacn_ip_udp = rpcrt4.dll
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Rpc\ClientProtocols'
Microsoft's 1722 article: "If the ClientProtocols key or any of the four default values are missing, import the key from a known good server." Its 1753 article adds the boot state: "Verify that the source DC is booted in normal mode. And verify that the OS and DC role on the source DC have fully started."
SMB signing. Microsoft's 1722 article lists "SMB signing mismatches between DCs" as a cause and recommends consistent settings through the Default Domain Controllers Policy. Read the values on both DCs:
# Read-only. SMB client and server signing values (1 = enabled; names from Microsoft's 1722 article)
foreach ($svc in 'LanManWorkstation', 'LanManServer') {
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\$svc\Parameters" |
Select-Object @{ n = 'Service'; e = { $svc } }, RequireSecuritySignature, EnableSecuritySignature
}
The sample values in that article turn "always" signing off. We wouldn't weaken signing on DCs to fix a mismatch. Make the values match through policy at the stricter setting your baseline uses (our view).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
net view \\DC1 fails, ping works |
The source is up but not answering as a DC, or SMB is blocked | The services above; Step 6 for 445 |
NTDS stopped or the DC booted into DSRM |
Microsoft's 1753 causes: the server application never started or died | Start it after reading why it stopped (System and Directory Service logs) |
| Nothing listening on 135 | RPC itself is down |
RpcSs and RpcEptMapper
|
ClientProtocols values missing |
Microsoft: import the key from a known good server | Step 10 |
| Signing values differ between DCs | Microsoft's "SMB signing mismatches" cause | Align by policy (Step 10) |
Step 8: The sibling: "The target principal name is incorrect" (read-only)
If /showrepl shows -2146893022 (0x80090322) instead of 1722, the network got through and Kerberos failed. Microsoft: "This error occurs when the source domain controller doesn't decrypt the service ticket provided by the destination (target) domain controller." Its top cause: "The destination domain controller receives a service ticket from a Kerberos Key Distribution Center (KDC). And the KDC has an old version of the password for the source domain controller." Microsoft's specific root causes:
- "A bad name-to-IP mapping in DNS, WINS, HOST, or LMHOST file." The destination reached the wrong DC (Step 4 again).
- "The KDC and source domain controller have different versions of the source domain controller's computer account password."
- "The KDC couldn't find a domain to look for the source domain controller's SPN."
- "Authentication data in Kerberos encrypted frames were modified by hardware (including network devices), software, or an attacker."
Microsoft's reads, in order:
:: Read-only. On the source DC's console: missing or duplicate SPNs and other security errors
dcdiag /test:checksecurityerror
:: Read-only. On the destination, close to the time of the error: which KDC is it using?
nltest /dsgetdc:contoso.com /kdc /force
:: Read-only. Password attribute versions for the source's computer account: on the source, then on that KDC (DC3 is an example)
repadmin /showobjmeta DC1 "CN=DC1,OU=Domain Controllers,DC=contoso,DC=com"
repadmin /showobjmeta DC3 "CN=DC1,OU=Domain Controllers,DC=contoso,DC=com"
Microsoft: "DCDIAG /TEST:CheckSecurityError can check for missing or duplicate SPNs and other errors." Run it "on the console of all source domain controllers that fail outbound replication with the SEC_E_WRONG_PRINCIPAL error." For the /showobjmeta pair, Microsoft says to look "for obvious version number differences in password-related attributes (dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet, lmPwdHistory)." And on nltest: "/FORCE: Forces the computer to run the command against the DNS server instead of looking in the cache for the information."
Time. Microsoft lists "Time accuracy within 5 minutes to support Kerberos authentication" among replication's dependencies. A quick read of the offset between the two DCs:
:: Read-only. Three samples of the offset from the destination to the source (w32tm syntax from Microsoft's Windows Time tools page)
w32tm /stripchart /computer:DC1.contoso.com /samples:3 /dataonly
If the offset is minutes, not milliseconds, read Windows Time Not Syncing with Domain Controller before you touch passwords.
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| CNAME or A record points at another DC or another forest | Bad name-to-IP mapping; the realm in the ticket is wrong | Step 4, then Step 10 |
checksecurityerror reports missing or duplicate SPNs |
Microsoft: "Duplicate SPNs may cause bad SPN to name mappings." | Fix the SPN (our reading: find the duplicate owner first) |
| Password attribute versions differ between the source and the KDC | The KDC has the old password: Microsoft's top cause | Step 10: Microsoft's KDC sequence |
| Offset of minutes between the DCs | Outside Kerberos tolerance | The Windows Time post |
| Error right after a DC restore or a long outage | Replication failures "can prevent domain controllers from having a current password value for domain controllers in a given domain" | Step 10: KDC sequence or netdom resetpwd
|
Step 9: Is the partner still a real, current DC? (read-only)
Microsoft's first check before any 1722 fix: rule out intentional disconnections. Its example is a DC "that has been built in a staging site and is currently offline awaiting its deployment in the final production site." Also check whether the source still exists at all. Microsoft's 2087 event text: "If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller's metadata with ntdsutil.exe".
The tombstone lifetime. If the last success is older than the forest's tombstone lifetime, a 1722 fix that lets replication resume can bring lingering objects with it (our reading; Microsoft's event 1388 is a lingering object replicating when strict replication consistency isn't in effect). Microsoft's /showrepl message for that case: "The time since last replication with this server has exceeded the tombstone lifetime." Read the value:
# Read-only. The forest's tombstoneLifetime in days (the object path and read form are ours)
$config = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$config" -Properties tombstoneLifetime |
Select-Object tombstoneLifetime
Microsoft: "In any forest created using Windows Server 2003 SP1 or later, the value of tombstoneLifetime is set to 180 days by default. In any forest upgraded from Windows 2000 or installed with Windows Server 2003 (no service pack), the default tombstoneLifetime attribute is not set and Windows therefore uses the internal default of 60 days."
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| The source was decommissioned or rebuilt | Its NTDS Settings object is stale; replication keeps trying it | Metadata cleanup, deliberately, after you confirm it's gone |
| The source is a staged DC, offline on purpose | Expected errors | Document it; Microsoft suggests IFM for staged DCs |
| Last success older than the tombstone lifetime | Event 2042 territory: "Replication hasn't occurred with this partner for a tombstone lifetime, and replication can't proceed." | Don't force it. Microsoft's lingering-object guidance first |
| Last success within days, the source is real | A 1722 fix is safe to test | Step 10 |
Common false starts (read these before you change anything)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| Restricting the RPC port range first | Microsoft: "Use the method that is described in this article only if the RPC server does not offer a way to define the server port." A narrow range can exhaust ports, and a bad value makes "the entire configuration" invalid | Find the blocked step with PortQry (Step 6) |
repadmin /replicate ... /force |
Microsoft: /force "allows replication with corrupt and divergent partners. Do not use this parameter if you suspect that Update Sequence Number (USN) Rollback has occurred." |
Read the last success and the tombstone lifetime (Step 9) |
Repeating repadmin /syncall /AdeP |
It asks for replication again; it doesn't change the path that failed (our reading) | One /replicate after one fix (Step 10) |
| Demoting and re-promoting the DC | Microsoft lists rebuilding only "If the problem that is causing replication to fail can't be resolved by any known methods" | Steps 4-8 name the layer first |
| Turning off Windows Firewall on the DCs | It hides which rule was missing, and the next DC build fails the same way (our view) | Open the documented ports between DCs (Step 10) |
| Adding hosts file entries for the partner | Microsoft lists stale hosts entries as a cause of wrong-target errors. They outlive the next re-IP | Fix the DNS record (Step 4) |
netdom resetpwd for a plain 1722 |
Microsoft's netdom sequence is for password mismatches (-2146893022); 1722 means no connection was made (our reading). A Microsoft Q&A answer suggests it for 1722 anyway (community) | Steps 4-7 for 1722; Step 8 for the target principal error |
| Metadata cleanup on a DC that's only unreachable | It deletes a working DC's objects from AD (our reading of Microsoft's cleanup steps) | Confirm the DC is gone (Step 9) |
| Turning off SMB signing to make DCs match | Fixes a mismatch by weakening both DCs (our view) | Match by policy at the stricter setting |
Step 10: Change one layer, then prove it (only after the read)
Pick the one change Steps 1-9 point at. Save the current state first, so you can compare or put it back:
# Low-risk write. Save replication status and the registry keys this step may touch (our habit)
New-Item -Path C:\Temp -ItemType Directory -Force | Out-Null
repadmin /showrepl * /csv > C:\Temp\showrepl-before.csv
reg export 'HKLM\SOFTWARE\Microsoft\Rpc' C:\Temp\rpc-before.reg /y
reg export 'HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' C:\Temp\ntds-params-before.reg /y
reg export 'HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' C:\Temp\netlogon-params-before.reg /y
DNS records (Step 4). Fix a stale A record in the DNS console, remove any hosts file entry for the partner, then have the source register again. Microsoft: "The Net Logon service on a domain controller registers the DNS resource records that are required for the domain controller to be located on the network. The DNS Client service registers the host (A) resource record that the alias (CNAME) record points to." Its commands, on the source DC:
:: Change, on the source DC. Microsoft's manual registration: Netlogon records, then the host (A) record
net stop netlogon && net start netlogon
ipconfig /flushdns && ipconfig /registerdns
Microsoft: "Wait 15 minutes, and then review events in Event Viewer to ensure proper registration of the resource records." Then run ipconfig /flushdns on the destination and resolve the CNAME again (Step 4).
An extra adapter registering (Step 5). Turn off registration on the adapter that shouldn't be in DNS, then remove its stale A record:
# Change. Dry-run first ('Backup' is an example adapter name), then re-register the remaining adapter
Set-DnsClient -InterfaceAlias 'Backup' -RegisterThisConnectionsAddress $false -WhatIf
Register-DnsClient -WhatIf
DC DNS client settings (Step 4). Point each DC at internal DNS servers only; send internet names through forwarders. Microsoft: "To forward external DNS requests, add the ISP's DNS servers as DNS forwarders in the DNS management console." After the change, Microsoft's order: "If you change any DNS client settings, you must clear the DNS resolver cache and register the DNS resource records."
The firewall (Step 6). Ask for a rule scoped to DC-to-DC traffic: 135/TCP and 49152-65535/TCP, plus the other ports in Microsoft's table, in both directions, because each DC is a destination for some partners (our reading). Test with PortQry from both sides afterward. Microsoft's 1727 steps end the same way: "Repeat step 1 through 3 on the source DC."
Pinning AD's RPC port (Step 6), if the firewall team needs one port. Microsoft's KB 224196 values, on each DC that should use them. Microsoft: "Don't assume that clients only use the Netlogon RPC services and thus only the setting DCTcpipPort is required." And: "You should always configure both registry settings and open both ports on the firewall." Two different ports; the numbers below are examples:
# Change. Pin NTDS and Netlogon to two different ports (50000/50001 are examples). Dry-run first
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'TCP/IP Port' -PropertyType DWord -Value 50000 -WhatIf
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -Name DCTcpipPort -PropertyType DWord -Value 50001 -WhatIf
Microsoft: for TCP/IP Port, "Restart the computer for the new setting to become effective." For DCTcpipPort, "Restart the Netlogon service for the new setting to become effective." If both values are the same port, "Netlogon error event 5809 is logged in the system log." Microsoft's known-issues list for static ports names logon and replication problems that later updates fix, so patch first (our summary of that list).
Restricting the whole RPC range (Step 6), last. Only when the firewall can't allow the default range and no per-service port exists. Microsoft's example range "isn't a recommendation of a minimum number of ports needed for any particular system," and "previous experience shows that a minimum of 100 ports should be opened, because several system services rely on these RPC ports to communicate with each other." The values go under HKLM\Software\Microsoft\Rpc\Internet (Ports, PortsInternetAvailable, UseInternetPorts), then "Restart the server." Test one DC first, and keep the rpc-before.reg export to put it back (our habit).
ClientProtocols (Step 7). If the read found values missing, Microsoft's fix is to "import the key from a known good server." Export it on a healthy DC of the same version and import it with reg import on the broken one (the export and import form is ours).
SMB signing (Step 7). Set the four signing policies once, in the Default Domain Controllers Policy, so both DCs match. Pick the stricter value your baseline uses (our view).
The target principal name is incorrect (Step 8). Microsoft's top resolution, on the destination DC: disable the KDC, restart, replicate from the source, then put the KDC back:
# Change, on the destination DC (BR-DC2). Microsoft's sequence; dry-run the startup change first
Set-Service -Name KDC -StartupType Disabled -WhatIf
# ...restart the destination DC, then replicate from the source (Microsoft's repadmin form):
# repadmin /replicate BR-DC2.contoso.com DC1.contoso.com "DC=contoso,DC=com"
Set-Service -Name KDC -StartupType Automatic -WhatIf # Microsoft's article writes Auto; Set-Service documents Automatic
Start-Service -Name KDC -WhatIf
Microsoft's fallback: "If it doesn't resolve the issue, see the Resolution section for an alternative solution in which you use the netdom resetpwd command to reset the computer account password of the source domain controller." Run it on the source DC itself. Microsoft: "If you want to reset the password for a Windows domain controller, you must stop the Kerberos Key Distribution Center service and set its startup type to Manual." Then clear the ticket cache, run the reset against a healthy DC, and restart:
:: Change, on the source DC (DC1) with its KDC stopped and set to Manual. DC3 is a healthy DC, an example
klist purge -li 0x3e7
netdom resetpwd /s:DC3 /ud:contoso\admin.user /pd:*
Microsoft: "Kerberos tickets for the system account that are used by Active Directory replication can be purged without a restart by using KLIST -li 0x3e7 purge." After the restart, start the KDC and set it back to Automatic.
More detail if you're still stuck. Microsoft's 2087 event text: "By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur." Its target-principal article sets DS RPC Client under NTDS\Diagnostics to 3 and then looks for events 1962 and 1963. Turn it up for the test, and back to 0 afterward (the reset to 0 is our habit).
Then prove it. One destination, one source, one partition, then the same reads as Step 2. Microsoft: "The /replicate command tests replication success after you remove suspected fault conditions without waiting for the replication schedule to open."
:: Read-mostly. Trigger one inbound replication, then re-read status (names and partition are examples)
repadmin /replicate BR-DC2 DC1 DC=contoso,DC=com
repadmin /showrepl BR-DC2
repadmin /replsummary * /bysrc /bydest /sort:delta
# Read-only. No current failures for the destination, and a fresh last success from the source
Get-ADReplicationFailure -Target BR-DC2 | Select-Object Partner, FailureCount, LastError
Get-ADReplicationPartnerMetadata -Target BR-DC2 -PartnerType Inbound |
Select-Object Partner, Partition, LastReplicationSuccess, LastReplicationResult
Check the other partitions on the next scheduled cycle, and check the reverse direction: the source pulling from the destination. Then confirm the change the user waited for, like the group membership on the branch DC (our habit).
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Stale or missing DNS records | Fix the record; Microsoft's Netlogon restart and ipconfig /registerdns on the source |
Hosts file entries |
| Multihomed DC registering the wrong IP | Stop registration on the extra adapter | Leaving both and hoping the right one answers |
| DCs pointing at ISP DNS | Internal DNS on the DCs, forwarders for the internet | Public resolvers on DC adapters |
| Firewall blocks 135 or the dynamic range | A DC-to-DC rule for 135 and 49152-65535 | Turning off Windows Firewall |
| Firewall team needs one port | Pin TCP/IP Port and DCTcpipPort to two ports, open both |
Pinning one and opening one |
| No other option for RPC | A restricted range with room to spare, tested on one DC | A tiny range on busy DCs |
| -2146893022 password mismatch | Microsoft's KDC sequence, then netdom resetpwd if needed |
Rebuilding the DC |
| Last success past the tombstone lifetime | Lingering-object guidance first |
/force and hope |
FAQ
What does Active Directory replication error 1722 mean?
The destination DC's RPC client couldn't connect to the RPC server on the source DC. Microsoft: "RPC error 1722/0x6ba/RPC_S_SERVER_UNAVAILABLE is logged when a lower-layer protocol reports a connectivity failure." The usual lower layers are DNS, routing and firewalls, the NIC, or a service that isn't running on the source.
How do I fix "The RPC server is unavailable" between domain controllers?
Read before you change. Get the exact partner and status from repadmin /showrepl, resolve the source's GUID-based CNAME from the destination against each of its DNS servers, then test port 135 and the replication port with PortQry. Fix the one layer that fails, and prove it with repadmin /replicate for one partition.
What ports does Active Directory replication need?
135/TCP for the RPC endpoint mapper and the dynamic range 49152-65535/TCP on current Windows, unless you've pinned AD's port. DNS (53), Kerberos (88), LDAP (389), and SMB (445) are part of the same conversation. Microsoft's firewall article for AD domains and trusts has the full table.
What's the difference between 1722 and "The target principal name is incorrect"?
1722 means no connection was made. -2146893022, "The target principal name is incorrect," means the connection was made but the source couldn't decrypt the destination's Kerberos ticket. Microsoft's top cause is a KDC with an old copy of the source DC's password, or DNS sending the destination to the wrong DC.
Does repadmin /syncall /AdeP fix replication errors?
No. It asks for replication: Microsoft's flags are /A for all naming contexts, /d for distinguished names in messages, /e for all sites, and /P to push changes outward. If the path is broken, it fails with the same error. Use it to confirm a fix, not to make one.
Related posts
- Netlogon Event ID 5719 (the member side: DC locator, DNS, ports, and sites at boot)
- DFS Replication Not Working (when SYSVOL or replicated folders are the ones behind; DFSR has its own 1722 searches)
- DFS Namespace Not Accessible (namespace servers read from the PDC emulator and AD sites, so AD replication matters there too)
- Windows Time Not Syncing with Domain Controller (Kerberos needs DCs within five minutes of each other)
Free checklist
A firewall change that allowed port 135 between sites but not the RPC range is a change nobody tested from where the replication flows. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=active-directory-replication-error-1722
Admin Pack Studio; not affiliated with Microsoft. Steps 1-9 favor read-only checks: repadmin /replsummary, /showrepl, /showobjmeta, Get-ADReplicationFailure, Get-ADReplicationPartnerMetadata, Get-WinEvent, Get-DnsClientServerAddress, Resolve-DnsName, Select-String, dcdiag /test:dns, dcdiag /test:checksecurityerror, Get-NetIPConfiguration, Get-DnsClient, portqry, Test-NetConnection, netsh int ipv4 show dynamicport, Get-ItemProperty, Get-NetFirewallProfile, net view, Get-Service, Get-NetTCPConnection, nltest /dsgetdc, w32tm /stripchart, Get-ADRootDSE, and Get-ADObject. repadmin /showrepl /csv redirection and reg export write local files. DNS record fixes, Netlogon restarts, ipconfig /registerdns, Set-DnsClient, Register-DnsClient, DNS client and forwarder changes, firewall rules, TCP/IP Port, DCTcpipPort, Rpc\Internet values, ClientProtocols imports, SMB signing policy, KDC startup changes, klist purge, netdom resetpwd, diagnostic logging, repadmin /replicate, and metadata cleanup are deliberate changes. Change one layer at a time, test with one partnership first, and check current Microsoft Learn for version-specific behavior.
Top comments (0)