Making ThinPrint Work with VMware View and Liquidware Labs ProfileUnity

Our Providence address:
999 Main Street, Suite 715
Pawtucket, RI 02860
401-272-6688
Our Boston address:
800 South Street, Suite 300
Waltham, MA 02453
855-679-2971

Making ThinPrint Work with VMware View and Liquidware Labs ProfileUnity

Added on: 06.07.13, by Andy Ward

The Configuration:

I started down this road with what seemed to be a bizarre problem that I can’t say I had run into before - a small VMware View 5.1 environment using ProfileUnity 5.5. My master image had been configured with all of our network printers served from a 2008R2 print server. The individual user accounts had only the appropriate printers installed and default printer configured per each user’s physical location. ProfileUnity printer portability was being used to maintain these settings across recomposes.

The Problem:

Everything was great with this configuration until I recomposed the pool. My long term goal was to be able to use non-persistent desktops with “destroy on logoff” - so smooth operation after a recompose was important. On the first logon, the default printer was never what the user had originally set. The default always ended up being the first named printer alphabetically - so the Adobe printer was it. After working with  Liquidware Labs support, we determined the culprit was ThinPrint. I tested by disabling the TPAutoConnect service on my master and composing with a test VM/account and it worked great. That, of course, led to another problem as I do have a number of remote users who rely on ThinPrint for remote printing. TP has allowed me to not have to worry about what kind of USB printers people are using at home. It just works, so I needed to keep it available to any user based on where they connect from. I also have a couple of users internally with USB printers that are using it.

I needed to dynamically control this for all of my users because my internal staff will likely need to connect remotely via a View Security server. Because of this, I needed to be able to determine if a user was connecting from one of our internal LANs or remotely and then run a script to control ThinPrint appropriately. After some trial and error, it was discoverd that running “tpautoconnect –d”, which disconnects TP connected printers, sometimes dropped the default setting to the first alphabetical printer again, depending on the state of the system when it last logged off and saved its settings. The problem here was if a remote user, using ThinPrint, logged off with the TP connected printer active as default, the profile was saved with this setting. If this user logs in at the main office the following morning, without the need for TP as the printers are all served on the network, the system becomes confused at logon and just selects the first available printer alphabetically when it no longer has its prior default. It’s like shutting your computer down, physically disconnecting your default printer, and booting back up. Which printer will be default now? The answer is Adobe PDF.

The Requirements:

As stated previously, I needed to determine if the user was connecting from the internal network with our usual network printers or from a remote location where ThinPrint would be necessary. After making this determination, I would need to ensure that ThinPrint would be off for internal sessions and on for remote sessions. Additionally, I want to be sure that ThinPrint disconnects its connections (tpautoconnect –d) and stops its service BEFORE the user logs out. This will ensure that a user’s default printer at the main office never gets overwritten by a TP printer in the profile settings. Given my options, I decided to leave the ThinPrint service in manual mode in my master image. This would be an easy configuration for the bulk of my internal users as they simply don’t need it. My tasks beyond that were to ensure that the service starts up when a remote user logs in. Also, I want to be sure to run the tpautoconnect –d command and stop the service on log off which I scripted to run quietly and for everyone regardless. As an extra precaution, I set up a script to stop the service at logon for my internal users. It will run 99% of the time while the service is already stopped, but if it saves one person some aggravation, then I’ve done a better job.

The Steps:

ProfileUnity offers a ton of options to determine who, what, or where a connection is coming from. I ended up using a filter, shown above, to read a volatile environment variable from the registry. Since I have a separate connection server for remote connections through the Security Server I decided to use the “ViewClient_Broker_DNS_Name” variable under “HKCU\Volatile Environment”. A remote user connects through ViewCS3.mydomain.local while internal users connect through ViewCS1 or ViewCS2 (load balanced). The filter looks into the registry to see if the View Client Broker is ViewCS3 or NOT. That’s it. It is or it isn’t. Pretty simple. Gotta love Unity!

Now that I can tell the difference between internally and externally connected sessions, I need to fire off some scripts. I’ve got two ProfileUnity “Application Launcher Scripts” and one “User Defined Script”. Despite the names, they’re all just batch files. One challenge is that all of the scripts are either starting or stopping the ThinPrint service (TPAutoConnSvc). All of my users are just users. No admin rights here so by default they can’t start or stop services so the script was useless until I changed that. Via Group Policy on the container that holds all of my View VMs I created a new policy and gave my “ProfileUnity” user group, which is the default licensing group for Unity, the right to start and stop the TPAutoConnSvc service. In your Group Policy editor you can find “services” under “Computer Configuration\Policies\Windows Settings\Security Settings\System Services”. It was listed on my Group Policy editing system only because the TP services are installed there.

Here is what I did with the scripts:

1.

** Script is launched DURING UNITY CONFIGURATION EXECUTION.

Filter (Detect_External_Client – shown above) is using “OR” logic.
Any one condition must be met. This allows me to specify my
internal users with USB printers to ride the same rule as they need TP.

- External user determined by “External User Filter”

ViewClient_Broker_DNS_Name – Registry value IS = ViewCS3.mydomain.com”

OR
Username Contains – Username with local USB printer needing TP to operate.

APPLICATION LAUNCHER SCRIPT 1:
named “tpacSTRT.bat

@echo off
net start TPAutoConnSvc

 

2.

** Script is launched DURING UNITY CONFIGURATION EXECUTION.

- Internal user determined by “Internal User Filter”

ViewClient_Broker_DNS_Name – Registry value IS NOT = ViewCS3.mydomain.com”

APPLICATION LAUNCHER SCRIPT 2:
named “tpacSTOP.bat”

@echo off
"c:\program files\vmware\vmware tools\tpautoconnect" -d –q
net stop TPAutoConnSvc

 

3.

** Script is launched BEFORE ProfileUnity AT LOGOFF (Pre-Logoff)

- All users – internal or external. No filter needed here. We’re just firing off a script at logoff.

USER DEFINED SCRIPT 1:

named “tpacSTOP.bat” **Same script as above.

@echo off
"c:\program files\vmware\vmware tools\tpautoconnect" -d –q
net stop TPAutoConnSvc

The Results

This worked very well and did exactly as I intended. The only down side is that when a user doesn’t log off, but only disconnects and then connects back up from another location. Without the logon/logoff process, we’re not accomplishing anything. I’m a stickler with my users about logging off daily anyway because I want to ensure that profile components are being updated regularly. My next project with this will be to use the View ADMs to fire off a VB script to query the same registry keys and execute the same batch files during re-connect.

View All Blog Articles