1

I've recently moved about 40 users onto some new Windows 2012 R2 RDS infrastructure. They are all logging onto their RDS sessions from thin clients with no local resources attached (printers, drives). The network printer connections were rolled out via GPO. The printer shares are from another 2012 R2 file and print server. Roaming profiles and also folder redirection are in the mix if it matters.

The issue we are running into is that every morning I'll have one or two people call me about their broken network printer. The way the printer becomes broken is particularly confusing to me. I've never seen this type of issue before. The user is unable to print to the printer but the properties are still accessible. In the windows "devices and printers" control panel it looses its mini icon denoting it as the default printer. Setting any other printer to default results in no change. In powershell, listing the printers does not show the failed printer. Trying to add a printer via powershell will also result in no change. You can not remove the printer with powershell either as it isn't able to be found in its failed state.

How I have been fixing the issue so far is to remove the printer via the control panel UI. This causes another printer to be selected as the default printer and the mini icon shows up again. Finally, I issue the command in powershell to re-add the failed printer. The UI can be used as well, I just prefer powershell.

Here is a screenshot of the printer in its failed state. enter image description here

Does anyone know what could cause an issue like this or how to diagnose it further?

Digital ink
  • 490
  • 10
  • 22

2 Answers2

0

The easy print protocol very easily loses connection to the forwarded printers in a remote desktop session. This is usually caused by momentary network hiccups. The easy solution is to log off and back on. I have yet to see a more graceful recovery method.

AggrostheWroth
  • 1
  • Isn't Easy Print only in play for printers that are attached to the client? We are running thin clients that do not run windows and don't have local printers. – Digital ink Aug 29 '16 at 23:58
0

Here is the solution I've come to on this issue. I've removed the single printer deployment setting from the group policy governing the users in question. Its been a week without incident and it directly corresponds with that change. I can not explain how that helped though. The printer setting was a "create" entry. From my reading of how the different printer deployment options work, that entry should never have taken action as the printer was already present for each user. That said, here I am, problem free.

If anyone has any insight it would be appreciated. Dealing with this issue is making me think twice about group policy. I may be looking to powershell for printer deployment in the future.

Digital ink
  • 490
  • 10
  • 22
  • I never use create, as after it's applied it's no longer applied. (in example if you change a setting in the printer after it's deployed) I use "modify" without problem at that level. (if all print driver are pre-installed on the server) – yagmoth555 Sep 12 '16 at 17:20
  • Create fit the bill for this job though. My intent was to have the printer created in the event that any new AD accounts were made. I was expecting it to have zero impact after a user got the printer. – Digital ink Sep 13 '16 at 19:35