Latest Windows update breaks deployed printers GPO

[Sonic007]

Anyone noticed a problem with deployed printers when installing the latest Windows updates?

 

Member of staff logs in and there are no printers.

 

Doing a gpudate /force does not get them added either.

 

Only workaround I have seen is it will deploy the printers if the member of staff is set as a local administrator on that machine. Which isnt ideal.

 

I dont believe there is a patch for this yet?

 

Anyone else in the same boat?

 

 

Thanks.

Edited October 6, 2021 by Sonic007

[Oaktech]

Partial workaround...

 

https://support.microsoft.com/en-gb/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872

[ITGuyNW]

Does it allow staff to carry on as normal if the patch isn't on the print server?

[Oaktech]

Does it allow staff to carry on as normal if the patch isn't on the print server?

 

I've got both scenarios and with the workaround above in place both sites carry on as before.

[Michael]

This is the only workable solution in a domain environment, unless you're using scripts or a third party tool... it just complicates matters further.

 

Specifying trusted server(s) is greatly going to reduce the surface area of attack, as anything coming from outside would need to match the FQDN. I'm yet to hear of anyone online being compromised in this way despite it not being recommended by Microsoft.

 

I'm curious whether early Windows 11 adopters are having to apply the same fix, or whether Microsoft have properly fixed this? If the issue's still there, then I'd say we're a long way off having a proper resolution to this problem.

[liamrobinson]

I've had the same issue since the August Patch, machines that already have the driver work, new machines don't work. Even with me logging in (Domain Admin) Kinda left it til now as i've been snowed under but i need to sort something, i've paused the September Patch as i know that breaks it even more

[Sonic007]

It is a right pain.

Thanks for your sugestions so far. I will take a look.

 

Does anyone know if there is a way I can inject the drivers for my staff users? So once the drivers are there and they login, the GPO does it's thing and the printers appear?

 

Or maybe just disabling "Only use Package Point and Print" Group Policy will sort it?

Edited October 6, 2021 by Sonic007

[Oaktech]

It is a right pain.

Thanks for your sugestions so far. I will take a look.

 

Does anyone know if there is a way I can inject the drivers for my staff users? So once the drivers are there and they login, the GPO does it's thing and the printers appear?

 

If you follow the partial mitigation workaround in my link you can continue as before, changing the drivers only on the server. If you are determined to have the full mitigation then I would install the drivers by script or GPO or Software Centre if you have it.

[liamrobinson]

I've spent the last couple of hours on this and still having the same issue as you Sonic007. Existing PC's with the drivers already there works fine. However the GPO for new devices (even as admin) doesn't want to deploy.

 

Print Server: Server 2019 with 2021-08 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5005030) (not deploy Sept patch yet)

Client: Windows 10 21H1 with 2021-08 Cumulative Update for Windows 10 Version 21H1 x64-based Systems (KB5005033) (also not deployed Sept patch yet)

 

I've tried the Reg fix issue as outlined, still no avail. If i add the printer manually it works fine. Just the GPO deployment that's not working.

 

I'm deploying the printers like i have done for the past 10 years, Create empty GPO > Go to print server > Print management >deploy via GPO >Choose GPO

 

I know its not a GPO issue as it works on other PC's that have previously had the printers installed.

 

I'm scratching my head now as theres not many people that seem to be having this issue

 

[Sonic007]

If you follow the partial mitigation workaround in my link you can continue as before, changing the drivers only on the server. If you are determined to have the full mitigation then I would install the drivers by script or GPO or Software Centre if you have it.

 

Thankyou.

 

 

So essentially all I need to do is this below? And specify my domain controller which has my printers?

 

Permit users to only connect to specific print servers that you trust

 

This policy, Point and Print Restrictions, applies to Point and Print printers using a non-package-aware driver on the server.

Use the following steps:

 

1. Open the Group Policy Management Console (GPMC).
   
2. In the GPMC console tree, go to the domain or organizational unit (OU) that stores the user accounts for which you want to modify printer driver security settings.
   
3. Right-click the appropriate domain or OU and click Create a GPO in this domain, and Link it here.Type a name for the new Group Policy Object (GPO) and then click OK.
   
