Skip to main content
Microsoftintermediate

Fix 0x0000011b: Windows Cannot Connect to the Printer

Fix error 0x0000011b when connecting to a shared printer. Caused by the CVE-2021-1678 print RPC hardening — patch the print server properly instead of using the registry workaround that weakens print security.

9 min readUpdated August 2026

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:

PhaseDateBehaviour
Initial deployment12 January 2021Fix present but off by default; admins could opt in via registry
Enforcement14 September 2021Enforced 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.

  1. 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
  1. Reboot the server.
  2. Restart the spooler if you did not reboot:
net stop spooler
net start spooler
  1. 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.

  1. Find the printer's IP address from its control panel or a printed configuration page.
  2. In Settings → Bluetooth & devices → Printers & scanners, choose Add device → Add manually.
  3. Select Add a printer using an IP address or hostname.
  4. Device type TCP/IP Device, and enter the printer's IP address.
  5. 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.

Advertisement

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 RpcAuthnLevelPrivacyEnabled to 0 disables the increased authentication level for the printer RPC interface. Microsoft documents 0 as 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

  1. Remove any failed printer entries from Printers & scanners, then add the shared printer again.
  2. Confirm it connects without an error dialog.
  3. Print a test page.
  4. 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.

Frequently Asked Questions

Find answers to common questions

It comes from the security hardening Microsoft shipped for CVE-2021-1678, a Windows Print Spooler spoofing vulnerability. The update raised the RPC authentication level required for the printer IRemoteWinspool interface. When the client enforces the higher level but the print server does not support it, the connection is refused with 0x0000011b.

No. Setting it to 0 disables the increased authentication level, and Microsoft states plainly that this is not recommended and that devices with it disabled are not protected. It works, which is why it circulates widely, but it reintroduces the vulnerability the update was written to close. Treat it as a temporary measure only.

Bring the print server and every client fully up to date on Windows updates so both ends support the higher authentication level. Once the server is patched, the mismatch that produces 0x0000011b disappears and no registry change is needed.

If you use it at all, it belongs on the client, since the client is the side enforcing the authentication level. Applying it to every workstation to accommodate one unpatched server is a poor trade — fixing the server is one change instead of hundreds.

The fix shipped in two phases. Updates from January 12, 2021 included it in deployment mode, off by default. From September 14, 2021 it moved to enforcement, applying automatically without a registry setting. Environments with unpatched print servers began failing at that point.

It usually stops the error and it is a bad idea. Removing a security update to fix a compatibility problem leaves the endpoint exposed to that vulnerability and to everything else fixed in the same cumulative update, and the update will reinstall.

Print servers built into routers, NAS appliances and older print boxes often do not implement the higher authentication level at all. Check for firmware updates. If none exist, connect the printer directly over TCP/IP from each client instead of through the appliance's share.

Add it as a local printer using a Standard TCP/IP port pointed at the printer's own IP address. This bypasses the print server share and the RPC path entirely, so 0x0000011b cannot occur. You lose centralised queue management, but it is a clean workaround that weakens nothing.

Set RpcAuthnLevelPrivacyEnabled back to 1 in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print and restart the print spooler. Record every machine you changed at the time you change it, or you will not find them all later.