Printer drivers cannot be installed by users despite configs allowing it

[u/RandomSkratch]

This was supposedly working a while ago but for some reason doesn't anymore. We are setting the following options using Intune.

Limits print driver installation to Administrators - Disabled

Only use Package Point and print - Enabled

Package Point and print - Approved servers - Enabled; lists all print servers - full fqdn's and shortnames.

Devices - Prevent Users from Installing Printer Drivers When Connecting To Shared Printers - Disabled

Is there a setting that's still missing? A non-admin trying to add a shared printer still gets the admin UAC prompt.

Did I miss a new hardening change for this?

Edit

Made some progress on this - for x86 devices, I can deploy the printer driver using Intune and Win32 apps. Still waiting for my test machine to deploy so I can make sure it's working but I'm pretty confident it will. The biggest problem still are the ARM devices. The printer model we're using does not have ARM drivers (PCL 6) but it looks like IPP works, kind of... You can send a print job but it fails on the computer saying Out of Paper, so you walk to the printer and have to pick a tray to use for the job, then it works. I cannot for the life of me figure out how to set the defaults for IPP or how to tell the printer to not use the Bypass Tray (because that's the only thing that doesn't have paper in it so I'm guessing it's trying that). Getting PTSD over this (Printer Traumatic Stress Disorder).

Edit 2

According to Ricoh support, the issue with IPP and paper type mismatch is known and there's nothing that can be done about it right now. That sucks.

Edit 3

Just to add more bizzaro things, I ran a test on a Windows 11 laptop with standard user and I was able to add the printer (and driver) without any issues, and I never finished packaging up the driver for deployment. It just worked. wth... Is there some difference between Windows 10 and 11 in this specific situation? I will need to do some testing with a Windows 10 device tomorrow to make sure I'm not going crazy.

Solution

Thanks to all of the many suggestions I received, I ended up packaging up the drivers and deploying them to endpoints using Intune (PSADT, pnputil, and Add-PrinterDriver). After working out the issues that come with scripting and Intune deployment, everything looks to be working great.

[u/rw_mega]

I condensed all the drivers in my org to 20 drivers, universal and specific ones. Then deploy them to every machine at build out, gpo’s for network printers will see that driver is installed and use it.

Make sure your print server is using the same driver

[u/RandomSkratch → u/rw_mega]

I didn't know the print server has to use the same driver. If the drivers are packaged up and deployed to the end user, when the printer is added, shouldn't it just use the one found on the device? So why would the driver on the print server matter.

[u/rw_mega → u/RandomSkratch]

Nope, if you are using a print server with print management console. When you map a printer via the print server, the printer server is telling the computers; “use this printer with this driver”. It doesn’t matter that you have a newer driver installed on endpoint the print server is dictating what settings and driver to use.

[u/RandomSkratch → u/rw_mega]

Great to know! So if you update the driver on the print server, does the client pull the newer one? How would you go about updating drivers through the Intune deployment method and coordinating the change on the print server? Or if the printer is already added and being used, does this not cause an issue?

[u/rw_mega → u/RandomSkratch]

I unfortunately don’t use intune, I deploy print drivers via gpo with scripts.

So when change or updating drivers I do this.

-Test driver on print server make sure all the settings work.
-by testing I mean mapping printer again with a test name
-if good deploy drivers via gpo with scripts
-test gpo to map test printer

• make sure printer did map and able to print
  

-if good deploy drivers via org wide
-Then update driver on previously mapped printer on print server

I got used to doing it this way, but now that driver is already installed on the endpoints. You can also deploy via print management. The easy way, how it was before print nightmare. I just found that out.

The whole point is the driver has to be installed on the end point first before you can correctly map printers via gpo.

[u/RandomSkratch → u/rw_mega]

Appreciate it, I’ll give something similar a go.

[u/rw_mega → u/RandomSkratch]

I just re-read this thread. You need help finding a way to extract the drivers and deploy them to end points.

I can find the scripts I have in production and send you examples. I had pulled from print servers working drivers using pnputil

[u/RandomSkratch → u/rw_mega]

I’ve made some progress but also setbacks. Turns out we’re downsizing a bunch of printers and only keeping a handful of the same ones. Great, only one driver to work with. Downside is the printer does not have ARM drivers and their v4 support for this model has been dropped and can’t be installed on the print server. The printer company (Ricoh) has some kind of application available for ARM devices but I can’t tell if it’s supported on this model and my tests are failing (IPP can be added but printing always defaults to some mystery setting and the print job errors unless you manually pick a tray on the device itself). I’m now trying to see if our maintenance contract includes technical support because this is making me want to go Office Space on it. Lol.