Another printer deployment problem

[swpmre]

Hi,

One of our sites is having printer deployment issues.

 

We are using Windows Server 2012 R2 and Windows 10. We deploy printers through Print Management to specific OUs.

 

Sometimes (and by no means a majority of times) the printers don't appear on PCs. Usually a reboot, or reboots solve the problem and the printer deploys.

 

It is not all rooms/computers, but it is several different printers, though I cannot see a pattern.

 

Does anyone have an idea of what the problem might be?

 

Martin

[ShellfishClive]

It could be that the printer isn't disconnecting when the pervious user has logged off. Are all the other do you have any other policies that are in the same GPO and do they always work?

[swpmre]

Yes, the GPOs seem to all apply correctly. It's only with printers that I've seen the problem - which is of course not the same as there not being other problems, but I would be surprised - drives always map, etc etc.

[TechMonkey]

No clues in Event Viewer? I've normally found when the printers don't apply, or take awhile to apply, it is a misconfigured printer mapping that is hanging while it tries to contact the incorrect address. Another trick I use is to set a delete all printers rule first, which clears out any issues.

[Katy]

I've found with Windows 10 it just does what it wants with printers - randomly ignores the mapping and the log claims the printer name is invalid, yet log off/back on and suddenly it is valid again. Random users, random computers. I'm currently using a powershell login script as it can be forced to keep trying to install the printer until the error goes away (usually the second run through the loop), and I've moved my printers onto a 2016 server as some were showing as "printer does not exist" on random users and random computers.

 

I hope you find a solution in your specific case, but I've had these issues for over a year without any proper pattern or reason (or fix) and they happened on all version of win10 we've tried (LTSB 1511, 1609 Enterprise, 1703 Enterprise, 1709 Enterprise)

[ShellfishClive]

I've found with Windows 10 it just does what it wants with printers - randomly ignores the mapping and the log claims the printer name is invalid, yet log off/back on and suddenly it is valid again. Random users, random computers. I'm currently using a powershell login script as it can be forced to keep trying to install the printer until the error goes away (usually the second run through the loop), and I've moved my printers onto a 2016 server as some were showing as "printer does not exist" on random users and random computers.

 

I hope you find a solution in your specific case, but I've had these issues for over a year without any proper pattern or reason (or fix) and they happened on all version of win10 we've tried (LTSB 1511, 1609 Enterprise, 1703 Enterprise, 1709 Enterprise)

 

We map printers by using GPO to drop a file onto the C drive and then a .bat file runs on login and adds the printers based on the file dropped. We've found this has always been a better way to do it as GPO is so unreliable when mapping them.

[swpmre]

But, unless I'm misunderstanding you, that couldn't be the case here as the printer does make sometimes?

[Katy]

On ours the printers were mapping 99% of the time probably, just the 1% had absolutely no pattern - random users, random computers, sometimes changing user on the same machine the printer appeared etc.

[ShellfishClive]

But, unless I'm misunderstanding you, that couldn't be the case here as the printer does make sometimes?

 

I think the issue lies with the way policies work then they are applied to machines. The printer simply take too long to map when logging in that is what causes the issue. You can get this with Drive Maps too however that's more straight forward so they apply so much quicker, which makes them apply most of the time.

 

It's just GPO being GPO in this case.

[Duke5A]

I've seen printers do some screwball things of late. We're running LTSB 1607 with printers served off of Server 2016 deployed via GPP. Our issues weren't with the deployment method though, but were with driver's failing to copy over properly. These failures are visible in the Application Log inside Event Viewer. GPP does refresh at a set interval though, so will reapply even after the user is logged in.