Published printers disappears from AD!


Published printers in AD disappears after a moment (day). what is the cause and resolution for it?


The printer pruner is only possible if the spooler service (printer spooler) is running on at least one domain controller. If the spooler service is not running on the

domain controller, the printer pruner is not possible. By default the spooler service is running in automatic mode (running on the context of system account) on all the domain controllers of a domain. Except on a Core server edition (the spooler service does not exist).

Things to check:

1. The printer server is correctly registered in DNS (need A record on the DNS zone) ?
2. The DHCP client service is running on the printer server (for some reason, dynamic DNS updates require the DHCP client service to be running.
3. The subnet that the printer server is in is correctly registered in AD topology.
4. Enable printingService operational log on the DC: wevtutil sl Microsoft-Windows-PrintService/Operational /e:true
5. Enable GPO on the DC, to start the spooler in automatic mode (local system) and to enable the log: “Log directory pruning retry events” (see below)

The printer pruner runs on DCs (not as a service, but as a thread within the spooler service) and needs to contact the print queues on printer servers in order check that they are still available. If there is poor connectivity between the DC(s) and printer server then you can see this type of unexpected pruning behaviour. Usually the problem is a misconfiguration in DNS, in which case you might get off-site DCs pruning the printers because bad network connectivity.

To determine which DC is responsible for the pruning. Enable the event logs for the PrintService (From Server Manager expand Diagnostics–>Event Viewer–>Applications and Services Logs–>Microsoft–>Windows–>PrintService. Right click Operational and choose Enable Log). I also enabled the GPO setting “Log directory pruning retry events” and assigned it to my DCS. After a period of time the event IDs I listed above for Win2k8 were listed (343 and 346) and I finally figured out which DC was removing the printers. Note: other method using auditing tool like Dell change auditor for AD (create a rule to audit printqueues).

If the printer server is on the same AD site than the DC (of couse; check the point 3 above), it’s probably not a DNS issue if the DC in the same AD site is pruning the printers. The pruner will only remove the printers from AD if it can’t contact the print queue on the printer server for some reason. Some of these reasons can be:

1. Outage of the printer server for a period of more than 24 hours (by default the pruner will try to make contact 3 times with 8 hour intervals before performing the removal).
2. Network problems between the DC and printer server.
3. Firewall between the DC and printer server.
4. Problems with the DC itself.

If you don’t find a specific problem, you could try a workaround with Group Policy settings. First of all increase the Directory pruning interval (from the default
8 hours), together with the Directory pruning retry (from the default of 2 retries). You could also enable Check published state and set it to an appropriate value (12 hours should be sufficient). This is a useful setting in that it will cause pruned printers to be re-published without having to restart the spooler on the print

Note: According to the article found the TechNet article 246906 “Printer Pruner May Prune all of the Print Queues Objects on Its Site”. If
“Allow pruning of published printers” policy is disabled, enable the policy and set the interval to Never”. => I wouldn’t recommend that setting as it effectively stops all pruning. Pruning is a good thing because it helps maintain current information in AD. Consider the
following scenario: You have a printer server that has some hardware problems. You down the server, rebuild the machine with new hardware, call it something else and republish all your newly created print queues. If you have the pruning set to Never you will end up with two sets of print queue information in AD because the old printer information will never go away. This is an extreme example, but similar things can happen on a smaller scale, i.e. one or two print queues removed long ago remain published in AD forever.

Other resources:

How to use Group Policy settings to control printers in Active Directory:

Print management step by step guide:

AD DS Printer publishing event IDs: