Printing Issues "Driver Update Needed"

[Koldov]

@Jaan and you still can't get printers deployed?

 

I'm not entirely sure if people are saying the September update breaks printer deployment even with all the fixes, as they came out to get around the August update I think...?

 

Are your Point and Print GPOs in 'User' and 'Computer' for the client machines (not sure you need it on the server)?

 

Also, is your regedit on the clients?

 

How are your printers deployed?

 

EDIT: As well as the 'don't accept spool connections' thing, there was a 'fix' that ran a PS script to set DENY permissions on the SPOOL folder for the SYSTEM account, make sure that hasn't been used on the clients

Edited September 22, 2021 by Koldov

[Norphy]

I'm not entirely sure if people are saying the September update breaks printer deployment even with all the fixes, as they came out to get around the August update I think...?

 

Yes, in my experience it does. Even with all of those fixes in place, even with drivers prestaged on the client, mapping a printer queue hosted on a machine with the 2021-09 hotfix installed, printing is broken.

 

There is one possible workaround that I've seen mentioned in this thread, originally posted by @NetworkServices:

 

Weirdly this issue has only affected our users who share their printers from their workstations rather than our main fleet of printers that are shared from a server. The "Cannot connect to printer" message was popping up on any machine that tried to connect to the printer share. Removing KB5005565 from the workstation that shares the printer seemed to do the trick but as I am not keen on leaving machines unpatched I discovered that I could leave KB5005565 in place and modify the registry instead. Adding the following key and then restarting the spooler service allowed other workstations to connect to the shared printer...

 

HKLM\System\CurrentControlSet\Control\Print

 

"RpcAuthnLevelPrivacyEnabled"=dword:00000000

 

If you're getting 0x0000011b when trying to map a queue hosted on a September patched computer, try putting in that DWORD at that key on the server hosting the queue. It "fixed" it for me on my test bed.

[Koldov]

Yes, in my experience it does. Even with all of those fixes in place, even with drivers prestaged on the client, mapping a printer queue hosted on a machine with the 2021-09 hotfix installed, printing is broken.

 

Are these per 'User' or per 'Computer' deployments and is it any deployment method like start-up SCRIPT, PDQ, GPO/GPP?

[Jaan]

and you still can't get printers deployed?

My printers have now started to appear and work after applying the changes in my post

 

I'm not entirely sure if people are saying the September update breaks printer deployment even with all the fixes, as they came out to get around the August update I think...?

 

Are your Point and Print GPOs in 'User' and 'Computer' for the client machines (not sure you need it on the server)?

All in Computer, don't have anything in user, I have this applied to the print server also. But yes i suspect you're right and it's only needed on the clients

 

Also, is your regedit on the clients?

And the print server, its the same GPO i have used for both clients and the Print server

 

How are your printers deployed?

I deploy them from the print server, into a empty gpo

 

[Norphy]

Are these per 'User' or per 'Computer' deployments and is it any deployment method like start-up SCRIPT, PDQ, GPO/GPP?

 

Per user, either deployed with a GPP or manually mapping the queue

[Jaan]

@Jaan and you still can't get printers deployed?

 

I'm not entirely sure if people are saying the September update breaks printer deployment even with all the fixes, as they came out to get around the August update I think...?

 

Are your Point and Print GPOs in 'User' and 'Computer' for the client machines (not sure you need it on the server)?

 

Also, is your regedit on the clients?

 

How are your printers deployed?

 

EDIT: As well as the 'don't accept spool connections' thing, there was a 'fix' that ran a PS script to set DENY permissions on the SPOOL folder for the SYSTEM account, make sure that hasn't been used on the clients

 

i haven't ran any PS scripts

[Jaan]

I have the sept update and haven't had to do the ""RpcAuthnLevelPrivacyEnabled"=dword:00000000" reg "fix".

[Koldov]

and you still can't get printers deployed?

My printers have now started to appear and work after applying the changes in my post

 

Great, that's good to hear!

 

How are your printers deployed?

I deploy them from the print server, into a empty gpo

 

Does that go into a 'User' policy or a 'Computer' policy?

[4HeadDev]

I'm not entirely sure if people are saying the September update breaks printer deployment even with all the fixes, as they came out to get around the August update I think...?

 

10th August update is the cumulative update that 'broke' most printers -- AKA prompting for administrator elevation when installing drivers. The 14th September update is the one that outright broke printing and was throwing those 11b errors.

 

Currently I'm not removing the 10th August update because it includes the fix for the print driver exploit, nor am I advocating for anyone to outright set the new regkley edit I've seen everyone ranting about to 0 and just leaving it there. It's just another risk that I'm not keen on taking. I only removed the recent 14th Sept update from print servers, and even then I had my tongue in my cheek about the whole thing because it does add some extra security fixes.

 

