Printers will not deploy to domain computers via group policy; printers can be installed locally on same computers, but only in a certain way

Question

So here's where we are. We have been running a virtual print server on Server 2012 R2 for years now - it predates my employment here, so I don't know exactly how long. But it's been a while. Recently we tried to run an in-place upgrade on the existing server to get it on Server 2019. This in-place upgrade we could never get to work, it would fail every single time. Rather than continue to fight with an upgrade, we opted to just build an entirely new server in our same virtual environment, just a clean install of Server 2019. We're not a huge organization, so it wasn't ideal, but it was manageable. Building out the server went pretty much flawlessly, we got all our networked printers and drivers added in fairly short order. This is where the fun begins.

As I'm sure many others do, we have group policies in place to deploy certain printers on domain computers based on the OU in which they reside. From the old print server, this worked well for the most part. However, once we began attempting to deploy the printers installed on the new print server, we have been stymied. The printers absolutely will not deploy from the group policy. Neither deploying per computer nor per user will help. We have tried adding completely new group policies to deploy from the new print server, this is no help either. Running the GP Results wizard on computers in OUs affected by this printer group policy show that the policy was applied... but no printers are actually installed.

Printers can be installed to computers in the domain, but only locally, and only with a certain process. The client computer finds the computers on the new print server easily enough. Through the "Printers & scanners" setting, clicking on "Add a printer" brings all the printers down into the list as you'd want and expect. But try to add a printer from there? Oh, no. Windows regretfully says "That didn't work. We can't install this printer right now. Error #740." To actually get a printer installed, you have to get to "The printer I want isn't listed" one way or another. From there, you must choose "Find a printer in the directory, based on location or feature." Again, the user will see a nice big list of printers on our new print server, and doing the install from here installs the printer with no further trouble.

This, to be polite, is not ideal. We are a pretty small organization, but we would really rather not have to spend the time accessing 150-200 computers to manually install printers. I have read countless other posts about GP deployment breaking after MS released a fix for the PrintNightmare exploit and people's attempted solutions, but the other situations I have read aren't described as quite the same as ours. Has anyone else encountered a situation like ours? Is printer deployment via GP just completely broken now, or is there some solution out there that we have yet to try?

Answer 1

Type 4 driver are designed to never install from a print server. That's the way of the world.

Type 3 drivers by default, need admin credentials if you are adding a connetion to a shared printer. For local printers, the standard user can install that driver.

If that driver happens to be the same version as the driver on the server, then a connection can be added. The spooler will not use the driver from the server when the user is not admin.

The problem you will have for connections: once any driver file on the server is updated, your standard user clients will not be able to print. This is by design since they will not be able to download the new software from the server.

The security exploit was fixed, no one can dump a malicious file unauthenticated onto the print server. The malicious file can be added by a malicious print server admin intentionally. No download prevents an exploit on the client.