4. Right-click the GPO that you created and then click Edit.
   
   
5. In the Group Policy Management Editor window, click Computer Configuration, click Policies, click Administrative Templates, and then click Printers.
   
   
6. Right-click Point and Print Restrictions, and then click Edit.
   
   
7. In the Point and Print Restrictions dialog, click Enabled.
   
   
8. Select the Users can only point and print to these servers checkbox if it is not already selected.
   
   
9. Enter the fully qualified server names. Separate each name by using a semicolon (.
   
   
10. In the When installing drivers for a new connection box, select Show warning and Elevated Prompt.
    
    
11. In the When updating drivers for an existing connection box, select Show warning and Elevated Prompt.
    
    
12. Click OK.
    
    

Edited October 6, 2021 by Sonic007

[Oaktech]

I've spent the last couple of hours on this and still having the same issue as you Sonic007. Existing PC's with the drivers already there works fine. However the GPO for new devices (even as admin) doesn't want to deploy.

 

Print Server: Server 2019 with 2021-08 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5005030) (not deploy Sept patch yet)

Client: Windows 10 21H1 with 2021-08 Cumulative Update for Windows 10 Version 21H1 x64-based Systems (KB5005033) (also not deployed Sept patch yet)

 

I've tried the Reg fix issue as outlined, still no avail. If i add the printer manually it works fine. Just the GPO deployment that's not working.

 

I'm deploying the printers like i have done for the past 10 years, Create empty GPO > Go to print server > Print management >deploy via GPO >Choose GPO

 

I know its not a GPO issue as it works on other PC's that have previously had the printers installed.

 

I'm scratching my head now as theres not many people that seem to be having this issue

 

 

Have you set the GPO point and print restrictions to whitelist the print server?

[Oaktech]

Thankyou.

 

 

So essentially all I need to do is this below? And specify my domain controller which has my printers?

 

That's what I've followed and I've had 0 issues now across 3 schools.

[Michael]

For those of you still experiencing issues after following my guidance notes, I'd highly recommend downloading the latest drivers.

 

- Point and Print needs still remain enabled (User and Computer)

- FQDN print servers specified in GPO

- Regedit must be applied (check on a few clients it's applying)

- Drivers in x64 environments must be WHQL

- In Print Management > Server > Drivers, make sure they're 'Packaged'

- In Print Management > More Actions > View > Add/Remove Columns, select 'Type' and click OK. It should read Type 3.

 

If all the above is correct, then I absolutely see no reason why it's not working. If drivers are not deploying even in a domain admin context, then it'll most likely be something else - for example is DNS correct, can you ping the print server, printers on their own VLAN to workstations. I can't think of anything else?

[Duke5A]

This is the only workable solution in a domain environment, unless you're using scripts or a third party tool... it just complicates matters further.

 

Specifying trusted server(s) is greatly going to reduce the surface area of attack, as anything coming from outside would need to match the FQDN. I'm yet to hear of anyone online being compromised in this way despite it not being recommended by Microsoft.

 

I ended up going this route. As long as the clients and server are at the same patch level (September cumulative) all seems fine.

[liamrobinson]

Update: Was tired yesterday didn't see the Registry GPO hadn't applied properly. For anyone struggling, My DC didn't have the \Printers\PointAndPrint keys after Windows NT (Possibly because no printers installed). When using the browser to find the reg key location i couldn't go any further than Windows NT, i typed the full path into the box instead of using the browser but that didn't seem to work on my clients.

 

After manually creating the \Printers\PointAndPrint subkeys on my DC, the using the location browser, the regkey now applies to the clients and the printers are deploying via GPO again.

 

It's a shame there's no real fx without compromising security, lets see what they bring next Tuesday, my guess is more issues!

 

Thanks for all your help.

[Michael]

Glad it worked My instinct would be as you've described - printers not deploying due to the missing/required registry entry.

 

As I say, I'm yet to hear anyone being compromised as they've got to guess the printer FQDN which could be anything.

[Sonic007]

Has the printing nightmare been fixed? How are you all deploying your printers now?