Unable to Print after installing 2021-09 Cumulative Update (KB5005573)

Copper Contributor

Anyone else having user print issues after installing this update on a Windows Server 2016 Standard? We can send jobs to the spooler just fine from the server itself, but a user submitted job is just simply terminated. Problem started happening after installation. We've removed the update on 1 server to test, and it appears that jobs are now printing again properly. Problem is, it's been installed many servers. We will likely uninstall update to remedy issue, but that's not a real solution.




16 Replies

Last night was our patch date here, and we're walking into a mountain of "can't print" tickets this morning across our 1,200 something printer shares.

Print servers (2012 R2) can reach our printers, print server can successfully send test jobs. But clients can't print, similar to OP's reported behavior. No output, no error.

Also, to quote one report:

the printer shows up in Word to print, but when looking in Settings (Win10) the printer has disappeared

We're about to try ruling out patch removal from both a print server and client.

We have the same problem. Uninstalling KB5005573 seems to fix the printing issue for windows 10 users, however having less luck w/windows 7 users- keeps asking to reinstall drivers, does so (takes forever to install drivers), then fails to print. rinse and repeat...


I'm actively looking for solution, and will post what I find to all forums I visit, please reciprocate in kind?




Thankfully I'd only rolled it out to a handful of the servers we have deployed, so it wasn't too hard to uninstall and get things back to normal. Was supposed to complete all servers over the weekend, that isn't going to happen now.

Night now, our fix is to not install. But will update you if we come up with anything else.


Here are the KB's to watch out for: (that I've found so far)

2016 - KB5005573 2019 - KB5005568 2012 - KB5005613



Updated list per: https://candid.technology/printnighmare-patch-windows-issue/
KB5005606 (Windows Server 2008)
KB5005618 (Windows Server 2008)
KB5005623 (Windows Server 2012)
KB5005607 (Windows Server 2012)
KB5005613 (Windows Server 2012 R2)
KB5005627 (Windows Server 2012 R2)
KB5005568 (Windows Server 2019)
KB5005615 (Windows 7 Windows Server 2008 R2)
KB5005565 (Windows 10 2004, 20H2, and 21H1)
KB5005566 (Windows 10 1909)


@GeekNaHalf patching caused quite the commotion for me this morning. I ended up rolling back KB5005573 and restarted the print servers. It would appear that this has been long in the process according to this link: https://support.microsoft.com/en-us/topic/managing-deployment-of-printer-rpc-binding-changes-for-cve...


Unfortunately with everyone and anyone making noise about the issue... I did not feel I had enough time to research the root cause. That article would have been nice to be made aware of prior to patching this last weekend. 


I am currently in the testing phase on that article to see if it works or not. I suspect it will work, but I'm not sure why Microsoft doesn't just address the problem rather than disable a feature that everyone seems to use.

I had issues with users saying their department printers were not showing up. With this regedit solution I was able to get them to pop back up! Thank you, I was about to rollover to the past update.
Glad it helped. I am also going to try and uninstall all printers and drivers from the DC, and then reinstall with only v4 drivers, re-apply the patch and see if users can still print. Hopefully that will correct the problems for W10 users at least. W7 clients are screwed regardless I think.
If anyone hears of better solution(s), pls post.

Thanks. Removing KB5005573 also fixed MacBook printing issues using Equitrac client with Windows backend server.
So anyone that simply removed September's updates from their server to fix this will see the same thing with any subsequent month's updates as well. This is due to changes Microsoft announced and later enforced in regards to RPC authentication to address a print spooler spoofing vulnerability. (Note that this is a separate issue from the Point & Print admin elevation requirement caused by PrintNightmare mitigations)



Disabling enforcement of these RPC auth level changes will make printing work again, i.e. not silently fail.

That said, I've found no documentation or guidance that outlines **why** specifically this RPC auth level enforcement breaks things, and what needs to be accommodated or made different in our environments to not need this workaround.

Here is what worked for me & other partners in my field.


The spoofing vulnerability CVE-2021-1678 has been known for quite some time (in January 2021 Microsoft published something about it, see also my blog post Details of Windows NTLM vulnerability CVE-2021-1678 published). As I now read out from Benjamin Delpy above tweet, this also affects printer RPC binding and authentication for the remote Winspool interface.

Microsoft has started to address this vulnerability via security updates in January 2021 and September 2021. To do so, a new registry entry was set that administrators could use to increase or decrease the RPC authentication level.



When the DWORD value RpcAuthnLevelPrivacyEnabled=1  is set, Windows encrypts RPC communication with network printers or print servers. However, this security measure was rolled out in two stages via security update: :

  • Since January 12, 2021, there was a so-called deployment phase for this purpose, in which administrators set this registry value
  • With the security update of September 14, 2021, the enforcement phase was initiated, i.e. RPC encryption is active by default

The details can be found in the Microsoft support article Managing deployment of Printer RPC binding changes for CVE-2021-1678 (KB4599464). This could explain the connection problems of clients with the Windows printer spooler in various scenarios. It is reported that printing is no longer possible after installing the September 2021 update.

This workaround could help

Instead of uninstalling the security update from September 14, 2021, users have come up with the idea of disabling the enforcement mode on the server.  



If I interpret the above tweet correctly, disabling the relevant settings under:


on the server to allow printing again. There is the DWORD value:


and then restart the print spooler (see this reddit.com thread and in Bleeping Computer's forum). Maybe it will help someone. 



Thanks for this one - had been removing updates for the last 2 months!
I have tried this workaround on server 2012 r2 and when i navigate to the entry, i cannot find the rpc dword entry, and the september update is not showing as installed on the server. However still getting problems with windows 7 clients not printing... Any ideas?
I had to create the value as shown in the previous post… works a treat
Excellent, i thought that may be the case.

First thing im doing monday morning, cheers :thumbs_up: