Windows 10 1803 GPO Printers Inconsistent

[Boatvan]

This may be a very niche issue I'm having, but Group Policy in my Windows environment has been very spotty lately, especially in the realm of printer deployment. In a perfect world, I could use our status quo of Deployed Printers under Computer Configuration and it would just work. Not the case anymore. Below is an excerpt from my edugeek thread of a possible fix I am testing:

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

I know it is a shot in the dark, but if anyone has this issue or any input, my PO'ed users and I would be grateful. Let me know if you need more information or details.

 

[Solaris17]

Thats odd, I have mine served per computer, as well as two for user IIRC they follow him. I deploy via a print server though and do the GPO modifications from the print server itself and its deployment manager. My print server is domain joined but doesnt contain the ADDS role.

Have you checked your DNS server logs? to make sure their isnt some kind of issue?

 

[Boatvan]

Thats odd, I have mine served per computer, as well as two for user IIRC they follow him. I deploy via a print server though and do the GPO modifications from the print server itself and its deployment manager. My print server is domain joined but doesnt contain the ADDS role.

I neglected to mention the following details and caveats:

-This is mainly occurring on profiles that are logging into the PC for the first time when the "traditional" GPO printer deployment is used under Computer Configuration.
-Student account profiles are "pruned" after 10 days of not being logged into that particular machine, essentially making them semi-temporary
-My print server is also domain joined and running Windows Server 2016. I'll have to check what roles it has active, but I am 99% sure it only acts as a print server
-We had issues using temporary profiles using Windows 10 LTSB but migrated toward 1803 education as LTSB causes more issues than it fixes
-We temporarily fixed this by adding a scheduled task to gpupdate /force shortly after login
-This only started happening again as of a couple weeks ago, so I suspect it may be a bug in an update?

EDIT: I can provide more details/error messages tomorrow as it does throw an error in group policy logging

 

[Solaris17]

We temporarily fixed this by adding a scheduled task to gpupdate /force shortly after login

Hm this alludes to the problem. I too had issues with 1803+ I had to gpupdate /force and reboot the machines, sometimes more the once.

The difference between our setups is my environment is pretty static, techs are assigned workstations, and while others can log in without issue, I do not prune user profiles as often. I keep mine at 30 days.

Additionally all of my workstations are on static IPs. And my DNS lease times are set to 1 day (24 hours) in AD I think the default is 7. Im not sure if it has anything to do with your environment but those are pretty big differences and I have a gut feeling about it, because I ran into similar.

If your in the EDU space your network load is also probably higher then mine since you have alot more fluid users. I dont know how much control you have over your environment though, im pretty lucky in that I own the infrastructure so I can touch whatever I like.

 

[Macgyver69]

This may be a very niche issue I'm having, but Group Policy in my Windows environment has been very spotty lately, especially in the realm of printer deployment. In a perfect world, I could use our status quo of Deployed Printers under Computer Configuration and it would just work. Not the case anymore. Below is an excerpt from my edugeek thread of a possible fix I am testing:


I know it is a shot in the dark, but if anyone has this issue or any input, my PO'ed users and I would be grateful. Let me know if you need more information or details.

Hi Boatvan,
I believe we are in the same boat and have been for a long time now (i.e. ever since we went from Windows 7 to Windows 10), Windows 7 never had this problem!.
We to have an open area <200 PCs, Domain Environment for students, Deleting Profiles through GPO after 2 days, Deploying Printers through GPO (Printer installed through Print server).
I could talk forever on all the testing we have done on this but I will leave that to when I am writing a book and will call it the neverending story!
Now cutting to the chase we believe that we have it nailed down to mainly one thing PROFILES NOT being Deleted Properly! but that then opens up a few more bags of worms as to why. The GPO is set to delete any profile that has not been used for 2 days (48 hours) and then on reboot they get removed or do they??? It does seem to delete all the data but leaves the hidden Appdata folder behind.
Now we install the printers through the User Configuration so that we can set a default printer (yes we tried every way through gpo) and yes that works Perfectly every time for the users first time logon and also it works every time that a user logs on before the 48 hours lapses.
Now once the 48 hours lapses and the PC restarts it attempts to delete the profiles and most if not all of the time the users Profile folder gets left behind with everything deleted bar the hidden Appdata folder (e.g. C:\Users\StudentUserName) and then when the User try’s to log on they can no problem but guess what NO PRINTERS! Now if you simply run a gpupdate (don’t even need a gpupdate /force) the printers come in straight away or if they log off and back on the printers will come in. this is not ideal and is a major problem.
Now this could be resolved by Never deleting Profiles again but they fill up the Hard Drives quickly due to the number of students logging in on a daily basic.
We do have more testing to try and find ways of removing what may be preventing the User Profiles from being deleted (To Me it looks like the UWA (Universal Windows Apps) eg. Skype).
But I think it is Microsoft that need to provide a proper way of deleting these profiles through GPO or some other deployable mechanism.???
I have not proved this for definite but I am really quite confident it is the incorrect Deletion of profiles that is the issue for us and it sounds like this could be your issue too.
So can you check the profiles on your PCs to see does this match up and if needs be change your deletion to 1 or 2 days for testing purposes for a week or 2 and you will see on Mondays that they will be the highest fail rate!!!
Note we Shutdown all the PCs each night and use the BIOS to start them up at 9am each morning as restarting the PCs everyday is useful to this testing also!
Also watch out for the Hidden NTUSER.DAT file that is inside a working User Profile and the date on that I think may be what it uses to tell the GPO when to delete the User Profile.

I am very curious to see what results you come up with after testing out my findings???

S

 

[Boatvan]

@Macgyver69 , my apologies for not updating this, but my loopback method worked it seems. I am not in a position to test this at this time since my workaround is low impact and seems to work. If this ever changes, I will keep your method in the chamber. My true hope is that Microsoft fixes this, but how likely is that? If I have time in the near future, I can try this on some test machines. I appreciate your work on this.

Here is an example of a Group Policy Object that successfully adds the printer to the profile:

"Configure user Group Policy Loopback Mode" in [Computer Configuration>Policies>Administrative Templates>System>Group Policy>] Enable and set to merge (Not sure what would be different if set to replace, depends if the policy is only there to connect to a printer)

Navigate to [User Configuration>Preferences>Control Panel Settings>Printers], right click and select "new" then"Shared Printer"

Select Create in the dropdown and put in the share path. I wouldn't set any default printer on this since you are about to replace.

Click apply then OK.

Next, right click an empty space and select new and shared printer once more

This time select Replace in the dropdown and also put in the share path once more. You may set the printer as default now if you so desire

Click apply and OK once again.

It should look like this when you are finished:

At the time of this issue I didn't have the time to dig into the why, but only how to fix it. I did start to come to the conclusion that the improper deletion of the profiles was the culprit.

Hope this may help someone someday!

IMPORTANT EDIT - You may want to set the "Remove if no longer applied" in the "Common" tab of the first two screenshots. I have it set for the "Replace" object because they are very stubborn once added in case you ever wanted to remove it.

 

[Macgyver69]

Hi, that's no problem at all I'm glad to hear you have a fix but we use a loopback policy to deploy them too.
But if I understand you correctly that you create and replace the same printer in the same policy. If so that is probably the only thing we did not try. But I will surely test it and that would be great if it works and if it does work I will post back here to let you know. But still I believe it is a big Microsoft problem that they don't want to fix.
Thanks for the quick reply.
S

 

[Boatvan]

@Macgyver69 Through trial, error, and some online searching, I pieced together that the initial "create" is the failed attempt to add it (possibly partially created) and the "replace" function forces it to re-add it successfully. My big fear was any sort of login time impact, but luckily in my environment, it adds no noticeable time to login. I wish I could really dig deeper into the why, but you are correct that Microsoft needs to fix this natively. I think their focus has shifted to their cloud (Azure) Active directory/Group Policy, but the majority of us still use on-prem and will be using it for the foreseeable future. With all these updates to other things, though AD/GP is not "sexy" like OS feature updates, many people rely on these functions every day and Microsoft should be taking these seriously.