Windows · Windows Server  ·  high  ·  Windows Update & servicing

0x0000011b — cannot connect to a shared printer after the print security updates

The print security hardening changed how clients authenticate to a print server, and clients that have the update while the server does not are refused.

What you see

Connecting to a shared printer fails with 0x0000011b, or printing to an already-installed shared printer stops working. Started after a Patch Tuesday.

What is actually wrong

KB5005652 enforces RPC over a channel that requires the server to be patched and to have the matching driver isolation. Mixed patch levels between client and print server are the usual state that produces it.

Codes and articles

0x0000011b0x11b0x000007090x0000007c0x00000040KB5005652KB5006670KB5005565

Fixes (2)

Bring the print server and clients to the same patch level
Elevated PowerShell1–2 hourslow riskreversible

The supported fix. Do the server first.

  1. Patch the print server fully and restart it.

  2. Confirm the spooler is running and the shares are published.

    PowerShell
    Get-Service SpoolerGet-Printer | Where-Object Shared | Format-Table Name, ShareName, DriverName -AutoSize
  3. Make sure the drivers on the server are v3 packaged or v4 drivers — unpackaged v3 drivers are refused by the hardened path.

    PowerShell
    Get-PrinterDriver | Format-Table Name, MajorVersion, PrinterEnvironment -AutoSize

    The hardening will not install a driver from the server that is not packaged, and the client-side failure looks identical to the RPC one.

  4. Patch the clients fully and restart.

  5. Remove and re-add the printer connection on one client to test.

    PowerShell
    Remove-Printer -Name '\\PRINTSRV\HP-Reception'Add-Printer -ConnectionName '\\PRINTSRV\HP-Reception'
Confirm it workedA test page prints from a client with no elevation prompt.
PowerShell
Get-Printer -Name '\\PRINTSRV\HP-Reception' | Format-List Name, PrinterStatus
If you need to undo itNone needed — this is the intended configuration.
Disable the RPC hardening as a temporary measure
Elevated PowerShell on the clients15 minuteshigh riskreversible

Only as a stopgap while the server is scheduled. This turns off a security mitigation — put a date on it.

  1. Understand what this does: it reverts the client to the authentication level the vulnerability was patched to prevent. It is a deliberate, temporary reduction in security.

    This registry value is widely posted as 'the fix for 0x11b'. It is not a fix; it is the mitigation being switched off.

  2. Set the value on the affected clients.

    PowerShell
    New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Print' -Name RpcAuthnLevelPrivacyEnabled -Value 0 -PropertyType DWord -Force
  3. Restart the spooler.

    PowerShell
    Restart-Service Spooler
  4. Record which machines you set it on, and schedule the server patch.

Confirm it workedThe printer connects. This is a symptom being suppressed, not a fault being fixed.
If you need to undo itRemove-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Print' -Name RpcAuthnLevelPrivacyEnabled, then restart the spooler. Do this as soon as the server is patched.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.