Windows Printing and Network Load Balancing

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!

Additional Resources:

– Yong Rhee

Share this post :