Dungas1337

It is strange i havent read anybody talking about certificates. Some printer (setup) installs selfsigned certificates and more and more lately to remediate the printer nightmare their customers facing. Monitor added certificates in Trusted Publishers folder e.g. If this is true, export it and deploy those certs to your endpoints before installing the core drivers.

I do not know what guys are doing different. I followed Microsoft practices for configuring security settings. Then, i connected to all available printers published on printerserver which will then download neccessary drivers, of course with local admin. Then use builtin export drivers powershell function to a folder. Removed all non-printerdrivers. Then use this exported folder to deploy once with SCCM for example to all devices. Now when that is all done, users can connect to any printershare without admin. So long as client has same driver as printerservers (assuming you do not update printerdriver on the serverside to another version of course) all will work flawelessly. Now when a new printerdriver is published, repeat steps above and only published the delta to endpoints and you are good to go.

If correct drivers are in driverstore users can connect to remote printer using Point-and-Print (also with Point-and-print restrictions set to Enabled) and not being prompted with admin credential.

Our solution is to deploy all printerdrivers to endpoints in advanced. Printerservers and workstations are all up-to-date and security best practices regarding to Printernightmare in place like registry to only allow administrators to install drivers our users can choose their own network printer which are published in ActiveDirectory. No admin credential prompts for regular users. Printers are deployed using PnPUtil which is available in Windows 10 by default.