A user clicks print, what happens next? When Citrix is thrown in the mix things work a bit differently. Although the Microsoft print basics still apply, and I’ll discuss them shortly, the way that print traffic will, or can be, routed throughout your environment depends on, one: the physical setup of your machines and printers and, two: the Citrix (print) policies configured. Due note that I will only focus on native Citrix printing and won’t go over any of the third party solutions out there.
Click here if you would likt to read and/or download the full cheat sheet combining both parts, one and two.
Introduction
Throughout part one I’d like to spend some time on the various print file formats used, the print drivers involved, some history, the Microsoft printing basics, where Citrix fits in and so on. While in part two I will focus on the actual printing pathways, how print traffic gets routed throughout our environment, when to use which, some pros and cons, the universal printer, print server and drivers, including some specific architectural setups.
Part two will also include a list of key takeaway’s, Citrix best practices and recommendations’ including some tips and tricks from the field, troubleshooting tools and a link to the .PDF document containing the complete printing cheat sheet. I will also highlight some of the defaults when it comes to Citrix printing and to deal with those. Everything I discuss is applicable to both XenApp and XenDesktop.
Microsoft print file formats
First things first. Microsoft supports two so-called print file formats, EMF and XPS. EMF stands for Enhanced MetaFile and XPS stand for XML Paper Specification. A print file format basically refers to the type of print output an application produces (after a user clicks print) and how it will be handled (routed and rendered) afterwards by the print subsystem. Although considered legacy, EMF is still widely used today, perhaps most even.
This is mainly because up till Windows XP and Server 2003 this is all we had, so you can probably imagine the number of applications that depend on EMF. XPS got introduced later with Windows Vista And Server 2008.
The way an application is written, or coded, compiled etc. will determine which print file format will be used. Win32 (Windows API) applications, meaning that they are based on a C-Based framework for creating applications, depend on and leverage the EMF print file format. WPF (Windows Presentation Foundation), representing a graphical subsystem for rendering user interfaces in Windows-based applications, uses the XPS print file format. As you would expect both behave somewhat different.
Some more differences between the two
XPS applies compression by compressing the print data into a .zip file. EMF does not apply compression at all. Also, EMF needs to separately (re) draw each image it encounters, even if the image is used multiple times within the same document. XPS however can reference a single image multiple times, which is useful for company logo’s, watermarks etc. especially within larger documents. For XPS to be used, assuming your applications supports it, both the print driver as well as the physical print device itself need to support XPS, otherwise it will be converted back to EMF.
After a user clicks print
Again, this is still from a Microsoft printing perspective. Once a user clicks print the application will produce some form of print output, a.k.a. print data. This data will contain all characters, fonts, color schemes, images and so on, which will then need to be ‘translated’ into something that the physical print device can understand and handle.
As explained above, depending on how the application is written / coded, this data will either be EMF or XPS based. With EMF the print output will either be processed by the GDI (Graphical Device Interface) turning it into a metafile (XML based) or it will, together with a locally installed print driver render the data into a printable format before handing it over to the (local or remote) print spooler service. However, with EMF GDI intervention is most common.
With XPS, the earlier mentioned print output is already in an XML format and will be send over to the print spooler service right away. See Image below.
From there the print data will (again) be handed over to a locally installed print driver further rendering the data (if needed) which will turn it into an actual print job before sending it back to the print spooler service. During this phase it will also determine if the so-called target printer is locally attached or remote (print server) before sending it over to the actual physical print device.
Print Spooling
The process where the application print output is received by the spooler service, which hands it over to a print driver rendering it into a print job and sends it back to the spooler service and then over to the physical print device, is what we actually refer to as print spooling. Of course this is still somewhat high level, but it does give you a good indication on what is taking place under the hood.
Local and remote print spooling
When, from a client perspective, print spooling takes place locally it will consume local resources (CPU / MEM). For example, on a pc with a locally attached printer spooling will be local to the client. However, when that same pc uses a network-provisioned printer spooling will take place remotely, consuming (remote) resources on the print server.
Another example would be when we have a session on a XenApp server (client). Here we would also have a network provisioned printer (in most cases anyway) meaning that from a client perspective spooling will take place remotely on the print server.
When spooling takes place remotely, not only will remote resources on the print server be used, each individual print job will also generate a certain amount of network traffic (RPC / SMB) between the client (which can be a XenApp server as noted above) and the print server. You need to take both into account when sizing your print architecture setup.
Some history
A couple of years ago (and perhaps even today) most of our print issues were caused by badly written print drivers. They were not optimized for multi user environments, not tested or signed and as a result services would hang (spooler en Citrix Print Manager) blue screens would pop up, the auto creating of printers would fail and occasionally we would experience high CPU loads and so on.
With Windows NT all we had were so called version 2 (kernel mode) drivers which, of course, ran in kernel mode. It isn’t that hard to imagine what happened if one of those drivers got corrupted or went bad in any other way. You would simply loose the whole system and everything on it. Luckily with Windows 2000 came version 3 (user mode) drivers, which are still widely used today. Now we would only lose the user mode section of a server if something were to go wrong with on of those drivers. Although this still basically leaves the server useless, the impact is less then the with kernel mode drivers.
With Windows Server 2008 R2 Microsoft introduced a mechanism, which automatically blocks the installation of version 2 kernel mode drivers, a good thing. They also introduced a feature called Print Driver Isolation which, when configured, does exactly as the name implies, it isolates your print drivers. With Print Driver Isolation you can choose from three separate modes; None, Shared and Isolated.
Print Driver Isolation
With the None mode (which will be applied by default) nothing changes, all drivers will still be able to interact and as a result if one goes bad it can still potentially bring down the whole machine, or the biggest part of it anyway. With Shared mode however we have the ability to group a certain amount of print drivers and run them in a process completely separated from all other print drivers including the Print Spooler and CTX Print Management service on the same system.
These print drivers will then run a 100% isolated in a process named ‘PrintIsolationHost’. This also means that if something were to go wrong, only the drivers within that isolated process would be potentially affected. And since it also runs separate from the Spooler and CTX Print Management service, it won’t affect any of the other users on the same system.
With Isolated mode the same rules apply, only here the isolation part will get applied on a per print driver basis. For each print driver a separate ‘PrintIsolationHost’ process will be created and it will run completely separate from all other drivers and services as mentioned above.
This also means that more local resources will be consumed and thus needed, especially when you want to isolate multiple, or perhaps dozens, of print drivers. Something to be aware off and consider before implementing. Also, and this is not just me talking, you might want to consider why a print driver needs to be isolated from all others and if it’s worth implementing such a driver onto your production environment, at all.
You are probably better of to use None and Shared mode in production and to use Isolated for troubleshooting purposes only, which of course could apply to production environments as well, only temporary.
Version 4
As off Windows Server 2012 we also have version 4 mode drivers, which are still user based and can also be isolated. So basically all of the above applies here as well. They are designed to handle the more modern metro style applications and are based on the XPS print file format exclusively. They are supposed to support a larger amount of different printer types, are more stable, support enhanced printer sharing and they should be a lot easier to install and maintain as well, or so I have been told.
Citrix Pint Management Service
Up till now most of what I’ve discussed is specific to Microsoft printing in general and as such applies to all environments where Microsoft Operating Systems are used and documents are printed, including Citrix. The Print Management Service is where it gets a bit more specific from a Citrix point of view. It got introduced in 2005 around the same time as the EMF based universal print driver, it handles a few different, and specific, tasks with regards to CTX printing process. For one, it directly communicates with the Print Spooler service, which can either be local or remote in the case of a print server as we’ve discussed earlier.
It also talks to the local ICA client when needed (when the client printing pathway is used, partially shown in the image below, but we’ll get to that later) and compresses data before it is send over the ICA channel, again, when using the client printing pathway. It’s also in charge of the ICA virtual channel for client printer mapping / creation within your Citrix session. Which is good to know when troubleshooting auto create printer failures for example.
What’s wrong today?
Now that we’ve talked about some of the (Microsoft) print specifics (mostly) that come into play when dealing with printing on a CTX orientated environment, and don’t worry there’s more to come, and we also covered some of the print driver history and so on, what is wrong today when dealing with Citrix printing?
We’ll to be honest, not that much has changed. We still have to deal with delayed logons and printing, services that crash, blue screens, CPU spikes, auto creation failures and more. And if we can related these types of issues back to Citrix printing (since there might be dozens of reasons why all this may happen) then in most cases it is still because of faulty drivers and/or badly designed or judged print architecture setups, which I will discuss in more detail during part two.
Round up part one
This concludes part one of this two part series. Part two will discuss the printing pathways available and how we can use them to our advantage. As mentioned we will also have a closer at the Citrix universal product portfolio and I will include a list of key takeaway’s, CTX best practices, recommendations, tips and tricks as well, including some of the URL’s I used as a reference. Stay tuned!
One response to “Citrix printing internals cheat sheet… Part one!”
[…] Part 1: https://www.basvankaam.com/2015/10/27/citrix-printing-internals-cheat-sheet-part-one/ […]