Printing discussions have been a constant during my customer engagements, and generally speaking I noticed that there are misconceptions about printing capabilities delivered with VMware View, ThinPrint and Active Directory Group Policies. In addition to that, there are always those questions from the field about how printing should be handled in a VDI environment. What to do with print queues? Should print drivers be deployed to virtual desktops?
I am writing a small series of printing articles, just like I did some time ago with storage, where I will discuss the architectures available, deployment, troubleshooting, printing over WAN etc. This is the part one.
Starting from the beginning
VMware OEMs a sub-set of the .Print Server Engine full-blown product. Many people think ThinPrint is a VMware owned product and/or feature, but it is not. ThinPrint is a German company that stands on its own and was founded in 1999. Their .print generic drivers can be found in a range of strategic partnerships with VMware, Citrix, Fuji Xerox, HP, Lexmark, Microsoft, Wyse, and others. ThinPrint has managed to embed their ThinPrint agent into a range of devices, from Thin Clients to Printers and the company reign almost alone in its market segment.
The ThinPrint OEM version in VMware View allow soft-clients (View Client) to present printers to the virtual desktop. Printing is possible from a virtual desktop to printers that are defined on the client device. The printer drivers and devices MUST be configured and connected to client device. The printers can be local or network connected (direct IP or print server). As today, ThinPrint (TPAutoconnect service) is only supported by View Windows clients.
Update: As Dwayne Lessner (@dlink7) rightly points out; the ThinPrint agent is also available in some Wyse and HP Thin Client devices. I’ll cover those end point devices in the next article of this series. Just making it clear, however it is mentioned in the above paragraph.
The picture above demonstrate the scenarios where the OEM version of ThinPrint will work (black lines), and where it will not work (red lines).
This ThinPrint virtual printing feature does not require additional print drivers to be installed in the View desktop. For remote users (home or kiosk) the ability to present the locally configured printer device inside the virtual desktop is extremely useful. In truth, there is a generic ThinPrint printing driver that is automatically deployed with VMware Tools and VMware View agent (TPAutoconnect service).
Location Based Printing
Location-based printing feature maps printers that are physically near client systems to VMware View desktops, enabling users to print to their local and networked printers from their virtual desktops.
The AutoConnect Location-based Printing for VMware View group policy setting is a name translation table. You use each row in the table to identify a specific printer and define a set of translation rules for that printer. The translation rules determine whether the printer is mapped to the VMware View desktop for a particular client.
When a user connects to a VMware View desktop, View Manager compares the client system to the translation rules associated with each printer in the table. If the client system meets all of the translation rules set for a printer, or if a printer has no associated translation rules, View Manager maps the printer to the VMware View desktop during the user’s session.
AutoConnect Location-based Printing uses 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.
The pictures below demonstrate a Group Policy configuration for the auto mapping feature.
When editing and mapping printers to a specific virtual desktop or subnet verify that required printer drivers are installed on the physical desktop and the printer is actually mapped. The auto connect feature will not automatically deploy drivers, however it will set as Default the most suitable printer based on location and the AutoConnect rules.
To deploy ThinPrint auto mapping you must register the TPVMGPoACmap.dll existing in the VMware View connection server under install_directory\VMware\VMware View\Server\extras\GroupPolicyFiles\ThinPrint\. The registration must be done at a Domain Controller in your Active Directory infrastructure using the following syntax: regsvr32 c:\ TPVMGPoACmap.dll
Drivers deployed to Parent VM
Print drivers may be pre-loaded into the Parent VM and the printers mapped via login script or Group Policies. This approach is useful where printers cannot be configured at the physical device, such as Thin Clients and Zero Clients. The downside is that drivers will have to be managed at the Parent VM level.
It is recommended to keep Parent VMs as lean as possible, and adding multiple drivers to Parent VMs will result in a bloated base image, especially when new printer support is often added to the Parent VM. This could quickly become a management hell depending on the deployment size.
In an organisation with 50 branches there may be 100 different types of printers (I personally have never seen an organisation with standardised set of printers across the whole organisation). Without ThinPrint the administrator would have to pre-deploy and maintain drivers for multiple supported printers at Parent VM level. Deploying printer drivers to the Parent VM would ensure that all child virtual desktops have the required printer drivers when needed.
Most VDI setups remove user’s ability to configure printers and install drivers; however users who have administrator privileges can still install drivers to their virtual desktops without creating a conflict with the virtual printing component (ThinPrint). It is also possible to provide privileges to users to manually or automatically, via GPO, map printers during logon.
Drivers deployed On Demand
Another good option to deal with drivers being deployed inside virtual desktops is automation. If desktop pools are set to Persistent assignment it is possible to use Group Policies and logon scripts to automatically deploy printer drivers and make printers available inside virtual desktop during user’s logon.
With Windows 2003 R2 is it possible to enable the printer management role into Windows. Print Management allow administrators to centrally manage print servers and deploy printers with group policy. Windows 2008 introduced the ability to add printers via Group Policy Preferences.
This article and video about Deploying Printers With Group Policy explain how to implement the solution in few quick steps.
For privilege access configuration refer to Allow Standard Users to Install Drivers For Devices from Specified Setup Classes.
If desktops are set as Floating assignment you are still able to deploy printer via group policies, however it is critical to understand that these operations generate IOPs, Network Traffic and consume CPU cycles. Maybe not as much, but if you require 20 different printers to be available maybe it’s a good idea to think of a different deployment method.
Printing over the Network (Compression)
When using the ThinPrint OEM VMware View utilises the pass-through “printer” to stream the print data to the physical printer. In this case when you print in the virtual desktop, it captures the print job in a “generic” format using the ThinPrint Generic driver, compresses it, and sends it down to the end point. At the end point the data is decompressed and sent to the locally installed print spool. (Note that in this case the end device is a Windows machine running VMware View soft-client; for other types of device refer to .Print Server Engine)
When using specific printer drivers inside virtual desktops the print data is sent from the virtual desktop directly to the printer in an uncompressed native format. As you can imagine, depending on the size of the document this can take up a good amount of bandwidth. For centralised deployments, where desktops are in the datacenter and printers are in remote branches this could be overkill, since this bandwidth consumption goes yet on top of the display protocol and USB traffic amongst others.
An alternative to reduce bandwidth consumption is the adoption of packet de-duplication appliances. As an example, Cisco WAAS provides a feature called Print Application Optimizer (PAO) to accelerate Microsoft Windows printing. When printing documents on printers located at the remote branches, the PAO improves performance as it reduces the number of round trip messages needed to go over the WAN between the Print server and the local printer. Other solutions to be considered are Expands and Riverbed.
.Print Server Engine (this is NOT the OEM version)
If you your printing requirements go beyond than what can be achieved through OEM ThinPrint or automated AD deployment you may need to have a look at the full .Print Server from ThinPrint. This is a paid product and you will get more information at http://www.thinprint.com
The key features provided by .Print Server Engine are:
- Driver Free Printing
- Compression of print data
- Printer Virtualization Layer (V-Layer)
- SSL encryption
- Connection-oriented bandwidth control
- Virtual Channel Gateway
- .print AutoConnect
- Dynamic Printer Matrix
Amongst several features .Print Server Engine allows you to have a single centralized server that contains drivers for the printers in your organization. Using the generic ThinPrint driver virtual desktops push the print data in compressed format to the .Print Server (this is a Windows Servers). The job is then converted and sent in an uncompressed format to the print device.
Optionally, clusters of .Print Server can be created offering the ability to send the print data in a compressed format to the .Print Server in the remote branch. The .Print Server in the remote branch is then responsible for the conversion and final delivery of the uncompressed print job to the print device. Having clusters allow organisations to reduce bandwidth consumption through use of compression and offer additional security since it’s possible to encrypt the data traffic using SSL between .Print Server servers.
Disabling Virtual Printing
If you require to completely disable virtual printing capabilities there are few methods to achieve the same result.
– The first method is actually not to install the ThinPrint AddOn. Refer to my article VMware View 4.5 Command Line Usage to understand how to install View agent without ThinPrint AddOn.
– Secondly, if you are using RDP it is possible to enable/disable the native virtual printing via Group Policies. See example bellow:
HKEY_CURRENT_USER\Software\Policies\VMware, Inc.\VMware VDM\Client\RDP Settings\RedirectPrinters = False
– ThinPrint can also be disabled from the client side by starting install_dir\Program Files\VMware\VMware View\Client\bin\wswc.exe with the switch /noVMwareAddins.
– Lastly, you can also stop the TPAutoconnect service and set it to Disable.