AD Printer Publishing

You have two options when using the Location field. The first is to simply complete the Location field on the General properties page of each printer defined on a print server. This approach lets your users search on all or part (by using the wildcard—*—character) of the location. The second, and far more effective, option is to also complete the Location field for all defined subnets in AD and enable the Pre-populate printer search location text Group Policy setting. When you use this approach, users will see the location field in the Find Printer options prepopulated with their workstation's location, as Figure 2 shows. The workstation determines the location information by comparing the workstation's IP address with the subnets defined in AD. When the workstation finds a match, it copies the subnet's Location field and uses it to prepopulate the Find Printer location information. For more information about prepopulating the Location field, see the Microsoft white paper "Best Practices for Deploying Printer Location with Active Directory" (http://www.microsoft.com/windows2000/technologies/fileandprint/print/addeploy.asp).

You can also find printers by using the Active Directory Users and Computers snap-in. Right-click the domain in the left-hand pane, select Find, then choose Printers from the drop-down list and enter your search criteria. To view the print queue objects in the snap-in below their parent print-server objects, as Figure 3 shows, you first need to select View, Users, Groups and Computers as Containers from the menu options.

Troubleshooting Printer Publishing
Win2K Server and later print servers use Lightweight Directory Access Protocol (LDAP) to automatically publish printer information in AD. As Figure 4 shows, DNS SRV records advertise the LDAP services that run on domain controllers (DCs). To publish printer information, the print server uses DNS SRV records to attempt to locate the closest DC. For performance reasons, the print server attempts to publish information to a nearby DC. In a distributed AD infrastructure with sites joined by low-bandwidth connections, the print server should publish to a local DC rather than to a remote DC. As a result, if problems exist with DNS or if the DNS configurations on the print server are incorrect, you'll probably experience problems publishing printers in AD.

When a printer is successfully published to AD, the print server that performed the publishing logs an event ID 36 in the System event log, similar to the one that Figure 5 shows. You can use ADSI Edit or ldp.exe to verify that the print queue object has been published successfully in AD and that the attributes have been populated with values (examples of which appear in Web Table 1) as expected.

Any computer or user that writes information to AD must have certain permissions to do so. To successfully create the print queue objects in AD, the parent object (i.e., the print server) must have permission to create child objects. This permission (i.e., allowing SELF to create/delete all child objects) is set by default, but if you've made any changes to the default settings, you might need to specifically set this permission to publish printers in AD.

If the print server fails to publish printers when you select the List in the Directory check box as I described earlier, it will keep trying. Meanwhile, the print server will display the message The Directory operation is still in progress. This message can also appear if a problem exists after you've cleared the check box to remove printer information from AD. The process of publishing or removing a printer typically takes only a few seconds, so you'll know something is wrong if the print server is still trying after a few minutes. If you experience this problem, verify that the DNS settings on the client are correct and that the DC DNS SRV records are available. If you still can't identify a problem, make sure that the parent computer object has permission to create child objects.

Printer Pruning
AD automatically removes printer information when a print queue is removed from a print server. But what happens when a print server is suddenly removed from the network, never to return? In this case, AD doesn't automatically remove the printer information because removing this information is a function of the print server itself. As a result, obsolete print queue objects can linger in AD indefinitely. To address this problem, Microsoft has developed a printer pruner service (aka directory pruning in Group Policy). The printer pruner service isn't actually a separate Windows service but instead runs as a thread within the spooler process on DCs.

Under certain conditions, the pruner can cause unpredictable results. I occasionally see newsgroup postings in which the poster complains that some or all printers have disappeared from AD. How can this happen? Let's examine how the pruner works to see how these problems might occur.