Tuesday, July 16, 2013

Local ThinPrint Printer & Non-persistent VMware View Desktops aka (Thin)Printer Hell

Quick thanks to the Oatmeal for reminding me why printers were sent from Hell to make us all miserable.

Had an usual request at work. End user using View is located in an office where we do not own the network. The printers and end points are not ours to control. This makes it interesting when dealing with printers and non-persistent desktops.

This particular case involved the following:
  • End User uses a Windows client to connect to View.
  • The local printer installed on the Windows client is a network printer.
  • The local printer installed in the virtual desktop via Virtual Printing method as defined by VMware.
  • End User is assigned a non-persistent, floating desktop pool. Desktops refresh after log off.
The Problem:
The printer is not set as default and the user must change it to the default every time they log in.

We use Liquidware Labs to manage profiles and I wondered why it wasn't capturing this particular setting.  I opened a case with them to investigate.  While I waited I decided to read the Thin Print manual for fun and see if I could utilize our ThinPrint GPO to resolve the issue.

VMware's documentation on the ThinPrint GPO really isn't detailed enough. You can find hints of what to do here and here.  However the documentation is still sorely lacking and you need community resources like this to really find out how to use the Group Policy Object, especially for location based printing.

In the ThinPrint GPO the last column is "IP Port/ThinPrint Port" but the documentation never explains what the "ThinPrint Port" is. On page 24 of the Thin Print manual is documenation that describes the ThinPrint Port and how the name is determined.
Using this information and information from the virtual machine the end user was connected to I drafted the a configuration for the GPO. Below is the configuration after I exported it to a CSV.
true,*,*,*,mydomain\username,hplaser,"TP Output Gateway!hplaser#:3"

I tested this while I was logged in as the end user. I removed all printers created by ThinPrint AutoConnect Service, refreshed group policy and then restarted the ThinPrint AutoConnect Service. It appeared to work OK. For the final test I logged the user out of their desktop and asked them to log in again. Since they are assigned to a non-persistent, floating desktop pool they received a new desktop.  The printer was set as default after login.