Printing Issues "Driver Update Needed"

[CHiLL]

I've read through this thread and I don't think I'm any the wiser on how to resolve this.

 

From what I've gathered, the only sure way we know to get around this is to disable Point and Print and set "RestrictDriverInstallationToAdministrators" to 0 - which ? Or purchase an alternative printer deployment method, such as Papercut via an additional license?

Edited August 25, 2021 by CHiLL

[SpaceInvader83]

I think in summary, deploy the print drivers using whatever method you prefer separately - whether that be SCCM, PDQ Deploy, build into you imaging process etc. Then deploy printers as normal.

[tdk1069]

I've yet to find a way to get it to work reliably, Having had to just change our gpo (Created by a helpful Project Manager with Domain Admin access) They added all 83 printers via IP and not printer share so I'm having to revert as well, and finding most still prompt for drivers even having had the driver installed by the original gpo. With the occasional ones just just won't play the game at all. This has been such a huge time sink when have site mergers and new domain to set up

[JordanT91]

I think in summary, deploy the print drivers using whatever method you prefer separately - whether that be SCCM, PDQ Deploy, build into you imaging process etc. Then deploy printers as normal.

I've done that. I've deployed the drivers with pnputil via SCCM, but the printers mapped via GPO aren't appearing for users. No idea what's going on...

[Jaan]

No word of another fix from Microsoft yet?

 

This is a good read about the whole situation https://www.mdmandgpanswers.com/blogs/view-blog/the-ultimate-guide-to-printnightmare-and-overcoming-it

[smarties11]

I've read through this thread and I don't think I'm any the wiser on how to resolve this.

 

From what I've gathered, the only sure way we know to get around this is to disable Point and Print and set "RestrictDriverInstallationToAdministrators" to 0 - which ? Or purchase an alternative printer deployment method, such as Papercut via an additional license?

 

The summary so far is, in order of best security....

 

1. Get Type4 printer drivers for all your printers - these are user mode drivers and will work without any further changes after the August update. The reality is that this isn't possible for most. Even the HP Universal driver isn't available in Type4

2. Deploy print drivers to the machine via your preferred method. If the print driver is already on the machine, you won't be prompted to download it

3. Set the 'RestrictDriverInstallationToAdministrators' reg key to 0 AND set the 2 point and print policy GPOs to only allow your printer server (these are at Computer Config | Admin Templates | Printers - 'Point and Print Restrictions' and 'Package Point and print - Approved servers')

 

In our environment I have opted for 3, because we already set those GPO settings to specify our printer server - so adding the reg key then doesn't leave us completely exposed, as all print servers except the one specified will still ask for elevation - plus this buys me a bit of time too - once things are quieter in September I will probably move to deploying out the drivers and then ultimately hopefully printer manufacturers will get their arses into gear and release Type 4 drivers.

[tdk1069]

We are using option 3 at the moment as I just don't have any more time to devote to currently.

 

We had all the printers installed (via machine policy, but direct to the printer IP not via the print server) All I did was move them to user & point them via the print server so PaperCut would track it and still got prompts for installing drivers so not sure why it ignores the drivers from the first GPO... But... Project for later on now..

[3s-gtech]

We already used the P&P restrictions from years back, so just deployed the reg key at present. It's a bodge, but that'll nestle in nicely with the other bodges. Spooler disabled on all servers at least.

[StephenPink]

In the end I decided to over-engineer it slightly; basically option 3, however the reg key is set to 0 via a powershell scheduled task at login, then reset to 1 30 minutes later. Slightly less risky bodge maybe?

Did try option 2, but even with drivers installed, couldn't get the printers to map!

[3s-gtech]

That's a cunning little idea. It's a bit like the film Independence Day - a disguised object can get through a gap in the defences only through a very specific window. Much less Goldblum though, sadly.

[Jaan]

do these changes not make you vulnerable to the original exploit?

[3s-gtech]

Yes, but it's about managing that risk if it can't be removed entirely. Considering the implications of the spate of ransomware attacks recently, it's the approach we have to apply to all systems - ideally make them watertight, but if that's not possible then only allow water through in a controlled manner...

[CHiLL]

The summary so far is, in order of best security....

 

1. Get Type4 printer drivers for all your printers - these are user mode drivers and will work without any further changes after the August update. The reality is that this isn't possible for most. Even the HP Universal driver isn't available in Type4

2. Deploy print drivers to the machine via your preferred method. If the print driver is already on the machine, you won't be prompted to download it

3. Set the 'RestrictDriverInstallationToAdministrators' reg key to 0 AND set the 2 point and print policy GPOs to only allow your printer server (these are at Computer Config | Admin Templates | Printers - 'Point and Print Restrictions' and 'Package Point and print - Approved servers')

 

