First published on TECHNET on Aug 07, 2007
OK, so before we get too deep into the post, let's quickly outline the most likely reasons for missing print queues:
The first thing to do is to see if there are any common traits that are shared by the missing print queues - for example:
If you are able to fail the resources back to the working node, you can look this up via the GUI. Alternatively you can find the same information via the registry. More often than not, you can isolate the problem based on one of the three scenarios above. So let's look at these in more detail.
When dealing with Missing Print Processor Registry Entries / Missing Print Processor DLL's, the first thing to do is find out what exactly is missing. The following registry key contains the list of all of the clustered print queues that are installed - so you should be able to tell which queues are missing on the problem node: HKLMClusterResources<Resource GUID>ParametersPrinters . Once you locate one of the problem queues, look for a value named “Print Processor” which will tell you the name of the Print processor in use. You can also find the driver being used by the printer in the “Printer Driver” value data. Now take a look at the other queues that are problematic - do they use the same print processor or driver? If they do, look inside the following registry key (for an x86 based print driver): HKLMClusterResources< GUID>ParametersEnvironmentsWindows NT x86Print Processors . Is the Printer Processor listed here? If not then we are either missing the print processor registry entry or we have an invalid print processor set.
If you have several OEM print processors that seem to have issues, you can force all the print queues to use the default Print Processor, WinPrint. You can either set it from the printer properties or you can use WMIC or the SetPrinter utility. The WMIC command is as follows on Windows Server 2003: wmic printer set PrintProcessor = WinPrint . You can also use the setprinter.exe Resource Kit utility to set the printer processor to Winprint using the following command: SetPrinter.exe \Servername 2 pPrintProcessor="Winprint".
You can check if it is a missing registry issue by verifying it with the working node. If the registry entry is missing, you can import the missing entry. As an alternative you can set the print queue to use the default print processor - WinPrint - by modifying the registry value. This removes the printer dependency on an OEM print processor. If you elect to import the missing entry, you also need to make sure that you have the appropriate files loaded as well. Inside the Print Processor registry key, you’ll find the print processor “Driver” entry which will point to the Print Processor DLL. Verify that the file exists in the correct path which is: C:windowssystem32spooldrivers<GUID>DriversPRTPROCS. To guard against the possibility of a version mismatch, you may elect to copy over the DLL from the working node. Obviously if the registry entry matches up, you should still check that the files match up between the nodes.
Unlike the Print Processors, Language Monitors are set on a per driver basis rather than on a per print queue basis. So first find out the driver that the printer is using from the “Driver” value of the affected print queue. With this information go to the appropriate driver under: HKLMClusterResources< GUID>ParametersEnvironmentsWindows NT x86DriversVersion-3 and note the monitor listed in the “Monitor” value. The default language monitors are PJL Language Monitor and BJ Language Monitor. If the driver is using some other 3rd party monitor, you can safely modify the data for “Monitor” to NULL or no value (blank). In this scenario you might see printers using different drivers fail to load when they use the same monitor. Either reinstalling the driver or using a newer version of the driver is something that you can always try first.
If the missing print queues are using the same printer driver and everything else look fine, there might be something wrong with the driver. Test by using a Generic driver, you can also try reinstalling the affected driver or try a newer version of the affected driver if available. Compare the size of the GUID folder: C:windowssystem32spooldrivers<GUID> on each node of the print cluster. The size of the folders should match on all nodes of the cluster after a successful failover. If the GUID folder on one of the Cluster nodes is corrupt, there are several options:
There are three possible ways to restore this folder:
And finally, another cause of missing queues occurs when a large number of changes were made since the last failover and those changes exceed the size of the quorum log. Printer information is replicated to all nodes in the cluster via the cluster registry. As we discussed in our initial cluster post, the cluster registry is located at HKEY_LOCAL_MACHINECluster . The registry is instantiated in each node in a file called ClusDB under the %systemroot%Cluster directory. Updates to the cluster registry are replicated from the local ClusDB to a checkpoint file (chkxxx.tmp) and quorum log file (quolog.log) in the MSCS directory on the quorum disk.
If there are a large number of changes to the ClusDB (for example, adding a large number of printers), it is possible that the quorum log may wrap and changes will be lost on failover if its log size is set too small. For example, if you have installed printers and the size of the Clusdb file is 6 megabytes (MB), you should increase the size of the reset quorum log to 8192 bytes (8 MB). By default, the size of the reset quorum log on Windows Server 2003 is 4 MB. You should increase the size of the reset quorum log in 64 KB increments. A good rule is to double the current size of the reset quorum log.
Because clustered print servers store a large amount of information in the cluster registry, it is important that the quorum log size is larger than the ClusDB. To do this, view the file size of %SystemRoot%ClusterClusDB, and within Cluster Administrator ensure that the Reset Quorum log at value is larger than the ClusDB. By default, the quorum log change size in Windows Server 2003 is 4096 KB. But if you have a large print server with hundreds of print queues, this is one maintenance task that should be checked periodically.
Last but not the least, some of the steps given above may be used as a quick workaround to bring the server backup, however if you identify an OEM driver as the cause of the issue; you should report it to the appropriate vendor. Only if you report the bug will they be able to track and fix it.
And that brings us to the end of our three-part series on Windows Server 2003 Print Clusters. Hopefully you find this information useful. If you have any feedback, we'd love to hear from you.
Additional Resources:
- Sumesh P.
OK, so before we get too deep into the post, let's quickly outline the most likely reasons for missing print queues:
- Missing Print Processor DLLs
- Missing Print Processor Registry Entries
- Missing Print Monitor Registry entries
- Corrupt/Missing Driver Files
- Quorum Log Size
The first thing to do is to see if there are any common traits that are shared by the missing print queues - for example:
- Do they use the same Printer Driver?
- Do they use the same Print Processor?
- Do they rely on a specific Port Monitor?
If you are able to fail the resources back to the working node, you can look this up via the GUI. Alternatively you can find the same information via the registry. More often than not, you can isolate the problem based on one of the three scenarios above. So let's look at these in more detail.
When dealing with Missing Print Processor Registry Entries / Missing Print Processor DLL's, the first thing to do is find out what exactly is missing. The following registry key contains the list of all of the clustered print queues that are installed - so you should be able to tell which queues are missing on the problem node: HKLMClusterResources<Resource GUID>ParametersPrinters . Once you locate one of the problem queues, look for a value named “Print Processor” which will tell you the name of the Print processor in use. You can also find the driver being used by the printer in the “Printer Driver” value data. Now take a look at the other queues that are problematic - do they use the same print processor or driver? If they do, look inside the following registry key (for an x86 based print driver): HKLMClusterResources< GUID>ParametersEnvironmentsWindows NT x86Print Processors . Is the Printer Processor listed here? If not then we are either missing the print processor registry entry or we have an invalid print processor set.
If you have several OEM print processors that seem to have issues, you can force all the print queues to use the default Print Processor, WinPrint. You can either set it from the printer properties or you can use WMIC or the SetPrinter utility. The WMIC command is as follows on Windows Server 2003: wmic printer set PrintProcessor = WinPrint . You can also use the setprinter.exe Resource Kit utility to set the printer processor to Winprint using the following command: SetPrinter.exe \Servername 2 pPrintProcessor="Winprint".
You can check if it is a missing registry issue by verifying it with the working node. If the registry entry is missing, you can import the missing entry. As an alternative you can set the print queue to use the default print processor - WinPrint - by modifying the registry value. This removes the printer dependency on an OEM print processor. If you elect to import the missing entry, you also need to make sure that you have the appropriate files loaded as well. Inside the Print Processor registry key, you’ll find the print processor “Driver” entry which will point to the Print Processor DLL. Verify that the file exists in the correct path which is: C:windowssystem32spooldrivers<GUID>DriversPRTPROCS. To guard against the possibility of a version mismatch, you may elect to copy over the DLL from the working node. Obviously if the registry entry matches up, you should still check that the files match up between the nodes.
Unlike the Print Processors, Language Monitors are set on a per driver basis rather than on a per print queue basis. So first find out the driver that the printer is using from the “Driver” value of the affected print queue. With this information go to the appropriate driver under: HKLMClusterResources< GUID>ParametersEnvironmentsWindows NT x86DriversVersion-3 and note the monitor listed in the “Monitor” value. The default language monitors are PJL Language Monitor and BJ Language Monitor. If the driver is using some other 3rd party monitor, you can safely modify the data for “Monitor” to NULL or no value (blank). In this scenario you might see printers using different drivers fail to load when they use the same monitor. Either reinstalling the driver or using a newer version of the driver is something that you can always try first.
If the missing print queues are using the same printer driver and everything else look fine, there might be something wrong with the driver. Test by using a Generic driver, you can also try reinstalling the affected driver or try a newer version of the affected driver if available. Compare the size of the GUID folder: C:windowssystem32spooldrivers<GUID> on each node of the print cluster. The size of the folders should match on all nodes of the cluster after a successful failover. If the GUID folder on one of the Cluster nodes is corrupt, there are several options:
There are three possible ways to restore this folder:
- Restore the GUID folder from a Tape Backup
- Remove and re-add the problematic node from the “Possible Owners” list. This will cause the Spooler Resource to re-create the drivers on the local node
- Rename the existing GUID folder and copy the GUID folder from a working node.
And finally, another cause of missing queues occurs when a large number of changes were made since the last failover and those changes exceed the size of the quorum log. Printer information is replicated to all nodes in the cluster via the cluster registry. As we discussed in our initial cluster post, the cluster registry is located at HKEY_LOCAL_MACHINECluster . The registry is instantiated in each node in a file called ClusDB under the %systemroot%Cluster directory. Updates to the cluster registry are replicated from the local ClusDB to a checkpoint file (chkxxx.tmp) and quorum log file (quolog.log) in the MSCS directory on the quorum disk.
If there are a large number of changes to the ClusDB (for example, adding a large number of printers), it is possible that the quorum log may wrap and changes will be lost on failover if its log size is set too small. For example, if you have installed printers and the size of the Clusdb file is 6 megabytes (MB), you should increase the size of the reset quorum log to 8192 bytes (8 MB). By default, the size of the reset quorum log on Windows Server 2003 is 4 MB. You should increase the size of the reset quorum log in 64 KB increments. A good rule is to double the current size of the reset quorum log.
Because clustered print servers store a large amount of information in the cluster registry, it is important that the quorum log size is larger than the ClusDB. To do this, view the file size of %SystemRoot%ClusterClusDB, and within Cluster Administrator ensure that the Reset Quorum log at value is larger than the ClusDB. By default, the quorum log change size in Windows Server 2003 is 4096 KB. But if you have a large print server with hundreds of print queues, this is one maintenance task that should be checked periodically.
Last but not the least, some of the steps given above may be used as a quick workaround to bring the server backup, however if you identify an OEM driver as the cause of the issue; you should report it to the appropriate vendor. Only if you report the bug will they be able to track and fix it.
And that brings us to the end of our three-part series on Windows Server 2003 Print Clusters. Hopefully you find this information useful. If you have any feedback, we'd love to hear from you.
Additional Resources:
- KB278455: How to set up a clustered print server
- KB257897: MSCS printer shares may not come online if quorum log is too small
- Sumesh P.
10/7/2008: A quick note about using the WMIC command listed above. The WMIC will reset the print processor for a standalone print server. For clustered print servers use the SETPRINTER command listed above
Updated Mar 16, 2019
Version 2.0
CraigMarcho
Microsoft
Microsoft