Print queue objects in AD provide a useful facility when users are trying to find printers, but with a 2003 MSCS clustered virtual print spooler, occasionally the information in AD does not reflect the current state of printers. This post describes some problems I've come across with duplicate/incorrect information and some ideas of how to automatically combat the problem.
Print Queue Objects in AD
Print queue objects in 2003 clustering are named with the virtual print server name, but they are children off a physical computer account. Which computer account the printers are children of is determined by the physical node that owned the cluster spooler resource when the printer was originally published in AD. As a virtual print server fails between nodes, the printer objects in the directory are not re-published (I assume unless the object is not found in the directory).
It's intuitive that print queue objects would be republished on failover to the node that currently owns the spooler, but that could potentially be hundreds or thousands of printer objects being created/deleted with each failover so it's practical not to. It appears the printer object is confirmed using the virtual print server name, and no change is made if the object is found - regardless of which physical node the print queue object is a child of.
In the scenario of a stand-alone printer server, when a printer is deleted, the spoolsv service also removes the directory object. In a clustered virtual print server this also occurs, however, it appears that in a 2003 cluster the object is not automatically removed from the directory if the node that owns the object when deleted is different than the publishing node.
None of this really matters if everything is working perfectly, but in a 2003 MSCS I have seen the following situations:
- Print queues that no longer exist still being visible through a search in AD
- Duplicate print queue objects, published against each physical none in the cluster that has hosted the virtual print spooler.
The first was a bigger problem, and I believe the following scenario will result in stale print queue objects persisting:
- You have a two node cluster, CL01 and CL02. CL01 owns a virtual print spooler and other cluster groups, under which you create all the print queues.
- At a later time you decide that the load could be better split, and move the virtual print spooler to CL02
- You then clean up your print queues from the virtual server, also expecting that they will be automatically removed from AD.
In the scenario above, the print queue objects would not be removed from AD, as the physical node that owns the spooler (CL02) does not own the original print queue objects - as they were created when CL01 owned the resources. In this state, the invalid print queue objects will not be purged. Note that this is assuming you aren't using AD printer pruning - by disabling the spooler service on your DCs or using Group Policy to control pruning.
I'm unsure of the exact scenario that caused the duplicate print queue objects, presumably there was some problem finding the existing record, so at some point it was created off the other node as well - resulting in duplicate results in a search (both of which would work, but still).
Some low maintenance ideas to correct this problem:
- Use AD printer pruning, which will ensure print queue objects in AD are managed. Note that this sounds like the obvious solution, but does have caveats and may not suit all environments.
- Periodically remove published records from all but the designated primary node, toggle the published attribute on those printers no longer having a record in AD, causing the printers to be republished against the primary node. This could easily be scripted and scheduled
- Modify printer creation change control processes to ensure that new printers are only created and deleted when the preferred owner is hosting the virtual print server
In an ideal world, three above followed by one make the most sense, but if you needed option two you could do something like this:
- dsrm CN=%virtual_server%-%QueueName%,CN=%physical_server%,DC=domainRoot
- cscript prncfg.vbs -s -b \\%virtual_server%\%QueueName% -published
- cscript prncfg.vbs -s -b \\%virtual_server%\%QueueName% +published
- dsquery * -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName distinguishedname find /i "%QueueName%"
This removes the AD object against the 'incorrect' node, toggles the published flag (using prncfg from the Resource Kit Tools - see 'Network Printing Tools and Settings' reference below), and then queries AD to verify the printQueue object has been created.
Printer Pruning in AD
Pruning of printer objects in Active Directory is controlled either by the server that deletes the printer from its local spooler, or Domain Controllers through periodic printer pruning. Printer pruning is a domain/site-wide activity which processes all printQueue objects.
In a clustered solution, I believe when a Domain Controller looks up the printqueue objects, it will connect to the virtual print spooler node to verify the printers still exist. So regardless of which physical is publishing the printer, as long as the printer is contactable through the virtual server it shouldn’t be pruned.
As long as the spooler service is enabled on at least one Domain Controller, it will prune printers (at the default of 3x8 hour checks). There are risks of doing this, primarily that if the print server is down for longer than 24 hours (or if the DC can’t contact the server), all printers will be pruned from the directory. This logs an Event 50 for each pruned printer in the system event log of the DC that pruned the object - at least it’s easy to trace.
Printer Commands
Query and compare the printers published from each server to determine duplicates:
- dsquery * "CN=%physical_server%,DC=domainRoot" -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName driverName printCollate printColor printLanguage printSpooling driverVersion printStaplingSupported printMemory printRate printRateUnit printMediaReady printDuplexSupported > CL1.txt
- dsquery * "CN=%physical_server%,DC=domainRoot" -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName driverName printCollate printColor printLanguage printSpooling driverVersion printStaplingSupported printMemory printRate printRateUnit printMediaReady printDuplexSupported > CL2.txt
- for /f "skip=1" %i in (CL1.txt) do @find /i "%i" CL2.txt
The following two commands help identify mismatches in printers published in AD versus those shared through the virtual print server.
Count the number of printers published in AD:
- find /i /c "%virtual_server%" CL?.txt
The number of printers shared against a node:
- rmtshare \\%physical_server% find /i "\\%virtual_Server%" /c
Query printers published against a physical server:
- dsquery * "CN=%physical_server%,DC=domainRoot" -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName driverName printCollate printColor printLanguage printSpooling driverVersion printStaplingSupported printMemory printRate printRateUnit printMediaReady printDuplexSupported
References:
Network Printing Tools and Settings
http://technet.microsoft.com/en-us/library/cc778201.aspx
Printer Pruner May Prune All the Print Queue Objects on Its Site
http://support.microsoft.com/kb/246906
Printer Pruner May Not Remove Printer Queue Objects from Active Directory
http://support.microsoft.com/kb/246174/
A server does not prune printers on a Microsoft Windows Server 2003-based server cluster
http://support.microsoft.com/kb/908128
Useful Windows Printer command-line operations:
http://waynes-world-it.blogspot.com/2008/09/useful-windows-printer-command-line.html
Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.
Read more!
