When I started this blog, it was all about showing you the options you have when you want to make sure the end user (without admin permissions) can still install printer drivers when needed.
After the whole Nightmare Printer rollercoaster, I am also showing you how to deal with all of the Printer Nightmare update issues, as these updates could break your possibility to print.
I will divide this blog into multiple parts: The first four parts will show you how to ensure your users can install Printer Drivers, and the other parts are all about the Printer Nightmare.
1. Installing Printer Drivers with no admin Permissions
Implementing admin less can be difficult, especially when users are accustomed to installing printers on their own. To alleviate some of the trouble of introducing admin less, you can allow your end-users to install printer drivers on their own.
Of course, Printix or Microsoft Universal Printer are way better solutions when you have some “static” printers. But this solution can be useful for frontline workers who suddenly need to use a printer somewhere.
First, I want to show you how you can do this when having your old-fashioned GPOs. You need to configure 2 options:
The first one you need to configure:
And the second one:
*Class = Printer {4658ee7e-f050-11d1-b6bd-00c04fa372a7}
*Class = PNPPrinters {4d36e979-e325-11ce-bfc1-08002be10318}
The full list of device classes is available:
But when going Cloud Native, you want to configure these settings in Intune. I will give you some options.
2. Administrative Templates
The first one is a Windows 10 Administrative Template. You will need to search for “Allow installation of devices using drivers…” and add the 2 classes, as I showed you with the old-fashioned GPOs.
But I am missing the option to disable: “Prevent users from installing printer drivers”? So the first thing that will come to mind, use group policy analytics! So I did…
As shown above, MDM support is 0%. That’s bad news.
3.PowerShell Script
You could also use a Powershell script to deploy these kinds of settings. Here is the PowerShell Script
$Regpath = "HKLM:\Software\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses"
$RegAllowPath = "HKLM:\Software\Policies\Microsoft\Windows\DriverInstall\Restrictions"
$name1 = "printer"
$value1 = "{4658ee7e-f050-11d1-b6bd-00c04fa372a7}"
$name2 = "PNPprinter"
$value2 ="{4d36e979-e325-11ce-bfc1-08002be10318}"
$name3="AllowUserDeviceClasses"
$value3 = 1
New-ItemProperty -Path $RegPath -Name $name1 -Value $value1 -PropertyType String | Out-Null
New-ItemProperty -Path $RegPath -Name $name2 -Value $value2 -PropertyType String | Out-Null
New-ItemProperty -Path $RegallowPath -Name $name3 -Value $value3 -PropertyType DWord | Out-Null
Or, create an Intunewinapp, as I did with slightly more advanced PowerShell scripts. It contains the IntuneWinapp and a PowerShell script to deploy it to your tenant. (Remember to change the source path.)
https://call4cloud.nl/wp-content/uploads/2020/10/Windows10_AllowPrinterInstallation.zip
Now, when you deploy the intunewinapp, go and install a new printer with a fresh printer driver! As shown below, there is no UAC prompt!
4. Settings Catalog
And there it is… “Prevent users from installing Printer drivers when connecting to shared printers” is now available from the Settings Catalog
Now we have all settings available, let’s also add the: Allow installation of devices using drivers that match these device setup classes:
{4d36e979-e325-11ce-bfc1-08002be10318}
{4658ee7e-f050-11d1-b6bd-00c04fa372a7}
5. Printer Nightmare Updates KB5005010
Of course, everyone now is aware of the Printer Nightmare issue(s). Luckily Microsoft is trying to fix it and has already released a nice update/patch to solve it… Unfortunately, things can break when this update is deployed.
Today (01-09-2021) I received an email about this blog…. as it wasn’t working anymore for him. So let’s take a look at the issue. After installing the Printer Nightmare update you could encounter a nice UAC prompt warning when installing a shared printer. With the update deployed you still need to enter the admin credentials…. even when you have applied the settings, I mentioned earlier.
So how will we fix this and still be safe against the printer nightmare issue? It’s a no-brainer, to do nothing. When you still want to make use of the possibility to let users install drivers on their own please combine Point and Print restrictions and add this wonderful registry key:
RestrictDriverInstallationToAdministrators DWORD 0
If you don’t want to use PowerShell to define this RestrictDriverInstallationToAdministrators registry key, you could also create a new settings catalog and search for Limits Print driver installation to Administrators
When you don’t configure this key or configure it to 1, only users with administrative permissions may install the shared printer. But when you configure this key to zero and combine it with Point and Print restrictions, you can ensure that end-users can only install printers from “allowed and trusted” servers. An error will be shown if an end-user tries to install a printer from a non-trusted server.
So you want to make sure your users can only use point and print to these servers as you could configure with this old-school legacy GPO
Now, you have got 3 possible options to deal with this.
- PowerShell Script
- Creating a new Settings Catalog
- Preinstalling the Printers and Drivers on the devices
1.The PowerShell script.
Let’s start with the PowerShell script. Here is the PowerShell script you could upload to Intune. Remember to change the value of YourPrinterServer to your Print Server.
$keypath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint
$keypath2 = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint"
$keypath3= "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\ListofServers"
$keypath4 = "HKLM:\Software\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses"
$keypath5 = "HKLM:\Software\Policies\Microsoft\Windows\DriverInstall\Restrictions"
New-Item -Path $keyPath -force | Out-Null
New-Item -Path $keyPath2 -force | Out-Null
New-Item -Path $keyPath3 -force | Out-Null
New-Item -Path $keypath5 -force | Out-Null
New-Item -Path $keypath4 -force | Out-Null
new-ItemProperty -Path $keypath -Name RestrictDriverInstallationToAdministrators -Value 0 -force
new-ItemProperty -Path $keypath -Name TrustedServers -Value 1 -force
new-ItemProperty -Path $keypath -Name Restricted -Value 1 -force
new-ItemProperty -Path $keypath -Name NoWarningNoElevationOnInstall -Value 1 -force
new-ItemProperty -Path $keypath -Name TrustedServers -Value 1 -force
new-ItemProperty -Path $keypath -Name UpdatePromptSettings -Value 2 -force
new-itemproperty -path $keyPath -Name Serverlist -type string -value YourPrinterServer -force
new-ItemProperty -Path $keypath2 -Name PackagePointAndPrintServerList -Value 1 -force
new-ItemProperty -Path $keypath3 -Name YourPrinterserver -Value YourPrinterServer -force
$name1 = "printer"
$value1 = "{4658ee7e-f050-11d1-b6bd-00c04fa372a7}"
$name2 = "PNPprinter"
$value2 ="{4d36e979-e325-11ce-bfc1-08002be10318}"
$name3="AllowUserDeviceClasses"
$value3 = 1
New-ItemProperty -Path $keypath4 -Name $name3 -Value $value3 -PropertyType Dword | Out-Null
New-ItemProperty -Path $keypath5 -Name $name1 -Value $value1 -PropertyType String | Out-Null
New-ItemProperty -Path $keypath5 -Name $name2 -Value $value2 -PropertyType String | Out-Null
2. Creating a new Settings Catalog
Now, let’s take a look at how to configure the Point and Print restrictions in Intune by creating a new Setting Catalog
You can check out if the values were updated on the client itself by running
Get-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\’
3. Preinstalling the Printers and Drivers on the devices
When looking at the Printer Nightmare CVE, you could also choose to install the printers and the corresponding drivers on the device itself. In this blog below, I am giving you 2 options. One with the PnPutil.exe and one with Printbrm.exe. If you are interested, please read it.
https://call4cloud.nl/2021/07/what-about-printer-drivers
6. Printer NightMare Update KB5005565
And again….. after a new update fixing the Printer Nightmare bugs…. something broke. There is a possibility you will receive the error 0x0000011b when you try to install the printer. I guess when making use of Kerberos you should have no problems but it still needs some explanation.
With this update, Microsoft changed the 1 setting which they warned about in the KB4599464: RpcAuthnLevelPrivacyEnabled
When the CVE-2021-1678 first arrived, Microsoft issued an update to fix this problem “A security bypass vulnerability exists in the way the Printer Remote Procedure Call (RPC) binding handles authentication for the remote Winspool interface”
So they added this key to give you the ability to turn it on yourself: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print\RpcAuthnLevelPrivacyEnabled with the value of zero. As stated they were going to enforce it in September 2021… Guess what happened with the latest September Update… They enforced it by changing the value to 1.
Luckily when you are encountering (yet again) printing issues, you could change this value back to 0 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print\RpcAuthnLevelPrivacyEnabled. Of course, we need to perform this action on the Print Server itself!
It’s way better than removing the whole KB… because it also fixes some stuff apparently 🙂 and it will add a lot of new possibilities to use new ADMX_ Settings with Intune
UPDATE 21-09-2021
If you still have Windows 2012 r2 Printers servers running and the solution above isn’t working for you, try to create the next DWORD: CopyFiles and change the value to 1
RegKey Location: HKEY_LOCAL_MACHINE\SOFTWARE\POLICIES\WINDOWS NT\PRINTERS\
Because the latest Printer Nightmare Update also changed the CopyFiles directive print driver feature, with the update applied the CopyFiles feature is disabled by default.
7. Printer NightMare Update KB5006670
I could say… and again… but this is somehow three in a row :). With the KB5006670 update installed you could end up with a nice new error: 0x00000709.
But this time solving the error is a little bit more difficult as changing the RpcAuthnLevelPrivacyEnabled isn’t working anymore. But what’s left as uninstalling the update should be your last resort.
Luckily you have got 2 options left.
- You could copy the win32spl.dll from a still-working device to the not so working device. But beware of the permissions on that file!
- The CopyFiles method I described in part 6
8. Printers with the V4 Framework
Now that I have shown you all your options, I still need to tell you more about the Printer Nightmare Fix I described above. The registry key RestrictDriverInstallationToAdministrators (DWORD 0) is only needed when you are using older drivers.
When using the V4 Framework drivers, it isn’t necessary to deploy this registry key because of the updated printer-sharing mechanism. This is referred to as enhanced Point and Print, and it allows print clients to print to v4 shares without downloading the manufacturer-provided device driver from the print server.
Option 1:
- If you have Printers that DO support V4 Drivers
- Change the RestrictDriverInstallationToAdministrators to 1
- Change your printer Drivers to V4
-Don’t forget to configure the point and print restrictions… it’s always a good thing to have them
Option 2:
- If you have printers that DON’T support V4 Drivers
- Change the RestrictDriverInstallationToAdministrators to 0 or pre install the drivers
- Make sure you configure the point and print restrictions to only allow installing printers from specific servers
9. Some Tips !
Tip 1. But I do need to point out the fact if a server doesn’t need the printer spooler service….. DISABLE IT! and this definitely goes for your domain controllers! Please make sure you configure a GPO and push this to all of your servers which doesn’t need to have the Printer Spooler Running
Tip 2. If you don’t want to Disable it, please make sure you configure the “allow Print Spooler to accept client connections” to disabled
10. Background Information about Point and Print
Have you ever considered the difference between Package Point and Print and Point and Print?
I guess it needs some explaining on its own, so let’s go.
When using Point and Print, users can connect to the remote printer and download the drivers from the printer server by using the system account (I guess that’s why it is a little bit vulnerable)
The main difference when using or configuring the Package point and print settings instead of the regular Point and print settings is that the Print server you are using is using package-aware drivers. Again, I need to explain what package-aware drivers are.
Package aware drivers ensure that all of the package’s driver’s components are configured for Point and Print operation. You can check it out by opening the registry and taking a look at the PrinterDriverAttributes (it is also an unsupported method to make your Driver package aware)
The printer Package contains a catalog file (.CAT) that provides authentication when it’s copied to the client.
Conclusion:
As I said before, you need to implement adminless! Almost none of your users need local admin permissions. Allowing users to install their own printers will create a small security breach in your fence but with Point and Print restrictions applied you could limit the Printer Nightmare Impact. Allowing it in this way you could minimize the risks while greatly improving user freedom within their device.
If you want boys to respect you, show them you’re serious, Install Drivers, Print Something.
You have got 3 options to implement this: A PowerShell script or the new nice setting catalog!
It seems support for “Prevent users from installing printer drivers” is now in the Settingscatalogue (Previes)
Thanx….Yes, it is indeed. I updated my blog
Hi,
when I assign this policy, allow installation of …, to users or devices, the result is always Not Applicable. I use the right device ID classes. What is your experience?
Hi,
I just created the settings catalog in a test tenant to check out whats happening and if I am experiencing the same thing
WHen I am configuring them with the settings catalog, it seems to work?
Hello Rudy,
Could it be that since the fix for PrintNightmare this is not working anymore?
We now do have some users that are getting a trust message when installing a printer driver from a print server and have to login with admin credentials to install the driver.
Hi.. that could be very much true.. You will need to define the PointAndPrint servers.. as I am on vacation now… its difficult for me to test the outcome… Could you try it out?
$keypath = “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint”
$keypath2 = “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint”
$keypath2 = “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint\Listofservers”
New-Item -Path $keyPath -force | Out-Null
New-Item -Path $keyPath2 -force | Out-Null
New-Item -Path $keyPath3 -force | Out-Null
new-ItemProperty -Path $keypath -Name Trustedservers -Value 1 -force
new-ItemProperty -Path $keypath -Name NoWarningNoElevationOnInstall -Value 1 -force
new-itemproperty -path $keypath2 -name PackagePointAndPrintServerList -value 1 -force
new-itemproperty -path $keyPath3 -NAME “PrintServer1” -type string -value “printerserver.hosting.local” -force
new-itemproperty -path $keypath2 -name PackagePointAndPrintOnly -value 1 -force
Some of my printers are refering as “Print Queues” which can be seen in Device Manager with Class PrintQueue and Class Guid {1ed2bbf9-11f0-4084-b21f-ad83a8e6dcdc}. When I add this class GUID to script it successfully adds it in registry. But still can’t install those printers as non-admin user. Any hint?
Hi, to be sure, did you also read the part about the nightmare update?
Hi,
Yes , I tried to set this for users after your blog update. So I included all necessary changes eg. RestrictDriverInstallationToAdministrators DWORD 0
I just don’t know why this printers that are detected in Device Manager as “Print queues” instead of “Printers” won’t install as they are detected with different GUID. And in MS list of available GUIDs I either didn’t found this class for PrintQueue. What seems to me that all my MFP printers are detected as Print Queues in Device Manager on print server.
How to be 100% sure.(its hard as I cant test it) this isn’t working?
$Regpath = “HKLM:\Software\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses”
$RegAllowPath = “HKLM:\Software\Policies\Microsoft\Windows\DriverInstall\Restrictions”
$name1 = “printer”
$value1 = “{4658ee7e-f050-11d1-b6bd-00c04fa372a7}”
$name2 = “PNPprinter”
$value2 =”{4d36e979-e325-11ce-bfc1-08002be10318}”
$name3=”AllowUserDeviceClasses”
$value3 = 1
$name4 = “LocalPrintQueue”
$value4 = “{1ed2bbf9-11f0-4084-b21f-ad83a8e6dcdc}”
New-ItemProperty -Path $RegPath -Name $name1 -Value $value1 -PropertyType String | Out-Null
New-ItemProperty -Path $RegPath -Name $name2 -Value $value2 -PropertyType String | Out-Null
New-ItemProperty -Path $RegallowPath -Name $name3 -Value $value3 -PropertyType DWord | Out-Null
New-ItemProperty -Path $RegallowPath -Name $name4 -Value $value4 -PropertyType DWord | Out-Null
Yeah, meanwhile I found my mistake. Facepalm.. I was using right GUID for LocalPrintQueue but I was using “YourPrintServer” wrong. I added now FQDN of print server and everything is working.
This is full tested script,
$keypath = “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint”
$keypath2 = “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint”
$keypath3= “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\ListofServers”
$keypath4 = “HKLM:\Software\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses”
$keypath5 = “HKLM:\Software\Policies\Microsoft\Windows\DriverInstall\Restrictions”
New-Item -Path $keyPath -force | Out-Null
New-Item -Path $keyPath2 -force | Out-Null
New-Item -Path $keyPath3 -force | Out-Null
New-Item -Path $keypath5 -force | Out-Null
New-Item -Path $keypath4 -force | Out-Null
new-ItemProperty -Path $keypath -Name RestrictDriverInstallationToAdministrators -Value 0 -force
new-ItemProperty -Path $keypath -Name TrustedServers -Value 1 -force
new-ItemProperty -Path $keypath -Name Restricted -Value 1 -force
new-ItemProperty -Path $keypath -Name NoWarningNoElevationOnInstall -Value 1 -force
new-ItemProperty -Path $keypath -Name TrustedServers -Value 1 -force
new-ItemProperty -Path $keypath -Name UpdatePromptSettings -Value 2 -force
new-itemproperty -path $keyPath -Name Serverlist -type string -value PrintServerFQDN -force
new-ItemProperty -Path $keypath2 -Name PackagePointAndPrintServerList -Value 1 -force
new-ItemProperty -Path $keypath3 -Name PrintServerFQDN -Value PrintServerFQDN -force
$name1 = “printer”
$value1 = “{4658ee7e-f050-11d1-b6bd-00c04fa372a7}”
$name2 = “PNPprinter”
$value2 =”{4d36e979-e325-11ce-bfc1-08002be10318}”
$name3=”AllowUserDeviceClasses”
$value3 = 1
$name4 = “LocalPrintQueue”
$value4 = “{1ed2bbf9-11f0-4084-b21f-ad83a8e6dcdc}”
New-ItemProperty -Path $keypath4 -Name $name3 -Value $value3 -PropertyType Dword | Out-Null
New-ItemProperty -Path $keypath5 -Name $name1 -Value $value1 -PropertyType String | Out-Null
New-ItemProperty -Path $keypath5 -Name $name2 -Value $value2 -PropertyType String | Out-Null
New-ItemProperty -Path $keypath5 -Name $name4 -Value $value4 -PropertyType String | Out-Null
Thanks Rudy!
Haha.. Nice to hear… Thanx for your replying back
If the Name of your printer server is a CNAME in DNS, make sure you add the resolved name as well in the allow list. We have a few printer servers, most of them have A records setup, but one of them was created as a CNAME (not sure why)…I was not able to map to that printer until I added the other name. Of course the event logs made no hint of this being the issue 🙂
Thanks for another great write up.