Surviving Printing on Citrix
Printing is the number 1 headache on Citrix servers. The impact of a single user having printing problems sometimes causes problems for all the users on that server.
In a worst case scenario, a single user could shut down a server due to a blue screen.
A few simple rules can help you stabilize your server.
In Citrix Metaframe 1.8 and the first release of Citrix XP, the printing mechanism relied on the underlying OS, and its printing subsystem. In Citrix XP FR1 and up, the UPD I and II were introduced, which were indeed universal, but underneath still relied on the OS printing subsystem.
In Citrix Presentation Server 4, Citrix introduced a new printing subsystem, built from scratch.
Since most people still run Citrix XP or MPS3, I will stick to those, and talk about CPS4 printing in a later article.
In order for a client to have a printer, it either needs to be a network printer, or a so called auto-created printer. For both uses, a driver needs to be installed on the server. An auto-created printer uses the full driver functionality on that server, and a network printer only uses the preferences dll part of that driver.
Since most issues occur on auto-created printers, I will focus on that in this article.
Most problems arise when using auto-created printers, as the driver on the server is used in full.
When the client hits the print button, the print job is pre-spooled on the server by using that driver, before it’s sent to the client for final printing. This pre-spooling is a behavior many printer manufacturers do not take into account when building drivers. Even if they state “certified for OS”, this does not mean that this driver is 100% Terminal Server/Citrix aware. The best advice I can give you is to test any driver that does not come from the OS CD Rom, before hitting the production servers. That could save you on issues like users receiving a “wfshell” error at logon, a crashing spooler service or, in worst case, even blue screening the server.
Sometimes drivers try to write to the location of the driver, so it could help to give users write access to %systemroot%\system32\spool. This is mostly needed for third party drivers.
Kernel and user mode drivers
When looking at drivers, there are 2 versions out today. A so called “Version-2 kernel mode” driver, and a so called “Version-3 user mode” printer driver.
Open up the printfolder on the server, click “File”, “Server Properties” and then hit the Drivers tab.
In the sample picture you can see drivers listed as “Windows 2000” and 1 driver listed as “Windows NT4.0 or 2000”. That is a “Version-2 kernel mode” driver, and should be replaced by a version-3 user mode driver ASAP. Version-2 drivers run in the same memory space as the OS, and can cause serious damage when misbehaving. In the old NT4 TSE/Metaframe 1.8 era, this was the number 1 problem maker, and still exists today. It can cause those spooler crashes and can even cause a server to blue screen.
Once those version-2 kernel mode drivers are gone, it’s time to take a look at third party drivers in general. As I mentioned, most of them require write access to the spooler folder, and they often leave old stuff behind in that folder, so a cleanup of it once in a while will not do you wrong.
Most versions of drivers available out there are the PCL5 or the PCL6 versions. PCL6 versions have been reported to give trouble on Terminal Server/Citrix, so if you have one of those causing trouble, replace it with a PCL5 version, and you have a good chance that the trouble will be gone.
Keep in mind that most vendors create hardware that is PCL or PS compliant, and can easily be mapped to HP basic drivers. (Xerox, Kyocera etc)
Securing the drivers
The drivers installed on the server, should only be yours. If the option to “automatically install native drivers” is activated, even normal users can install drivers on the server automatically. If the server cannot find the i386 folder for that native driver, and the client is Windows 2000 or Windows XP, those native driver files will get copied from the client to the server (the last thing you want is a few meg of drivers transferring over the WAN line). My advice is to disable that option in the CMC. It might give you more work, but it helps to keep a more stable environment.
Once all drivers are correctly installed, I would advise you to use the “compatibility” option in the CMC to make sure only safe drivers are used during use (should a new driver slip in via a remote admin RDP session by accident).
Keep in mind, that it can get pretty busy in that spooler folder with all the drivers and spooling done there.
Sometimes a driver gets corrupted. In that case, a simple reinstall on the server can fix the issue. Good practice would be to have all drivers installed on your server packaged in a folder somewhere for fast recovery (and making sure you don’t get version conflicts).
As for performance over the WAN line, keep in mind that the more complex the driver is, the more data is generated, to be sent to the client over the WAN line. If the user needs basic printing and is, for example, PCL compliant, then using a simple “HP LaserJet 4” driver will generate less traffic, than a “HP LaserJet 4050 PCL 6” driver. Using the drivers from the OS CD Rom, over vendor drivers, are also better for performance in general. Only revert to vendor drivers for specific functionality.
You can use the Citrix functionality of mapping drivers to do this. If, per server, you can use the wtsprnt.inf for it, or if you want to set them farm-wide, you can use CMC printer mapping.
Keeping a small number of good drivers on the server, and mapping the family name driver to it, will keep your printing subsystem healthy and as fast as possible (third party drivers can cause slower logon times).
User sees all printers
If one of your applications requires the user to have “local admin” rights or “power user rights” on the server, then the user will see all auto created printers. This is by design of the OS.
Put some extra effort into finding out what the user needs exactly for extra rights, by using filemon and regmon from www.sysinternals.com to start his application. It will keep your servers more stable and it’s less confusing for the users.
The Citrix UPD drivers
These drivers are perfect for keeping as few drivers on the server as possible. Most printers are pretty compatible with them. Only a few need specific mapping. Either for functionality, or for not being PCL compatible. There is a small flaw in the UPDII driver, on Windows 2000, where the HP 4500 driver creates bigger print jobs than needed. You can fix this, by replacing the Windows 2000 “HP Color LaserJet 4500” driver with its Windows 2003 equivalent.
Version 8 of the Citrix client has also been more optimized on the rastering of the client side job, so if you’re still using version 6 or 7 of the client, I would advise you to upgrade.
Tuning the UPD’S:
There is not so much to be tuned, but if you are using the UPD’s on a WAN environment, where bandwidth is an issue, there is something you can try. In the properties of an auto-created printer, there is an option called “Enable advanced printing features” which is enabled by default. (also for normal auto-created printers)
If you tick that option off, your job size could shrink dramatically (up to 10% of original) depending on the document type and content you’re trying to print.
The downside is that the option is enabled by default again, when the user logs in next time, but it’s a killer tip for those user on small WAN lines, needing to print.
The use of printer bandwidth is basically unlimited, and could cause problems on shared lines.
In the CMC you can set the maximum bandwidth for a session to take. That will protect the bandwidth on the server side, but will force the users into taking more time for a print job to fully load.
The good thing is that a single print job, will no longer affect the performance of all the users on that line.
I would advise experimenting a bit with the bandwidth setting, until you have happy users, but they are not killing the line with their print jobs.
All the above advice creates a lot of extra work in the beginning. Fully administrating and testing your drivers however will save you a lot of troubleshooting and user complaints in the long run.