GPO Printers no longer working after 1511

[Sheridan]

In our test room we've noticed that since updating to build 1511 none of the GPO deployed printers are working anymore. Each PC simply logs the error "Group Policy was unable to add per computer connection \\server\printer. Error code 0x57"

 

The same GPO's are working on the Windows 7 machines so its not like the names or drivers are missing. The error code just seems to be a generic failure one as well. It does seem to work if you're logged in as an admin though.

 

One thing this test room has proved is that W10 is a complete pain!

Edited July 18, 2016 by Sheridan

[Michael]

This looks like the same problem, be it Windows 7.

 

I've deployed the July 2016 Windows 10 update and had no issues/reports of printer issues.

 

I suspect it could be a security issue - relating to Point and Print Restrictions (if not configured).

[Michael]

Looking at specific details here I'd say I'm right, it probably is linked to Point and Print Restrictions, but also the likes of unsigned drivers.

 

I know you can override it in 32Bit environments, not 100% sure in 64Bit but I know it's enforced by default.

[Sheridan]

We haven't got any point and print restrictions set on our Win10 GPO's - we've deliberately cut the policies back to the minimum for a fresh start so they're all set to Not Configured.

[Michael]

We haven't got any point and print restrictions set on our Win10 GPO's - we've deliberately cut the policies back to the minimum for a fresh start so they're all set to Not Configured.

 

Well you definitely need to configure them.. User and Computer GPOs otherwise you're probably seeing lots of UAC prompts which will be otherwise supressed using Point and Print Restrictions.

[free780]

Are you using fqdn for your print server in gpp?

[Sheridan]

These are machine deployed printers - using the \\server\printer name. It worked fine in W7 and was working ok in W10 until recently. And now it seems to be working again since I restarted the print service on the print server! I'll have to reboot a few of the clients to see if it starts playing up again.

[FN-GM]

This has started to be an issue for us. Did you manage to fix it please?

[Michael]

This is the fix.

[FN-GM]

Our driver is already "true" for packaged

[mrbios]

Printing in 1607 is literally the only windows 10 problem i have right now, been ongoing since deployment. Luckily I'm only deployed to 10 in the library and 6thform, but periodically i get machines where the printer hasn't mapped. All my drivers are "true" for packaged same as @FN-GM, I've set the registry key for "LegacyDefaultPrinterMode" and i've got the full FQDN set in my approved point and print servers list. I also notice in security on the event viewer you can see the point the driver tries to install and fails. Adding the printer manually then works fine!

 

Such a frustrating problem.

[free780]

I found spaces caused the issue with mapping. So I got rid of the spaces.

[Jobos]

I found spaces caused the issue with mapping. So I got rid of the spaces.

 

And did removing the spaces in the printer name solve the problem?

[FN-GM]

I found spaces caused the issue with mapping. So I got rid of the spaces.

 

And did removing the spaces in the printer name solve the problem?

 

Our printer name has spaces but not the share name. Where did you remove the name please?

[mrbios]

Personally mine don't have spaces in the name or the share, so i doubt it's that.

[newpersn]

Personally mine don't have spaces in the name or the share, so i doubt it's that.

 

 

Thats my point and print. I haven't added no server name to the list. All print drivers have been modded to be true for being packaged

[mrbios]

[ATTACH=CONFIG]43030[/ATTACH]

 

Thats my point and print. I haven't added no server name to the list. All print drivers have been modded to be true for being packaged

 

Wasn't there a windows update (albeit windows 7) that required the servers to be defined in that list late last year? I think i assumed that change would have carried across to windows 10 and added that in. I'll try my policy with the the top tick box removed.

[newpersn]

Wasn't there a windows update (albeit windows 7) that required the servers to be defined in that list late last year? I think i assumed that change would have carried across to windows 10 and added that in. I'll try my policy with the the top tick box removed.

 

Not had any problems since moving away from .vbs to GPP. You havent got any poilcys interfering with your printers? Ours is all set within our main Windows 10 policy and with Level targeting. (work fine for windows 7/8.1 and 10)

[FN-GM]

Did anyone manage to get to the bottom of this please?

[mrbios]

Did anyone manage to get to the bottom of this please?

 

I still have this same issue. Sometimes printers map, sometimes they don't. I've had to enable AD searches so that kids can add printers through the word "add printer" method, which is annoying.

[newpersn]

Anyone checked the event viewer?

[free780]

Or enabled GPP debug logging?

[jtotheb]

Did anyone manage to get to the bottom of this please?

 

Possibly...

 

Printers deployed via GPP based on the computer that the user is logging onto via loopback mode. (Classic "Delete All" at the top of the list.)

Point and print restrictions configured.

Drivers on the print server are of the packaged variety.

Roaming profiles which should be removed on logoff.

Windows 10 Education x64 1703

 

On first logon from cold printers were largely not available to the user.

Event Log -> Application -> Group Policy Printers "Group Policy object did not apply because it failed with error code '0x80070057 The parameter is incorrect.' This error was suppressed."

 

Log straight off and back on and boom there they are.

 

Tried using Add-Printer Powershell. Similar results from cold with the 0x80070057 error displayed in the script window.

 

Add the printer manually and all is well.

 

Scooby Doo fade...

 

Having made a successful connection to the printer, we want the connection info from the registry:

HKCU\Printers\Connections\ for the printer in question.

 

Put this into GPP -> Windows Settings -> Registry - I was using the registry wizard whilst editing the GPO and then cutting and pasting the printer connection key to the top to tidy it up as this GPO is just for printers. With a key folder per printer it makes the targeting easier.

Apply the item level targeting to the key folder as you would to the printer itself (big red arrow).

Edit: Possibly missed a key point here. The printer itself still needs to deployed in the GPP Printers section (if that wasn't particularly clear).

???

Profit

 

I'm now seeing no errors in the event log and I've gone from seeing 90+% failure on first cold login to 90+% success. (*Whispers* So far it's been 100% success but I don't want to tempt fate or anger the computer gods)

 

A bit more legwork than I'd like, but if it works every time I'll live with it for the time being.

Edited September 20, 2017 by jtotheb

[mrbios]

Interesting fix @jtotheb i'll test this out myself soon and report back

[Katy]

We have printers randomly not connecting (not very often, about 5% of the time) deployed via GPP with Win 10 1607 Ent. Might try the registry thing above and see if that fixes it, but we get an error along the lines of "The printer name is invalid" in the event logs (but log off/on again and it maps fine, add it manually and it maps fine, so the printer name is obviously not invalid).

Printing in Windows has always been awful, how can it be that difficult to just work reliably