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:
- 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:
- get the printer list
- get the printers properties
- 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.
- User Prints from App
- Application submits print job to GDI
- GDI creates EMF (Universal highly compressible windows language)
with info from driver
- GDI passes EMF to Print Spooler
- Print Provider sees EMF data
- Sends EMF to Print Processor for conversion (Rendering)
- GDI converts EMF to RAW (language printer understands little compressibility)
- GDI passes RAW data to Spooler
- Print Monitor sees RAW and sends to printer
The ThinPrint Printing Architecture
- ThinPrint replaces driver with Universal
- Adds a Printer Port “TPPort” to Windows Print Monitor
- Processor + Driver (ThinPrint Output Gateway – TPOG) adds “secret sauce” and does not render to raw
- 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.