Troubleshoot domain controller replication error 1727-The remote procedure call failed and did not execute
This article provides a resolution to solve the error message The remote procedure call failed and did not execute that occurs during domain controller (DC) replication on Windows Server.
Original product version: Windows 10, version 2004, Windows 10, version 1909, Windows Server 2019, Windows Server 2012 R2, Windows Server 2016
Original KB number: 4019721
This Active Directory (AD) replication error appears in one or more of the following forms:
- Decimal: 1727
- Hex: 0x6bf
- Symbolic: RPC_S_CALL_FAILED_DNE
- Error message: The remote procedure call failed and did not execute.
This problem occurs because of one of the following reasons:
- A network connectivity issue between the two domain controllers (DCs). See the following sections for details.
- A load-induced performance issue on the replication partner. This issue is less common and is often transient in nature. See the following sections for details.
About the network connectivity issue
This problem occurs when the DC's replication partner cannot complete the RPC connection to AD Replication's RPC Service (DRSR UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2). More specifically, the replication partner can bind to the RPC endpoint mapper but cannot complete the DRSR RPC bind.
Be aware that firewalls, routers, WAN optimizers, other intermediate network devices and network filter drivers could be the root causes of this problem.
About the performance issue
This problem occurs when one of the following conditions is true:
- The server is backlogged and doesn't respond to the TCP ACK or the response message. Therefore, the sender abandons the TCP session.
- The network is too slow or unreliable to be able to deliver the TCP ACK or the response message.
To resolve this problem, determine any recent changes that would affect the network between the two DCs and undo those changes if possible. If there are no recent changes, you must fully examine the RPC network connectivity between the two DCs. To do this, follow either the high-level troubleshooting steps or the detailed troubleshooting steps.
High-level troubleshooting steps
Take a double-sided network capture while you reproduce the problem. To do this, follow these steps:
- Start a network capture on both DCs.
- Manually initiate replication between the two DCs.
- Stop both sides of the trace when you receive the error.
Examine the RPC conversation between the two DCs, and determine whether there is ever a case in which the message that is sent from the requestor DC doesn't incur a response from the replication partner.
Occasionally, there is a partial response that includes the piggy-back TCP ACK for the request message. But the traffic has been modified or the response doesn't actually arrive at the requester DC. Therefore, the TCP stack doesn't receive an ACK.
Detailed troubleshooting steps
Start a network capture on both DCs before you take the following steps to test DC connectivity.
Test the source DC connectivity from the destination DC
Follow these steps on the destination DC:
Verify whether the source DC is listening on TCP port 135. To do this, run the
PortQry.exe -n -e 135command.
If the port status is FILTERED, the AD replication failure is likely to fail and return error 1722, instead. Try resolving error 1722, and then check whether the AD replication succeeds. If the problem persists, restart the detailed troubleshooting steps.
If the status is not FILTERED, the commands return the RPC endpoint mapper database. Search for MS NT Directory DRS Interface to find the upper-range port in the endpoint mapper database that the source DC is listening on for AD replication. You may get one or more entries. Make a note of the ports for ncacn_ip_tcp.
For example, you get something that resembles the following, which presents two upper-range ports 49159 and 49160:
UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface ncacn_ip_tcp:2012dc UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface ncacn_ip_tcp:2012dc
The upper-range ports are DC specific and are dynamically assigned. However, an administrator can hard-code the port that is used for AD replication by using the following registry value.
Registry value: TCP/IP Port
Value type: REG_DWORD
Value data: (available port)
Test TCP port connectivity to the upper-range ports that you note. To do this, run the following command:
PortQry.exe -n <SourceDC> -e <Upper_Range_Port_Number>
For example, you run the following commands:
PortQry.exe -n 2012dc -e 49159 PortQry.exe -n 2012dc -e 49160
If port status is FILTERED, review the network trace that you've captured to determine where the packet is blocked.
Test DNS. Verify that the destination DC can resolve the CNAME and HOST records of the source DC, and that the resolved IP address is the actual IP address of the source DC. If DNS points to an old or invalid IP address, then RPC connection attempt is made to an incorrect source DC.
Test the destination DC connectivity from the source DC
Repeat step 1 through 3 on the source DC.