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 ©
31 responses to “Citrix Printing Pathway… an overview”
Great Article, printing scenarios can indeed be very confusing. The citrix knowledge base article is not very clear about the different scenarios. good to see you outlined it very well. thanks for sharing this with the community.
My thoughts exactly, I did use some of the Citrix E-Docs for reference but once I made it ‘my own’ the whole concept became more clear. Glad you liked it and thanks for the reply!
This is a great article! There are also third party printing solutions such as Tricerat that are great for printing in Citrix environments. Here is a link. http://www.tricerat.com/
Thank you Jason, I will give it a look! Glad to hear you enjoyed it.
I have a dilemma where my customer have the xenapp servers and print server in one central location and the clients and network printers are spread on wan sites with not very good bandwidth. At the moment they are connecting to a published desktop and are using the network printers from the central location – there are no servers on the WAN sites. They are complaining of course, especially when printing PDF files. As I understand you article (very good btw!) my only option here is to use TCP/IP printing on the wan clients and treat them as local client printers? As I see it Client Network Printers are of no use for us since the print server are separated from the clients i.e. the print job has to travel over the WAN link three times albeit compressed between the XenApp Server and the client. Or have I misunderstood you?
Hi Robert,
First of all, thanks! You understood correctly :-) You don’t want to use the client printing pathway with your print server set up this way. Local print servers could be an option, but I’m guessing that’s a no go? Uhm… yes you could use TCP/IP printing. When you set up an TCP/IP printer you need to select ‘Local printer attached to this computer’ so this might work over ICA as well, I’m not a 100% sure. If it doesn’t I doubt if it will boost performance since the (uncompressed) data still needs to traverse the network, you’ll skip the Print Server and spooling will take place locally on your client devices, this might speed up things a bit. Give it a test :-)
If it does work… It will require some additional administration regarding printer setup, configuration and maintenance. I hope there aren’t to many clients per location? This way you will also generate some extra network traffic on your local LAN, shouldn’t be an issue, but you need to be aware.
Let me know what you think and or keep me posted!
Regards,
Bas.
Thank you Bas for confirming my theories! :-) And you are right; it’s not an option to put print servers on all the remote offices, although this would be the best option imo, at least from an administrative perspective. I’ll keep you posted regadring ICA compression with TCP/IP printing.
Regards, Robert
You’re welcome just give me a shout :-) Hope it ends well for you, good luck and have a good weekend. Please let me know how it turned out.
Hi Robert,
How is it going? Did you ‘solve’ your print issues?
Regards,
Bas.
Direct TCP/IP connections cause Citrix to use the ICA pathway :) We do this here – AD GPOs create TCP/IP printers on the client which Citrix redirects to the user’s environment. Printing then follows the client path as the TCP/IP connection is a local printer.
Nice! Although suspected, it’s nice to know for sure. Thank you for sharing Michael! Good note on the GPO :-)
Regards,
Bas.
Hello Bas,
I have the exact same issue as Robert in terms of where the print devices, print server and XenApp servers are located and the only option I can currently see is to use the method described by Michael.
What I’m wondering though is if the Citrix Universal Print Server can solve the administrative overhead by simply installing the client on XenApp 6.5 and the UPS service on the print server. However I cannot for the life of me find out how the UPS printing pathway categorically works. Do you happen to know what the printing pathway is for UPS and how the compression works? It appears as though the print jobs are compressed on the UPS and sent directly to the print device, but how would it decompress at the other end ready for printing?
Hi Andrew, good question, unfortunately I don’t have an answer at the moment, let’s look into it shall we :-) ?
Looking at the project phaser blog http://blogs.citrix.com/2011/11/17/project-phaser-universal-print-server-tech-preview-released/ it looks like it uses the Network pathway based upon the drawing and comments like:
“The solution does not in any way depend upon client capabilities because the clients are simply not involved in the printing functions.”
I’m really not clear on understanding how the compression works if this is the case. Sounds like it is shrunk server-side and sent to the print device. I don’t really see how that will work though. Plus there seems to be no information anywhere on what the expected compression ratios are.
Hi Andrew,
I had a look as well, and yes, the answer is no ;-) It indeed focuses on the network printing pathway. UPS was, or is, initially designed to support universal printing to network (session) printers, meaning the printing pathway. The UPS has been designed to deal with the P2P issue, which automatically sends the printer driver down to the client (XenApp Server) when a (network sessions) printer is mapped, through policies for example.
UPS is based on the same architecture as the UPD (Universal Print Driver) that has been around for a while now and is used to prevent third party driver installation on XenApp servers, but is specific to client printers. UPS does the same but for (session) network printers. So all network (session) printers being provisioned through a Microsoft print server won’t need a native or third party driver on the XenApp / XenDesktop server.
As far as the compression goes, indeed, not much information on that. The increased WAN compression, when XenApp and Print servers are apart, comes from EMF (UPD) within the CGP which is used in the UPS architecture, but no exact numbers. Have a look here In your situation I think you’ll be better of with the client pathway as discussed in the article, if you the situation you describe is like Roberts.
Great article – My cenario is slightly different. We have a corporate XP build and the organization has migrated from a Novell NDS managed environment to a Windows AD managed environment. The desktop OS is still XP and there still exists the Novell client but the primary authentication is through Windows. Novell client is used primarily for some legacy Novell file shares. I personally have an unmanaged Windows 7 desktop and have no performance issues printing (15sec) on either of or PS4.5 or XA 6.5 farms. BTW using TCPIP direct printing. However from the enterprise XP desktop next to me when I print anything from Citrix the 1st time I print a document it normally exceeds a minute and a half. If i print the same document in the same session again it prints in 20-30sec. If I open a new document in the same citrix session and print it, the 1st print again execeeds a minute and a half and subsequent prints of the same document in the same session take 20-30 secs. I tried the policy setting suggsted in your article to force the client pathway and this made no difference.
Any thought on this would be appreciated .
PS – User Autentication domain and Citrix farm AD domains are different with no trusts in place.
Hi Craig,
Unfortunately I don’t have much time at the moment (I’m at a customer site) but will give it a look later. You say your situation is slightly different, with the Novell clients you mean, or is your infrastructure set up differently; print server, XenApp server and clients separated?
Hi,
Sorry for late reply. We went on with TCP/IP printers for users with the highest demands. We did as Michael, i.e. used GPOs to create the ports and printers. This is the way we did it http://claymoore.wordpress.com/2009/02/04/deploying-tcpip-printers-with-group-policy-preferences/ . One thing to keep in mind with this setup is that if your wan sites have really low bandwidth or are oversaturated and the printer driver is not present on the client, the install may take a long time to complete – in our case (Kyocera drivers) it took up to 20 minutes for the printer to be installed on XP machines, with Windows 7 it became a lot better but still took a fair amount of time.
Thank you Robert, better late then never :-) Good to hear. I assume that once everything was in place, drivers installed and printers set up etc… it worked as expected? Thanks again, this really helps!
Yes, once in place it worked as expected, but there is no magic to poor networks, so although things improved the customer still need faster links, but that’s another story. :)
Hi Bas
I have some further evidence regarding the slow performace issue
I got the desktop team to add a direct tcpip printer to the enterprise XP PC (don’t ask – infrastructure team here do not have elevated rights to managed desktops). Tested printing from Citrix – No delay. Printed to via the AD print share and it was slow. Unfortunately we have multiiple authentication domains and a lack of trusts between them and different teams managing them so it is quite difficult and time consuming to co-ordinate a troubleshooting exercise. From where I stand scnario of xenapp and print server in different sites to client and physical printers. Have tried the
disable the Citrix policy: Direct connections to print servers
Made no difference
Hi Graig,
Finally found some time :-)
Correct me if I’m wrong, but if I understand correctly then your XenApp and Print servers are separate from your client and print devices, right?
If this is the case, then I think I know why TCP/IP printing works relatively quickly as opposed to your original configuration which is using the network printing pathway.
Using your original configuration, I’m still assuming that your XenApp and Print servers are separate from your client and print devices, print traffic travels from your XenApp server to the Print server, quickly because they’re on the same site. The print server does his job and sends the print job over the network (uncompressed) to the print device. Could be slow because the data travels the network uncompressed.
If, using this set up, you configure your environment to use the client pathway then the job will travel the network (compressed) to the client device, then back to the Print server (uncompressed) and again from the print server to the print device (uncompressed).
However, if you configure direct TCP/IP printing, then it will again travel the client pathway but it will skip the print server since it will ‘think’ that the printer is directly connected to the client device. So you start a print job on the XenApp server, it will travel (compressed) to the client device and from the client device to the printer! Fast, because they’re close together.
That’s probably why TCP/IP printing is the fastest of the tree. Does this make any sense?
So in your case, forcing to use the client pathway will only increase the delay. If the above is correct then using TCP/IP direct printing might be the way to go, or you could rethink and redesign your printing infrastructure, which is probably going to be an issue, but I thought I’d mention it anyway :-) Let me know what you think.
Regards,
Bas.
Thanks Bas for your response.
Yes you have the correct undertstanding of our setup
That does sound like a good explaination, the bit I can’t understand is why printing from a desktop ie not via Citrix but still via print server is still fast.
Also if you print the same document in the same citrix session a 2nd time it is a lot quicker (almost like its cached)
Could it have something to do with the authentication domains being different i.e. Print servers and client desktops in the same domain. Xenapp servers and user ids used to logon to xenapp resources are in a different AD domain with no truust in place.
Kind Regards
Craig
Hi Craig,
I’m not sure on the, same document in the same session part, but I can imagine that printing / spooling a document for the second time directly after it has been printed for the first time works faster than opening and printing a new one, even if it’s in the same session. I‘d like to give you an explanation, but I’m not a 100% sure if it’s accurate… So I’ll try and dig a bit more, but do let me know if you (or enyone else) come(s) up with something, I’m again pretty busy :-)
About the mixed domains… If your Print server is in a different domain then your XenApp server, with no trusts configured, then it will automatically use the client printing pathway, which in your case isn’t what you want. So I can imagine that printing outside of Citrix, through your Print server, seems fast, or at least faster than your default XenApp setup.
Bas.
Thanks Bas
Much appreciated
Will update with findings as and when we get to the bottom of the problem
Kind Regards
Craig
No problem Craig, hope it all turns out well for you!
Thanks for the great article Bas,
This is my problem as reported by the users when they do printing over the WAN link, it is very slow and almost kills the bandwidth in certain satellite office.
Hi Albert,
Thank you and no problem! Glad it helped.
Regards,
Bas.
Hi Bas,
really I loved your article, thanks for sharing these helpful information. I have similar scenario:
Two sites connected through VSAT p2p link 1mbps.
In HQ located the XenApp server 7.5 which published application there (no printers).
On the remote site users use tcp/ip printer (no print server just network printer connected directly to switch).
When the user print directly to his printer outside CITRIX session it print immediately.
But when he launches citrix then print, it takes long time at least 3 min and more.
Please any help in this matter is highly appreciated
Hi Mohamed,
Have you read through the previous comments? Sounds to me you need to have a look at the client printing pathway (using ICA, and thus compression, over the WAN) in combination with TCP/IP printing as explained in one of the previous comments :-)
With or without print servers present.
Although, as mentioned earlier, there’s not much we can do about slow(er) links, we can only try! Good luck!
Regards,
Bas.
Thank alot…