First published on TECHNET on Jul 20, 2007
Today we're going to start looking at Clustered Print Servers. Clustering itself tends to intimidate many administrators, especially newer administrators. Much of the fear factor usually stems from being unfamiliar with how clustering works, and the fact that you are dealing with shared storage. Throw in the fact that most production clusters are providing mission-critical services and it's easy to see how an administrator might be somewhat hesitant regarding clustering. While we're not really going to cover clustering itself in this post, we will touch on some basic concepts as we go along. So let's get started ...
So what exactly is a print cluster? A print cluster is a print server that is configured as a spooler resource on clustered servers. In a Windows Server 2003 cluster server configuration is a group of independent computers that work together to provide a common set of services and present a single-system image to clients. What this means is you group two or more physical servers presenting a single virtual server name to clients. That virtual server name is the access points to services created on the cluster, including printing. For example: You have 2 physical servers, NodeA and NodeB. Those servers are in a cluster group and have a spooler resource installed. That spooler resource has a name associated with it: PrintServerA. Clients access ‘\\PrintServerA’ to gain access to printers installed on the spooler resource.
There are numerous services and applications that can be clustered - for example, SQL and Exchange are often clustered. Network services such as File Servers and Print Servers are perhaps the most common examples of non-application clusters. We are going to focus on Print clusters since that is primarily the area that the Performance team supports. When you think of a print cluster, just remember that what you are dealing with is a print server that is installed on a clustered set of servers and presents a single virtual server name to clients. The print cluster provides a high availability solution for printers. Thus, if the active node (server that owns the print resource) fails, the print resource fails over to the next server in the cluster. This allows the printers to remain available by maintaining the same access point for clients. So in our example above, if NodeA owns the print resources and fails for some reason, then the resources would fail over to NodeB. From the client perspective, they would still just access the virtual server name -
Okay, before we get into the troubleshooting of common print cluster problems and best practices, it is important to understand where the information is stored. The primary difference between a local print server and clustered print server is the file and registry locations where the print cluster stores configuration information. We covered the
Basic Printing Architecture
in a previous post.
Note: The information below applies to Windows 2003 server clusters only as there are significant differences between the functioning of a Windows 2003 and windows 2000 print cluster.
Windows Server 2003 cluster service stores all printer and port information inside the cluster registry:
. Each <Resource GUID> subkey represents a clustered resource. You can look at the “Type” value of a given resource to identify a Print resource; it should have the value data: “Print Spooler” as seen below:
key contains the print spooler configuration information of interest. All printer, driver and port information is stored in separate keys under the Parameters key. From this point onwards the registry structure is mostly the same as that of the local spooler at:
Let's take a look at some of the other important registry keys:
: This key contains the structure necessary for other Windows based print clients (such as Windows NT 4.0, Windows 2000 and IA64-based Windows Clients). The list of installed drivers and related information is stored under the subkeys of appropriate print clients.
: This key is where the cluster will store Port monitor information; the only supported Port monitors on a cluster are the TCP/IP and LPR standard port monitors. This is not to say that you cannot install third party port monitors on a cluster - however, if the port monitor is not cluster-aware you could experience some problematic behavior. Information regarding the TCP/IP ports, such as the port address, name and SNMP information, is stored here.
: All other monitor information (other port monitor + language monitor) is located in the local node’s Print\monitors key.
: All print queue information is stored in this key. This key also contains information about the Print Processor in use by each queue.
The clustered print spooler files are stored separately from that of the local spooler. The start of the tree for file storage is here:
as shown below.
Beyond this the folder structure is same as that of the standalone server's print spooler. The drivers, print processors and color profiles are stored here under appropriate folders. The driver files installed on the clustered print spooler are located in the following folder:
. For example, for x86 print clients the drivers are stored under C:\windows\system32\spool\drivers\<GUID>\Drivers\w32x86. Let's take a look at some other important folders:
: This is the store for the 3rd party print processor DLL's used by the clustered printers. The same information is replicated in the shared disk under the folder named PrinterDrivers. In our example, the shared disk for the print spooler is drive S:
S:\PrinterDrivers\PRTPROCS -> Print Processors
S:\PrinterDrivers\Drivers -> Driver files under the appropriate client folder structure
S:\PrinterDrivers\Monitors -> Monitor DLLs if there are any
The Spool folder where the print jobs are spooled is also located on the S: drive in the Spool folder
I guess that's enough theory for this post. In our next post on Windows Server 2003 Print Clusters, we'll take a look at some best practices and guidelines.
- Sumesh P.