Printing Issues "Driver Update Needed"

[gshaw]

Actually this does make sense -

 

[ATTACH=CONFIG]62915[/ATTACH]

 

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.

 

@Michael it's horribly confusing isn't it

 

Soon as we received the guidance the two registry keys were set to 0 so that makes it more "fun"

 

The strange thing is that the machines that are coming up with Driver Update Required actually do have the driver already installed, same version as the server just a different user (mapped via GPP). I presume it's because the object is getting re-mapped and the Spooler somehow thinks it needs to update what's already there. Getting more reports of it today too

[Michael]

@Michael it's horribly confusing isn't it

 

Soon as we received the guidance the two registry keys were set to 0 so that makes it more "fun"

 

The strange thing is that the machines that are coming up with Driver Update Required actually do have the driver already installed, same version as the server just a different user (mapped via GPP). I presume it's because the object is getting re-mapped and the Spooler somehow thinks it needs to update what's already there. Getting more reports of it today too

 

Reassuring it's not just me!

 

As per my registry screenshot here if you leave the registry keys as 1 and 2, rather than both 0, it should work as before.

 

It's this bit in particular which is confusing. My understanding setting these as 0 effectively disables Point and Print. Microsoft's 'solution' appears to be disabling Point and Print resolves the security issues, but that really isn't the solution.

 

Also (on the same reply), specifying allowed servers on the Point and Print GPO, should greatly reduce the surface area of attack. The theory being to successfully run the exploit, you'd either have to spoof the FQDN of your print server, or somehow take over your print server altogether. It just all seems highly unlikely coming from the outside world, but most likely someone on your LAN in terms of probability.

[Michael]

@gshaw - have you resolved this issue now?

[newpersn]

Following this. And getting mixed messages on the fix

 

What are you doing to stop the admin message when the driver needs installing/updating?

 

I've changed driver and I'm getting a error on the print server when a user prints.

[mullet_man]

I've not even had chance to look into this as yet, it's on my radar but trying to get other jobs sorted first, had a busy summer as usual.

 

Will try and give this thread a full read later this week.

[Michael]

The short version:

 

Leave your Point and Print GPO 'as is' like this example, including your servername.fqdn:

 

 

Create the following GPP regedit:

 

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

Value: RestrictDriverInstallationToAdministrators

Dword: 0

 

Registry should look like this on a workstation:

 

[banditelvis721]

i turn the RestrictDriverInstallationToAdministrators registry value to 0, and in about 15-20min it turns itself back to 1 WTH is going on, can i stop this??

please help

perry

[Michael]

i turn the RestrictDriverInstallationToAdministrators registry value to 0, and in about 15-20min it turns itself back to 1 WTH is going on, can i stop this??

please help

perry

 

There must be a conflict of GPP policy or script, as this regedit can't be added as a GPO. Microsoft may add it as a GPO at a later date maybe?

[Chuckster]

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!

 

@StephenPink would you happen to share the PowerShell script?

[StephenPink]

@StephenPink would you happen to share the PowerShell script?

 

Sure no worries - this may not be the best/neatest way to do it but works for us...

 

# Script to unrestrict driver installation - as per August 2021 Windows Update change (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)


# Checks to see if Print Driver installation already unrestricted

If (Test-Path -Path "C:\Windows\InstallFlags\PrintDriversUnrestricted")
   {
       EXIT
   }

# Unrestricts Print Driver installation to allow users to install

$RegistryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint"
$RegistryKeyName = "RestrictDriverInstallationToAdministrators"
$RegistryKeyValue = "0"

New-ItemProperty -Path $RegistryPath -Name $RegistryKeyName -Value $RegistryKeyValue -PropertyType DWORD -Force


# Sets Flag to show that Print Driver installation is unrestricted

New-Item -Path "C:\Windows\InstallFlags\" -Name "PrintDriversUnrestricted" -ItemType Directory

 

and then

 

# Script to restrict driver installation - as per August 2021 Windows Update change (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)


# Checks to see if Print Driver installation already restricted

If (!(Test-Path -Path "C:\Windows\InstallFlags\PrintDriversUnrestricted"))
   {
       EXIT
   }

# Restricts Print Driver installation to administrators only

$RegistryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint"
$RegistryKeyName = "RestrictDriverInstallationToAdministrators"
$RegistryKeyValue = "1"

New-ItemProperty -Path $RegistryPath -Name $RegistryKeyName -Value $RegistryKeyValue -PropertyType DWORD -Force


#Removes Flag to show that Print Driver installation is unrestricted

Remove-Item -Path "C:\Windows\InstallFlags\PrintDriversUnrestricted"

 

 

The first one, to unrestrict is deployed via Group Policy scheduled task and the trigger is user logon. The second, to re-restrict is the same but the trigger is delayed by 30 minutes.

However, I'm not 100% sure that background Group Policy refresh isn't causing issues with this... need to investigate more today, because it didn't when testing but now they're back, users are reporting no printers!

 

Cheers,

Stephen

[Michael]

Sure no worries - this may not be the best/neatest way to do it but works for us...

 

# Script to unrestrict driver installation - as per August 2021 Windows Update change (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)


# Checks to see if Print Driver installation already unrestricted

If (Test-Path -Path "C:\Windows\InstallFlags\PrintDriversUnrestricted")
   {
       EXIT
   }

# Unrestricts Print Driver installation to allow users to install

$RegistryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint"
$RegistryKeyName = "RestrictDriverInstallationToAdministrators"
$RegistryKeyValue = "0"

New-ItemProperty -Path $RegistryPath -Name $RegistryKeyName -Value $RegistryKeyValue -PropertyType DWORD -Force


# Sets Flag to show that Print Driver installation is unrestricted

New-Item -Path "C:\Windows\InstallFlags\" -Name "PrintDriversUnrestricted" -ItemType Directory

 

and then

 

# Script to restrict driver installation - as per August 2021 Windows Update change (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)


# Checks to see if Print Driver installation already restricted

If (!(Test-Path -Path "C:\Windows\InstallFlags\PrintDriversUnrestricted"))
   {
       EXIT
   }

# Restricts Print Driver installation to administrators only

$RegistryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint"
$RegistryKeyName = "RestrictDriverInstallationToAdministrators"
$RegistryKeyValue = "1"

New-ItemProperty -Path $RegistryPath -Name $RegistryKeyName -Value $RegistryKeyValue -PropertyType DWORD -Force


#Removes Flag to show that Print Driver installation is unrestricted

Remove-Item -Path "C:\Windows\InstallFlags\PrintDriversUnrestricted"

 

 

The first one, to unrestrict is deployed via Group Policy scheduled task and the trigger is user logon. The second, to re-restrict is the same but the trigger is delayed by 30 minutes.

However, I'm not 100% sure that background Group Policy refresh isn't causing issues with this... need to investigate more today, because it didn't when testing but now they're back, users are reporting no printers!

 

Cheers,

Stephen

 

This is why I haven't taken this approach. As you say, when Group Policy refreshes, then logically it'll see the user isn't a Domain Admin or Local Admin (whichever applies) and then removes access to the print share. GPP or script changes are generally pretty quick on modern versions of Windows.

 

As I say, I think Microsoft's approach is - disable Point and Print, then you're secure, offering no real alternative on how to deploy printers. This isn't a solution in my view. It's like saying disable the print spooler on every workstation, then you're secure. The whole printer model/spooler service needs re-writing.

[gshaw]

Even with the registry keys and forcing drivers through I'm still getting UAC prompts. There seems to be a really weird combination of factors that decide if you get the prompt or not:

 

- has the machine ever seen that driver before i.e. is it in the local machine's Print Management Server properties

- is the printer in the user's profile already

