How to Fix “RPC Server Is Unavailable” in Windows Server?

What Does “RPC Server Is Unavailable” Actually Mean and How Does RPC Work?

The “RPC server is unavailable” error means a Windows client cannot successfully establish or complete communication with the RPC endpoint required by an operation. The error does not necessarily mean that the Remote Procedure Call service has stopped because DNS, routing, firewall filtering, TCP 135, dynamic RPC ports, service registration, authentication, or server configuration can all interrupt the communication path. Microsoft describes RPC as an intermediate layer where lower-level connectivity failures can surface as error 1722 or RPC_S_SERVER_UNAVAILABLE.

Windows uses Remote Procedure Call to let applications and operating-system components perform operations across another computer. Active Directory replication, Microsoft Management Console operations, DCOM applications, certificate services, remote administration, and other Windows infrastructure components can depend on RPC, so an RPC failure can affect much more than a single application.

An RPC client normally contacts the RPC Endpoint Mapper on TCP 135 before connecting to the service endpoint assigned to the application. The client reaches TCP 135, queries the Endpoint Mapper for the registered RPC interface, receives an endpoint, and then attempts the actual RPC connection to that endpoint. This two-stage model is the most important concept when troubleshooting the error.

Which Ports Does Windows RPC Require?

TCP 135 alone does not guarantee successful RPC communication because the actual service may use a dynamically allocated TCP port after Endpoint Mapper communication succeeds. A firewall can therefore allow TCP 135 while blocking the second connection, leaving the client with the same “RPC server is unavailable” message even though the first connectivity test succeeds. Microsoft identifies failure to connect to the allocated dynamic port as a common cause of RPC errors. Modern Windows environments commonly use TCP 135 for the RPC Endpoint Mapper and TCP 49152–65535 for dynamically allocated RPC ports. The exact ports depend on the Windows version, service, application, and RPC configuration, so administrators should not treat 49152–65535 as a universal requirement for every RPC workload. Microsoft documents this high-port range for modern Windows Server and also supports controlled RPC port configurations where required.

Active Directory operations can require additional protocols alongside RPC, including DNS, Kerberos, LDAP, and SMB. Microsoft documents TCP 135 for RPC, TCP 445 for SMB, TCP/UDP 389 for LDAP, and other domain-controller dependencies. Therefore, administrators should investigate an Active Directory RPC failure as a multi-protocol communication problem rather than focusing on a single port

How Do You Check DNS and Network Connectivity First?

DNS should be validated before changing firewall or Windows service configuration because the client must reach the correct server before RPC can work. Verify that the affected hostname resolves to the intended server IP address and check for stale records, incorrect DNS suffixes, split-DNS problems, or incorrect static DNS settings that could send the client toward the wrong endpoint. Microsoft specifically identifies DNS failures as a common contributor to RPC error 1722 in Active Directory environments.

Basic network reachability should be established before investigating RPC-specific behavior. Confirm that routing is correct and consider whether a VPN, NAT boundary, firewall, ACL, network segmentation rule, or security appliance exists between the client and server because any of these can interrupt the RPC communication path.

Incorrect DNS can create an RPC error even when the Windows server itself is healthy. This is especially important for Active Directory because domain controllers rely heavily on DNS for locating infrastructure and establishing authentication and replication relationships.

How Do You Test TCP 135 and Interpret the Result?

TCP 135 should be tested from the affected client to determine whether the RPC Endpoint Mapper is reachable. A PowerShell test can quickly establish whether the initial TCP connection succeeds.

Test-NetConnection <server-name> -Port 135

A successful TCP 135 test proves only that the Endpoint Mapper is reachable, not that the required RPC service endpoint is reachable. If TCP 135 fails, investigate the server firewall, upstream firewall, routing path, security appliance, server IP configuration, or RPC infrastructure before moving to dynamic-port troubleshooting.

A failed TCP 135 connection usually points to a lower-level connectivity problem rather than an application-specific RPC problem. Microsoft associates RPC error 1722 with failures such as DNS, routing, blocked firewall ports, network authentication, resource limitations, and unavailable higher-layer services.

How Do Windows Services and the RPC Endpoint Mapper Affect Connectivity?

The Remote Procedure Call service and RPC Endpoint Mapper provide core infrastructure for Windows RPC communication. The Endpoint Mapper tells clients which endpoint a registered RPC service is using, while the affected application or Windows service must remain available and correctly registered for the final RPC operation to succeed.

