Published printers disappears from AD!
Symptom:
I have a recurring problem that is strange. I have 90 published, network printers on a server that on occation will disappear from the Active
Directory. I have to stop/restart the spooler service on this server and on a DC in order to get the printers to reappear in the AD search option.
The DCs is running Win2K8 r2 with SP1. I do not have the “Directory pruning interval”, “Directory pruning priority” or “Directory pruning retry” set
with in the AD set. … The user can still find the printer by going through the old NT4 style printer search.
Has any seen this issue before? If so, what is the cause and resolution for it?
Investigation:
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). When the Spooler service is running you can monitor the event IDs 47 or 50.
Some things to check:
1. The printer server is correctly registered in DNS ?
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.
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.
Use the EventCombNT tool to search for events 47 and 50 in the System event log on DCs. This will show you which DC is responsible for the pruning. From there you can
generally work backwards to find the problem.
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
server.
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.
Troubleshooting for Published Printers Missing:
1. Launch GPEdit.msc on the Print Server.
2. Navigate to Computer Configuration / Administrative Templates / Printers.
3. Configure the Allow Pruning of Published Printers policy to Disabled.
4. Refresh group policy.
By default the DC checks 3 times with 8 hours between checks to determine if the printer is still valid before deleting it. “The Print Pruner is a thread that runs under the spooler context on all DCs. It uses ADSI calls ( ADsGetObject, IID_IDirectorySearch->ExecuteSearch) to get the list of all the printQueue servers in the AD.
To check whether the server is in same site it uses Winsock call (gethostbyname) and other net APIs (DsAddressToSiteNames,DsGetDcSiteCoverage).
To check if the print queue\print server availability it uses OS APIs (NetServerGetInfo, OpenPrinter,GetPrinter).
So all the work by pruner is done using ADSI, WinSock and OS functions.”
Workaround to get the Disappeared Printers back:
Click on Start, Run, Services.msc
Stop and restart “Print Spooler” service
Note: When the spooler service is restarted on a print server it automatically republishes the printers.
Note: On a cluster service, just stop the Print Spooler service, since the cluster service will automatically start the service when it tries to bring the Print resource online.
Other resources:
http://www.adamfowlerit.com/2013/08/19/network-printers-keep-disappearing-from-directory-services/
http://blogs.technet.com/b/askperf/archive/2009/05/05/printing-and-active-directory.aspx
How to use Group Policy settings to control printers in Active Directory: http://support2.microsoft.com/kb/234270/en-us
Print management step by step guide: http://technet.microsoft.com/en-us/library/cc753109%28v=ws.10%29.aspx
AD DS Printer publishing event IDs: http://technet.microsoft.com/en-us/library/cc773824%28v=ws.10%29.aspx
