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.
