Windows cannot connect to the printer: error 0x0000011B and 0x00000709

Fix it now

Windows will not complete the connection to the shared queue. Microsoft publishes no meaning for 0x0000011B – it is not even a defined Windows error number – so work the companions instead: 0x00000709 is an invalid printer name and 0x00000BCB says the driver is not on this machine and would have to be downloaded.

Get-Printer -ComputerName printsrv | Select-Object Name,ShareName,Shared
net stop spooler
net start spooler
rundll32 printui.dll,PrintUIEntry /in /n "\\printsrv\ShareName"

1. Connect with the ShareName exactly as it comes back, including case and spaces. A wrong or renamed share is what 0x00000709 is telling you and it is quicker to rule out than anything else here.
2. Bring both machines to the same current update level and reboot both. Most of these are one end patched and the other not, and patching both settles it without any further change.
3. Try the same connection from an elevated session. If it succeeds as an administrator and fails as a standard user, the block is driver installation rather than the connection, and the driver is the thing to fix.
4. Pre-stage the driver on the client with your deployment tool or pnputil /add-driver, so nothing has to be installed at connection time.
5. As an interim measure that avoids the shared queue entirely, add the printer on a standard TCP/IP port with the driver installed locally.

The registry workaround circulated for this code lowers the authentication level the print RPC call requires. Microsoft publishes neither the value nor the code’s meaning on Learn or its support site, so it is not a documented fix and it is not in this article.

If the standard user who reported it can now add the queue and print, you are done. If not, the next section covers what the connection actually involves and which half of it is failing.

Why it happens

Connecting to a shared printer is two operations that look like one. First the client makes a remote procedure call to the print server to enumerate the queue and open a handle to it. Then, in most cases, it obtains a driver for that queue and installs it locally. Both halves were tightened after the run of print spooler vulnerabilities, and a failure in either produces a dialog that says Windows cannot connect to the printer.

0x0000011B is worth being blunt about. Decimal 283 is not a defined Windows error number – it is absent from Microsoft’s own system error code list – and no Microsoft page publishes a meaning for it. What is published are its companions, and they are more useful than the headline. 0x00000709 is ERROR_INVALID_PRINTER_NAME, the printer name is invalid. 0x00000BCB is ERROR_PRINTER_DRIVER_DOWNLOAD_NEEDED, the driver was not found on the system and needs to be downloaded. 0x0000006E is ERROR_OPEN_FAILED, the system cannot open the device or file specified. 0x000003EB is ERROR_CAN_NOT_COMPLETE, cannot complete this function.

Read those four and the shape of the problem appears without needing a definition for the first. Either the name you gave does not exist on that server, or the driver half cannot complete, or the call itself was refused. Those are three different repairs, and the way to tell them apart is to change one variable at a time: the same queue from an administrator, the same queue from a second client, a direct port instead of the share.

Full reference

What each number here is published as

That first row is the reason this article is structured the way it is. A page that tells you confidently what 0x0000011B means is telling you something Microsoft has not published, and the advice built on it – usually a registry value – is aimed at a cause nobody has documented. The companions are documented, so work those.

On the registry workaround

There is a registry value widely circulated for this code that reduces the authentication level the print RPC call requires. It is worth knowing it exists, because you will meet machines that have it, and worth knowing what it does: it takes the client and server back to accepting a call that the update made them refuse. Microsoft does not document it on Learn or its support site, which means nobody is committing to what it protects or when it will stop working.

• If you find it set on machines you inherited, record where, and plan to remove it once both ends are patched.
• Do not roll it out as a fix. It weakens every print connection that machine makes, not the one you are trying to repair.
• Prefer the routes that leave the security posture alone: patch both ends, pre-stage drivers, deploy connections by policy, or connect to the device directly.
• If you must use it to keep an office printing for a day, put a date on removing it and tell somebody other than yourself.

Which half of the connection is failing

Deploying the connection instead of asking users to make it

The durable answer in a managed estate is that users do not add printers at all. The connection is deployed with the driver already staged, so nothing is fetched at connection time and the whole class of failure disappears. Microsoft documents printer settings under Group Policy, including the Point and Print settings, at Computer Configuration, then Policies, Administrative Templates, Control Panel, Printers – which is where Package Point and print – Approved servers lives, and it is the setting worth having whether or not you are chasing this error today.

Before you conclude the server is at fault

1. Confirm the exact ShareName from the server rather than from anybody’s memory.
2. Confirm both machines are at the same current patch level, and reboot them if you are not sure the last update finished.
3. Test the same queue from a second client on the same subnet. Two clients failing differently is a client-side story.
4. Remove the stored connection from the user’s profile and let it be recreated, so you are not testing a cached failure.
5. Test a direct TCP/IP port to the device. If that prints, everything you are chasing is between the two computers and the printer is not involved.

Clearing the spooler’s queue folder with the service running can corrupt the queue for every user on a shared print server. Stop the service, clear it, start the service, and warn anyone with a job waiting that they will need to send it again.

Every code this article covers

Confirm the fix worked

1. Have the standard user who reported the fault add the printer on their own machine and print a test page.
2. Run Get-Printer on that client and confirm the queue is listed with the driver you expected.
3. Confirm the connection survives a reboot rather than needing to be added again.
4. Check the print server’s event log for further refusals after the change.
5. Confirm any registry workaround you found or set has been removed once both ends are patched.

Questions people ask about this