Fix Printer Error 0x0000011b on Windows Shared Printers

Error 0x0000011b hits when you try to add or use a shared printer after a Windows security update changed RPC authentication. Here's the real fix, not the workarounds you'll read elsewhere.

You try to add a shared printer on a Windows 10 or 11 machine, click through the wizard, and it dies with "Windows cannot connect to the printer. Operation failed with error 0x0000011b." No print, no queue, nothing. It usually shows up right after a Tuesday patch cycle — KB5005565 and the follow-up PrintNightmare fixes are the usual suspects. Small offices with one shared printer on a Windows box acting as the print server get hit hardest, because everyone's machine updates on different days and suddenly half the staff can't print.

I had a dental office call me about this exact thing last month. Four front-desk machines, one shared HP LaserJet on the back-office PC. Two workstations updated overnight, the other two didn't. Half the office could print insurance forms, half couldn't, and the morning was a mess.

Why 0x0000011b Actually Happens

Microsoft patched a nasty vulnerability called PrintNightmare (CVE-2021-34527) where a low-privileged user could install a malicious print driver and run code as SYSTEM. The patch tightened how the print spooler authenticates remote clients over RPC. The side effect: older or differently-patched clients can't talk to the spooler anymore, because the server now demands a higher RPC authentication level than the client is offering. That mismatch throws 0x0000011b.

It's not a driver problem. It's not a firewall problem, no matter what forum posts tell you. It's an authentication handshake mismatch introduced on purpose by Redmond. Reinstalling the printer won't help. Restarting the spooler might clear it for five minutes and then it comes right back.

The Fix

The real fix is one registry value on the machine acting as the print server. This dials RPC authentication back to the level the old behavior used. Yes, it slightly weakens the PrintNightmare mitigation — but in a small trusted LAN with no exposed print ports, that's an acceptable trade. If you're on a network where random laptops join, stop reading and set up a proper print server with authentication on the client side instead.

Find the print server. That's the PC with the physical printer attached, or the one everyone's connecting through. Not the client machine throwing the error.
Open Registry Editor as admin. Hit Windows key, type regedit, right-click, Run as administrator.

Navigate to the Print key. Go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print

Create the value. Right-click in the right pane, New > DWORD (32-bit) Value. Name it exactly:
```
RpcAuthnLevelPrivacyEnabled
```
Leave the value data as 0.
Restart the Print Spooler service. Open an elevated Command Prompt or PowerShell and run:
```
net stop spooler
net start spooler
```
Or restart the whole server PC. Honestly, on a small office machine, just reboot it.
Test from the client. Go to the problem workstation, remove the broken printer entry in Settings > Devices > Printers & scanners, then re-add it via \\servername\printername in File Explorer. You should connect cleanly.

If you'd rather do it from PowerShell (handy when you're remoting into five machines), it's one line:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Print" -Name "RpcAuthnLevelPrivacyEnabled" -Value 0 -Type DWord

Then Restart-Service Spooler and you're done.

Do this on the print server only. Setting it on client machines does nothing. I've watched people punch this into every workstation on the network before realizing the value lives on the server side.

If It Still Fails

Sometimes the registry fix alone isn't enough, and there are a few specific things to look at:

Check the client patch level. If the client machine is running a build older than the server, you might get 0x0000011b anyway. Get both onto the same Windows build — 19044.1706 or newer for Windows 10, or a current Windows 11 build.
Point-to-Point (P2P) printing is the culprit more often than people admit. If users are connecting with a standard TCP/IP port to a printer physically attached to someone's desktop, that's P2P and it's fragile. Proper fix: install the printer on the server with a local port, share it, and have clients connect to the share, not the IP.
Check the print server's firewall. Port 445 (SMB) and the RPC dynamic range (typically 49152–65535) need to be open on the server for client connections. Windows Firewall handles this via the File and Printer Sharing rules, but third-party AV suites (looking at you, older Bitdefender builds) can silently block RPC.
Look at the Event Viewer on the server. Filter System log for source PrintService or Microsoft-Windows-PrintService/Admin. If you see repeated 0x0000011b entries with timestamps matching client attempts, the auth handshake is still failing — check that the registry value actually got written and that the spooler picked it up after restart.
Windows 11 22H2 and later can be picky. There have been reports that the value needs to be set to 0 on both the server and any Windows 11 client that's also acting as a print relay. Unusual setup, but I've seen it in one home office with a laptop sharing to a desktop sharing to a printer. Yes, that's as dumb as it sounds — flatten that topology.

If you're in a domain environment, don't do the registry trick. Push it out with Group Policy under Computer Configuration > Preferences > Windows Settings > Registry, or better, deploy printers via a proper print server role with Point and Print restrictions configured correctly. The local registry hack is for workgroups and small offices without a domain controller.

One more thing: after you get this working, note that the next cumulative update could undo your work if Microsoft decides to re-enable the strict mode. It happened once in early 2022 when a patch reset RpcAuthnLevelPrivacyEnabled for everyone. Keep the reg file handy.