In the end it came down to whether the clients wanted to print or not, and all of them wanted to print... Lol.

 

Also loving microsoft's reply with 'Just use type 4 drivers lol'. If only it were that simple!

Edited September 22, 2021 by 4HeadDev

[Jaan]

Great, that's good to hear!

 

 

 

Does that go into a 'User' policy or a 'Computer' policy?

 

Both actually, we have a follow me printing for staff (user) and room specific printers (Computers) we also use Papercut if that's of any use.

[Koldov]

Both actually, we have a follow me printing for staff (user) and room specific printers (Computers) we also use Papercut if that's of any use.

 

Well, it's about time you sit back and relax with a well earned cuppa and a few Eduhobnobs then!

[Jaan]

Well, it's about time you sit back and relax with a well earned cuppa and a few Eduhobnobs then!

 

I'm not even joking when i say, i could go to sleep under my desk for a week.

 

this has been horrible. it isn't the end of it as we are "vulnerable" still and need a long term fix.

Edited September 22, 2021 by Jaan

[rklarr]

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

 

The vulnerability forced their hand, but. Ya. They don't want to support the old stuff. In this case, I don't care; I hope someone at HP is 'using horse reigns' on the type 4 dev team.

 

I'm working on building a driver repository to use with a pnputil script. Anyone have a quick-n-dirty method for putting the right files together? I'm loathe to go through the list dragging and dropping 200 files? Thx.

[Koldov]

@Jaan - Well if I've understood correctly (not a given by any means) and all you have is the regedit 'RestrictDriverInstallationToAdministrators' set at '0' but you have mitigated that by requiring Point and Print to only accept drivers from your named server (requiring a hacked driver to be installed on your print server) and it's working for you, I think you have done all you can for now really and wouldn't lose too much sleep over it. Plus you have all the latest updates installed (bonus)!

 

Happy to be corrected though.

Edited September 22, 2021 by Koldov

[Jaan]

@Jaan - Well if I've understood correctly (not a given by any means) and all you have is the regedit 'RestrictDriverInstallationToAdministrators' set at '0' but you have mitigated that by requiring Point and Print to only accept drivers from your named server (requiring a hacked driver to be installed on your print server) and it's working for you, I think you have done all you can for now really and wouldn't lose too much sleep over it. Plus you have all the latest updates installed (bonus)!

 

Happy to be corrected though.

 

Not sure what you mean by "requiring a hacked driver to be installed on your print server"

 

but yeah, allow non admin to install drivers and only allow our named server

 

haven't updated removed or touched the drivers on the print server. Still the same type 3 drivers i was using pre any of this printnightmare stuffs

Edited September 22, 2021 by Jaan

[Koldov]

Not sure what you mean by "requiring a hacked driver to be installed on your print server"

 

From what I understand, the actual 'Print Nightmare' vulnerability is that once on your network as a normal domain user an attacker can install a driver that has been hacked with malicious code from a remote server, giving the user 'SYSTEM' privileges, now you have restricted drivers to only come from your server by Point and Print, it would mean they would have to get a hacked driver onto your server (which is unlikely).

 

Because the 'hacked driver' can't come from outside of your network as you have restricted Point and Print to only allow drivers to be installed from your server, that has mitigated the risk.

 

Various Internet searches:

 

"(The) 'PrintNightmare' vulnerability in Windows Print Spooler basically gives any user with a regular account the ability to gain admin-level access on any system running Windows Print Spooler. The vulnerability stems from a failure by the service to properly restrict access to a function that is used for installing a printer driver on a system.

 

This gives any authenticated user the ability to call the function and "specify a driver file that lives on a remote server," CERT CC said. "This results in the Print Spooler service spoolsv.exe executing code in an arbitrary DLL file with SYSTEM privileges," it noted."

 

"a security bypass vulnerability exists in the way the Printer Remote Procedure Call (RPC) binding handles authentication for the remote Winspool interface."

 

Print Nightmare is a critical threat to all devices running Windows 7 or higher, as the print queue service does not restrict access to the RpcAddPrinterDriverEx function, allowing attackers to execute malicious code on our computer.

[Jaan]

Ah yeah ok sorry i misunderstood you..... i thought you thought i'd installed a hacked driver to get it to work

[4HeadDev]

I'm not even joking when i say, i could go to sleep under my desk for a week.

 

this has been horrible. it isn't the end of it as we are "vulnerable" still and need a long term fix.

 

Yeah tell me about it -- I've been working alongside a coworker with just the two of us trying to get a workaround out to dozens of clients. I understand the vulnerability kind of forced them to dump this on us but come on... It's never a good sign when you have experienced system admins going 'damn this patch is utterly awful, let me just uhhhhhh re-expose my system again because it can't get much worse' LOL. You'll need a decent cup of tea and a nice long sleep under the desk once this rolls over at long last.

 