A failed application service can therefore produce an RPC error even when the Windows operating system and network interface remain online. Active Directory, certificate services, DCOM-based applications, management components, and other RPC-dependent workloads can become unavailable when their required service endpoint stops, fails to register, or cannot accept the requested operation.

Restarting RPC blindly is not a reliable production troubleshooting strategy. RPC is foundational to Windows, so restarting core infrastructure without identifying the failed communication stage can interrupt dependent components and hide the original cause; first determine whether the failure is DNS, transport, Endpoint Mapper, dynamic endpoint, service registration, authentication, or application specific.

How Do You Find and Test the Dynamic RPC Port?

A dynamic RPC failure occurs when TCP 135 works but the client cannot establish

a connection to the endpoint returned by the RPC Endpoint Mapper. Port-querying tools, endpoint information, Windows event data, and network traces can identify the dynamic endpoint and show whether the second TCP connection is being blocked.

TCP SYN retransmissions to the dynamic RPC port are strong evidence that the connection is failing at the TCP layer. Microsoft identifies this pattern as a common indication that a firewall, intermediate network device, Windows Filtering Platform, NIC behavior, or another filtering mechanism is preventing the connection from completing.

The most useful troubleshooting question after TCP 135 succeeds is therefore not “Is RPC running?” but “Can the client reach the endpoint that RPC actually assigned?” This distinction prevents administrators from repeatedly restarting services when the real problem is a blocked network path.

How Should You Configure the Firewall and RPC Port Range?

A firewall supporting Windows RPC must account for both TCP 135 and the dynamically assigned RPC ports required by the workload. Microsoft describes TCP 135 as the Endpoint Mapper connection and the dynamic port as the subsequent service connection, so permitting only TCP 135 is incomplete for many RPC applications.

You should not expose the entire RPC dynamic range to untrusted Internet traffic merely to eliminate an RPC error. Firewall policies should restrict the source networks, destination systems, protocols, and required ports, while public-facing infrastructure should use segmentation and other security controls rather than broad inbound access.

A controlled RPC port range can be useful when network firewalls cannot safely manage the normal dynamic range. Microsoft documents methods for configuring RPC to use defined ports or ranges, allowing administrators to build narrower firewall policies while maintaining the required RPC functionality.

An incorrectly configured or excessively small RPC range can create new failures instead of solving the original problem. Services may be unable to register endpoints or available ports may become exhausted, so a restricted range should be designed around the workload instead of selected arbitrarily.

How Do You Troubleshoot RPC in Active Directory?

Active Directory RPC troubleshooting requires checking several interconnected protocols and services rather than testing TCP 135 alone. Domain-controller communication can involve DNS, Kerberos, LDAP, SMB, RPC, dynamically assigned ports, authentication, and time synchronization, so an RPC error can represent a broader domain communication problem.

System time should be checked when RPC failures occur during domain authentication or Active Directory operations. Kerberos authentication is sensitive to time differences, so verify the system clock, time zone, and domain time synchronization when network connectivity appears healthy but authentication-dependent operations continue to fail.

Supporting Windows services can also matter depending on the workload. Microsoft identifies incorrect DNS, incorrect time or time-zone settings, TCP/IP NetBIOS Helper, and Remote Registry among potential contributors to certain Windows logon scenarios involving the RPC server unavailable message.

Active Directory replication failures should be treated as a functional communication problem rather than simply a service restart problem. Microsoft documents error 1722 during replication and recommends validating DNS, network ports, the RPC endpoint, and other domain-controller communication dependencies before forcing replication repeatedly.

How Do You Troubleshoot Application-Specific RPC Errors?

RPC failures must be analyzed in the context of the application that generated the error. Certificate enrollment, Active Directory replication, remote management, backup software, DCOM applications, and other Windows workloads can all use RPC while depending on different service endpoints and supporting protocols.

Windows error 1722 is represented as RPC_S_SERVER_UNAVAILABLE, but the code does not identify the failed component by itself. The underlying failure can involve DNS, TCP connectivity, dynamic RPC ports, firewall filtering, network routing, authentication, resource limitations, or an unavailable higher-layer service.

SMB port 445 can appear during RPC-related Windows troubleshooting because some operations depend on RPC and SMB together. TCP 445 is not the RPC Endpoint Mapper port, but Microsoft lists SMB alongside RPC and other protocols for several Active Directory and Windows communication scenarios, so the exact workload should determine which dependencies are tested.

