Jump to content

Windows 10/Server 2012 R2/2016 Printer GPO issues


Recommended Posts

Posted

Hi All,

I have an open thread on Technet, but I wanted to try here too as I am not really getting much in the way of suggestions. Please see below for the thread I made there that explains my issue and everything we've tried:

 

https://social.technet.microsoft.com/Forums/windowsserver/en-US/105c614d-8f53-4b69-885c-cb8f0d8c25bc/windows-10server-2012-r2-printer-gpo-issues?forum=winserverprint#105c614d-8f53-4b69-885c-cb8f0d8c25bc

 

Basically, we are trying to deploy printers to windows 10 machines from a print server. We have tried both our original Windows Server 2012 R2 and a brand new Windows Server 2016 print servers with the same result. We have tried both Group policy Preference deployment and Deployed printers. The users being affected are domain guests (students). This means the profile is removed from the local machine each time a domain guest logs out. We are getting error 513 in the event logs when the printers try to add. For any further details, please refer to the link. To retype it all would make this a wall of text.

Posted

Several things come to mind -

 

- What's the make/model of printer and are the drivers signed?

- I presume all your clients are 64Bit?

- And thirdly (through trial and error myself), have you tried deploying the FQDN with GPP printers?

Posted

Hi Michael,

The issue is make/model independent. We have had a Kyocera copier with this error as well as HP printers. We tried both older and newer signed drivers from the vendors.

All of our clients are 64 bit. We do however have a mixed Win7 and Win10 environment. We are currently seeing this issue only on the Win 10 machines. We have the same issue on both LTSB and full fledged Win 10 Education.

We have tried the FQDN with GPP with the same 513 error. The details of this error are vague. It reads "the parameter is incorrect".

Posted

Do you know which flavours of Windows 10?

 

LTSB could be 2015 or 2016 and Education could be 1507, 1511, 1607, 1703 or 1709.

 

I know you've tried GPP, but have you tried the Fully Qualified Domain Name in the path, rather than NETBIOS? I've had printers deploy 'better' specifying the full path \\server.domain.com\printer share name, rather than just \\server\printer share name

 

It's one and the same, but that's Windows for you!

Posted

Hi Michael.

I appreciate your quick replies!

LTSB 2016 is what is on the "production" PC's. I was mistaken on the other one, it was Windows 10 Pro, not education on a test machine. The version of the Pro Test machine was 1709. Also, yes, we did do both NETBIOS and FQDN names in GPP, even the IP address of the server in the FQDN. Same error across the board.

Posted

Have you tried good old fashioned scripts? this might get you working whilst you look for a "proper" fix with GPP. Scripting does have one benefit - you can asymmetrically add printers via scripts to avoid long login times (GPP pauses and waits for timeout when a printer is offline or missing).

 

don't forget you will need "loopback processing" if you are putting this USER logon script in a computer OU

 

on error resume next

Set WshNetwork = CreateObject("WScript.Network")

WshNetwork.AddWindowsPrinterConnection "\\\"

WshNetwork.SetDefaultPrinter "\\\"

set wshnetwork=nothing

Posted

Hi there,

We are an odd case because we assign printers by computer instead of by user. To my knowledge, there isn't a way to assign printers on startup using scripts. As described in my Technet thread linked above, I think it is less of a GP thing and more of a Domain Guest issue. Please see my below workflows for the conditions that cause the printer to not add. Maybe this will clarify. It is quite hard to explain otherwise.

 

REBOOT--->Sign in as "Existing" Temp Profile--->NO PRINTERS--->LOG OFF--->LOG BACK IN AS SAME USER--->PRINTERS ADD

REBOOT--->Sign in as "New" Temp profile--->PRINTERS ADD

REBOOT--->Sign in as "New" Non-Guest profile---> PRINTERS ADD

REBOOT--->Sign in as Existing Non-Guest profile--->PRINTERS ADD

 

 

An "existing" Guest is a domain guest that has logged onto that particular pc in the past. A "new" guest is one that has never logged into that particular PC before. This issue does not affect regular profiles.

Posted

Assign the .vbs to a computer OU as a user logon script and ensure Loopback processing is enabled as "merge".

 

For the original issue, my guess is permissions. Somewhere along the line permissions are causing an issue. an existing guest already has the printer and doesn't query for additional drivers, queue, server information. A new guest has to and is failing somewhere.

Posted

Hi KK20,

I think you may have misread my workflow. I don't blame you, it is quite confusing. An existing temp profile is the one not getting the printers. New guests get it right away. I also would like to mention that as a Domain Guest, no trace of the user should be left once they log off anyway. Everywhere I look, the permissions are the same for a domain user and a domain guest. If you have a particular spot in mind to look, please let me know.

 

