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

Hey,

I looked up the 740 error
C:\>winerror 740
740 ERROR_ELEVATION_REQUIRED

The user will need to have administrative rights to connect to this share.

Answer 2

These are not answers - so this is still an ongoing issue. We have the same problem.
Things were working well with our GPO policies under v4 print drivers, and before the 'Print Nightmare' patch.
Due to some software issues we had to back-grade the v3 drivers using the same GPO names. We just replaced the printers deployed in our existing GPO's. We deploy printers by Computer as they must exist in particular locations to utilize particular printers. We place computers in OU's and the apply the policies accordingly.

On to the things we have learned.....and not learned.

Many of our computers have just been updated with Windows Updates for the past year or two. Most all computers are new since 2019 and some are very recently imaged with 21H2 Windows 10 Pro. Primary DC is 2016. All other DC's are 2012 R2 - fully patched.

We have been having problems as described in this thread, where the GPO is applied, but the printer doesn't install. We can install manually, too, but that isn't the point.
We've been fighting this since November when we first updated large groups of computers with the Summer 2021 patch for "Print Nightmare."

Yesterday, 6/6/2022, we were deploying a computer, the policies were not installing the 4 printer drivers as necessary and we were determined to work with this until it killed us.
One of the techs tried installing just one of these printers by using the IP address (not the correct way to use a print queue server). But the prompt came up to elevate the installation, he clicked YES, --- not only did that printer install -- but ALL the other 4 printers installed and appeared on the Windows 10 workstation.

Ok, fine, that proves that the problem IS an Elevation issue - but it does not resolve why the GPO refuses to elevate the installation.
The Local Administrators group - contains the user - and also contains their departmental security group - which the user also belongs.

More testing today - but I don't think we are any closer to a real solution. I wish someone at Microsoft would chime in.

Answer 3

Hi. I have the same problem. But there is other way to do it. I recently start to support client who have this kind of problem. I have never use deploey printers before that way. There is another way how to do it and apply the gpo to computer not to user.

1. Create a GPO
2. Edit GPO and under Computer Configurations - Preferences - Control Panel - Printers
3. Add printers from directory if is shown (you can enable printer to be seen in directory) or you can set IP manually. And the beauty is another step...
4. In the window switch to "common" and check "Item-level targeting" and choose " New-item" and then "Security- Group" and choose your group which is full of computers which you want to apply this gpo at.

Works perfect and it is just the same but different path. NO need to apply to users you can still do that with computers.

Martin

Answer 4

Hi,

That's interesting that search in AD UI results in the successful addition of the connection.

I'm hope you noticed the difference in the print server name when the client system builds out the printer name.

When using the AD UI, you get the FQDN of the server name.

Are you using Print Management Console to add the printers to your GPO or the Group policy management tool?

If already using Group policy Management, have you tried setting up the connection using FQDN rather than the short name?

My second question is regarding the error returned when attempting the connection addition. Is this 0x740? If you are seeing 0xnnn errors please provide the error codes.

Thanks

Answer 5

GCSCreditUnionIT-5517 - Thank you for your post. I've just taken over a new client's existing network, and have also run into this exact same error that you are having, only difference is that the print server here is a fully patched Server 2016 Standard, instead of 2019. Client machines are fully patched Windows 10 Pro. I haven't tried your workaround of deploying via GPO to USERS instead of COMPUTERS, will give that a shot as a workaround, but we also would prefer to be able to deploy via COMPUTERS due to roaming users across multiple locations.