question

GCSCreditUnionIT-5517 avatar image
1 Vote"
GCSCreditUnionIT-5517 asked BradRosborough-4287 commented

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

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?

windows-server-2019windows-group-policywindows-server-print
· 1
5 |1600 characters needed characters left characters exceeded
Toggle Comment visibility. Current Visibility: Visible to all users

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

GCSCreditUnionIT-5517 avatar image GCSCreditUnionIT-5517 ·

Adding further details for this one...

More experimentation has revealed that we can deploy printers thru GP to USERS just fine, as long as the policy is configured for an OU or security group containing users.

However, this is not what we need. In our organization, we have users who are constantly moving from branch to branch, from machine to machine. What we need is for the user to have printers installed based on WHERE they are (per-machine deployment) and not WHO they are (per-user deployment). Say if a user has been working at Branch A, but needs to move to Branch B for the day, we want the user to get Branch B printers automatically when they log on to a machine at Branch B. Deploying on a per-user basis is mostly useless to us, except for the group of users who seldom change location.

1 Vote 1 ·

3 Answers

DAL-3662 avatar image
0 Votes"
DAL-3662 answered

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.

5 |1600 characters needed characters left characters exceeded
Toggle Comment visibility. Current Visibility: Visible to all users

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

TheAlanMorris avatar image
0 Votes"
TheAlanMorris answered BradRosborough-4287 commented

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.

· 1
5 |1600 characters needed characters left characters exceeded
Toggle Comment visibility. Current Visibility: Visible to all users

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

BradRosborough-4287 avatar image BradRosborough-4287 ·

And when you try installing it from an admin you receive the same error.

I have changed the drivers for the printer that we are having issues with on the print server with no success on the client-side.

So, we can officially remove the administrative rights being the issue.

0 Votes 0 ·
TheAlanMorris avatar image
0 Votes"
TheAlanMorris answered BradRosborough-4287 commented

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

· 2
5 |1600 characters needed characters left characters exceeded
Toggle Comment visibility. Current Visibility: Visible to all users

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

GCSCreditUnionIT-5517 avatar image GCSCreditUnionIT-5517 ·

We have been adding printers to GPOs through Print Management Console with the "Deploy with Group Policy..." function. The deployment "succeeds" in that no errors are thrown during the operation. Running RSOP on a computer within the OU where the GPO is applied indicates that the policy was applied successfully. Yet no printers are actually installed on computers within the OU. Not when the computer is restarted. Not if gpupdate /force is run. Not if a group policy update is pushed from the domain controller. They just don't install.

1 Vote 1 ·
BradRosborough-4287 avatar image BradRosborough-4287 GCSCreditUnionIT-5517 ·

Have you had any success? I am only having issues with one of the printers on my network and it is a Toshiba eStudio -506 while the printers working are Kyocera.

0 Votes 0 ·