Printing Architectures for VDI – Part 2

Some articles get stuck and never get published. I wrote this one a while back and for different reasons the publishing was delayed. However, while reviewing some of the new features in VMware View 5.0 I noticed that the Location Based Printing feature has been extended.

Location based printing support in View has been extended to include all non-Windows based clients supported by View Client (iPads, Android HoneyComb and CIUS).  This feature continues to be configurable via Windows Group Policies and enables IT to allow end users to print to the nearest network printer as they roam between sessions across devices.

This feature extension allow those devices to print to the closest network printer without any client hardware dependencies.

This is the second part of the Printing Architectures for VDI series. The first part of this series I published earlier this year, and can be found here.


Handling Reconnection from Different End-Points

The Location-based printing feature maps printers based on a name translation table. This operation happens during user logon and utilize the VMware View Client Volatile variables to identify the client system’s IP address, name, and MAC address, and the user’s name and group.


Understanding TPAutoConnect and .Print client communication

I have briefly mentioned the generic, aka universal, ThinPrint printing driver (TPAutoconnect) in my previous article. TPAutoconnect is the service that provides the sub-set of .Print (full product) capabilities. The .print client is loaded as a plug-in and wrapped by VMware View client. The service is responsible for enumerating all available printers.

ThinPrint AutoConnect (TPAC) is responsible for creating the users session printers and, after logoff/disconnect, to remove those printers again. Installed as a service process TPAC receives system notifications about new/reconnected user sessions also about session disconnect/logoffs.

When a new session is signaled the service has to find this session, gather the correct user credentials and start a process which communicates with the .print Client about the to be created printers. At session logoff another process is spawned to remove the not longer necessary printers from the system.

The ThinPrint Output Gateway (TPOG) printer driver is a generic printer driver for Windows32/64 systems. Microsoft defined a standard for data exchange between applications and the print spooler subsystem. This format is called EnhancedMetaFile (EMF).

The TPOG provides the interface to the applications and thus gathers the complete print data. Those data are then transferred to the local machine and are brought back to the local print spooler by the .print Client.

TPOG based printers which were created by AutoConnect provide a number of standard properties transferred from the local PC:

  • resolution
  • duplex
  • paper formats + margins
  • paper trays

Additional printer properties which may be available locally such as stapling, booklet printings etc. are proprietary enhancements not defined by Microsoft. Those settings can’t be used with the TPOG.


ThinPrint Port Monitor

The ThinPrint port monitor is the heart of the .print Engine. It acts as transport layer for the Windows print spooler. Main features are:

  • Multi protocol (virtual channels like PCoIP/RDP/ICA, TCP, LPD, serial port for VMware ACE or offline mode for VMware View)
  • Integrated to Windows print system – port pooling, cluster ability
  • Control of bandwidth for print data
  • Print data are transferred compressed

When a user connects to the virtual desktop the TPAutoConnect service starts a process to communicate with the .print Client and the end-point. Note that the client-device must support .print technology. This end-point can be the VMware View Windows softclient or a ThinClient with the .print client. If the end-device in use does not support .print technology only network printers are enumerated.

The printer creation process is done in 3 steps:

  1. get the printer list
  2. get the printers properties
  3. create the session printers with transferred properties

Steps (1) and (2) are performed by the tpautoconnect.exe (user) process and (3) by the TPAutoConnect service.

The tpautoconnect.exe process on the virtual desktop queries the .print client for state changes every 30s. Only the status change flag is transferred, not the whole printer list. If there were changes to the local printer setup (newly created printer, a printer was removed from the list etc.) the AutoConnect complete communication process is executed once again.


The Windows Printing Architecture