I have found that the whole reason my own server wasn't affected is because I have the printers deployed on a per computer basis. Printers are installed prior to the logon screen, which uses SYSTEM privilages. Whereas in my workplace, we deploy them normally on a per user basis so they can roam with the users.

[Koldov]

I have the printers deployed on a per computer basis. Printers are installed prior to the logon screen, which uses SYSTEM privilages..

 

This is what mostly saved me from a lot of stress... that and we are quite a small school.

 

99% of our printers are deployed by GPP on a per computer basis, for those that aren't I created an OU and put the relevant printer GPP in it, move their computer into that OU let it restart and install the printer and then move it back to the original OU (seems to work so far).

 

All the teachers have a school laptop and all get the same 2 printers installed, so it's easy enough to have a GPP linked to the OU that has all the teacher laptops in it. They do have a year group printer each, so if it comes to it I will be putting all the laptops that teachers from a particular year group use into sub OUs and do it that way too!

 

The ICT suite has a printer, so all those computers are in their own OU and have a GPP for a the printer in that room.

 

All the admin staff use one printer and their computers are all in one OU, same for the finance staff.

[free780]

I discovered this yesterday.

GPP Printer on computer level works. How ever if your using PCounter it wont map the port correctly. Not sure about papercut.

 

Printer Connections seem to fail as the mapping is done in the user context even though it can be set at the computer level.

 

I tried PrintUI with a script from sccm using the SYSTEM account. But even that fails with the new default behaviour.

 

Sorry if I was bullish on this thread earlier. I've decided to use the reg fix as a temporary measure.

 

I could map the printing with a local administrator service account via a SCCM Task Sequence but this seems to be bad for security. I can't have 1st/2nd line having to elevate every time a device is imaged.

 

If Microsoft just allowed the system to do Printer Connections and you push out drivers via SCCM it would be fine.

 

 

This is what mostly saved me from a lot of stress... that and we are quite a small school.

 

99% of our printers are deployed by GPP on a per computer basis, for those that aren't I created an OU and put the relevant printer GPP in it, move their computer into that OU let it restart and install the printer and then move it back to the original OU (seems to work so far).

 

All the teachers have a school laptop and all get the same 2 printers installed, so it's easy enough to have a GPP linked to the OU that has all the teacher laptops in it. They do have a year group printer each, so if it comes to it I will be putting all the laptops that teachers from a particular year group use into sub OUs and do it that way too!

 

The ICT suite has a printer, so all those computers are in their own OU and have a GPP for a the printer in that room.

 

All the admin staff use one printer and their computers are all in one OU, same for the finance staff.

[Michael]

I've installed the September 2021 patch on a 1607 workstation, so the build number reads: 14393.4651

 

This is using Type 3 drivers, Point and Print GPOs configured and the GPP regedit added prior = no problems.

 

If I did run into issues, my first steps would be to upgrade to the latest Type 3 driver from whoever your provider is. The more I read about Type 4, the more it reminds me of HTML5 many years back. It just wasn't ready, too many ifs and buts, but now it's a mature/supported plugin.

[Koldov]

Somebody mentioned that pushing out the actual Type 4 driver from the manufacturer to the client (if you are lucky enough to be able to get them) seems to bypass the issue of having a minimal/generic/reduced functionality for the user?

[Michael]

Somebody mentioned that pushing out the actual Type 4 driver from the manufacturer to the client (if you are lucky enough to be able to get them) seems to bypass the issue of having a minimal/generic/reduced functionality for the user?

 

I did wonder 'what's the difference?' only issue, this won't work for Papercut schools.

 

I'm not entirely sure why this is the case, but probably easy enough to include in a future update.

[dfergusson]

Somebody mentioned that pushing out the actual Type 4 driver from the manufacturer to the client (if you are lucky enough to be able to get them) seems to bypass the issue of having a minimal/generic/reduced functionality for the user?

 

Yes, that is what we did, we added the universal type 4 drivers directly to the client then add a temporary step to remove any existing printers so that when printers were reapplied on login they would pick up the new drivers.

 

I got the following from an article online that explains the change of driver deployment for Type 4.

 

"Starting with V4 drivers the distribution model on the print server was changed. If the user connects to a V4 shared printer queue, the corresponding V4 driver from the local driver store on the client is installed or downloaded from Windows update. If no driver is available, the so called “Microsoft enhanced “Point and Print driver” is used"

Edited September 23, 2021 by dfergusson

[dfergusson]

I did wonder 'what's the difference?' only issue, this won't work for Papercut schools.

 

We using Papercut, the main thing is to ensure that all printers are using the same printer driver type, you are unable to mix type3 and type4 with Find-Me Printing.