Thoughts from the EPS Windows Server Performance Team
Hello, my name is Yong Rhee and I’m a Support Escalation Engineer on the Windows Server Core-Performance team. Every now and then, we work with a customer whose administrator is trying to deploy a printing solution on Windows Server 2003 (or Windows Server 2008) and they want to spread the load using Network Load Balancing. They are trying to achieve this by using either a software solution such as Microsoft NLB, or a hardware solution such as BigIP. Alternatively, they may try spreading the load using Round robin DNS (A records). Of course, when problems arise, their first call is to us ... and that's when they get the bad news: Using Network Load Balancing and DNS Round-robin to create a redundant printing solution is not supported.
There is an exception to this - if you have only one active node and you maintain a hot spare machine, you would need to swap the IP addresses (you must use static addresses) between the machines to redirect the traffic. In addition you would also need to ensure that your printing configurations are identical on both machines. This would include the registry information for the print environment as well as the actual printer drivers installed on the machine. Using a solution such as the PrintBRM.EXE command line tool can facilitate this synchronization. Even in a scenario with only one active node in the load-balanced environment, should you call in for support, one of the first things that you may be asked to do is to disable the load balancing before we troubleshoot the printing issue.
So why is printing not supported in this configuration? Basically, in order to have successful network load balancing, the session state for a client must be maintained. For a print environment, DNS Round-robin and Network Load Balancing can disrupt the conversation between a client and the print server to which it is connected. The client workstations could have a conversation that lasts a long time (many minutes or even hours) and it requires the client to talk to the same Print server - and in particular the same spooler process (spoolsv.exe).
With Microsoft Failover Clustering (MSCS) the print queue only exists on one virtual server at any one time and guarantees the configuration does not change when the print queue is moved between cluster nodes. Registry information and driver files are kept in synchronization between the cluster nodes during the failover process. We often see this scenario when enterprises are consolidating servers. To ease some of the pains of migration, you can use Microsoft KB article 870911 to consolidate print servers to avoid having to remap client shares.
So what is the official Microsoft recommendation with regards to implementing a highly available Printing solution? Use a clustered solution - either on Windows Server 2003 or Windows Server 2008. The documentation below will help you design and implement a highly available print environment. And that brings us to the end of another post. Thanks for stopping by!
- Yong Rhee
I found your NLB printing information interesting but everyone seems to forget to mention that we are still dealing with the traditional Microsoft process "spoolsv.exe" and it is not capable of being managed by more than one OS/Server at a time. That is why Active/Active is off-limits.
I invite you to review my document on NLB printing that I have published on my site ( http://smbradley.com/documents/NLB_Printing_SBradley.doc ). I have successfuly deployed this in a REAL environment with ~ 1 million jobs per month. It "IS" supported by Microsoft cluster and print teams but you better be willing to support it yourself first. Why deal with NLB over traditional clustering? Simple...Transition time to recover from a server or service outage (7 seconds), I can use STD OS and it will span data centers. Replication was a challange but I scripted the process using PrintMig. We have ~ 2500 print queues on a HP DL385 with 4GB of ram and Win2k3 SP2.