One of the problems that has plagued Citrix admins and engineers has been third party print drivers. All it takes is for one bad print driver to misbehave, crash the print spooler, and generate dozens of support calls from users who suddenly cannot print.
This common problem led to Citrix including the Citrix Universal Print Driver (Citrix UPD) which is compatible with many popular printers, and is much easier on the Windows print spooler. In cases where the Citrix Universal Print Driver does not play well with an application or a particular printer, the Citrix Universal Printer can be mapped into a user’s session as a virtual printer that offloads the print job to the user’s client machine, using the native or third-party print driver installed on the client machine.
Between these two wonderful gifts from Citrix, why even consider using a third-party print driver like the HP Universal Print Driver?
Despite the stability and compatibility of the Citrix Universal Print Driver, I have found that even it sometimes causes the Windows print spooler to crash. I’m not saying that the driver itself is at fault. There could be a problem with the data an application is sending to the print subsystem and the Citrix UPD. Regardless, the print spooler sometimes crashes and has to be restarted to restore printing on the affected XenApp server.
There are three approaches to resolving the problem of the Citrix UPD crashing the spooler-
Eliminate the driver itself as the cause (blame an application, an OS patch, or something else)
Do not map client printers into a user’s session, and instead allow them to only use the Citrix Universal Printer
Allow use of native or third-party print drivers
Option 1 is the most time-consuming and possibly the least rewarding because you may find that the problem actually is the driver, or an application that cannot be rewritten for whatever reason, or an OS patch that is absolutely necessary.
Option 2, forcing users to use the Citrix Universal Printer, can potentially work marvelously for small print jobs provided the user understands how to use the Universal Printer options.
Option 3, using native or third-party print drivers, makes many of us cringe. In Windows Server 2008 R2, some native HP drivers simply cannot be used. The native drivers HP gave to Microsoft to include in Windows included a bug which prevented the drivers from being used. This problem leaves the HP Universal Print Driver as the only native option for HP printers in Windows Server 2008 R2. If you have other printer brands in your environment, native drivers included with Windows will probably work. But remember that there is no guarantee that the native drivers will not crash the print spooler.
So which option is best? As usual, it depends on your environment. Despite the issues, I propose that option 3 can be a good option for XenApp 6 environments where printing is not heavy. Allowing native and third-party print drivers in addition to the Citrix Universal Printer and the Citrix UPD offers the most flexibility. The biggest problem I have seen with using the HP Universal Print driver is that it can consume the entire CPU and render the server almost useless. If users in your XenApp environment are doing a lot of printing, don’t use the HP Universal Print driver. Don’t even install it. Otherwise, test it out and see how it holds up under your workload.
If you decide to try third-party printer drivers, you don’t have to worry about these drivers crashing the print spooler thanks to the inclusion of a new feature in Windows Server 2008 R2 that allows print drivers to be isolated from the spooler. Print driver isolation works by creating a separate process, PrintIsolationHost.exe, for each session. Instead of a faulty driver crashing the spooler, it will only crash the PrintIsolationHost process, impacting only the user whose print job triggered the crash. Recovery is as simple as having the user log out and back in.
Enabling print driver isolation is easy and is done on a per-driver basis. In Windows, just launch Print Management under Administrative Tools. Right-click the driver you wish to isolate, and select “Isolated”
The change takes effect immediately and no restart of the spooler is required. While print driver isolation is a valuable and much-needed feature, it is not compatible with all print drivers. And it is absolutely not compatible with the Citrix Universal Print driver! If there were a way to isolate it without breaking printing, it would save almost everyone from having to use native or third-party print drivers.
Of course, isolating native and third-party drivers is only part of the solution. For maximum flexibility and compatibility, we need to automatically map the Citrix Univeral Printer into all user sessions, and set policies regarding the use of the Citrix UPD.
Mapping the Citrix Universal Printer to all user sessions is done through Citrix user printing policies. When it comes to how the Citrix UPD is used, we have two options. We can either disallow the use of native and third-party print drivers, and allow only the use of Citrix UPD-
Or we can allow the use of native or third-party print drivers, if present, and fallback to the Citrix UPD if native drivers are unavailable.
The beauty of this configuration is that we can use Citrix policies to control when, if, and which print drivers are allowed without having to make any modifications to the XenApp server itself. Native and third-party print drivers are installed and isolated, but we can choose to disallow them by simply modifying the Citrix user policies. If the Citrix UPD causes problems with the print spooler, we can switch over to native and third-party drivers by simply changing the policies. And as if that weren’t enough, the Citrix policies can be filtered on a per-user basis. This means one group of users can be forced to use Citrix UPD, while another group can be permitted to use native drivers! Now you can see why I chose this configuration to provide the most control and flexibility without sacrificing stability of the XenApp environment.
Earlier I mentioned that the Citrix Universal Printer is useful for small print jobs when the user understands how to use it. Rendering larger print jobs through the Universal Printer is extremely slow, and if users are trained in its use they can end up unintentionally printing to the wrong printer. Also, the Citrix Universal Printer requires the appropriate print drivers be installed on the user’s client machine, making its universal use a potential administrative nightmare. In the future I hope to see some intelligence built into XenApp and the ICA client that automatically detects and selects the best method of printing based on the user’s unique configuration.
Citrix printing has improved tremendously over the years. One size still does not fit all, but we are getting there. Hopefully the Citrix Universal Print Server (Project Phaser) will be the silver bullet that solves printing in Citrix forever.