In our environment I have opted for 3, because we already set those GPO settings to specify our printer server - so adding the reg key then doesn't leave us completely exposed, as all print servers except the one specified will still ask for elevation - plus this buys me a bit of time too - once things are quieter in September I will probably move to deploying out the drivers and then ultimately hopefully printer manufacturers will get their arses into gear and release Type 4 drivers.

Thanks, I already had Point and Print and the Approved Servers specified, applying that registry key resolved the issue for us.

 

Am I right in thinking that with the server specified via Point and Print, our clients are only vulnerable if the print server itself is compromised, since that's the only server they're told to download drivers from?

Edited August 25, 2021 by CHiLL

[3s-gtech]

Perhaps something spoofing DNS may also do it.

[smarties11]

Thanks, I already had Point and Print and the Approved Servers specified, applying that registry key resolved the issue for us.

 

Am I right in thinking that with the server specified via Point and Print, our clients are only vulnerable if the print server itself is compromised, since that's the only server they're told to download drivers from?

 

This is my understanding, yes. Any server identifying itself as the FQDN(s) you specify in those policies will be considered safe by your clients, anything else will require elevation.

 

Hopefully Microsoft will make things clearer soon. There ought to be a more secure way to implement the above, e.g. by checking the SSL certificate on the print server is signed by your own / a trusted CA or something? But seems Microsoft have gone with the extreme fix on this one!

[Michael]

My honest opinion is I think Microsoft are being somewhat disingenuous whether this issue is truly fixed. Longer term I suspect Type 4 drivers will be the norm, but back on planet earth, the vast majority of corporate/school environments probably will be using Point and Print + Type 3 drivers.

 

In summary, these are the steps I took to evaluate each environment -

 

On your Print Server, load up Print Management, then on the right navigate to More Actions > View > Add/Remove Columns, then add 'Type'. This'll give an overview of drivers in your environment.

 

Highly recommended - add your Print Servers to an allow list servername.fqdn for both User and Computer GPOs, by amending the Point and Print GPO.

 

Add the following GPP regedit -

 

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint

Dword: RestrictDriverInstallationToAdministrators

Value: 0

 

That's all you can do for now!

[DrCheese]

Longer term I suspect Type 4 drivers will be the norm,

 

The cynic in me thinks that MS have done this simple so that end users (eg us) start putting pressure on vendors to make type 4 drivers & focus their efforts there. Too many have just gone "meh" and pushed out type 3 because it's always been the done thing

[gshaw]

My honest opinion is I think Microsoft are being somewhat disingenuous whether this issue is truly fixed. Longer term I suspect Type 4 drivers will be the norm, but back on planet earth, the vast majority of corporate/school environments probably will be using Point and Print + Type 3 drivers.

 

In summary, these are the steps I took to evaluate each environment -

 

On your Print Server, load up Print Management, then on the right navigate to More Actions > View > Add/Remove Columns, then add 'Type'. This'll give an overview of drivers in your environment.

 

Highly recommended - add your Print Servers to an allow list servername.fqdn for both User and Computer GPOs, by amending the Point and Print GPO.

 

Add the following GPP regedit -

 

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint

Dword: RestrictDriverInstallationToAdministrators

Value: 0

 

That's all you can do for now!

 

@Michael are you putting RestrictDriverInstallationToAdministrators in conjunction with either of the original two registry values MS recommended or as a replacement for?

 

My understanding was that if you have the NoWarningNoElevationOnInstall and UpdatePromptSettings configured they override the RestrictDriverInstallationToAdministrators setting?

 

https://support.microsoft.com/en-us/topic/kb5005010-restricting-installation-of-new-printer-drivers-after-applying-the-july-6-2021-updates-31b91c02-05bc-4ada-a7ea-183b129578a7

[sjatkn]

I was following the advice of others, using the pnputil to add a driver to the driver store and Add-PrinterDriver on the clients, but was still getting problems. I then realised that the version of the driver on the server and the client were different. The client version was the latest one from the vendors website, where as the server was still on the version that was originally installed. So what I ended up doing was to update the driver on the server as well.

 

So the process I have now is, and I am still in early stages, and need to get it rolled out fully. This is based on Server 2012R2 and Windows 10 clients.

 

• Download the latest driver and expand it so you get to the driver files.
  
• On the printer server.
  
• Print Management. Select a printer model, right click and Properties > Advanced > New Driver.... Use Have Disk and install it from the now expanded driver download.
  
• In PowerShell you now need to use Add-PrinterDriver as just adding the driver does not seem to complete the job. Add-PrinterDriver "Driver name from INF file" -verbose
  
