[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 97
  • Last Modified:

Network printer becomes inaccessable randomly in 2012 R2 RDS sessions

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.
Failed printer screenshot
Does anyone know what could cause an issue like this or how to diagnose it further?
0
DonovanV
Asked:
DonovanV
1 Solution
 
DonovanVAuthor Commented:
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.
0

Featured Post

[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now