How Can Firewalls, NAT, and Security Software Break RPC?

A stateful firewall can allow TCP 135 while still blocking the dynamically negotiated RPC connection. This can happen when ACLs permit only the well-known Endpoint Mapper port, when high TCP ports are restricted, when RPC inspection behaves unexpectedly, or when the security policy does not permit the source-to-destination dynamic connection.

NAT can complicate RPC when the endpoint returned by the server cannot be reached correctly through the translated network path. RPC-heavy Windows infrastructure, particularly domain controllers, should avoid unnecessary NAT boundaries where direct domain communication is required because dynamic endpoint connectivity becomes more difficult to manage.

Endpoint security software can block RPC independently of the standard Windows Firewall configuration. Host intrusion-prevention systems, EDR products, network filtering drivers, and other security controls can drop traffic after it reaches the operating-system networking stack, so a seemingly correct firewall rule does not always prove that the traffic is passing.

What If TCP 135 Works but RPC Still Fails?

When TCP 135 succeeds but the RPC operation fails, the next priority is identifying and testing the dynamically assigned endpoint. This is where packet captures, PortQry, Windows event logs, firewall logs, and service registration information provide stronger evidence than repeatedly restarting Windows services.

A packet capture can separate DNS, TCP, Endpoint Mapper, and application-layer failures into independently verifiable stages. The useful sequence is to identify the TCP 135 connection, observe the Endpoint Mapper response, identify the allocated destination port, and determine whether the client completes the second TCP handshake.

Microsoft identifies failure to connect to the allocated dynamic port as the most common cause of the “RPC server unavailable” error in its RPC troubleshooting guidance. If the client sends repeated SYN packets to the dynamic port without receiving the expected response, investigate the firewall, intermediate device, destination filtering, Windows Filtering Platform, NIC behavior, or filter drivers. DNS can independently cause the same RPC error by directing the client to the wrong server or preventing it from locating the intended infrastructure endpoint. This is why DNS should remain part of the troubleshooting sequence even when a basic IP connectivity test succeeds.

Restarting the affected application can restore RPC only when the application endpoint temporarily failed and successfully re-registers. A restart cannot correct a blocked firewall port, incorrect DNS record, network ACL, security policy, or routing problem.

What Production Architecture Prevents Recurring RPC Failures?

Reliable Windows infrastructure treats RPC as a complete network dependency rather than a single TCP port. Production architecture should combine correct DNS, synchronized system time, controlled firewall policies, appropriate dynamic RPC handling, service monitoring, network segmentation, and application-specific dependency mapping so that an RPC failure can be isolated before it becomes a larger outage.

RPC monitoring should measure functional connectivity rather than only Windows service state. Useful signals include endpoint availability, TCP connection failures, network latency, packet loss, firewall drops, authentication failures, service state, relevant Windows events, and application transaction success because a server can remain healthy at the CPU and memory level while an RPC dependency is unreachable.

Active Directory monitoring should correlate DNS, LDAP, Kerberos, SMB, RPC Endpoint Mapper, replication health, and system time. Monitoring these dependencies together gives infrastructure teams a functional view of domain-controller health instead of treating each protocol as an unrelated alert.

What Are the Lessons From a Production RPC Failure?

A representative production RPC incident can be resolved faster when the failure is divided into DNS, Endpoint Mapper, dynamic-port, service, and application layers. Consider a Windows domain environment where remote management operations suddenly return error 1722 while the domain controller remains reachable by IP address; if DNS is correct and TCP 135 responds normally but RPC operations continue to fail, dynamic RPC connectivity becomes a stronger hypothesis. The fastest isolation strategy is to compare a successful RPC client with a failing client while testing the same destination and operation. If both clients resolve the same server correctly and both can reach TCP 135, but only one can establish the dynamically assigned TCP session, investigate client-side firewall policy, network ACLs, security filtering, VPN segmentation, or asymmetric routing.

A controlled RPC architecture reduces the likelihood of the same failure returning after remediation. Document network paths, restrict firewall rules to trusted systems, monitor domain-controller dependencies, maintain consistent configuration management, and deliberately docume

nt any restricted RPC ranges so future firewall changes do not silently break Windows management traffic.

What Should Infrastructure Teams Measure After RPC Remediation?

