Error 0x000006BA: the RPC server is unavailable when adding a printer

Fix it now

0x000006BA is Windows error 1722, RPC_S_SERVER_UNAVAILABLE: the RPC server is unavailable. Adding a shared printer is a remote procedure call to a spooler, and this is that call getting no answer. Either the Print Spooler is stopped or crashing at one end, or the RPC path between the two machines is blocked.

net stop spooler
net start spooler
Get-Service Spooler | Select-Object Status,StartType
Test-NetConnection printsrv -Port 135
Test-NetConnection printsrv -Port 445

1. If either port test returns False, the fault is the path rather than the spooler. On the server, enable the inbound rules in the File and Printer Sharing group in Windows Defender Firewall with Advanced Security.
2. Check which profile the server’s adapter is on with Get-NetConnectionProfile. A rule enabled for Domain does nothing if the adapter has been classified as Public, and a server landing on Public after a reboot produces this error on its own.
3. If the spooler will not stay running, clear the queue folder with the service stopped, then start it and watch for a few seconds.
4. Retry the connection using the server’s fully qualified name: rundll32 printui.dll,PrintUIEntry /in /n "\\printsrv.example.local\queuename".

A disabled spooler on the client blocks the install too, and it is easy to miss while you are concentrating on the server. Check both.

If the queue adds and prints, you are done. If it does not, the next section covers what the wizard is actually doing and where the call is being lost.

Why it happens

Adding a shared printer is not a file copy. The client calls into the remote spooler to enumerate queues, read driver information and open a printer handle, and those calls travel as remote procedure calls. The client first contacts the endpoint mapper on TCP 135 to ask which port the spooler interface is listening on, then connects to the port it is given. Depending on configuration the same traffic can instead run over an SMB named pipe on TCP 445.

That gives the failure three distinct places to happen: the local spooler, the remote spooler, and the network path carrying the call. The Print Spooler service depends on the RPC subsystem, so if RPC is unhealthy on either machine the spooler will not start at all, and every printing operation fails at once rather than degrading gradually.

The companion codes each name a stage. 0x000006D9 is EPT_S_NOT_REGISTERED, published as there being no more endpoints available from the endpoint mapper – in practice, you asked for an interface and the mapper had nothing to hand out, which is what a stopped spooler on the target looks like from the client. 0x800706B9 carries Win32 1721, RPC_S_OUT_OF_RESOURCES, not enough resources available to complete the operation. 0x00000BBA is ERROR_SPOOL_FILE_NOT_FOUND, the spool file was not found, which turns up when the spooler restarts underneath a job that is already in flight.

Full reference

Reading the four codes as published

0x000006D9 is worth reading carefully, because its published wording is about the mapper rather than about the spooler. It tells you the endpoint mapper answered and had nothing for the interface you asked about. A stopped spooler on the target is the common reason, but so is a spooler that is running and has not registered, which is why the next step after seeing it is to check the service on the far machine rather than to reach for the firewall.

Commands worth knowing

Get-Printer -ComputerName is the most useful line here, because it exercises the same path the Add Printer wizard uses and gives you a clean error instead of a dialog. If it returns the queue list, the RPC path is fine and your problem is further along. If it fails the same way, you have reproduced the fault in a form you can test repeatedly.

Where the network profile catches people out

Windows applies firewall rules per profile, and a server that comes back from a reboot before its domain controller is reachable can classify its adapter as Public. Every rule you enabled for Domain then does nothing, printing stops for everyone, and nothing in the printing stack looks wrong. Get-NetConnectionProfile answers it in one line, and it is worth checking before any deeper investigation on a server that has recently restarted.

When both spoolers are healthy and the ports are open

• Try the fully qualified name rather than the short name. A short name that resolves to the wrong machine fails exactly like a blocked port.
• Check for a second print server answering for the same name, usually a leftover DNS record.
• Confirm the client is not being served by a stale cached credential for that server, which produces a refusal rather than a timeout.
• Look at whether an endpoint security product is filtering RPC locally on either machine; its logs will name what it dropped.
• Test from a machine on the same subnet as the server. A path that works from the server itself tells you nothing about the client’s route.

Every code this article covers

Confirm the fix worked

1. Run Get-Printer -ComputerName printsrv from the client and confirm the queue list comes back without an error.
2. Add the printer and print a test page end to end.
3. Confirm the spooler is still running on both machines several minutes later, not stopped again.
4. Confirm Get-NetConnectionProfile on the server shows the profile whose firewall rules you enabled.
5. Reboot the client once and confirm the printer connection returns at logon without being re-added.

Questions people ask about this