Thursday, December 20, 2007

Using NLB for redundant print servers

Working at an ASP, limiting downtime is critical; not only could it cost us money it could also cost us hard earned customers. One of the critical services we provide is printing - i.e. printing paychecks, printing pick-tickets for warehouses, printing invoices, etc... It could be said that if printing goes down then the customer comes to a halt. These issues have been compounded by the fact that we are running a Citrix environment which is extreamly sensitive to print drivers and printing issues.

To work around this we have come up with several short, medium, and long-term solutions. For the short-term we are using the Microsoft Print Migrator tool (printmig.exe) to backup all print drivers and configurations on a weekly basis. This way if a bad driver or configuration is introduced into the environment we can quickly roll-back to the prior config. For the medium-term, we are developing a printer compatibility list - similar to a windows hardware compatibility list - of known good and bad printers and drivers. This list is reviewed with every new printer entering the environment to ensure the appropriate drivers are being used. These solutions ensure stability of the software on the print servers, but nothing ensures the stability of the hardware.

To improve the hardware of the print servers we have 2 general choices - use brand new high end hardware, or setup a redundant/clustered solution. Brand new high end hardware is very expensive, and while it improves the likelyhood of uptime it doesnt ensure it. Clustering the print server is supported and documented by MS, but that requires the Enterprise version of Windows along with a shared SCSI disk. Its also a hot-spare scenario, essentially doubling your costs (more if you include the shared disk), without improving performance. Lastly, there is the idea of using a Network Load Balancer to balance the workload between multiple servers. This could be setup using Microsoft's NLB to share the load between the systems, and then use the print migration tool to synchronize the printers between the servers.

The NLB is the configuration we are in process of implementing now. I ran the test in the lab and the only drawback I found was that if a server has a sudden failure then any print jobs in the queue would be lost. Since jobs only stay in queue for a short time (only until they are forwarded to the printer) this will be reletivly few, all new or in process jobs would fall over to the second NLB node. This also allows the print servers to balance loads between themselves, allowing them to be lower end systems. Below is the general configuration I tested in the lab successfully.

Using NLB for redundant print servers

  1. Setup both print servers with 2 NICs – 1 DHCP, 1 static
  2. Setup NLB using the NICs with the static addresses
  3. In the registry set the following (per
    • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
    • Value name: DisableStrictNameChecking
    • Data type: REG_DWORD
    • Radix: Decimal
    • Value: 1

  4. Create a DNS Alias for the NLB VIP
  5. Install and configure printers on print server A
  6. Using the printer migration tool, backup and restore all printers from server A to server Ba. Create a recurring schedule to perform this nightly
  7. From the clients install printers from file://dnsalias/

NLB Cluster Properties

Cluster ParametersIP Address
Cluster ParametersSubnet Mask
Cluster ParametersFull internet nameDNS alias of cluster
Cluster ParametersCluster operation modeUnicast
Cluster ParametersAllow remote controlUnChecked
Cluster IP Addressn/an/a
Port RulesFrom0
Port RulesTo65535
Port RulesProtocolsBoth
Port RulesFiltering ModeMultiple host
Port RulesAffinityNone

Once I got the hardware and NLB setup I tested using printmig.exe to mirror the printers from server A to server B. I created a script that runs on server A nightly via scheduled task and the backup works but the restore to server B doesnt. A little debugging and I came across the %windir%\system32\spool\pm\pm.log and the error "FAILURE - Can't get printer driver directory:". Some research showed that this is a security setting that stops printmig from working remotely (from server A to server B) but not locally. To fix this go to Start Run and type gpedit.msc. Browse to Local Computer Policy Computer Configuration Administrative Templates Printers and set "Allow Print Spooler to accept client connections" to Enabled"

Update 2:
Once I began running the print migrator tool to move from our shared printserver to this redundant configuration, I found the below error in the %windir%\system32\spool\pm\pm.log
2008:01:07 08:37:40 WARNING: Kernel Mode drivers (version 2) are blocked on the target machine. Disable Kernel Mode driver blocking and re-run Printer Migrator. Ignoring this warning (Cancel button) will result in driver installation, but because they are kernel mode drivers - a serious problem with any dependent print queue could potentially bring down the system. Selecting OK will result in restore termination.
Another google search shows yet another group policy that needs to be set to allow version2 drivers. NOTE: This is not generally a good idea, version 2 drivers are kernel mode and therefore can crash the entire server, not just the spooler. To resolve this issue, update the driver or perform the following steps:
  1. Open gpedit.msc
  2. Browse to Computer Configuration Administrative Templates Printers
  3. Select "Disabllow installation of printers using kernel-mode drivers" and set to disabled.


smbradley said...

I found you NLB printing write up to be well worth the read. I have also been working with NLB printing and currently I have it in production for similar reasons.
My infrastructure supports ~2500 queues and ~ 1 million jobs (not pages) per month. Traditional clustering was too slow to transition in a failure.
Since I see you article is dated 2007 I was wondering if you had any updates. I am specificly wondering about the implied Active/Active configuration.
My documentation is available at


Vikas Shah said...

I tried your way to configured NLB, but when i install printer in user machine i am getting below error message

[Window Title]

[Main Instruction]
Operation could not be completed (error 0x00000709). Double check the printer name and make sure that the printer is connected to the network.


I can browse printer using NLB Virtual Host Name and IP Address but when i double click on shared printer its giving above error

Ryan said...

I am also getting the 0x00000709 error when I connect using the FQDN (ie \\ and double-click on the printer).

It works fine though if I map the virtual IP (ie \\ and double-click on the printer)

PauloV said...

I recently made this configuration with two Windows Server 2012 using VMs but was having the same error 0x00000709 when I tried to install the prints on desktops.

I'v solved this problem adding one more Value at regedit:

Value name: OptionalNames
Data type: REG_MULTI_SZ

Note that the Value is the name of the created cluster.

Hope this help!