...or How the Incompetent Code Monkeys at Microsoft Managed to Bork Network Shared Printing World-wide.
It all began in August when Microsoft released an update (KB5005565) that was supposed to address a vulnerability the Windows 10 sprint spooler... "A remote code execution vulnerability exists when the Windows Print Spooler service improperly performs privileged file operations." An unintended side-effect of the update was that printing to a network printer hosted by a Windows 8 or 10 computer stopped working. In some cases, the attempts would be accompanied by error 0x0000011b, in other cases, no error code appear, but it just doesn't print and when you go Devices & Printers and open the print dialog for that printer, the print job has "Access denied" in the Status column.
This issue only appears to happen when printing to network shared printers, that is printers attached, say via USB, to a host windows computer or print server, and you are trying to print to them from a client computer. It does not appear to effect network attached printers, that is printers that are directly connected to a network using their own built in Wi-Fi adaptor, or using an Ethernet cable to a network port.
A search of the internet revealed two possible workarounds
Option 1 - Uninstall KB5005565 and use wushowhide.diagcab (available from the Microsoft website) to block the update from downloading and installing, and
Option 2 - 1 Uninstall KB5005565 and find (or if it doesn't exist, create) the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\Print\ and set the DWORD value of RpcAuthnLevelPrivacyEnabled to 0.
These workarounds were only necessary on the host machine, the one with the printer(s). Option 2 fixed it for me, and everything was going swimmingly, until this week, when, wouldn't you know it, the idiot Microsoft Code Monkeys went and did it again. This update KB5006670 borked printing to network shared printers, even with the above mentioned registry key correctly set.
Again a search of the internet revealed two possible workarounds
Option 1 - Uninstall KB5006670 and use wushowhide.diagcab to block the update from downloading and installing, and
Option 2 - Leave KB5006670 installed, and get a copy of Win32spl.dll (its in C:\Windows\System32) from a non-updated machine and overwrite the existing file on the updated machine.
I mean, what the actual **** is going on here. Don't these idiots test their updates before they release them?
Anaaanyway... the issue here is that, apparently, this issue only affects network shared printers that were not installed "with Administrative Privileges" Well, unless I have done something wrong, I installed and shared all the printers at my business using my Admin Account, and I still got hit with this problem... twice!
It all began in August when Microsoft released an update (KB5005565) that was supposed to address a vulnerability the Windows 10 sprint spooler... "A remote code execution vulnerability exists when the Windows Print Spooler service improperly performs privileged file operations." An unintended side-effect of the update was that printing to a network printer hosted by a Windows 8 or 10 computer stopped working. In some cases, the attempts would be accompanied by error 0x0000011b, in other cases, no error code appear, but it just doesn't print and when you go Devices & Printers and open the print dialog for that printer, the print job has "Access denied" in the Status column.
This issue only appears to happen when printing to network shared printers, that is printers attached, say via USB, to a host windows computer or print server, and you are trying to print to them from a client computer. It does not appear to effect network attached printers, that is printers that are directly connected to a network using their own built in Wi-Fi adaptor, or using an Ethernet cable to a network port.
A search of the internet revealed two possible workarounds
Option 1 - Uninstall KB5005565 and use wushowhide.diagcab (available from the Microsoft website) to block the update from downloading and installing, and
Option 2 - 1 Uninstall KB5005565 and find (or if it doesn't exist, create) the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\Print\ and set the DWORD value of RpcAuthnLevelPrivacyEnabled to 0.
These workarounds were only necessary on the host machine, the one with the printer(s). Option 2 fixed it for me, and everything was going swimmingly, until this week, when, wouldn't you know it, the idiot Microsoft Code Monkeys went and did it again. This update KB5006670 borked printing to network shared printers, even with the above mentioned registry key correctly set.
Again a search of the internet revealed two possible workarounds
Option 1 - Uninstall KB5006670 and use wushowhide.diagcab to block the update from downloading and installing, and
Option 2 - Leave KB5006670 installed, and get a copy of Win32spl.dll (its in C:\Windows\System32) from a non-updated machine and overwrite the existing file on the updated machine.
I mean, what the actual **** is going on here. Don't these idiots test their updates before they release them?
Anaaanyway... the issue here is that, apparently, this issue only affects network shared printers that were not installed "with Administrative Privileges" Well, unless I have done something wrong, I installed and shared all the printers at my business using my Admin Account, and I still got hit with this problem... twice!
via International Skeptics Forum https://ift.tt/3mZFf8l
Aucun commentaire:
Enregistrer un commentaire