Printers do not deploy to Win10

Question

We deploy a lot of Printers via Group Policy. These are all targeting the Computer side and NOT using Group Policy Preferences. Lately we are randomly seeing the Printer Connections not being made. Our legacy Windows 7 machines (didn't and the remaining ones still don't have the problem). All Win10 machines will install some printers, and not others.

Event Viewer:
Group Policy was unable to add per computer connection \PrintServer\Printer. Error code 0xBCB. This can occur if the name of the printer connection is incorrect, or if the print spooler cannot contact the print server.

Source: PrintService
Event ID: 513
OpCode: Spooler Operation Failed

Fundamentally, I've figured out that the problem is that the print driver(s) are not being pushed/pulled from the print server. Permissions? Firewall? AV?

They are the latest drivers on the server. They are package aware v3 drivers. A non-privileged user has the problem. An network administrator gets the printer installed. A manual "Add Printer" will fail because the driver is missing. If the printer driver is installed on the client machine and then logs in, a manual "Add Printer" will succeed. Immediately after login, I get a LoadLibrary failed with error 87 message. I'm doing this testing using RDP, which in the past has caused a LoadLibrary 87 error too. Point and Print restrictions are Enabled with printer servers defined. Restarting

Any ideas?

Answer 1

Hello @David Young ,

Thank you for your question

There are many reasons that deploying a printer via Group Policy would fail. One common problem is due to the Point and Print Restrictions policy not being configured correctly. This will commonly result in users not being able to download drivers from print servers. This setting can be configured under Computer Configuration > Policies > Administrative Templates > Printers. This should be configured in one of two ways:

Disable the policy. This is the easiest and fastest method, but doesn’t allow for granular control over which print servers can be connected to.
Enable the policy. You will need to modify the following settings at a minimum:
Set “When installing drivers for a new connection” to “Do not show warning or elevation prompt”
Set “When updating drivers for an existing connection” to “Do not show warning or elevation prompt”
Unless you want to restrict these settings to a particular set of print servers, uncheck “Users can only point and print to these servers” and “Users can only point and print to machines in their forest”
Another reason printers might not be deployed properly is if the linked OU does not match the policy type. If you are deploying a printer using User Group Policy Preferences, the linked OU should contain users that need to have the printer installed. If you are deploying a printer using Computer Group Policy Preferences, the linked OU should instead contain computers that need to have the printer installed. Linking a User GPP to an OU that only contains computers, or vice versa, will have no effect. When deploying a printer to an OS that is a different architecture than the print server (such as 32-bit Windows 7 connecting to a 64-bit Windows Server 2008 R2 print server), make sure the correct drivers are installed on the print server. Both the 32-bit and 64-bit drivers must have the exact same name for them to associate properly. Deploying a printer will fail if the appropriate driver for the printer can’t be found.

If the reply was helpful,please don't forget to upvote or accept as answer.

Thanks,

Aradhya C

Answer 2

After some more head banging, this is what I've figured out.

1. Using printer management console, I "pre-loaded" the printer drivers to the destination client. I know this is a problem so I just side-stepped this issue for now.
2. Symantec End Point (v14) is getting in the way. I don't know how or why yet. I have to disable SEP AV to get a printer to install, even when the driver is local.
3. I have 2 DCs. If the workstation has LOGONSERVER to the one DC, the printer will NOT install. If I force the end workstation to use the other DC, the printer will install.

I must remind you that it's not a GPO policy definition or configuration problem. I have MANY printers that are installing just fine. It's just two specific printers (one is an Enterpise HP LaserJet, and the other is a Kyocera MFP). The copiers and other printers ARE installing without these shenanigans. Something is fundamentally getting blocked or broken for these printers. I think in both cases they are "Universal Printer" drivers, not model specific ones. They are NOT using "winprint" for the print processor, but rather custom specific ones.