The workflow below demonstrates a common Windows Printing Architecture without use of ThinPrint technology. The second workflow demonstrates how ThinPrint hooks into the printing path and replaces the printer driver with a Universal driver.

  1. User Prints from App
  2. Application submits print job to GDI
  3. GDI creates EMF (Universal highly compressible windows language)
    with info from driver
  4. GDI passes EMF to Print Spooler
  5. Print Provider sees EMF data
  6. Sends EMF to Print Processor for conversion (Rendering)
  7. GDI converts EMF to RAW (language printer understands little compressibility)
  8. GDI passes RAW data to Spooler
  9. Print Monitor sees RAW and sends to printer


The ThinPrint Printing Architecture

  1. ThinPrint replaces driver with Universal
  2. Adds a Printer Port “TPPort” to Windows Print Monitor
  3. Processor + Driver (ThinPrint Output Gateway – TPOG) adds “secret sauce” and does not render to raw
  4. Print Provider + Print Monitor (TPPort) compresses and places EMF data in RDP virtual channel streamed in small chunks



Defining Default Printer when Local Printer is connected

The default printer assigned to any given user may be defined by a formula such as If network=x, than default printer=y. That is true when using Location Based-Printing.

However an interesting characteristic from the virtual printing technology, perhaps a small bug, with RDP or PCoIP is that if a local printer is attached to the end device, it will always be set as the default user’s printer, ignoring the name translation table setup via Windows Group Policies.

Despite some say it is a bug, the behaviour avoid that users connecting from home print mistakenly to the office or branch mapped printers. I have to agree that maybe there should be a better way to handle that. A possible solution would be perhaps to identify if the user is connecting from within the corporate network or not.

In the meantime, a possible solution is to disable the TPAutoconnect service when the user is logging from an external network. Using the View Agent Group Policy execute a VBScript or PowerShell script during user logon. The script should utilize the VMware View Client Volatile variable ‘View Client_IP_Address’ to identify where the connection is coming from and then disable the service with net stop “TP AutoConnect Service”.

Optionally, you may set the script to run every time the user connect or re-connect to the virtual desktop. This can be done utilizing the CommandsToRunOnReconnect registry entry, or configured it via windows group policy.



[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\VMware, Inc.\VMware VDM\Agent\Configuration\CommandsToRunOnReconnect]


More to come in the 3rd part of this Printing Architectures for VDI series. I’ll try to push it out soon. The first part of this series can be found here.


4 pings

Skip to comment form

    • Paul on 10/31/2011 at 6:01 pm

    Nice article; clear and informative. Thank you for taking the time.

  1. @Paul
    Thanks for the feedback.


    • Paul on 01/18/2012 at 8:05 am

    Hi Andre, do you know of any way to change the default resolution settings of the TPOG driver? I have read – correctly or incorrectly – that using Universal Print Drivers instead of the specific driver increases the size of the print sppol quite dramitically? We are currently testing location-based printing on Wyse terminals and it is very slow over 256K link with .4ms latency. In you opinion is there any way to improve this (rather than upgrading the link!) 🙂

  2. @Paul
    VMware View uses ThinPrint as for Universal Driver. You should talk to ThinPrint to install a spool server in each branch to improve printing times. Their printing server will compress the printing content.


    • Rick on 12/11/2012 at 5:07 pm

    Does this work with solutions like pharos or shared printers?

  3. @Rick
    I am not familiar with Pharos printing capabilities. Yes, you can used shared printers via a file server for printing from your VDI solution.


    • Luis Osorio on 02/01/2013 at 9:29 am


    Is thin print already setup to locate the printer nearest to you. O do i have to do that configuration?

  4. Luis, you have to register the ThinPrint DLL and configure the location based printing via Group Policies. You should be able to find instructions in the Administration Guide.


    • carl on 12/25/2014 at 9:41 pm

    Hi Andre, I could not tell the difference between virtual printing and location based printing. Could you give me a hand?

  1. […] Reference: (second para of the […]

  2. […] Exam PDF   VCAW510 practice test   VCAW510   VCAW510 exam dumps Reference: para of the […]

  3. […] Exam Dumps   VCAW510 dumps   VCAW510 Study Guide   VCAW510 exam simulations Reference: para of the […]

Comments have been disabled.