As for the .vbs workaround, I would consider that an absolute last resort. Our district is large and the complexity of setting up scripts and accompanying policies would be monumental.

 

I also know that eliminating domain guests would fix it, but it is either that or pay for Deep Freeze, which also causes some odd issues.

Posted
We're in the process of testing using the VB script listed and Loopback processing as a means of deploying printers in labs. Seems to be working on our test environment. We're hoping an alternative method can be found without the use of scripting. Lastly, we have several labs. Is it best to enable loopback processing in every single group policy for each lab? Or set loopback processing at the domain level and then just have each lab GPO include the VB script only?
  • 11 months later...
Posted
Did you ever find a fix for GPP and domain guest accounts. Getting a similar issue over here.

 

Hi there,

Ironically, we thought we had a workaround until just recently. We are again testing methods to get the printers to consistently add.

 

Our original remedy was to add a scheduled task to gpupdate /force at login while adding the printers in Deployed Printers under computer settings. We have been migrating to Windows 10 Education v1803 over the past few months. We also switched from guest accounts for students to persistent profiles that are pruned after 10 days of not logging in on that machine, so in a way, still a temporary profile, albeit a little less temporary.

 

I am currently testing a very very messy workaround in a few of our labs to see if it works. My new fix is as follows and boy is it ugly.

Please note I am still testing the validity of this fix!!! Attempt at the risk of wasting a lot of time if this ends up not working!!!

These steps are assuming you are creating a new policy for each formerly deployed printer. If policies exist, edit and remove the deployed printer in the computer settings and do as follows to the existing policy:

 

1: (Computer Configuration>Administrative Templates>System>Group Policy)

Configure user Group Policy loopback Processing mode ----> Enable and set to "Merge"

 

2: (User Configuration>Preferences>Control Panel Settings>Printers)

A: New Shared Printer for the printer you would like deployed (set to Create in properties)

B: New Shared Printer again for the printer you would like deployed (exact same settings, but set to Replace in properties)

 

So there it is possibly. You have to create then replace the printer for the blasted thing to appear. I will update with screenshots and verification that it works in the coming week. I am currently awaiting testing results from the users from my test labs.

 

I pray to the printing gods that this works because I have a lot of PO'ed users at the moment...

Posted (edited)

Thanks Man. I am currently following suite with User Configuration>Preferences>Control Panel Settings>Printers using a CREATE then, UPDATE for that same printer. It is working pretty well. I also have noticed perhaps our server 2012 which hosts these printers gets hit around 100 % cpu utilization at times.

 

How many printers are your deploying off of your server? Also, how many printers do you deploy to each OU?

We have around 20 shared printer queues, 2 printers in about 10 different OU's

Edited by UOFM
Posted

We've had this exact same problem as mentioned here and I believe that we have now found a fix. The issue is to do with the printer mappings against the users SID in the registry not clearing out. When they log on for the second time it tries to pull from the reg which doesn't work.

 

To remove the entries on logoff, take a look at this thread here with the registry entry needed... http://www.edugeek.net/forums/windows-10/191185-disappearing-printers-15.html#215

 

Since implementing the change I have struggled to replicate it. The only thing to bear in mind is that if a user has already logged onto a machine, then they may not get printers on the first logon since implementing the change, as the entries still exist within the registry, but after a subsequent logoff, they shouldn't get that error on the same machine again.

  • Thanks 1
  • 2 months later...
Posted

Fellow IT guys,

I know this has sat dormant for a long time, but the below method is working flawlessly for me. Thank you to all that gave suggestions. I will quote my post that I was first attempting this with.

 

"1: (Computer Configuration>Administrative Templates>System>Group Policy)

Configure user Group Policy loopback Processing mode ----> Enable and set to "Merge"

 

2: (User Configuration>Preferences>Control Panel Settings>Printers)

A: New Shared Printer for the printer you would like deployed (set to Create in properties)

B: New Shared Printer again for the printer you would like deployed (exact same settings, but set to Replace in properties)"

 

 

I posted detailed instructions in another forum and I hope it is OK to post this link:

 

https://www.techpowerup.com/forums/threads/windows-10-1803-gpo-printers-inconsistent.250182/

 

It is a little ways down and posted by Boatvan (with Screenshots!!!!)

 

 

I wish I could dig into the "why" further, but I think we are on the right track with improper deletion of profiles. I hope this may help someone in the future.

  • Thanks 1

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