- if there's multiple printers with similar drivers is one of them a lower version than what's already installed (Konica particularly I'm affected by on this)

 

Between Microsoft's shonky attempts to fix and manufacturers being slow on the uptake with suitable drivers it's being a real drain on resources

[Jaan]

I can see the manufacturers being forced to write type 4 drivers. The likes of papercut might also need to implement changes so the type 4 limitations are removed as much as possible.

[Michael]

Just to confirm I'm testing on the following, but should apply to any Windows 10 flavour -

 

Build Windows 1607 LTSB & Windows Server 2016 + August 2021 Patch, or build 14393.4583

 

Using Ricoh PCL6 Universal Driver, Type 3

 

- Signing in as user with Domain Admin rights = no issues or prompts related to printers

 

- Signing in as user with Standard rights = no issues or prompts related to printers

 

I should add I have Point and Print GPOs configured in both Computer and User contexts

 

 

 

And the GPP regedit added in a Computer context.

Edited September 2, 2021 by Michael

[mullet_man]

The short version:

 

Leave your Point and Print GPO 'as is' like this example, including your servername.fqdn:

 

[ATTACH=CONFIG]62942[/ATTACH]

 

Create the following GPP regedit:

 

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

Value: RestrictDriverInstallationToAdministrators

Dword: 0

 

Registry should look like this on a workstation:

 

[ATTACH=CONFIG]62943[/ATTACH]

 

Thank you Michael that's working for me now, really appreciate that.

 

Cheers.

[free780]

I really wouldn’t compromise security given the APT of ransomware. A malicious driver can gain SYSTEM level rights.

 

The RestrictDriverInstallationToAdministrators should not exist or set to 1 so that the default prevents installation of drivers by non administrators.

[mikkydoos]

As I say, I think Microsoft's approach is - disable Point and Print, then you're secure, offering no real alternative on how to deploy printers. This isn't a solution in my view. It's like saying disable the print spooler on every workstation, then you're secure. The whole printer model/spooler service needs re-writing.

 

 

Has any actually managed to do a printer deployment via GPO per user?

 

 

My reg tweak is working for existing printer installations... but new machines... not pulling the shared printer or driver through unless I manually add them... then it will install without prompt.

 

 

This is on a Papercut virtual print queue.

Point and print is disabled.

Reg tweak is present.

 

 

 

 

?????????

[gshaw]

I can't get Type 3 drivers to install without a UAC prompt, reg key allowed or not.

 

Type 4 are fine as expected but not available for our Konica MFDs at present

 

As it stands it's a constant stream of printer mapping tickets coming in, depending on which particular combination of printers in the user's profile and drivers on the machine it's either a manual mapping required or Update Driver and elevate manually with admin credentials. Printnightmare by name and by nature.

[4HeadDev]

I made an account specifically to comment on this thread as we're having this same issue at my workplace too -- We have dozens of schools we support with this problem.

 

Currently, the only thing that works for me is printers that use Type 4 drivers. The registry key 'fix' has been tested in a somewhat isolated environment on a few of the effected schools and I have 50/50 results, however I'm reluctant to use this fix regardless due to security issues. Disabling point and print also has mixed results. Also for those who use PapercutMF, the only fix that seems to work is using Type 4 drivers... But I can't 100% confirm this as only a very small pool of our schools use PapercutMF and are having this problem.

 

The issue is incredibly frustrating, so if anyone does happen to come across a more secure fix then please let me know. Other than that... I'll just hope that Microsoft will come up with an official fix soon.

[alanmorris]

Hi,

 

The latest fix from MS should be it but I no longer work at Microsoft. Basically, prior to early August, a standard user could install a print driver copied from a print server. Now Microsoft has made the change to prevent this by default. To go back to allowing a standard user rights to install the print driver that you added to the print server, a registry setting will need to added to the client system as is discussed previously. This setting allows what has been the default ability for the past 20 years just so you know.

 

The Do you trust dialog is here to stay as well but with the registry setting, a standard user will click through this and be able to install the print driver that you have control of on your print server.

 

When the registry setting has not been added, a prompt to install the driver occurs and administrative user name and password is required.

 

That's the new normal now in Windows.

 

Local printers will not be impacted.

 

As Microsoft states, you can configure the domain policy to only allow the client systems to connect to shared printers only on your server names so you should be doing this as well if you allow the install of the Type 3 drivers from the print server.

 

Type 4 drivers will work since they are NEVER copied down from the print server, the Windows client will use a preinstalled driver.

 

For PaperCut, that's where I am now, we can analyze page counts with Type 4 drivers. For print job redirection, the print drivers on all the target printers will need to change to Type 4. Don't mix the streams, don't mix Type 3 and Type 4.

 

If you have any Mac systems connecting to the shared Windows printers with Type 4 drivers, this will result in Windows deleting the jobs since the datatype is not supported. Windows does not dislike Macs, but the Macs will not submit the spool file in a format supported by Windows.

 

If you would like to move away from Windows to Windows traditional printing due to this issue, PaperCut Mobility Print is here for you.

[Michael]

Has any actually managed to do a printer deployment via GPO per user?

 

 

My reg tweak is working for existing printer installations... but new machines... not pulling the shared printer or driver through unless I manually add them... then it will install without prompt.

 

 

This is on a Papercut virtual print queue.

Point and print is disabled.

Reg tweak is present.

 

 

 

 

?????????

 

Yes - Point and Print Computer/User GPOs have to remain enabled, with GPP regedit.

[gshaw]

Hi,

 

The latest fix from MS should be it but I no longer work at Microsoft. Basically, prior to early August, a standard user could install a print driver copied from a print server. Now Microsoft has made the change to prevent this by default. To go back to allowing a standard user rights to install the print driver that you added to the print server, a registry setting will need to added to the client system as is discussed previously. This setting allows what has been the default ability for the past 20 years just so you know.

 

The Do you trust dialog is here to stay as well but with the registry setting, a standard user will click through this and be able to install the print driver that you have control of on your print server.

 

When the registry setting has not been added, a prompt to install the driver occurs and administrative user name and password is required.

 

That's the new normal now in Windows.

 

Local printers will not be impacted.

 

As Microsoft states, you can configure the domain policy to only allow the client systems to connect to shared printers only on your server names so you should be doing this as well if you allow the install of the Type 3 drivers from the print server.

 

Type 4 drivers will work since they are NEVER copied down from the print server, the Windows client will use a preinstalled driver.

 

For PaperCut, that's where I am now, we can analyze page counts with Type 4 drivers. For print job redirection, the print drivers on all the target printers will need to change to Type 4. Don't mix the streams, don't mix Type 3 and Type 4.

 

If you have any Mac systems connecting to the shared Windows printers with Type 4 drivers, this will result in Windows deleting the jobs since the datatype is not supported. Windows does not dislike Macs, but the Macs will not submit the spool file in a format supported by Windows.

 

If you would like to move away from Windows to Windows traditional printing due to this issue, PaperCut Mobility Print is here for you.

 

@alanmorris thanks for this, thus far the clearest explanation of where we're at and where we're going

 

Problem with the "do you trust box" is presumably that means all GPP mappings no longer function?

 

Type 3 drivers - the registry key doesn't seem to have any effect and I still get UAC elevation admin prompt

 

Type 4 drivers - these work but don't seem to be available for everything in our fleet, I'm told Konica ones don't currently work with PaperCut too, which is a problem given that's the majority of our Follow-Me queues

Edited September 6, 2021 by gshaw

[gshaw]

Yes - Point and Print Computer/User GPOs have to remain enabled, with GPP regedit.

 

@Michael what GPOs per User? All the settings I've seen are Computer based or HKLM GPOs, am I missing something obvious here? Are you saying you have managed to get Type 3 drivers on a fresh machine to deploy without UAC prompt?

[mikkydoos]

I've managed to get mine deploying as per @Michael 's settings.

 

Reg tweak deployed via GPP (Computer GPP)

Point and Print server defined without prompt. (User GPO)

 

Didn't work the other day... now its worked on some new laptops I'm setting up.

 

Hhhhmm

 

 

Microsoft just reek. It's become sooo sooo poor.

Edited September 6, 2021 by mikkydoos

[Michael]

@Michael what GPOs per User? All the settings I've seen are Computer based or HKLM GPOs, am I missing something obvious here? Are you saying you have managed to get Type 3 drivers on a fresh machine to deploy without UAC prompt?

 

Yes!

 

Computer Config > Policies > Admin Templates > Printers > Point and Print Restrictions

 

Specify server.fqdn and the drop down menus as follows:

 

 

Create a GPP regedit:

 

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

Value: RestrictDriverInstallationToAdministrators

Dword: 0

 

Registry on a workstation should look like this -

 

 

User Config > Policies > Admin Templates > Control Panel > Printers > Point and Print Restrictions

 

Specify server.fqdn and the drop down menus as follows:

 

 

All working with Type 3 drivers. As I say, Microsoft's solution of disable Point and Print just isn't viable. Specifying your print server's FQDN via GPO is the best you can do to secure connections, but I expect in coming months they'll revise the guidance/recommendations.