Stress testing print drivers on XenApp

While dodgy print drivers no longer often cause a BSOD, they are still an on-going source of issues on Citrix XenApp farms, namely print spooler crashes and application crashes. Resolving print driver problems within a production environment is challenging and time consuming due to user testing and the change control requirements of live environments, so suck it up and spend the time doing thorough testing during the project to ensure you don't enter a world or printer pain later on.

My interpretation of thorough is stress testing the print driver using Citrix's StressPrinters utility followed by UAT to ensure the printer driver meets the user's needs.

I just wrote the following guidelines for a client and thought I would share:

Use the Citrix StressPrinters utility to test print drivers before they are introduced into the XenApp farm. A test XenApp server must be used during stress testing to ensure the new print driver is not introduced into the production farm prior to successful testing.

1. Install the print driver onto the test XenApp server
2. A Printer Port must be created for use during the test. Open Print Management, expand the local Print Server right click Ports and select Add Port.

3. Choose Local Port, click New Port and enter the port name as “test”

4. There is a graphical interface for StressPrinters, but I prefer the command line interface. The following is an example showing a test of the HP Color LaserJect 2600n driver:

addprinter64.exe -name "StressTest" -driver "HP Color LaserJet 2600n" -conc 5 -iter 10 -delay 500 -port "test"

To test a different print driver simply replace the text "HP Color LaserJet 2600n" with the exact print driver name as displayed within Print Management.

The symptoms of a failed stress test are one or more of the following:

• The stress test hangs
• The Print Spooler crashes
• Interactive Services Detection pop-ups

Note that a successful test may still show warning as shown below:

If a print driver fails the stress test go back to the vendor's web site and hunt around for an alternative driver and try again. While this process does take some time to complete, the resulting stable XenApp farm is worth the effort.