Error 0x6BA during domain join: RPC and the endpoint mapper are blocked

Fix it now

0x6BA is Windows error 1722, RPC_S_SERVER_UNAVAILABLE, “The RPC server is unavailable”. The client found a domain controller, so DNS worked, and then could not open the remote procedure call conversation the join runs over. Credentials are never evaluated, which is why nothing tells you whether the password was right.

Test-NetConnection dc01.corp.example.com -Port 135
Test-NetConnection dc01.corp.example.com -Port 445
Test-NetConnection dc01.corp.example.com -Port 389
portqry -n dc01.corp.example.com -e 135

1. If 135 does not answer, the endpoint mapper is filtered or the domain controller is unreachable. Stop there and take it to the network team.
2. If 135 answers and the join still fails, the RPC dynamic range is the usual reason. Microsoft documents the default range on Windows Server 2008 and later as 49152 to 65535, and that whole range has to be reachable from the client subnet.
3. On the domain controller, confirm it is serving: dcdiag /test:Advertising. Microsoft notes this fails if Netlogon has stopped.
4. Retry with Add-Computer -DomainName corp.example.com -Credential (Get-Credential) -Restart, and if it fails again read C:\Windows\debug\NetSetup.LOG, which names the operation rather than just the code.

Microsoft’s own note on the advertising test is worth knowing: with TCP and UDP 88 blocked, the test still passes even though the domain controller cannot answer Kerberos requests. A pass is not proof the path is clear.

If the join completes, you are done. If not, the next section explains what a join needs beyond port 389 and which of the four codes you have.

Why it happens

A domain join is not one conversation but several. The client locates a domain controller over DNS, binds to LDAP to read the naming information, then does the real work over remote procedure calls: creating or claiming the computer object and setting its password. Those calls travel either over named pipes on SMB or directly over TCP, and the TCP path begins by asking the endpoint mapper on port 135 which port a given interface is listening on.

That second port is allocated dynamically. Microsoft documents the default dynamic range on Windows Server 2008 and later as 49152 to 65535. A firewall configured with the obvious ports – 88, 135, 389 and 445 – but not that range gets the client as far as the endpoint mapper and no further. It is the commonest reason for 1722 on networks where somebody has already opened what they believe are the Active Directory ports.

Microsoft’s dedicated page for 1722 is blunt about what it means: a lower-layer protocol reported a connectivity failure, and the common case is that the abstract TCP connect operation failed. The causes it lists are link-local failure, DHCP failure, DNS failure, WINS failure, routing failure including blocked ports on firewalls, IPSec or network authentication failure, resource limitations, and the higher-layer protocol not running. Every one of those is a network or service condition. None of them is a credential.

The neighbouring codes say what answered. 1753, EPT_S_NOT_REGISTERED, is published as “There are no more endpoints available from the endpoint mapper”: something answered on 135 and had nothing to offer, which points at a service that is not running or a domain controller that has not finished promoting. 1723 is the server reporting it is too busy. 1460 is a plain timeout, and on a wide area link that usually means packets are being dropped silently rather than actively refused.

Full reference

What the four codes mean

The port set, from Microsoft’s own table

Microsoft’s own diagnostic sequence for 1722

1. Check name resolution first: dcdiag /test:DNS /v /e /f:<filename.log> and nltest /dsgetdc:<domain>.
2. Prove the endpoint mapper is reachable: portqry -n <server> -e 135.
3. Prove the allocated port is reachable. Microsoft’s older guidance queried 1024-5000; on current Windows Server the equivalent question is about 49152 to 65535.
4. Check replication and directory health with repadmin /replsummary, repadmin /showrepl and dcdiag.
5. Only then start changing firewall configuration, because a change made before the sequence is a guess.

Narrowing the dynamic range without breaking something else

Apply the same range to every domain controller and restart them, because a client that reaches one DC on a permitted port and another on a blocked one produces failures that look random. Leave room: the range serves every RPC service on the server, not only the directory, and the symptoms of running out are not obviously related to the change that caused them.

When the join has to happen and the path will not open

Offline provisioning exists for this exact case. The computer account is created in advance from a machine that does have the path, the resulting provisioning data is carried to the client, and the client completes the join without ever contacting a domain controller. It is the supported answer for a segmented build network, and it removes both DNS and RPC from the problem rather than working around them.

Reading the join log

C:\Windows\debug\NetSetup.LOG records each step of a join with its status. It is the difference between knowing that the join failed with 1722 and knowing which call failed with 1722, and it costs nothing to read. If the log shows the failure at the point of creating or renaming the computer object rather than at the locator stage, you are looking at RPC and not at DNS, which is what this article is about.

Every code this article covers

Confirm the fix worked

1. Test-NetConnection <dc> -Port 135 returns true from the client’s own subnet.
2. A test to a port inside the dynamic range on the same domain controller also succeeds.
3. The join completes and the computer object appears in the organisational unit you targeted.
4. dcdiag /test:Advertising passes on the domain controller the client used.
5. gpupdate /force on the newly joined machine completes without errors.

Questions people ask about this