AD Printer Publishing

Mention the word "printers" to a group of IT pros and watch how quickly they lose interest. In fact, faced with having to deal with printers and printer problems, most of us would rather wander off to the server room to watch the little colored lights blinking on and off. Printers just aren't cool, right? Well, yes, but the ability to search for available printers in Active Directory (AD) is one of the most visible benefits to end users when you migrate from Windows NT to a Windows 2000 domain. And AD printer publishing is what enables these searches.

Printer Publishing
By default, Win2K Server and later print servers automatically publish printer information in AD. You can control whether printer information is published to AD by opening a printer's Properties dialog box, selecting the Sharing tab, and either selecting or clearing the List in the Directory check box, as Figure 1 shows.

Keep in mind that the printer information published in AD is simply a representation of the printer. The publishing process creates an object with an object class of printQueue in AD. The print queue object is itself a child object of the computer object that represents the print server. You can use tools such as ADSI Edit or ldp.exe to view the attributes of the print queue object in AD. Web Table 1 (http://www.winnetmag.com, InstantDoc ID 41104) shows an example of the attributes set for an Epson DFX-8500 printer. This information is useful when you need to verify that you've successfully published the printer information in AD.

For workstations that run Windows XP or Win2K Professional, you can use the List in the Directory check box to publish printer information in AD, but the process isn't automatic. For most organizations, the ability to publish workstation printers in AD is less useful than publishing printers associated with print servers because most workstation printers are dedicated to specific workstation users. Also, workstations are often switched off or otherwise unavailable for long periods.

Although you can also publish in AD those printers associated with NT 4.0 and Windows 9x machines, this process is more labor-intensive. Because a List in the Directory check box isn't available on these systems, you must create the print queue object either manually (by using the Microsoft Management Console—MMC—Active Directory Users and Computers snap-in) or by using the pubprn.vbs script in the system32 folder. For information about how to use the pubprn.vbs script, see the Microsoft article "Publishing a Printer in Windows Active Directory" (http://support.microsoft.com/?kbid=234619).

Searching for Printers
From a user's perspective, the biggest benefit of publishing printer information in AD is that doing so makes available a range of search possibilities. Not only can users search for all printers in the forest but they can also perform granular searches by specifying individual printer characteristics and capabilities. For example, users can search for printers by printer name, location, and model (if this information is available in AD) and by printer features (e.g., double-sided printing, color). In fact, by using the Advanced tab within the search function, users can search against just about any print queue object attribute stored in AD.

To access the search function from an XP or Win2K Pro workstation, select Start, Search, Find Printers. Although earlier Windows versions don't offer this functionality, users can still search for printers in AD if you install the Directory Services Client on their machines.

To make life easier for your users, ensure that the Location field is populated for each printer you publish in AD. As part of your initial AD design, give some thought to a workable, scalable naming convention for the location information. The syntax for the Location field is

name/name/name/name/...

proceeding from the most general location name to the most specific location name. For example,

Switzerland/Basel/Building8/Level1/Room18

identifies a specific room in the Switzerland office.

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.

The pruner runs on all AD DCs. Periodically, the pruner connects to the server print queue to ensure that printers published in AD are still available on the network. The pruner will try to contact a print queue a certain number of times within a given time frame. The default interval is three checks at 8-hour intervals in 24 hours (you can configure this interval in the MMC Group Policy snap-in under Computer Configuration, Administrative Templates, Printers). If the pruner is unable to contact the print queue within the given period, the pruner removes the print queue object from AD. Thus, using the default interval, the pruner can prune a printer from AD within a 24-hour period.

Each DC's pruner begins by compiling a list of all the printers published in AD. The pruner then uses DNS to determine which print servers are in its own AD site. The pruner then attempts to contact each print queue on the print servers in the same site, in turn, removing print queue objects from AD as required.

Problems can occur when the pruner can't find the print-server information in DNS and thus can't determine whether the print server is in the same AD site as the DC. In that event, the pruner simply assumes that the printer is in the same AD site as the DC on which the pruner is running. This assumption can cause problems in environments in which the DC and print server are in different locations with a slow network connection between them or if one of the machines is behind a firewall. If the DC can't contact a print queue within a specified period, the pruner will simply remove the print queue information from AD. The DC performing the deletion will of course use standard directory replication to replicate the change to all other DCs in the domain.

Another problem involves the DHCP client service. As you might be aware, the DHCP client service is necessary for dynamic DNS (DDNS) registrations. So, if the DHCP client service is stopped on the print server, the server can't dynamically reregister its host address (A) and pointer (PTR) resource records. After a period of time, the print server's DNS record might be removed from DNS through aging and scavenging. If the print server's record is removed, each pruner will assume that the DC on which it's running is in the same AD site as the print server. Again, if no network connection exists between any of these DCs and the print server, the pruner will remove the printers from AD. It's important to ensure that the DHCP client is running on all print servers in AD deployments that run DDNS, a task that you can enforce through Group Policy. Similarly, if you unplug a DC from the network for a period exceeding the configured retry interval but the DC continues to run, the pruner running on that DC will remove all published printers because it can't contact them. If the DC reconnects to the network, the DC will replicate the removal to other DCs.

Several event-log entries can be useful in troubleshooting printer pruning, including event ID 47 in the System event log on a DC. This event typically occurs when the pruner attempts, and fails, to contact the print queue on the print server. When event ID 47 is followed by event ID 50 in the System event log, the pruner retry threshold has been reached and AD has removed the print queue object.

Let's look at an example to show how these events can help you troubleshoot pruner problems. Imagine that you suddenly notice that some or all of your published printers no longer appear in AD. If you suspect a DNS problem, you need to identify which DC's pruner was responsible for deleting the printers. Rather than opening the Event Viewer for each DC in turn, you can use the EventCombMT utility from the Microsoft Windows Server 2003 Resource Kit to search the DCs for event IDs 47 and 50. EventCombMT has a graphical interface and lets you search for specific events in the event logs on a specified range of machines. The utility logs summary output information to a text file for easy viewing. After you identify the offending DC, you can determine what's causing the problem.

Under certain circumstances, you might see the opposite condition: the pruner's failure to remove printers from AD. To avoid this problem, don't remove the Print permissions assigned (by default) to the Everyone group in the security settings of the printers on the print server. If you really need to restrict access to the printer, you can remove the permissions assigned to the Everyone group and assign Print permissions only to the Domain Controllers group. Remember that the pruner running on DCs requires access to the print queues on the print servers. Without a minimum of Print permissions, the pruner can't perform its role.

Typically, the print server republishes printer information only when the spooler service restarts on the print server. Thus, without some other form of intervention, pruned printers won't reappear in AD. If a printer does drop off the list of published printers, you can clear, then select the List in the Directory check box on the Sharing tab in the printer's Properties dialog box. Alternatively, you can change a Group Policy setting to force the print servers to republish print queue information on a regular basis.

Managing Printer Publishing and Pruning Through Group Policy
The policies associated with printer publishing and pruning are well documented elsewhere. In particular, the Microsoft white paper "Integration of Windows 2000 Printing with Active Directory" (http://www.microsoft.com/windows2000/docs/printad.doc) and the Microsoft article "Using Group Policies to Control Printers in Active Directory" (http://support.microsoft.com/?kbid=234270) serve as good resources.

The default Group Policy settings work well for most AD environments, but if you have persistent problems with publishing or pruning, changing a few specific policies might help. As Figure 6 shows, you find the settings associated with printing and pruning in the Group Policy console under Computer Configuration, Administrative Templates, Printers. If you have severe problems with printers being pruned unnecessarily (e.g., because of network problems), I suggest that you first try increasing the Directory pruning interval. If that doesn't solve the problem, then increase the Directory pruning retry. You can also enable Check published state and set it to an appropriate value—12 hours should be sufficient. This last setting is particularly useful because it causes print servers to republish pruned printers without you having to restart the spooler on the print server. Be careful not to set this value too low—frequent spooler restarts might adversely affect server performance.

I don't recommend switching off printer pruning altogether because you could end up with orphaned printer information in AD. However, if you really want to do so, the setting to change is Allow pruning of published printers (set this value to Disabled).

A difficult decision arises with regard to the Group Policy pruning settings for manually published printers. If you allow pruning for these printers, you'll probably need to manually republish the printers from time to time, which can be both annoying and time-consuming. However, if you disable pruning for these printers, you'll most likely end up with orphaned printers in AD. You also don't have the option to use the Check published state setting because this policy works only with print servers that can automatically publish printers. A compromise would be to place manually published printers in a separate, dedicated organizational unit (OU) linked to a policy with higher than usual Directory pruning interval and Directory pruning retry settings. It's also a good idea to set the Allow printers to be published policy setting to No for your workstation OUs, which makes the List in the Directory check box unavailable.

Learning Points
The introduction of printer publishing in AD provides a handy way for users to quickly locate nearby printers. The many printer-related attributes stored in AD let your users carry out detailed searches for printers with specific features. For the Find Printer service to be effective, you must carefully plan and manage the printer publishing and pruning mechanisms. Pay particular attention to the Location-field naming schema because it largely determines the effectiveness of users' printer searches.

The publishing and pruning mechanisms aren't always trouble free, so you need to understand how the mechanisms work, the types of problems to watch for, and how to troubleshoot them. Fortunately, tools such as EventCombMT are available to help.

In addition, Group Policy settings let you control most publishing and pruning behavior. You should occasionally review and, where appropriate, modify the settings as your AD environment grows and changes.