Jump to content

2021-10 CU - KB5006672 - Cannot print...


Recommended Posts

Posted

Quick update... computers without the update still printing OK.

 

Removing update manually not going well so far... sitting on 100% complete for the last hour now!

Posted (edited)

Yeah ok, that's fixed it so the question is if it is something with my set-up (as there aren't many other people on here shouting about it)... or just another f'ed up MS update?

 

Trouble is the computers I've had problems with don't have Point and Print set.

 

Other test computers that do are taking forever to install the update and will take even longer to uninstall it no doubt... can't see I'll get it sorted out before I leave!

 

2012R2 print server doesn't have it installed yet either (will it help if server and clients are on the same CU level?).

 

Do I pull it from WSUS now or wait and see if I come into chaos tomorrow morning?

Edited by Koldov
Posted (edited)

Yes I'm sure it probably is, but this is the latest CU released to our WSUS last night (that was started for the August CU and carried on for the September CU).

 

Also, that thread is getting awfully long now and I'm not sure if the fixes in it are still relevant or if this new CU has broken things even more.

 

Now I'm getting all sorts of reports from users who have lost their printers and don't even have the CU installed!

 

Even as admin I can't right-click and see the Printer Properties to do a test page... remove the printer, reinstall it, test page, hang...

Edited by Koldov
Posted

Well if I run

 

add-printer -ConnectionName "\\\"

 

as a non admin with the registry setting to enforce only drivers can be installed as admin. Its possible to create a printer connection. Printer Connections via GPO seem broken if used in the user context.

 

So you need the drivers per deployed to devices and then the mapping in the user context not SYSTEM :confused2:.

.

What a pain trying to make sure drivers are deployed to devices and then setup some PowerShell command from the run command

Posted
After the registry key is in place to allow non-admins to install print drivers the issues I've seen were caused by the clients and server being at dissimilar patch levels. I installed the October Cumulative update on a couple of Windows 10 LTSC clients and left the print server, Windows Server 2019, at September. Clients could still print just fine to the Papercut queue. I don't know if this means anything though. Beforehand the server was at a higher level whereas the clients were at a lower. I'll find out tomorrow morning after patches are installed on the servers and report back then.
  • Thanks 3
Posted

That could be something...

 

Our clients (LTSC) updated to the October CU, but I have been unwilling to do the servers (2012R2) just yet so they are still behind.

 

I've pulled the clients CU in WSUS, so we are back to being ok, but I guess I'll have to be brave at some point and get everything up to speed and see if everything still works then...

 

Just for added bonus points, does anyone know once I've done 'Approved for removal' on an update in WSUS (but not declined it), is it just a case of selecting it again and approving it when I want it reinstalled...?

Posted
We have this at our school too. Just pulling the update from our print server now to see if that resolves it. Are others experiencing this if just the client updates? That is a step-up from last month where it was just the server patch that broke things.
Posted
Well if I run

 

 

 

as a non admin with the registry setting to enforce only drivers can be installed as admin. Its possible to create a printer connection. Printer Connections via GPO seem broken if used in the user context.

 

So you need the drivers per deployed to devices and then the mapping in the user context not SYSTEM :confused2:.

.

What a pain trying to make sure drivers are deployed to devices and then setup some PowerShell command from the run command

 

Thanks for this info... what method are you using to deploy print drivers to devices? And do you then have a powershell script to map the printers per user? Seems like an extremely big task for someone like a large secondary who has complex print allocation via item level targeting.

Posted
All seems well. I can confirm clients (Win10 1809 LTSC) with the September update can still print to the server (Server 2016) with the October update.
Posted
All seems well. I can confirm clients (Win10 1809 LTSC) with the September update can still print to the server (Server 2016) with the October update.

 

Same here, but some clients still on August/September patch, 2016 Servers all patched up to September, printing works fine.

 

I work with WUfB rather than WSUS, so all clients are 30 days behind the current patching level. I should thank you lot for being my beta testers month on month :D

  • Thanks 1
Posted
Thanks for this info... what method are you using to deploy print drivers to devices? And do you then have a powershell script to map the printers per user? Seems like an extremely big task for someone like a large secondary who has complex print allocation via item level targeting.

 

 

I'm just using Printer Connections (Computer and User) which seem to not work with the default behaviour (RestrictDriverInstallationToAdministrators not present) or with the RestrictDriverInstallationToAdministrators set to 1. GPP Shared Printers in the user context work as does Add-Printer.

 

You could have a AD Group targeting devices which SCCM syncs as a collection to deploy the drivers and also Item Level target the GPP Item against the AD Group. If you don't have may drivers you might as well deploy them across your whole environment.

 

