XenApp/XenDesktop 7.6 Network Printing Considerations

Printing is always a challenge in a XenApp/XenDesktop design, as so many different criteria come into consideration.

Note: I’ll use XenApp from now on, but from a printing design point of view, it does not change a lot between XenApp and XenDesktop, unless you are using RemotePC feature of XenDesktop (more on that at another time?)

On eDocs, some scenarios are covered, and there is one question that I’m often asked by customers when working on a XenApp design relates to the location of the print server. We always say that data should be close to the XenApp server. Is it the same for the Print Server location?

Different printing design possibilities

Often, in XenApp architectures, the Print Server is located in the datacenter, close to the XenApp server. With that setup, the important piece is the RAW bandwidth sent by the print server to the actual printer. It is also worth noting the use of SMB protocol between XenApp and the Print Server:

If you add Citrix Universal Print Server component to that configuration, HTTP will replace SMB, but the critical part remains the RAW bandwidth to the remote printer:

When the Print Server (here with UPS component) is located in the branch office, the focus switches from the RAW printer data to the traffic between XenApp and the Print Server as it’s the one being sent over the wire:

The goal today is to determine what print driver language offers lower bandwidth usage, where the location of a print server is best suited, based on the kind of documents and printing technology (Microsoft print server, Citrix UPS, Citrix UPS+UPD) used.

Of course, no one only prints a single type of document, however based on statistics that you can get within your company, these tests results might assist you in your decision.

Lab configuration

I have been using Citrix UPS 7.6 (on WS2008R2 SP1, as the WS2012R2 compatible release isn’t publicly available yet) with latest hotfixes and XenApp 7.6 on WS2012R2 with latest hotfixes (including UPS7.6 hotfixes) to connect to a published desktop. All is hosted on XenSerer. The printer is a Canon  iRC2030, declared as IP printer on UPS VM with the UFRII, PS3, PCL5e and PCL6 drivers (all 14.02 release except the PS3 which is version 21.52).

Note: UFRII is a proprietary Page Description Language (PDL) developed by Canon. I recommended reviewing Canon’s website for more details about this technology.

The tests

Printers were defined as Session Printers in XenApp and 3 tests performed : UPS disabled, UPS with native driver and UPS with UPD driver.

Sample DOCX, XLSX, PPTX and PDF  documents have been used (ShareFile link), all coming from the Citrix website. Microsoft Office 2010 and Adobe Acrobat Reader 10.1.4 were used. WireShark runs on the UPS VM to gather the amount of data sent to UPS and to the printer.

The tests performed without UPS are used as the reference, providing bytes and duration of the transmission to the endpoint (either UPS or printer). However, the duration to the printer does not include the actual print time, that is the amount of time required for the whole print job to be physically printed. Why? because I was far from the printer when I run my tests… 🙂

Disclaimer: the numbers are not real life numbers but gathered from a lab environment, with sample documents. You should perform similar testing to determine what is best suited in your environment.

Microsoft Network Printing results

Citrix UPS with native drivers

Citrix UPS with Citrix UPD driver

XenApp to Print Server traffic

To ease reading, a graphical view can be easiest, showing the traffic from XenApp to Print Server depending on the type of printer used (PCL5, PCL6 or UFRII) and the printing technology.

Using a PCL6 driver seems to be the most logical solution, compared to PCL5 and UFRII. It is worth noting the overhead generated by UPS over native Microsoft printing and I would recommended, if you want to evaluate UPS, to test with native drivers. Why? Because UPS embeds printing traffic in XTE service (Apache based service) which can lead to NetScaler TCP/HTTP optimization and load balancing (that’s for another topic some day).

Print Server to Printer traffic

To ease reading, a graphical view can be easiest, showing the traffic from Print Server to the traget printer depending on the type of printer used (PCL5, PCL6 or UFRII) and the printing technology.

PCL6 language is the best choice (I can’t explain the results with PDF and UPD when printing to PCL6, even if several tests have been done) if the bandwidth optimization between the Print Server and the printer is the ultimate goal.

Summary

From this testing, UPS will not help reducing the bandwidth but offers a free Universal Printing solution (no drivers anymore on XenApp!) and might benefit from NetScaler load balancing and TCP optimization (to be confirmed in another blog post…). PCL6 seems to provide a suitable choice for anyone wishing to limit the printing bandwidth either to the Print Server or to the Printer.