Printing Issues "Driver Update Needed"

[talksr]

So not both?

 

I have tried repeatedly removing update, it is not coming off. Any ideas? I am getting hounded by people every day because they cannot print.

 

[4HeadDev]

I have tried repeatedly removing update, it is not coming off. Any ideas? I am getting hounded by people every day because they cannot print.

 

[ATTACH=CONFIG]63183[/ATTACH]

 

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.

[Koldov]

Damn this nightmare!

 

It hasn't really caused much of an issue here and haven't had a problem for weeks (apart from one or two that hadn't moved to the new print server), now 4 teachers have come to me this morning saying their driver needs updating?

 

All these driver have been installed on their laptops for years!

 

I haven't changed anything and haven't installed any updates over the weekend... now I've got the dreaded 'update your driver' message popping up all over the place!

 

[talksr]

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.

 

 

Thank you for the helpful post and script.

I have run it and got the following:

 

The log file is showing the following...

**********************

Windows PowerShell transcript start

Start time: 20210927143119

Username: svr\administrator

RunAs User: svr\administrator

Machine: server (Microsoft Windows NT 10.0.14393.0)

Host Application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Process ID: 75724

PSVersion: 5.1.14393.4583

PSEdition: Desktop

PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.14393.4583

BuildVersion: 10.0.14393.4583

CLRVersion: 4.0.30319.42000

WSManStackVersion: 3.0

PSRemotingProtocolVersion: 2.3

SerializationVersion: 1.1.0.1

**********************

Transcript started, output file is C:\Users\Administrator\Documents\PrintNightmareSept21\FTY-SR-001_PrintNightmareSept21.log

KB5005568 not found.

Removing 5005573

KB5005613 not found.

KB5005627 not found.

**********************

Windows PowerShell transcript end

End time: 20210927143632

**********************

 

Not sure why it would not be able to find the file specified. KB5005573 is still showing as installed on Installed Updates.

What a mess.

[4HeadDev]

Damn this nightmare!

 

It hasn't really caused much of an issue here and haven't had a problem for weeks (apart from one or two that hadn't moved to the new print server), now 4 teachers have come to me this morning saying their driver needs updating?

 

All these driver have been installed on their laptops for years!

 

I haven't changed anything and haven't installed any updates over the weekend... now I've got the dreaded 'update your driver' message popping up all over the place!

 

[ATTACH=CONFIG]63185[/ATTACH]

 

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'.

[4HeadDev]

Thank you for the helpful post and script.

I have run it and got the following:

[ATTACH=CONFIG]63188[/ATTACH]

 

The log file is showing the following...

 

 

Not sure why it would not be able to find the file specified. KB5005573 is still showing as installed on Installed Updates.

What a mess.

 

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?

[talksr]

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?

 

Thanks for your post. Thought I would try renaming SoftwareDistribution but I am getting:

"The action can't be completed because the folder or a file in it is open in another program"

Any ideas what else might be using it?

[ADMaster]

I’m at a loss on how to fix this print nightmare stuff and stay secure. I thought I dodged it with GPP deployments, but my users just hadn’t rebooted from the patches yet. Now I’m getting the issue somewhat randomly.

I’ve had less than half a dozen reports so far. Most are the smaller HP LaserJet’s but one was the follow me queue / copiers. The most reliable method I’ve come up with is a series of PDQ steps.

Run as logged in user delete all shared

Run as admin set RestrictDriverInstallationToAdministrators to 0

Run as logged in user gpupdate force

Run as admin set RestrictDriverInstallationToAdministrators to 1

 

I’ve setup a VM, removed all printer drivers and deleted the profile of a test user. I’ve added this machine to all the printer deployment security groups.

If I make no changes one or two printers install.

If I try to preload the drivers with rundll32 printui.dll PrintUIEntry /in /n \\printserver\printer and rundll32 printui.dll PrintUIEntry /dn /n \\printserver\printer I can see the drivers loaded in print management MMC, but I still get driver missing errors in the GPP event log. However about half of the printers install this way.

 

Running the PDQ steps above gets me all but 1 or 2 printers. I’ve not really looked into those yet, it may be a simple permissions issue as I didn’t add the user to the group, just the computer.

 

I have 1 computer / user who nothing appears to be working. I ran the steps above yesterday to clear up the trust / driver dialog. Then the user got a message that said failed to print. After a reboot printing worked.

Today the computer is prompting for trust / driver again. Running the fix got us back to failed to print. I did not ask for reboot. Another user who I ran the method above was able to print without a reboot.

I checked this user is running 1909 with September's patch. For good measure I set RpcAuthnLevelPrivacyEnabled to 0 on the printer server and restarted the spooler. The user got the same error.

 

Do I need to leave RestrictDriverInstallationToAdministrators to 0?

I’m deploying GPP with the action create. If I change to update, will it break more users?

 

I'm also using point and print restrictions. The GPO has the full FQDN. I tested and could not connect to another print server.

The GPP deployments all use the hostname only.

Thanks

[talksr]

Thanks for your post. Thought I would try renaming SoftwareDistribution but I am getting:

"The action can't be completed because the folder or a file in it is open in another program"

Any ideas what else might be using it?

 

Just a quick update to say, for some reason, it now has allowed me to rename the SoftwareDistribution folder. I have renamed it SoftwareDistribution.old and re-executed the PowerShell script, but again, I am getting the same error. Tried again and again, rebooting server each time.

Have never had the need to roll back any drivers before this ridiculous situation. Any ideas? I have had multiple phone calls and emails from furious staff today who have been unable to print for over a week now. Nothing I can do to help them as everything I am trying is just not working.

[Koldov]

You may have had an issue when you renamed the Software Distribution folder due to it being in use most of the time (Windows checking for updates), when I have done it (not for many years), I've followed something like this, which includes stopping the services using it (bits & wuauserv):

 

https://webcache.googleusercontent.com/search?q=cache:0d-7CVqTTLsJ:https://www.windowscentral.com/how-clear-softwaredistribution-folder-windows-10+&cd=1&hl=en&ct=clnk&gl=uk

 

IIRC once done the list of 'Installed Updates' is actually empty, so I'm not certain your script will work as it won't know if it has the update installed or not.

 

Can you just list the specs of your estate and see if anyone who has a similar set-up has it working (as a lot of things might depend on the server/client OS & patching levels and how you deploy printers), I'm sure some of those with the September update have printing working. How do you do your updates on that server (WSUS, Windows Update) and how do you have it set (automatically apply updates, download and wait or just notify)?

 

For instance I have:

 

Server 2012R2 - print server (NOT patched with the Sept update - although I'm going to be brave at some point)

Windows Update - set to just notify

Windows 10 LTSC 1809 (and some LTSB) - all clients patched with September update.

Printers deployed via GPP to users

Point and Print restrictions enabled (as in many other posts) with 'RestrictDriverInstallationToAdministrators' regedit set to 0

 

How large is your estate and can you manually install printers as Administrator to keep the most vocal quiet and give yourself some peace and time to think and ease the stress?

 

 

 

All of these deploy and install fine, tested on a client with a fresh install of LTSC 1809 with Sept update. I use this PS script on the machine each time I test it to remove the drivers and package (a bit clunky and not as automated as I'd like, but the driver removal is manual so you can choose):

 

net stop spooler
rename-item -path "hklm:\system\currentcontrolset\control\print\environments\windows x64\print processors\winprint" -newname "winprint_old"
net start spooler
printui /s /t2
write-host "Now delete the printer drivers and press any key to continue..."; $x = $host.ui.rawui.readkey("noecho,includekeydown")
net stop spooler
rename-item -path "hklm:\system\currentcontrolset\control\print\environments\windows x64\print processors\winprint_old" -newname "winprint"
net start spooler
write-host "Press any key to exit the script..."; $x = $host.ui.rawui.readkey("noecho,includekeydown")
write-host "FINISHED!"
return

 

I know this isn't helping as you HAVE patched your server with the Sept' update, is it worth trying to spin up a VM and create a new Print Server (or just use another server for it), I know it's a pain but I see that you're desperate and it wouldn't take too long - and you're already suffering...

Edited September 30, 2021 by Koldov

[talksr]

You may have had an issue when you renamed the Software Distribution folder due to it being in use most of the time (Windows checking for updates), when I have done it (not for many years), I've followed something like this, which includes stopping the services using it (bits & wuauserv):

 

https://webcache.googleusercontent.com/search?q=cache:0d-7CVqTTLsJ:https://www.windowscentral.com/how-clear-softwaredistribution-folder-windows-10+&cd=1&hl=en&ct=clnk&gl=uk

 

IIRC once done the list of 'Installed Updates' is actually empty, so I'm not certain your script will work as it won't know if it has the update installed or not.

 

Can you just list the specs of your estate and see if anyone who has a similar set-up has it working (as a lot of things might depend on the server/client OS & patching levels and how you deploy printers), I'm sure some of those with the September update have printing working. How do you do your updates on that server (WSUS, Windows Update) and how do you have it set (automatically apply updates, download and wait or just notify)?

 

For instance I have:

 

Server 2012R2 - print server (NOT patched with the Sept update - although I'm going to be brave at some point)

Windows Update - set to just notify

Windows 10 LTSC 1809 (and some LTSB) - all clients patched with September update.

Printers deployed via GPP to users

Point and Print restrictions enabled (as in many other posts) with 'RestrictDriverInstallationToAdministrators' regedit set to 0

 

How large is your estate and can you manually install printers as Administrator to keep the most vocal quiet and give yourself some peace and time to think and ease the stress?

 

[ATTACH=CONFIG]63227[/ATTACH]

 

[ATTACH=CONFIG]63228[/ATTACH]

 

All of these deploy and install fine, tested on a client with a fresh install of LTSC 1809 with Sept update. I use this PS script on the machine each time I test it to remove the drivers and package (a bit clunky and not as automated as I'd like, but the driver removal is manual so you can choose):

 

net stop spooler
rename-item -path "hklm:\system\currentcontrolset\control\print\environments\windows x64\print processors\winprint" -newname "winprint_old"
net start spooler
printui /s /t2
write-host "Now delete the printer drivers and press any key to continue..."; $x = $host.ui.rawui.readkey("noecho,includekeydown")
net stop spooler
rename-item -path "hklm:\system\currentcontrolset\control\print\environments\windows x64\print processors\winprint_old" -newname "winprint"
net start spooler
write-host "Press any key to exit the script..."; $x = $host.ui.rawui.readkey("noecho,includekeydown")
write-host "FINISHED!"
return

 

I know this isn't helping as you HAVE patched your server with the Sept' update, is it worth trying to spin up a VM and create a new Print Server (or just use another server for it), I know it's a pain but I see that you're desperate and it wouldn't take too long - and you're already suffering...

 

 

Thanks for your helpful posts. I have been off for a few days, not been well not helped by the abuse I have received over these printers which has absolutely nothing to do with any chances I have made. I have returned back and now another site is having the same issue. Windows 2016 server, update KB5005573 was installed on it on 17th of September so obviously the client computers have only just done their updates. If I am understanding this right, the problem is KB5005573 (for a 2016 server) so if I can uninstall that, it will work on the client machines? Thankfully, it has uninstalled so I will try and do a reboot later.

 

Back to my last post...

 

You were right about wuauserv, it was that, as soon as I shut it down, I was able to rename software distribution folder, however, I have still been unable to remove the update.

 

The setup is as follows:

1 2016 FRDC

2 secondary domain connected "client" servers. One running 2016 and other running 2019.

The 2019 does not yet have the equivalent KB5005568 update so I am thinking of using this as a print server. But it is only a matter of time before it tries to install it and not sure I can prevent it from doing so.

 

The printers of which there are three are deployed via Group Policy. Everything is very basic. Just photocopiers with an IP address. It is a very basic GPO. It sits at the root of the domain and is called Printers All Locations.

The three printers are listed in there and will apply for all computers and locations in the domain so everyone gets the same ones.

The printer connection paths are listed as \\servername\PrinterName.

I tried to add the RestrictDriverInstallationToAdministrators reg to this GPO but it has made no difference at all.

 

I have spent hours trying to remove KB5005573 on this server and it just will not remove.

My only other thought would be to use the 2019 server (we use for Backups, Paxton Access and a few other things) as a print server, re-do the GPO and put in new paths for the printers?

What do you think?

 

We have WSUS on the second 2016 server but it is constantly crashing and not working, again spent hours trying to solve it and it just doesn't work so updates to client computers will be hit and miss at the moment.

[Koldov]

Haven't had time to go through everything in your post and I'm no expert for sure...

 

The reg entry should be a DWORD not a REG_SZ so see if changing that works first... and I also seem to remember the reg edit being dependant on Point and Print restrictions being set in the GPO (someone correct me if I'm wrong).

 

Do you have these set?

 

 

EDIT: Disclaimer - Just to say this is not 'best practise' or 'recommended' by MS... I'm not entirely sure what they expect us to do if someone has hundreds of workers and you are supporting them remotely or whatever...? You can't just pop down or RDC in to that many computers and install them yourself as an admin...

 

What is actually happening with this? Is it really not fixed properly (without a workaround) yet?

Edited October 4, 2021 by Koldov

[Koldov]

IIRC correctly a print server is fairly lightweight so putting it on a new server shouldn't be an issue, I did mine over the summer holidays and moved it to a VM as it was on a DC...

 

So, if you go that route I had a great bit of info which helped here:

 

http://www.edugeek.net/forums/windows-server-2012/223002-new-vm-print-server-kyocera-mostly-best-practise.html#post1910438

 

[ATTACH=CONFIG]63276[/ATTACH]

[Michael]

These settings still definitely work. If you're still experiencing issues, I'd highly recommend upgrading existing Type 3 drivers.

 

Uninstalling or further delaying the install of the September 2021 update will only complicate other security issues not related to this.

[Koldov]

Actually, you don't have WSUS sending updates to your servers do you? I just wondered if the problem was due to it being installed via WSUS (if that was the case you might have been able to set a removal by WSUS as well)...

 

As for WSUS, I would 100% not have my servers on it (or at least have all updates approved by you first), if it is just via Windows Update have them notify and not download or install.

 

If it is crashing a lot, have you got all the minimum correct updates categories set (I do not include anything extra like drivers personally) and all the IIS settings 'tweaked' I think there are settings (or links to them) in the posts in this thread.

 

http://www.edugeek.net/forums/windows-server-2012/212560-wsus-server-clean-up-wizard-crashes-reset-server-node.html

[talksr]

Actually, you don't have WSUS sending updates to your servers do you? I just wondered if the problem was due to it being installed via WSUS (if that was the case you might have been able to set a removal by WSUS as well)...

 

As for WSUS, I would 100% not have my servers on it (or at least have all updates approved by you first), if it is just via Windows Update have them notify and not download or install.

 

If it is crashing a lot, have you got all the minimum correct updates categories set (I do not include anything extra like drivers personally) and all the IIS settings 'tweaked' I think there are settings (or links to them) in the posts in this thread.

 

http://www.edugeek.net/forums/windows-server-2012/212560-wsus-server-clean-up-wizard-crashes-reset-server-node.html

 

Hello,

Thanks for your post. Yes I do, but WSUS has not worked for some time and I did go through all of the steps to clean it up. The issue is that the space on the server it is on is totally full. Like you suggested I didn't have many categories as they take up so much space.

 

The problem with WSUS is I only get this view:

 

I have no way of being able to see Critical/Security etc Updates.

Computers, Synchronisations, Reports or Options.

I did manage to search for KB5005573 and it found it 3 times. Twice for Windows 10 and once for Server 2016. I removed the entry, but still, server 2016 will not remove the KB5005573 update.

 

 

On the new 2019 server, WSUS also doesn't work. It constantly crashes and says something about the node. I have done all of the tricks regarding IIS tweaks etc but it never works.

[Koldov]

Ouch!

 

Drivers...

 

Rather than remove the entry (I'm not really sure what you mean), it would have possibly been better to 'Approve for Removal' and decline (although that might give you other problems when you want it back eventually, not sure if you can re-import declined updates as I've never done it - although the next cumulative might be here by then)?

 

 

Have you tried 'creating' other views (right click on 'All Updates' and choose 'New Update View')?

 

Also you can choose the drop down 'Approval' and choose something else like 'Any Except Declined' and status 'Failed or Needed' (or even 'All')

 

 

I'm not sure how your Computers are set to populate in WSUS (mine are set via Group Policy and client-side targeting with the groups pre-defined in WSUS).

 

Here's a good thread with more detail:

 

http://www.edugeek.net/forums/windows-server-2016/223203-windows-update-server-windows-server-2016-a.html

 

At this point you could trash WSUS completely, remove it and start again, I've done it twice a long time ago and it wasn't too bad... YMMV!

 

EDIT: Hold on, did you say you have WSUS on your 2016 server and your 2019 server... Is one set to be an upstream of the other?

Edited October 4, 2021 by Koldov

[talksr]

Ouch!

 

Drivers...

 

Rather than remove the entry (I'm not really sure what you mean), it would have possibly been better to 'Approve for Removal' and decline (although that might give you other problems when you want it back eventually, not sure if you can re-import declined updates as I've never done it - although the next cumulative might be here by then)?

 

[ATTACH=CONFIG]63278[/ATTACH]

 

Have you tried 'creating' other views (right click on 'All Updates' and choose 'New Update View')?

 

Also you can choose the drop down 'Approval' and choose something else like 'Any Except Declined' and status 'Failed or Needed' (or even 'All')

 

[ATTACH=CONFIG]63279[/ATTACH]

 

I'm not sure how your Computers are set to populate in WSUS (mine are set via Group Policy and client-side targeting with the groups pre-defined in WSUS).

 

Here's a good thread with more detail:

 

http://www.edugeek.net/forums/windows-server-2016/223203-windows-update-server-windows-server-2016-a.html

 

At this point you could trash WSUS completely, remove it and start again, I've done it twice a long time ago and it wasn't too bad... YMMV!

 

EDIT: Hold on, did you say you have WSUS on your 2016 server and your 2019 server... Is one set to be an upstream of the other?

 

Thanks for your post.

 

By Remove, I mean...

I can either Approve or Decline it. There are no other options that will be of use.

 

 

Yes, tried other views, but just get the same view whatever I try.

I can't remember how the computers for this site were added, but I would expect mine are also set via GP and client-side targeting.

I did manage to get it back to the proper view after more messing around by selecting Window>Update Services as opposed to All Updates. At least now I have proper control of it again!

 

Thanks, will have a look through that thread.

 

Yes, we have WSUS on 2016 and 2019 but they are both independent and nothing runs as an up or downstream server.

 

No devices have ever been pointed to the 2019 WSUS server as it has never worked. I just stopped the service on it using Start-Service wsusservice on PS.

Every single time we tried using it, we got the same errors about it not being able to connect to end node, looked it up, seemed to be IIS issue, went through all of the IIS settings and tweaks, no difference. The school was paying by the day, so we gave up as it was costing so much in time. Another broken Microsoft product, used to be great, now is just useless.

 

Shame as the 2019 server is new, has bundles of space, but cannot justify spending any more time on Microsoft's broken products.

The 2019 server, however would be prime for using as a Windows Print Server and then hopefully this would resolve this issue?

Does it matter if the Windows 10 clients have KB5005573 installed? My understanding is that if the server has it installed, that is why users can't print and are asked to install drivers or authenticate?

[Koldov]

Yes, it is the same process for 'Approve' and 'Approve for Removal' - after you choose 'Approve' the dialogue box in my previous post will come up and (if it has been approved previously I think) the option for removal (if it is possible - some aren't) will be available to select.

 

Hmmm... I don't have any choice but Window > Update Services...

 

You can close down the console and go into USER > APPDATA > MICROSOFT > MMC and rename wsus to wsus.bak to get a completely fresh console when reopening...

 

There's some good info on removing WSUS before reinstalling it here:

 

https://www.ajtek.ca/wsus/how-to-remove-wsus-completely-and-reinstall-it/

 

I would certainly fire up a print server on the 2019 box (if it isn't a DC) it can't hurt, I'm reasonably certain it is the server that should avoid the update (not recommended) the clients are OK with it. Depends on a lot of things still like drivers versions and such, some people are saying all updates installed and it is working, some need workarounds and reg tweaks... such a mess.

 

If you could do it in parallel and once created set only a test OU of devices up to connect to it?

[kingoranks]

Microsoft messed up on this, fcuking created problems for us all. Papercut has a workaround

[Norphy]

That's great. Have you got a link to that page and the workarounds?

[kingoranks]

Here you go

 

https://www.papercut.com/support/known-issues/#ng

[Norphy]

OK, the workarounds related to the September 2021 patch are both the same and are what was mentioned earlier in the thread:

Further workaround:

 

An additional temporary workaround is listed below, which allows customers to install the security fix. As detailed on the Microsoft KB, one temporary alternative to get printing working again is (on the Windows Print Server) to:

 

Add a new registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\RpcAuthnLevelPrivacyEnabled (type DWORD)

Set the new key value to 0.

Restart the Print Spooler service.

This should allow cross-server redirection to work as before.

[leewakelam]

I can't find the GPO either

[stkidlasaint]

OK, the workarounds related to the September 2021 patch are both the same and are what was mentioned earlier in the thread:

 

 

Thanks for this fix

One of my site printing start breaking and surely the September update caused this issue. After uninstalling the September update and printers are back to normal.

 

As the security team keeps pushing to have the latest patches on servers and September update again schedule to install again:confused: I have applied reg to fix to as workaround.