You're trying to print to a shared printer on another machine and Windows throws ERROR_REMOTE_PRINT_CONNECTIONS_BLOCKED (0X00000790). This usually happens right after a Patch Tuesday, or when someone enabled the Point and Print restrictions, or when a GPO got pushed that tightened the Print Spooler. I've seen it most on Windows 10 21H2 and Server 2019 boxes that were hardened after PrintNightmare. The printer installs fine, you can see it in Devices and Printers, but every job fails with 0x00000790.
What's actually going on
The Print Spooler service has a policy called "Allow Print Spooler to accept client connections." When that's set to Disabled, the spooler stops accepting inbound RPC from remote clients. Local printing still works. Remote printing doesn't. The error code 0X00000790 is Microsoft's way of saying "policy blocked this call before it even hit the print driver." It's not a driver problem, it's not a permissions problem on the share, and reinstalling the printer won't touch it.
Two ways this gets flipped to Disabled. First, someone (or a GPO) explicitly set it. Second, a security baseline — the MS Security Baseline for Windows 10/11 and Server — sets it to Disabled by default. If you applied a baseline, that's your culprit.
The fix
You need local admin on the print server (the machine hosting the shared printer), not the client. Log in there and do this:
- Open the Local Group Policy Editor. Hit
Win+R, typegpedit.msc, Enter. On Home editions you'll need to do the registry path instead — I'll cover that below. - Navigate to the policy. Go to
Computer Configuration > Administrative Templates > Printers. - Find "Allow Print Spooler to accept client connections." Double-click it.
- Set it to Enabled. Yes, Enabled. The policy name is confusing — enabling the policy means the spooler is allowed to accept connections. Disabling it blocks them. This trips up everyone the first time.
- Click Apply, OK.
- Restart the Print Spooler service. Open an elevated command prompt and run:
Don't skip this. The policy is read at service start, not on the fly.net stop spooler && net start spooler - Test from the client. Delete the printer on the client, re-add it via \\servername\printername, print a test page.
If Group Policy isn't your thing — registry path
Same setting, different door. On the print server, open regedit and go to:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\PrintersLook for a DWORD called RegisterSpoolerRemoteRpcEndPoint. If it exists and is set to 2, that's your block. Set it to 1 or delete the value. Restart the spooler afterward.
Values you'll see:
| Value | Meaning |
|---|---|
| 1 | Accept remote RPC connections (default) |
| 2 | Block remote connections — this is your 0X00000790 |
Domain-joined machines
If a domain GPO keeps re-applying the setting, local edits won't stick. Hop on a DC, open Group Policy Management, find the GPO that's setting it (search the settings report for "Print Spooler"), and change it there. Then run gpupdate /force on the print server. Don't bother editing the local policy on a domain box — it'll get stomped at next refresh.
Still failing? Check these
- RPC ports. The spooler uses RPC over TCP. If a firewall between client and server blocks the dynamic RPC port range, you'll get connection failures that look similar. Confirm ports 135 and the RPC dynamic range (49152-65535 on modern Windows) are open.
- "Restrict Print Spooler to accept client connections" GPO. There are two similarly named policies. One is under Printers, the other under Print Spooler. Check both.
- Point and Print restrictions. Separate setting under
Computer Configuration > Administrative Templates > Printers. If it's set to only allow point-and-print to specific servers, the client can't install the driver, and you get a different but related failure. - Spooler crashed. Check Event Viewer under
Applications and Services Logs > Microsoft > Windows > PrintService. A crashing spooler logs event 7031 or 7034 in System. If the service dies every few minutes, that's a bad driver, not the policy. - Client-side cache. Sometimes the client has stale state. Stop the spooler on the client, delete
C:\Windows\System32\spool\PRINTERS\*, restart. Doesn't always help, but it's cheap.
Quick sanity check: from the client, run telnet printserver 135. If it doesn't connect, you've got a network problem, not a spooler problem. Don't chase the policy if the port's closed.
The real fix is almost always step 4 above — flipping "Allow Print Spooler to accept client connections" from Disabled to Enabled. Everything else on this list is a red herring you'll only need if the obvious fix doesn't take. Restart the spooler, retest, and you're done.