Printing and Active Directory

Good Morning AskPerf.  My name is Philip Demaree and I am an Escalation Engineer based in Washington.  Today we’re going to take a look at some Printing and Active Directory concepts and troubleshooting.  To start with, what we’re going to do is look at the output from LDIFDE for one of our printer objects.  The command that we run is: LDIFDE –s <DC for the domain> -r objectclass=printqueue -f <path\filename> .  I’m running this on one of my Windows 200x Server machines and pointing it at my domain controller.    Printers that are published in Active Directory are published as a child object of the Computer object for the printer.  The –s switch points to the Domain Controller for the domain.  Printers that are published manually can exist anywhere in the AD as they are not connected to a computer object.

Here’s the full output of the command for one of the printers.

As you can see, all the metadata about the printer is available – Color, Duplex etc.  When we’re looking at this output, the most important line is this one, located near the end of the output: uNCName: \\trailorpark.perfwa.local\Test Printer #1 .  This is the path that the AD is still on the network during the Pruning process.  It uses the printer name, not the share name.  Now, you might have noticed that I have a space in my printer name.  In my testing, I discovered that spaces are OK, but putting the period character in the printer name causes issues (think about Fully Qualified Domain Names and you’ll understand why).  When the pruning process occurs, if this path cannot be found, the printer is pruned from Active Directory.  To verify this path and view the print queue you should be able to connect to this path from the Run command on the domain controller.

I mentioned manually published print queues a moment ago.  When you look at the LDIFDE output for a manual print queue, you will notice some differences:

You can see that the dn line doesn’t refer to a server in the same way that the published printer entries do.  Also the UNC name is a standard NetBIOS share path – what was input when the printer was manually added.

OK, but what happens if the LDIFDE output isn’t correct (or corrupted)?  If you do wind up with a situation like this, then you should get a network trace of the LDAP traffic between the Domain Controller and the Print Server.  If the data is correct in the trace, then you have some sort of underlying AD issue, and you should definitely get in touch with our Directory Services team.  However, if the data in the trace is incorrect, then the problem is a client-side issue and we need to figure out why the LDAP traffic is being garbled on the client before it sends it.

When you look at the LDIFDE output for a print queue, the “Location” field is the "path” to the printer when searching by Location.  The tree that is displayed when browsing for a printer in AD is built by assembling these paths from the Location field for all print queues.  This is then displayed as a logical tree.  The process is manual, so a good deal of planning needs to go into determining how the tree should be organized.  In the Group Policy under Computer Configuration\Administrative Templates\Printers there are two entries that affect the Add Printer Wizard in relation to browsing for printers in the Active Directory.  The first is “Pre-populate printer search location text”.  This is a Yes / No setting that determines whether or not the location field should be pre-populated when the user does a search.  The second is “Computer Location”.  This entry contains the text that will be put in the Location field during a search if the “Pre-populate printer search location text” is enabled.  This entry should be consistent with the tree structure defined by the administrators that we discussed earlier.

Now let’s switch gears for a second and discuss how to troubleshoot issues where printers “disappear” from Active Directory.  A print queue becomes orphaned when its uNCName points to a non-existent or incorrect printer.  This results in the domain controller not being able to resolve the name.  The Printer Pruner detects that a given PrintQueue object is orphaned by contacting the print server and comparing the Printer object to the Active Directory PrintQueue object.  Printer Pruner only runs on domain controllers.  Thus, if the domain controller is taken offline, the Printer Pruner is unable to contact any print servers and marks all the published printers as orphaned.  By default, Printer Pruner deletes orphaned printers after checking three times – waiting eight hours between checks.  Therefore, the domain controller would have to be running continuously and be unable to contact the print server for at least twenty-four hours before PrintQueue objects are deleted.

Troubleshooting these issues requires a little bit of detective work.  First, check the System Log on the DC to see if there are many Printer Pruner events at the time when the printers are deleted.  If there are, to determine if the problem is indeed related to the Printer Pruner verify that the domain controller has not been removed from or unable to communicate on the network for an extended period of time (replication events etc will provide clues as well).  Since the Printer Pruner thread runs in the context of the Spooler service (spoolsv.exe) you also need to ensure that at least one domain controller in each site in the enterprise is running the Spooler service.

There are some other things to check as well:

• Can the printer be seen from Active Directory Users and Computers?  See Microsoft KB Article 278504 for details.



• Are there any DNS errors?  An incorrect DNS Server or router configuration can prevent the domain controllers from being able to verify the print queues – resulting in the printers being considered orphaned.



• Check the domain policies for Directory Pruning Interval (try setting this to “Never”) and Directory Pruning Retry Periods.  These policies are located in the Group Policy Editor under Computer Configuration\Administrative Templates\Printers.

Well, that about does it for this post.  Hopefully you found the information useful.  Thanks for stopping by!

Additional Resources:

• Microsoft KB Article 234619: Publishing a Printer in Windows 2000 Active Directory



• Microsoft KB Article 234270: Using Group Policies to Control Printers in Active Directory



• Microsoft KB Article 278504: Problems searching for Published Printers by Server Name



• Microsoft KB Article 246906: Printer Pruner May Prune All the Print Queue Objects on its Site



• Microsoft KB Article 246267: Description of the Windows 2000 Active Directory Printer Pruner



• Microsoft KB Article 246269: Requirements for Proper Function of the Printer Pruner

- Philip Demaree

Share this post :