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
- Setup both print servers with 2 NICs – 1 DHCP, 1 static
- Setup NLB using the NICs with the static addresses
- In the registry set the following (per http://support.microsoft.com/kb/281308/)
- HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLanmanServerParameters
- Value name: DisableStrictNameChecking
- Data type: REG_DWORD
- Radix: Decimal
- Value: 1
- Create a DNS Alias for the NLB VIP
- Install and configure printers on print server A
- Using the printer migration tool, backup and restore all printers from server A to server Ba. Create a recurring schedule to perform this nightly
- From the clients install printers from file://dnsalias/
NLB Cluster Properties
| Tab | Setting | Value |
|---|---|---|
| Cluster Parameters | IP Address | |
| Cluster Parameters | Subnet Mask | |
| Cluster Parameters | Full internet name | DNS alias of cluster |
| Cluster Parameters | Cluster operation mode | Unicast |
| Cluster Parameters | Allow remote control | UnChecked |
| Cluster IP Address | n/a | n/a |
| Port Rules | From | 0 |
| Port Rules | To | 65535 |
| Port Rules | Protocols | Both |
| Port Rules | Filtering Mode | Multiple host |
| Port Rules | Affinity | None |
Update:
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%system32spoolpmpm.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%system32spoolpmpm.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:
- Open gpedit.msc
- Browse to Computer Configuration Administrative Templates Printers
- Select “Disabllow installation of printers using kernel-mode drivers” and set to disabled.
Comments
Post a Comment