4HeadDev

Might be worth referring to: http://www.edugeek.net/forums/windows-10/223374-printing-issues-driver-update-needed.html As this thread covers the whole issue. The October 12th patch also appears to cause the exact same issues mentioned in this thread. You can try some of the fixes mentioned in this thread to get it working. A permanent fix that does not comprimise security is to upgrade to 21H1 though.

Update: Have now managed to resolve this on some servers by upgrading to Windows 10 21H1 on the clients alongside the following updates on the Print Server: KB5005568 (Windows Server 2019) KB5005573 (Windows Server 2016) KB5005613 (Windows Server 2012 R2) KB5005627 (Windows Server 2012 R2) Most of the clients that we support weren't upgrading automatically because WSUS hadn't picked the upgrade yet. Only about 20% of the print servers we support have picked it up, which makes this 'fix' sort of unreliable. I'm also hearing that 20H2, KB5005031 and KB5005033 can also fix this but I have yet to find any actual proff, as I was testing the 20H2 upgrade on several clients and had very varied results.

Also just to add, papercut has stated that Type 4 Drivers dooes not work with them. Only Type 3 does.

Over a dozen of the clients I manage have Windows 2019 Servers and Print Servers with Type 3 drivers, and P&P restrictions are correctly applied to these. Unfortunately one of these work following the August 10th and September 14th update. I can only get them to work by outright removing the September 14th patch from the Print Server and doing a workaround for the August 10th patch. Has anyone else had any luck with this?

Hum... You could try renaming the SoftwareDistribution folder? Just go to C:\Windows\SoftwareDistribution and rename SoftwareDistribution to SoftwareDistribution.Old. Could also try allowing the OSUpgrade Registry key? You can add it by going to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\OSUpgrade in regedit, create a new 32-bit DWORD value called AllowOSUpgrade and set the value to 1. Have you managed to successfully roll back an update before on the machine you're currently doing so on?

I suspect they've recently picked up the problem updates. We were having this on all of our clients even though none of the drivers have been changed for several months. Managed to bypass it in the end but now most clients are just getting an error with the Sept 14th patch, which just shows 'access denied' 'printer unavailable/offline' or 'error message unavailable'.

Try this powershell script we made: <# Checking for updates KB5005568 (Windows Server 2019) KB5005573 (Windows Server 2016) KB5005613 (Windows Server 2012 R2) KB5005627 (Windows Server 2012 R2) KB5005623 (Windows Server 2012) KB5005607 (Windows Server 2012) KB5005606 (Windows Server 2008) KB5005618 (Windows Server 2008) KB5005565 (Windows 10 2004, 20H2, and 21H1) KB5005566 (Windows 10 1909) KB5005615 (Windows 7 Windows Server 2008 R2) #> #Constants $LogFilePath = "$home\Documents\PrintNightmareSept21" $LogFileName = "$env:COMPUTERNAME" + "_PrintNightmareSept21.log" $LogPath = ("$LogFilePath\" + $LogFileName) $updatelist = @("5005568", "5005573", "5005613", "5005627") Start-Transcript -Path $LogPath -Force # Go though each KB ID and if found, uninstall it foreach ($update in $updatelist) { $Found = Get-Hotfix -ID "KB$update" -ErrorAction SilentlyContinue If ($Found) { & Write-Host -BackgroundColor Yellow -ForegroundColor Red("Removing $update") try { wusa.exe /uninstall /KB:$update /norestart Wait-Process -Name wusa } catch { Write-Error ("Error removing $update") } } else { Write-Host("KB$update not found.") } } Stop-Transcript If it's failing, try running an administrative powershell window and running this script within it.

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.

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!

No. I currently support dozens of servers and I've found that only removing the problem patch from the print server works. The machines seem fine with the patch.

You'll need to remove the patch on your print server, rather than the client machines. One of these will be the affected patches: KB5005568 (Windows Server 2019) KB5005573 (Windows Server 2016) KB5005613 (Windows Server 2012 R2) KB5005627 (Windows Server 2012 R2)

Out of curiosity, has anyone had luck with further updating their computers which fixes the network printer issues? I have a client claiming that upon updating their computer with KB5005565 and KB5005699 (I think this is a new SSU as there are no hits for it on google) it fixed their printer issues. I've tried this one a few other devices and have had no luck.

It may be worth hiding that update, I have a few of the servers we support that have downloaded it and are awaiting an install, and even then it appears to have broken their printers. Have had to restart, install the update, and then remove it from WSUS and the server itself. It really is messy, and seeing some of the fixes that people are putting together is pretty scary because of the methods they're using. Half of them are just re-exposing their systems again. The lengths people are going to is extreme.

The issue with this new patch seems to directly just affect the print server, I found once I uninstalled the patch from the print servers for our clients. The clients work fine after they sign back in. Error code varies between 0x8007011b and 0x0000011b. I've also had to use the wushowhide.diagcab tool to prevent the update from reinstalling when WSUS syncs so... there's that too.

Just for awareness, the only way I've been able to fix the issues caused by the latest 14th September Microsoft patch are by outright uninstalling it. The affected patches for servers are: KB5005568 (Windows Server 2019) KB5005573 (Windows Server 2016) KB5005613 (Windows Server 2012 R2) KB5005627 (Windows Server 2012 R2) KB5005623 (Windows Server 2012) KB5005607 (Windows Server 2012) KB5005606 (Windows Server 2008) KB5005618 (Windows Server 2008) KB5005565 (Windows 10 2004, 20H2, and 21H1) KB5005566 (Windows 10 1909) KB5005615 (Windows 7 Windows Server 2008 R2) It's probably important to note that if you're using a WSUS, to decline the update you're about to remove or it WILL come back with a vengence... Slightly worried as the issues with the current patch because it's outright denying access for clients when pulling the print packages from the print server... But will have to see how it goes. Cause' what microsoft have done at the moment completely prevents you from deploying printers normally.