[22h2] Windows 10 Print Mappings via GPP inconsistent

[MYK-IT]

Hi All,

 

Yes, another "Windows 10 & Print Mappings issue" here...

 

We have been using the GPP method for years (GPO linked to computer / OU with loopback) to connect required printers (and define default). I know it's probably related to the MS Security updates (from last year) but we are experiencing inconsistency of the printers being successfully connected or not.

 

On the whole, it works - but many times when a user goes to print they only have 'Print to PDF' available (aka default Windows printer). And they have to log off/on again which 'usually' resolves the issue. But not always. Perhaps related to if their profile is already cached or not (e.g. logged into computer before) as we do purge via Storage Sense??? But as mentioned, even when it is cached we do have episodes of printers still not connecting.

 

- I know I could revert the MS Update via reg-tweak (Set RestrictDriverInstallationToAdministrators using Group Policy) - but that is not good security practice

- I have seen some posts suggesting to include the printer drivers within the WIM etc - but if users have been able to use the printers successfully on a computer wouldn't that mean the computer has the drivers installed already? Or only within user-context?

- Use PnPUtil?

 

Any suggestions would be appreciated, as is causing disruption - especially when an IT Suite Class come to the end of their lesson and realise they cannot print (and have to log out/in again etc. - and hope it works!)

 

Thanks,

Edited February 9, 2023 by MYK-IT

[t05h]

Are the printers you're adding like \\PrintServer\PrinterName?

 

Try the IP address of the print server instead of the name so: \\IP\PrinterName

Edited February 9, 2023 by t05h

[CHiLL]

This has been a renowned issue since Microsoft made changes to printing back in Windows 8 or 8.1 and made worse by PrintNightmare related patches too.

 

We're using GPP to deploy printers and here's what we've found/do:

 

• The user's first log on to a computer (where it generates a local profile for them) - printers will not map 99% of the time
  
• If the user logs out and back onto the machine, printers will map 99% of the time
  
• We're using the FQDN of the print server in the GPP mappings
  
• We're using Point and Print settings in GP, specifying the print server by FQDN
  
• We also have all the PrintNightmare patches in place, including the bypass to allow non-adminstrators to install drivers (un-does some of the PrintNightmare mitigations - but Point and Print should at least limit drivers being pulled from a specific target)
  
• We have set the GPO "Allow non-administrators to install drivers for these setup classes" to "Enabled" and specified these GUIDs: {0ecef634-6ef0-472a-8085-5ad023ecbccd}, {4658ee7e-f050-11d1-b6bd-00c04fa372a7}, {4d36e979-e325-11ce-bfc1-08002be10318}
  

 

Printing has been an absolute mess for us since about 2015, when we made the transition from Windows 7 to Windows 8.1.

 

We ended up listing the classroom and staff room printers in Active Directory, so those users who don't have a printer can browse the directory for it. Luckily, we use follow-me-printing for staff with restrictions on the printers, so students can't print to it. For office printers, it's less of an issue as office users are less likely to have their profile wiped or we can deal with it on a as and when basis. Any students caught printing to other room's printers (evidenced by Papercut logs) are issued detentions and whatnot.

Edited February 9, 2023 by CHiLL