However I don't think this is good enough from Microsoft given that printers have to be mapped in user context.

 

Its a shame you can't define a share where drivers can live where users can download them so point and print works as intended. Theoretically an attacker could compromise the share.

Posted

I've had reports of printing being broken coming through, but not as many as I thought I would have... possibly they just haven't shut down their laptops and done the updates.

 

Now I'm in a silly position where some have the update, some haven't and some have already had it installed and then uninstalled from WSUS, so even if I wanted to redeploy it I'm not sure everyone will get it... and a few people have moaned about it taking so long to uninstall...

 

Might just go crazy and approve the October CU again for all clients and remote in and do the servers tonight and just see what happens...

Posted
Also seeing this. October update installed and printing stops. Looks like server reports bad username or password in event viewer. Anyone else getting this in event viewer?
Posted

Well, I wasn't brave enough to update everything last night (couldn't face dealing with the chaos on a Friday)... As we are a 'live' environment if you like, it seems the only way to deal with these ridiculous MS updates is to install them see if they break something and if they do, uninstall them and wait for those with more time and resources to find a workaround.

 

I've currently been a little naughty holding off on the server updates for our print server VM (2012R2), so currently it's ticking away quite happily on August CU.

 

The only problem is, it makes troubleshooting a little more difficult with everything being on different OS and CU...

 

So currently I have:

 

Print Server 2012R2 - August (I know)

 

Clients (LTSC) - September (rolled back because October broke printing)

Clients (LTSB) - October (seem mostly OK, I did have one user email me complaining he couldn't print but now he says it is working)....

 

Now, it could be that the problem is the server being at the August CU so at some point I'll have to test getting everything up to the same CU level, but really not looking forward to it.

Posted (edited)

Ok, so now I am getting users (LTSB) reporting that they can't print... :mad:

 

Managed to speak to one and it seems that although they have had the latest October CU installed since Wednesday and they printed yesterday (Thursday) it was to a Brother printer... but today the issue is has become apparent because they tried to print to a Kyocera printer!

 

Pulling KB5006669 from WSUS now...

 

EDIT: Can't really understand why this thread (or any of the others for that matter haven't blown up)...

 

Everybody else printing OK with October CU...?

Edited by Koldov
Posted

Is it that hard to spin up a dev domain with a print server to test updates?

 

The spooler had 2 more vulnerabilities that were patched in October.

 

Print Nightmare continues.

 

There is a reversal method but is based on Microsoft admitting there is an issue and not removing the whole update.

Posted (edited)
Is it that hard to spin up a dev domain with a print server to test updates?

 

I don't know but I guess there are a lot of variations in the general public's estate - printer models, driver versions, OS versions, CU levels... gotta test 'em all!

 

Anyway, it has finally worn me down to the point that I am going to do just that for our estate (firing up multiple VMs as we speak)... and finally put all CUs on 'approval' in WSUS.

 

There is a reversal method but is based on Microsoft admitting there is an issue and not removing the whole update.

 

Is that the one replacing these from a known working (pre October CU) machine...?

 

Good Printer.JPG

Edited by Koldov
Posted
Ok, so now I am getting users (LTSB) reporting that they can't print... :mad:

 

Managed to speak to one and it seems that although they have had the latest October CU installed since Wednesday and they printed yesterday (Thursday) it was to a Brother printer... but today the issue is has become apparent because they tried to print to a Kyocera printer!

 

Pulling KB5006669 from WSUS now...

 

EDIT: Can't really understand why this thread (or any of the others for that matter haven't blown up)...

 

Everybody else printing OK with October CU...?

 

Yeah, all quiet on the western front here.

Posted (edited)
Yeah, all quiet on the western front here.

 

I couldn't work out from the other posts where your servers and clients ended up in terms of CU?

 

Here you have clients on (LTSC) with October CU and server (2019) at September CU...

 

I installed the October Cumulative update on a couple of Windows 10 LTSC clients and left the print server, Windows Server 2019, at September. ----- I'll find out tomorrow morning after patches are installed on the servers and report back then

 

Here you have clients (LTSC) on September CU and server (2016) on October CU...

 

All seems well. I can confirm clients (Win10 1809 LTSC) with the September update can still print to the server (Server 2016) with the October update.

 

I think you have at least established the October CU for the server might not be the problem. But I started this thread because my clients (LTSC and now LTSB) had updated to the October CU and that had broken printing, the server (2012R2) is still on August (just to complicate matters - because I was trying to avoid this MS chaos)...

 

Do you have any clients (LTSC) on October CU?

 

EDIT: At least it gives me the confidence to get the server up to the October CU! :)

Edited by Koldov

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...