Printing Architectures for VDI

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.


Scenario Discussion

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

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
  • Tracking
  • 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.


More to come in the 2nd part of this Printing Architectures for VDI.


6 pings

Skip to comment form

  1. Great Article Andre, I didn’t know that the Thin Print OEM driver was deployed with View. I always saw printing as the weakness for View over Citrix based solutions but from your article it looks to be very similar.

    I had a scenario where I had a DC in the UK and office in the US, I used the Citrix Universal Print Driver so that print jobs were sent compressed over to the local PC’s then spooled out to the print server within the local LAN. This provided optimal speed but our next concern was print quality as it was a sales office and high quality printing is what they do. We couldn’t tell the difference, only our top marketing print expert could actually see the difference with the naked eye but it was deemed acceptable. Based on that I could never understand anyone wanting to use native print drivers, however the exception is of course feature rich Multi Functional Devices which do not like the Citrix UPD much. I suppose this is where the Thin Print server comes in though, handy bit of kit to have in these scenarios.

    I wonder if there is any side by side comaprisons of the Citrix UPD and the VMware View Thin Print OEM drivers. Be interesting to see performance, compression rates, spooling sizes, quality and printer feature compatibility for both.

    Great Article, look forward to the next one.



    • Andrew Fidel on 04/27/2011 at 7:32 am

    Craig, most of the issues with MFD’s can be solved by adding the print driver name to a registry key on the client which causes the job to be submitted like a standard application job instead of injected into the middle of the print spooler path. This is nearly as annoying as the old Citrix driver name matching game but at least you only have to deal with unprinted documents instead of crashed spoolers/servers. I wonder if the View client has that workaround for their implementation yet?

    • Ernesto Pineros on 10/25/2011 at 2:16 pm

    Andrew nice article. Only one question? If I´m clear with Thin Print OEM included in VMware View Premier License we can´t use thin clients for print compression right? We need to buy print engine for vmware view.

    Am I right?

    Thanks a lot

  2. @Ernesto Pineros
    Yes, you are correct. The compression work between the virtual desktop to the .print server, between two .print servers, an between a .print server and a ThinPrint enabled printer. Either way you need the .print server.


    • Russ Ferrell on 11/07/2014 at 2:14 pm

    Hi Andre,

    We have WYSE thin clients running VMWare View 5.1. Can we cnnect a USB printer directly to them using Thin Print? Is it even possible to connect a USB printer directly to the thin client we have?

  3. Russ, yes, printing via USB should work natively with your Wyse think clients as long you have the ThinPrint driver installed at the virtual desktops. The ThinPrint is automatically installed with Horizon View agent. Please, also note that VMware does not support printing for Windows Server desktops.

    • Printing Architectures for VDI « on 03/30/2011 at 7:18 pm

    […] here to view the article Citrix, VMWare   Printing, VDI […]

  1. […] 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. […]

  2. […] to learn more about printing in VDI read my previous articles: Printing Architectures for VDI (Part 1) and (Part 2).  Troubleshooting ThinPrint in large environment can sometimes be a daunting task. I […]

  3. […] to learn more about printing in VDI read my previous articles: Printing Architectures for VDI (Part 1) and (Part 2).  Troubleshooting ThinPrint in large environment can sometimes be a daunting task. I […]

  4. […] want to learn more about printing in VDI read my previous articles: Printing Architectures for VDI (Part 1) and (Part […]

  5. […] want to learn more about printing in VDI read my previous articles: Printing Architectures for VDI (Part 1) and (Part […]

Comments have been disabled.