Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Many a times after a failover occurs on a clustered print server, a chill runs down the IT Administrator's spine when he notices that there are print queues missing. Today we will discuss a few basic things to check. Before doing ANYTHING however, get a backup of the print servers using the Print Migrator tool before making any modifications to either server.
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: HKLM\Cluster\Resources\<Resource GUID>\Parameters\Printers. 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): HKLM\Cluster\Resources\< GUID>\Parameters\Environments\Windows NT x86\Print 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:\windows\system32\spool\drivers\<GUID>\Drivers\PRTPROCS. 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: HKLM\Cluster\Resources\< GUID>\Parameters\Environments\Windows NT x86\Drivers\Version-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:\windows\system32\spool\drivers\<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_MACHINE\Cluster. 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%\Cluster\ClusDB, 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.
- 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
I'm trying to synthesize some of this information into more generalized cluster info:
Based on the description in this series about how the ClusDB works, it sounds like each node in a cluster hosts it's own stand-alone JET-engine clusDB, but all nodes SHARE a logfile. Upon failover, the new owner replays the logfile, committing all uncommited transactions to its own local copy of the DB.
However, this wouldn't work if the Quorum group were on a different node than the (for example) Exchange group, because the node wouldn't be able to write the creation of a new resource, such as a POP3 service, to the Quorum log, since it only owns the Exchange group, and not the Quorum group (andit's associated disk).
So how exactly are these changes committed across all members of a multi-node cluster? Is there RPC traffic sent to the Quorum Network Name (I don't have a test cluster to take down the quorum and try to create a resource while sniffing the private and public nets)? How are those changes commited to non-active nodes, or offline nodes?
Thanks in advance.
You are right, it becomes the duty of the node owning the quorum resource to update the quorum logs
anyone done activite/active clustered print server before?
i'm not able to create 2 print$ share folder on the 2 group. duplicate share name was the messsage. i'm looking solution that will enable me to point the drivers to print1$ and print2$. Not sure will there be other better options then above. Thanks.