• On the clients
  
• Distribute the driver using your favourite method. Use pnputil to add the driver to the store and Add-PrinterDriver to make sure Windows knows about it. Some drivers, Konica Minolta and Epson also require a certificate adding to "Trusted Publishers" before they will install. Install the driver manually on a machine, extract the certificate and then use certutil.exe or some other method to add it to the client .
  
• User connections to shared printers using that driver should now work. At least it did for me!
  

Edited August 27, 2021 by sjatkn

[Jaan]

Am i right in thinking that if the drivers for the printers we are using are "type-4" we wouldn't have a issue?

[JordanT91]

I was following the advice of others, using the pnputil to add a driver to the driver store and Add-PrinterDriver on the clients, but was still getting problems. I then realised that the version of the driver on the server and the client were different. The client version was the latest one from the vendors website, where as the server was still on the version that was originally installed. So what I ended up doing was to update the driver on the server as well.

 

So the process I have now is, and I am still in early stages, and need to get it rolled out fully. This is based on Server 2012R2 and Windows 10 clients.

 

• Download the latest driver and expand it so you get to the driver files.
  
• On the printer server.
  
• Print Management. Select a printer model, right click and Properties > Advanced > New Driver.... Use Have Disk and install it from the now expanded driver download.
  
• In PowerShell you now need to use Add-PrinterDriver as just adding the driver does not seem to complete the job. Add-PrinterDriver "Driver name from INF file" -verbose
  
• On the clients
  
• Distribute the driver using your favourite method. Use pnputil to add the driver to the store and Add-PrinterDriver to make sure Windows knows about it. Some drivers, Konica Minolta and Epson also require a certificate adding to "Trusted Publishers" before they will install. Install the driver manually on a machine, extract the certificate and then use certutil.exe or some other method to add it to the client .
  
• User connections to shared printers using that driver should now work. At least it did for me!
  

 

 

Sorry! I discovered this exact caveat a few days ago and I had every intention of posting it here in case somebody hadn't realised. Yes the server drivers have to exactly match the drivers on the PCs.

 

I've seen a few comments online about using pnputil to add the driver to the clients, but a few have missed out the add-printerdriver step. Like you said, the drivers actually have to be installed because pnputil only adds them to the repository.

 

My step by step is now exactly the same as yours and it seems to have worked for me, so hopefully you don't run into any issues!

[DrCheese]

Am i right in thinking that if the drivers for the printers we are using are "type-4" we wouldn't have a issue?

 

Correct. There are some other downsides to type 4 tho, especially if you use Papercut (eg you can't do hardware page or error checking anymore) - Of course, these are outweighed by security issues.

[free780]

I don’t understand why type 4 is a requirement. Maybe it was said earlier on.

 

In terms of driver version drift it shouldn’t happen really.

 

Pnputil adds the driver to the repository and add-printdriver adds it to the spooler.

 

You may have to manually add a print driver via the printer Management mmc to find the correct inf file.

 

Then use GPP or GPO to map the printer.

[Michael]

@Michael are you putting RestrictDriverInstallationToAdministrators in conjunction with either of the original two registry values MS recommended or as a replacement for?

 

My understanding was that if you have the NoWarningNoElevationOnInstall and UpdatePromptSettings configured they override the RestrictDriverInstallationToAdministrators setting?

 

https://support.microsoft.com/en-us/topic/kb5005010-restricting-installation-of-new-printer-drivers-after-applying-the-july-6-2021-updates-31b91c02-05bc-4ada-a7ea-183b129578a7

 

Apologies for the slow reply - I had to digest this as I found it somewhat confusing -

 

July 2021 Advisory

 

 

So in my case (and I expect 99% of admins), the above are false. Those registry keys are controlled by Comp Configuration > Administrative Templates > Printers > Point and Print Restrictions, so need to be left 'as is' if you want to continue using Point and Print.

 

What doesn't make any sense, are that both drop down menus are set to Do not show warning or elevation prompt but read as 1 and 2 and not 0 in the registry -

 

 

August 2021 Advisory

 

This guidance makes more sense:

 

RestrictDriverInstallationToAdministrators

 

Setting the value to 0 allows non-administrators to install signed and unsigned drivers to a print server but does not override the Point and Print Group Policy settings.

 

 

I appreciate this needs to be a managed security risk, but it's unclear whether this needs to remain as 0 each time printers are applied in an end user (non admin) context, or whether this can be set to 1 after a set period of time.

 

By all means if I've understood anything incorrectly, please let me know!

[Michael]

Actually this does make sense -

 

 

The default is either 0 for both entries, or they don't exist at all. As I wrote above, the answer would still be false for the majority of admins.