Hello, In our organization we have many, many stale computer accounts. It will be weeks or maybe months before we get around to cleaning it up, and in the meantime my SCCM sites are constantly showing warning/critical because of errors installing to hundreds of computers that don't exist any longer. As we speak there are 316, 348 and 745 warnings on my 3 primary sites. 90% of these warnings are Operating system error 53: The network path was not found. This is because that computer doesn't exist on the network anymore. Is there any way I could tell SCCM to remove a computer account if it gets the above error message 10 times in a row, or something along those lines? Or is my only option to wait until we have time to clean out AD in order to fix this? Thanks!

Unfortunately No. As long as the machines are discovered using AD System discovery they will keep showing up. What would help is moving machines which have not contacted AD for X number of Days to a "Disabled" OU based on your organizations policy and dont discover that container.You can look at http://www.myitforum.com/forums/m_137852/printable.htm which might help you perform a clean up at the AD side.

No but you can change the warning threshold for the ccm component. That will remove the warnings.Kent Agerlund | http://scug.dk/members/Agerlund/default.aspx | The Danish community for System Center products

I would also create a process to remove the DNS records for any machines that are getting error 53's. If SCCM can't resolve the IP when it discovers the machine, it will not try to create a CCR. You can parse the ccrretry folder to see which ones are getting error 53. DNS scavenging would be the best option, but if that's not possible, you could selctively remove the DNS records for those getting error 53 with DNSCMD.EXE. Here's an old article from Kim Oppalfenss :- http://scug.be/blogs/sccm/archive/2007/05/14/prepare-your-environment-for-running-sms-2003-active-directory-part1.aspx or http://blogcastrepository.com/blogs/kim_oppalfenss_systems_management_ideas/archive/2007/05/14/prepare-your-environment-for-running-sms-2003-active-directory-part2.aspx Regards, Tom Watson, E-Mail: Tom_... @... Blog: http://myitforum.com/cs2/blogs/tom_watson

Thanks for everyones replies, sorry for the late response. We are going to try and make time to clean up all old computer accounts and dns entries to clear up this warning/error spam. Thanks again!

What is your Delete Aged Inventory History task set to? The default of 90 days?http://www.enhansoft.com/

What is your Delete Aged Inventory History task set to? The default of 90 days? http://www.enhansoft.com/ Yes sir, the default of 90 days and for the past few days I have had it running daily, but the machines still exist in my SCCM database. Would an option be to delete all non-client systems and then allow AD discovery to do its thing again as usual?

Would an option be to delete all non-client systems and then allow AD discovery to do its thing again as usual? Are you asking if this is an option or a recomended solution? ;-)I delete all non-client system from time to time. I'm not saying it's a recomended thing to do and the maint tasks should take care of the ones you are seeing but I am short on patience sometimes so I just delete the non-clients and let AD System Disc find the valid systems again. John Marcum | http://www.TrueSec.com/en/Training.htm | http://myitforum.com/cs2/blogs/jmarcum

I am exploring stale computer accounts as well, and I am curious on the behavior of the AD System Discovery. I am wondering if someone out there can explain exactly what will cause AD System Group Discovery to write a DDR for a system? I ask becuase we were looking at a high number of machines that were no longer installed, and we enabled DNS Scavenging successfully. That resulted in AD System Discovery no longer creating DDRs for these old machines, but AD System Group Discovery is still writing DDRs, preventing the machines from automatically aging out of ConfigMgr (everything is basically 1 day old because discovery runs daily). Here's a bit of the adsysgrp.log...INFO: discovered object with ADsPath = 'LDAP://<machine in AD>... WARN: Could not get property (domain) for system (0x80005010) SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT WARN: Could not get property (memberOf) for system TST-MACHINE (0x80005010) SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT INFO: DDR was written for system 'TST-MACHINE' - D:\SMS\inboxes\auth\ddm.box\adhv5pjn.DDR at 2/23/2010 5:0:1. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT I did find an old SMS 2003 SP2 KB on the same subject, but no mention of it since this fix was included in SMS 2003 SP3 (http://support.microsoft.com/kb/921463). Anyone else see this behavior? I'm not sure if it is a problem with ConfigMgr SP2 or earlier... or if there is something in the AD data that also needs to be purged. Yes, I know that the best solution would be to remove the objects from AD, but sometimes that doesn't happen. I do not remember this being a problem before now, but I really did not notice because the DNS aging was enabled after the SP2 upgrade. Thanks, Mccollett