Win 10 21H2 - Printer deployment issue

[IT_Man_Dan]

Morning all,

 

We have a weird problem affecting 3 rooms on Win 10 21h2.

We have printers set to deploy to users via gpo (have tried gpp or deploying to computer also).

 

When logging in as admin user the printers deploy fine. However when logging in as a non admin user the printers don't deploy.

However, link that gpo to other rooms and the gpo works fine so it can't be a rights issue, surely?

 

Has anyone experienced similar or got any ideas?

 

Many thanks

[Sonic007]

Take a look here. I'm having a similar issue...

 

http://www.edugeek.net/forums/how-do-you-do/229175-new-ad-users-not-picking-up-printers-gpo.html

[Sonic007]

Did you get this sorte din the end?

[IT_Man_Dan]

Sorry for late reply. Had Ofsted in...

No annoyingly not but I feel it's a driver installation permission issue as had a play with papercut deploy and it managed to through up an access denied error when trying to add the printer as a student.

I haven't had a chance to look into it further though yet.

 

Have you had any luck?

[alanmorris]

Hi,

The new default to install the software from the server, you know this as the print driver, requires administrative access on the client system. Microsoft does have a policy if you which to revert this behavior to good old 2020 days.

 

Microsoft documents the policy in this KB. https://support.microsoft.com/en-gb/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872

 

To allow non admins to install the software you would need to disable this policy or set the registry value to 0

[h=2]Set RestrictDriverInstallationToAdministrators using Group Policy[/h]After installing updates released October 12, 2021 or later, you can also set RestrictDriverInstallationToAdministrators using a Group Policy, using the following instructions:

 

1. Open the group policy editor tool and go to Computer Configuration > Administrative Templates > Printers.
    
   
2. Set the Limits print driver installation to Administrators setting to "Enabled". This will set the registry value of RestrictDriverInstallationToAdministrators to 1.
   

[Sonic007]

So if we deploy in computer configuration instead of user, does it still not work?

[alanmorris]

@Sonic007,

 

A connection to a shared printer is only added in a user's security context. For "computer" connections ALL users who log onto a computer should receive the printer as long as they are admins or you configure the policy to allow the software installation by standard users. For "user" printers, the printer will be added for the user no matter what machine they log onto as long as they are admins or you configure the policy to allow the software installation by standard users.

[stottio]

Hi,

The new default to install the software from the server, you know this as the print driver, requires administrative access on the client system. Microsoft does have a policy if you which to revert this behavior to good old 2020 days.

 

Microsoft documents the policy in this KB. https://support.microsoft.com/en-gb/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872

 

To allow non admins to install the software you would need to disable this policy or set the registry value to 0

Set RestrictDriverInstallationToAdministrators using Group Policy

 

After installing updates released October 12, 2021 or later, you can also set RestrictDriverInstallationToAdministrators using a Group Policy, using the following instructions:

 

1. Open the group policy editor tool and go to Computer Configuration > Administrative Templates > Printers.
   
2. Set the Limits print driver installation to Administrators setting to "Enabled". This will set the registry value of RestrictDriverInstallationToAdministrators to 1.
   

 

Superb!!!!! Really stupid of Microsoft as usual, switch off something and give no real alternative. This works brilliant, removed key with PDQ, will turn back on with PDQ after a month of use.

[IT_Man_Dan]

Hmm I'm still having issues with this sadly.

I've tried a number of suggestions above including the reg change (not happy to do this long term) but I'm still getting the same result.

Log in as an admin user and the printer appears fine when applied by GPO - Computer config - Printer connections. however, login as a non admin and no printer appears even when you've logged on as an admin user previously so in theory the driver should have been installed.

 

Any further ideas please?

 

Many thanks

[alanmorris]

Hi IT_Man_Dan,

 

Maybe it's time to use a print driver for the shared printer which does not install from the Print Server is in order. If the print server is 2012 or greater, you can use a Type 4 driver for the share. In this case Microsoft will set up the connection using the basic Microsoft compatibility driver. No dlls are copied from the print server. I expect connections to the shares to work as expected.

 

On the client system, if the driver files on the server are different than those on the client, they can be mismatched even though you added the connection as an admin previously, check on the client in the C:\windows\inf\setupapi.dev.log file. If there is some file that is different on the client, the setupapi.dev.log file should indicate this.

[IT_Man_Dan]

Hi IT_Man_Dan,

 

Maybe it's time to use a print driver for the shared printer which does not install from the Print Server is in order. If the print server is 2012 or greater, you can use a Type 4 driver for the share. In this case Microsoft will set up the connection using the basic Microsoft compatibility driver. No dlls are copied from the print server. I expect connections to the shares to work as expected.

 

On the client system, if the driver files on the server are different than those on the client, they can be mismatched even though you added the connection as an admin previously, check on the client in the C:\windows\inf\setupapi.dev.log file. If there is some file that is different on the client, the setupapi.dev.log file should indicate this.

 

Thanks, This has resolved my issue

[alanmorris]

Super. I'm glad that worked out in your environment.