What is the best way to handle Citrix Uniprint traffic?


Article ID: 167280


Updated On:




Uniprint offers a way to get around three Citrix printing issues:
a) supporting large numbers of printers on a Citrix server 
b) problems with "unsuitable" drivers that can cause "blue screens" 
c) large bandwidth used by print jobs

Uniprint works by creating a PDF document (rather than normal "printer data") that gets sent to the client, where it is rendered and printed. Sending data this way GREATLY reduces the bandwidth used for printing, by several orders of magnitude: a 10k Word document can easily create a print job that is several megabytes, while the equivalent PDF file is probably under 100k!

Uniprint can use either of two methods to transfer the PDF file from the server to the client: 
a) client drive mappings 
b) Uniprint virtual channel

In both of these cases, the traffic uses Citrix priority tag 2.


It's usually desirable to treat Citrix print traffic differently from interactive Citrix traffic in order to ensure that users' interactive traffic remains unaffected.

You can do this with PacketShaper by creating a PSPrint exception class that matches to Citrix priority tag 3 and applying a Rate(2) policy to it.

Unlike regular Citrix print traffic, though, Uniprint uses Citrix priority tag 2. Thus, to classify and control Uniprint traffic, you need to create a class to match Citrix-ICA traffic, matching a Citrix priority tag 2, and then apply the desired rate policy and partition.

Be aware that other traffic (for example, client drive mappings -- files transferred to/from the client hard disk) will also use this priority. However, in reality, you would probably also like to control this traffic in a similar way.

For more information on creating Citrix classes, see Classify Citrix and Citrix Criteria in PacketGuide.