Windows 2003 Print Cluster Troubleshooting – When the spooler bites back

The print spooler is a temperamental beast at the best of times.  Print servers end up with a whole myriad of drivers, print monitors and print processors.  The more queues and printers there are the greater the potential for problems. Clustering your print server makes sense but it does add another layer of complexity for you to manage.  I recently tackled a problematic print cluster and thought Id blog about it.  In this post I have pulled together information on how to “clean up” a clustered print spooler.  I’ve drawn information from a few sources for this post.  Big thanks to Paul Cook (Premier Field Engineer in the UK) for his advice … the man knows his print clusters :)

Before we begin, have a read of the following posts:

https://blogs.technet.com/askperf/archive/2007/07/20/windows-2003-print-clusters-part-one.aspx

https://blogs.technet.com/askperf/archive/2007/07/27/windows-2003-print-clusters-part-two-recommendations.aspx

https://blogs.technet.com/askperf/archive/2007/08/07/windows-2003-print-clusters-part-three-troubleshooting-missing-print-queues.aspx

Right, so now you know how it all ties together.  Let’s tackle a few problems that I encountered:

1. 1. Unsupported Print Monitors were installed
   2. Print Queues were using third party Print Processors
   3. Third party printer drivers

Unsupported Print Monitors are a common explanation for the spooler biting back. 

WARNING

Use the Printing tool to take a backup of your current configuration BEFORE continuing. I would also advise that you take a system state backup to ensure that the cluster configuration is safe and sound. Let me re-iterate again, TAKE A BACKUP. Oh, and don’t forget to test everything before tackling your production systems! 

Unsupported Print Monitors

When a printer is installed into a cluster using a driver that ships with Windows Server 2003, the cluster service only uses the standard TCP/IP or LPR monitors. No third-party monitors are supported on server clusters.

The following monitors are considered supported:

• BJ Language Monitor
• Local Port
• LPR Port
• Microsoft Document Imaging Writer Monitor
• Microsoft Shared Fax Monitor
• PJL Language Monitor
• Standard TCP/IP Port
• USB Monitor
• Windows NT Fax Monitor

Make sure that each queue is using the Standard TCP/IP port monitor.  You can see the monitors installed on the cluster by viewing:

HKLM\Clusters\Resources\<resource id>\Parameters\Monitors

You should remove any unsupported print monitors from the above registry key once all queues are configured to use supported monitors.

Print Queues using third party Print Processors

The official line is that third party print processors ARE supported but NOT recommended (Microsoft recommend using the WinPrint processor).  Print processors are user-mode dynamic-link libraries that are responsible for converting the spooled data of a print job to a format that can be sent to a print monitor. Print processors are also responsible for handling program requests to pause, to resume, and to cancel print jobs.

You wont know what processor a particular driver will use unless you edit the INF before installing.  Realistically editing the INF is not an enticing option. I prefer changing the queue to WinPrint after you have set it up.  So the the first challenge is to identify what Print Queues are not using the WinPrint processor.  You could manually go through each subkey in 

HKLM\Cluster\Resources\<resource id>\Parameters\Printers

Or, you could script your way out of the problem like this:

This script creates a log file called results.txt listing the print processors for each print queue.  Now you know what queues are not using WinPrint, how do you go about changing them?  You have three options:

1. 1. Change it manually by going into the advance properties the queue, click Print Procesor and select WinPrint.

      

      

   2. Change it manually in the registry HKLM\Cluster\Resources\<resource id>\Parameters\Printers\<queue>\Print Processor

   3. Write a script to change all print processors to WinPrint.

      Const HKEY_LOCAL_MACHINE = &H80000002 strLogfile = "C:\results.txt" strComputer = "target server" intCounter = 0 Set objFSO = CreateObject("Scripting.FileSystemObject") Set objFile = objFSO.CreateTextFile(strLogFile) Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv") strKeyPath = "Cluster\Resources\<resource id>\Parameters\Printers\" objReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys For Each strSubkey in arrSubKeys objReg.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath & strSubkey,"Print Processor", strPrintProcessor If LCase(strPrintProcessor) <> "winprint" Then objReg.SetStringValue HKEY_LOCAL_MACHINE, strKeyPath & strSubkey,"Print Processor", "WinPrint" objFile.WriteLine "Printer: " & strSubkey & vbTab & "Print Processor was: " & strPrintProcessor & " but has now been changed to WINPRINT" intCounter= intCounter + 1 End if Next WScript.Echo "Finished. Modified " & intCounter & " printer processors" objFile.WriteLine "Modified" & intCounter & " printer processors" WScript.Quit

Once you have changed all queues to WinPrint you could now remove the third party print processors from the cluster.  However, think about the consequences before decide to delete them. 

If a print queue is configured to use a print processor that no longer exists it will not appear when the print spooler is restarted.  To get the queue back you have to edit the registry to change the print processor to WinPrint and restart the spooler.

Should you still wish to delete the print processors you will find them, depending on the environment in:

HKLM\Cluster\Resources\<resource id>\Parameters\Environments\Windows NT x86\Print Processors

Regardless of whether you delete the third party print processors every time you create a new queue or install a new driver, make sure you change the print processor to WinPrint. 

In some instances using the WinPrint Processor can reduce functionality on a printer e.g. twisty text or watermarks and the likes.  So, there may be instances where you have to use third party print processors.  You could consider creating a new Print Spooler resource on the cluster for third party processors and leave all of the WinPrint queues on another spooler.  Each spooler resource on a Windows 2003 cluster can have its own set of drivers, processors and monitors located in HKLM\Cluster\Resources\<resource id>\Parameters

Third party printer drivers

Third party drivers can impact the stability of your print cluster.    As a general rule, see if you can use the drivers that ship with Windows Server 2003 before considering the installation of third party ones. Another thing that really kills print servers is running the setup program that comes with printer drivers.  Not only is this not the supported method for adding a driver to a print cluster it also installs a whole lot of unwanted “stuff” (like system tray icons).  Check out the Cluster Server Resource Centre for more details.  Check out How to set up a clustered print server for details on how to setup the spooler and create print queues.

Conclusion

If you tackle the Print Monitors, Print Processors and Drivers you have gone a long way to ensuring that your print server is stable.  However, there is one thing that very quickly undoes all of your hard work and that’s Terminal Services Printer Redirection.  Imagine you’ve cleaned up your drivers, removed unsupported port monitors and set everything to use the WinPrint processor… all of a sudden different drivers start appearing on your cluster!  I recommend disabling client printer redirection on ALL print servers, not just the clusters (in fact, I have in the past disabled it completely on all servers to stop printer drivers being installed).  You can find the option to disable client printer redirection under:

Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection

Enable the Do not allow client printer redirection setting.

One last word

Windows Server 2008 Fail-over clusters are well worth looking into.  There have been improvements across the board.  Print Clusters are now easier to install, configure and manage.  Click on the image below to learn more about Windows Server 2008.