Citrix printing can be, or at least can be made, pretty complex, unfortunately I had to find out the hard way myself. When troubleshooting print issues the path a print job follows throughout your infrastructure is always a good place to start especially when its performance related. However, you do need to understand the differences between the various routes a print job can take, why and where it could impact performance. I remember a few years back all this got me buzzing… Let’s start and see what comes up.
The term printing pathway refers to the route a print job follows to reach its destination. This destination can be a printer directly attached to the user’s device, a workstation for example, or a network printer which communicates with a Print server. It also encompasses the location where the print job gets spooled. Both aspects are important as routing affects network traffic and spooling affects the utilization of local resources on a XenApp or Print server. Basically there are two pathways: The network printing pathway and the client printing pathway.
The network printing pathway
Used by network provisioned print devices: Print jobs are routed from the XenApp server hosting the user session and executing the application, over a network connection (uncompressed) directly to the print server, here it gets spooled and processed. The output is send to the network print device:
Note: If the XenApp and print server are on different domains (no trusts) or no network communication is possible, XenApp will automatically route the print job through the client printing pathway, which I’ll highlight shortly.
Depending on how your physical infrastructure is set up, and because the data being transferred is uncompressed, this could potentially impact overall performance. Imagine that both the print server and print device are in a remote site away from the XenApp server but near the client devices (which is not uncommon). Using the network pathway the uncompressed data needs to traverse the (WAN) network from the XenApp to the print server. Depending on the connection between the two locations users might experience latency. Off-course we could apply quality of service by limiting printer bandwidth through policies or perhaps make use of Branch Repeater and so on, but that’s an whole other blog post on its self. On the other hand, if the XenApp and print server, along with the print device are all in the same site and connected over a fast local network this is the preferred configuration to use. Ideal for LANs not for WANs.
But wait… You can control how data is sent to and from the print server by using the client printing pathway in conjunction with the network printing pathway, even when only network print devices are used, more on this in a minute.
The client printing pathway
The term client printing pathway refers to print jobs that are routed over the ICA protocol through the client device to the printer (either a printer connected directly to the client device or connected through a print server a.k.a. network print device) and spooled on the XenApp server.
The simplest configuration is when a print device is directly attached to the client device. The XenApp server will send the print job back to the client device (jobs are spooled locally on the XenApp server) which will forward it to the locally attached printer:
The advantage here is that the ICA protocol is used to send, and thus, compress the data. So even if the client and print device are physically separated from the XenApp server ICA is still used to send and compress the data across, for example, the WAN.
Now back to the client pathway in conjunction with the network pathway remark earlier. When client print devices get provisioned they can either be (I know, there are other possibilities) locally attached or accessed through a print server, which basically means using the client or network printing pathway. You can however, configure XenApp to make use of the client pathway when using network provisioned print devices. In this case print jobs are not routed from the XenApp server to the print server but are routed through the client device to the print server, which again adds the advantage of using the ICA protocol for compression, among other features:
If we think back to our first example (both the print server and print device are in a remote site near the client devices), uncompressed data travelled the network from the XenApp to the print server etc… If we, in the same scenario, configure XenApp to use the client pathway for use with network provisioned print devices, the data will be compressed through the ICA protocol and sent back through the client device, print server etc… Problem solved, Citrix recommends this configuration.
To force network print jobs to be routed through the client device (client pathway) you need to disable the Citrix policy: Direct connections to print servers.
Be careful when using this configuration, you need to make sure you have the right physical infrastructure in place. Example: you have two locations, site one and two. One holds the XenApp and print server; two has all the client devices and network printer. If you disable the ‘Direct connections to print servers’ Citrix policy, the data will be send back and forth and eventually will be send uncompressed to the print device. This behavior will cause excessive and unnecessary network traffic, this is why:
First off, remember that when disabling the policy, XenApp print job traffic is routed through the client device en no longer directly to the print server. In the example given (site one and two) first the data is send to the client device, through ICA, from site one to site two, then it is forwarded back to site one from client device to print server (uncompressed as the print server doesn’t make use of the ICA protocol) and in the last step the data, again, gets transferred back to site two, to the print device (also uncompressed). This is a good example when not to use this feature. In this case you just leave it be, then the print job data gets send directly from the XenApp to the print server on the same site where it gets spooled and forwarded to the print device in site two. Also uncompressed but two data transfers less!
There also is a ‘session printer’ Citrix policy which can be used to specify the network printer(s) to be auto created in a session, which will make use of the network printing pathway by default. There might be situations where the Direct connections to print servers policy is disabled, so al jobs are forced to be routed through the client devices, but you also want to provision one or two network print devices that make use of the network printing pathway because they’re located within the same physical site and are connected over a fast LAN. Session printing makes this possible, the best of both!
Off-course there is more to it than just the print pathway used, but hopefully this gives you kind of an idea, an helicopter view, on how things work underneath.
Bas van Kaam ©
