Connecting to a shared printer fails with:
Windows cannot connect to the printer.
Operation failed with error 0x0000011b
Unlike most printer errors, this one has a precise, documented cause — and the fix that circulates most widely on forums is one that weakens the security of your print environment.
Why This Happens
0x0000011b is a direct consequence of Microsoft's fix for CVE-2021-1678, a Windows Print Spooler spoofing vulnerability. The update raised the RPC authentication level required for the printer IRemoteWinspool interface, so that communication with network printers and print servers is encrypted rather than trivially spoofable.
Microsoft shipped this in two phases:
| Phase | Date | Behaviour |
|---|---|---|
| Initial deployment | 12 January 2021 | Fix present but off by default; admins could opt in via registry |
| Enforcement | 14 September 2021 | Enforced automatically, no registry setting required |
Once enforcement arrived, a patched client began demanding the higher authentication level. If the print server does not support it — because it is unpatched, or because it is a NAS, router or appliance that never implemented it — the negotiation fails and the client reports 0x0000011b.
So the error is a mismatch: a hardened client talking to a server that has not been hardened. The client is behaving correctly.
Fix 1: Patch the Print Server (The Correct Fix)
Because the mismatch is the problem, closing it on the server side fixes the error without weakening anything.
- On the print server, install all pending Windows updates:
# Check the current build
winver
# Check update history
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10
- Reboot the server.
- Restart the spooler if you did not reboot:
net stop spooler
net start spooler
- Retry the connection from a client.
Then patch the clients too, so both ends are current. This is one change on one machine instead of a registry edit on every workstation, and it leaves the vulnerability closed.
If the server is fully patched and clients still fail, confirm the server's spooler is genuinely running the patched binaries — a server that has not rebooted since the update is a common cause of "but it is patched".
Fix 2: Connect Directly Over TCP/IP
If the print server cannot be patched — an appliance, a NAS, an unsupported OS — connect clients straight to the printer instead. This bypasses the print server share and the RPC path entirely, so the error cannot occur, and it weakens nothing.
- Find the printer's IP address from its control panel or a printed configuration page.
- In Settings → Bluetooth & devices → Printers & scanners, choose Add device → Add manually.
- Select Add a printer using an IP address or hostname.
- Device type TCP/IP Device, and enter the printer's IP address.
- Supply the manufacturer's driver when prompted.
The trade-off is losing centralised queue management and server-side driver distribution. For a small number of clients that is usually an acceptable exchange for a clean fix.
Give the printer a static address or DHCP reservation first, or the direct connection breaks the next time the lease changes.
Fix 3: The Registry Workaround — Understand What It Costs
This is the fix you will find everywhere. It works, and it reduces your security.
What it does: setting
RpcAuthnLevelPrivacyEnabledto0disables the increased authentication level for the printer RPC interface. Microsoft documents0as not recommended, and states that devices with it disabled are not protected. You are reopening CVE-2021-1678 on that machine.
If you have a genuine, time-boxed need — a business-critical printer, a server patch scheduled for next week — apply it on the client, since the client is the side enforcing the level:
Registry path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print
Value name: RpcAuthnLevelPrivacyEnabled
Type: REG_DWORD
Data: 0
From an administrative Command Prompt:
reg add "HKLM\System\CurrentControlSet\Control\Print" /v RpcAuthnLevelPrivacyEnabled /t REG_DWORD /d 0 /f
net stop spooler
net start spooler
Conditions for doing this responsibly:
- Record every machine you change, with a date and a ticket reference. Undocumented registry changes survive for years.
- Set a review date, and actually revert on it.
- Do not push it fleet-wide by Group Policy as a convenience. That converts a single unpatched server into an organisation-wide exposure.
- Revert as soon as the server is patched:
reg add "HKLM\System\CurrentControlSet\Control\Print" /v RpcAuthnLevelPrivacyEnabled /t REG_DWORD /d 1 /f
net stop spooler
net start spooler
Do not uninstall the Windows update instead. That removes every other fix in the same cumulative update, and Windows will reinstall it.
Verify the Fix
- Remove any failed printer entries from Printers & scanners, then add the shared printer again.
- Confirm it connects without an error dialog.
- Print a test page.
- If you patched the server, confirm no registry workaround is still in place on the clients:
reg query "HKLM\System\CurrentControlSet\Control\Print" /v RpcAuthnLevelPrivacyEnabled
A result of 0x1, or the value being absent, means enforcement is active and you are protected. A result of 0x0 means that machine is still exposed and should be reverted.
To audit this across a fleet:
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Print" -Name RpcAuthnLevelPrivacyEnabled -ErrorAction SilentlyContinue |
Select-Object PSComputerName, RpcAuthnLevelPrivacyEnabled
Prevention
- Patch print servers on the same cadence as clients. This error only exists because the two drifted apart.
- Reboot after spooler-related updates. A patched-but-not-rebooted server behaves like an unpatched one.
- Retire appliance print servers that cannot implement current authentication levels. They will keep blocking security hardening indefinitely.
- Audit for the registry workaround periodically. Emergency changes made under pressure are exactly the ones that get forgotten.
- Prefer direct TCP/IP or Universal Print where centralised queue management is not required — see setting up Microsoft Universal Print.