RPC remediation should be measured through successful transactions rather than simply confirming that the RPC service is running. Useful operational measurements include RPC request success rate, TCP connection failure rate, authentication failure rate, packet retransmissions, Active Directory replication latency, incident frequency, and mean time to recovery.

These measurements provide stronger evidence of improvement than service-state checks alone. A Windows service can remain in a running state while a firewall, routing problem, endpoint-registration failure, or security filter prevents applications from completing RPC operations.

How Should Infrastructure Teams Manage Recurring RPC Problems?

Proactive server management reduces recurring RPC incidents by monitoring infrastructure dependencies before users report failures. A managed infrastructure model can combine service monitoring, network checks, security policy validation, patch management, firewall governance, configuration management, and incident response so that a communication dependency does not remain invisible until an application stops working.

A production support team should identify the affected workload and communication direction before changing infrastructure configuration. During an incident, engineers should determine whether one client or multiple clients are affected, validate DNS, test TCP 135, identify the dynamic endpoint where applicable, review firewall and security events, validate the affected service, and restore communication with the smallest safe configuration change.

<strong>Complex RPC incidents should be escalated when DNS and basic TCP connectivity pass but the dynamic endpoint, service registration, authentication, or application operation continues to fail. Active Directory replication, certificate services, DCOM, multi-site firewalls, NAT, VPNs, and restricted RPC configurations can require engineers who understand the complete Windows and network dependency chain.

When Should You Use Managed Windows Server Support?

Outsourced server management can provide continuous infrastructure monitoring and escalation coverage when internal teams cannot maintain 24×7 Windows operations. A mature provider should troubleshoot the actual communication path, maintain firewall and service dependencies, document configuration changes, monitor critical Windows services, and provide escalation from first-line validation to senior infrastructure engineering.

ACTSupport provides managed server administration, monitoring, security hardening, performance management, and infrastructure support across Windows, Linux, and cloud environments. Its managed server offering includes Windows Server support and 24×7 operational coverage for infrastructure that requires ongoing administration and monitoring.

<strong>If RPC failures repeatedly affect production servers, domain controllers, remote administration, hosting infrastructure, or customer-facing applications, ACTSupport can assess the communication path and provide ongoing infrastructure support. The goal is not simply to restart a service after an outage, but to identify the underlying network, security, configuration, or service dependency and prevent the same failure from recurring.

What Is the Fastest Practical RPC Troubleshooting Sequence?

The fastest reliable troubleshooting sequence follows the actual RPC communication architecture from the client toward the server.

1. Verify hostname resolution and confirm the correct server IP.
2. Verify basic network reachability.
3. Test TCP 135 from the client to the server.
4. Identify the RPC dynamic endpoint used by the affected service.
5. Test connectivity to the dynamic endpoint.
6. Review Windows Firewall and upstream firewall rules.
7. Check security software and network filtering devices.
8. Validate RPC and the affected application service.
9. Check DNS, time synchronization, and authentication.
10. Re-test the original application operation.
11. Capture traffic if TCP connectivity remains ambiguous.
12. Document the root cause and permanent firewall/configuration change.

This sequence prevents administrators from jumping directly to service restarts or firewall changes without identifying the failed layer. If TCP 135 fails, investigate the initial path; if TCP 135 works but the dynamic endpoint fails, investigate the second TCP connection; if both connections work, move upward into service registration, authentication, and application behavior.

What Is the Final Takeaway for RPC Troubleshooting?

“RPC server is unavailable” is a communication-path failure, not simply a message that the RPC service has stopped. TCP 135 provides access to the Endpoint Mapper, the Endpoint Mapper identifies the service endpoint, dynamic RPC ports carry the subsequent connection, DNS determines which server the client contacts, firewalls control packet flow, and Windows services register the endpoints that applications ultimately consume.

<strong>The correct fix comes from identifying which stage of that dependency chain failed. Treating RPC as a complete network and service dependency produces faster diagnosis, safer firewall changes, better Active Directory troubleshooting, and fewer recurring Windows infrastructure incidents.

Microsoft RPC References and Documentation

Microsoft Learn provides the primary technical references for Windows RPC troubleshooting, dynamic RPC allocation, Active Directory error 1722, and Windows Server network-port requirements. These references are particularly useful when designing restricted RPC ranges, troubleshooting firewall behavior, investigating packet captures, or diagnosing Active Directory replication failures.