I come from Singapore but find myself now living and working in the Netherlands, specialising in SMS 2003 / Configmgr 2007. I enjoy working and connecting people with computers and I hope I can share as much information as I can here through this blog.
“Computers do not just work like that, at the press of a button. From the moment a computer is switched on in your office, magic happens. That’s why you need an IT department and they do more than crawling under your desk to plug in that wire you kicked out.”
Sometimes, when a distribution point has been decommissioned or renamed, the previous server's site last known component statuses are still reported in the SCCM's Site Status panel. In most cases, we see the exact duplicated site components, thus the Component Status panel is showing 2 server names, and littered with twice the number of components. Obviously, we want to get rid of the redundant ones to get a nice and accurate overview of the site. There are a few ways to go about this and I will share here on the blog my preferred method. This method will also work for you if you see just one or two duplicated components.Example of components can range anything from the SMS_DESPOOLER to the SMS_WSUS_SYNC_MANAGER. Identify the components that are pointing to the decommissioned site system and ensure that the last status messages and heartbeats are from the past and not current. The best way is to just sort by the Site System name which gives you then an immediate overview. It also important to note that the new site system is functioning and that these ghost site component statuses have just somehow bizarrely failed to get rid of themselves after the migration/rename/decommission. To summarise it simply, the information is stored on 2 separate tables in SQL, the 'Summarizer_Components' and the 'Summarizer_ComponentTallys'. You do not have to guess what is going to happen next then!*Important! -Please BACKUP your SCCM Database. It makes good practice and sense to do so every time you want to conduct a clean up or deletion. It's the feeling of having the GET OUT OF JAIL CARD while being instructed to go to jail playing Monopoly. So please exercise caution while performing the following steps.
SELECT sitecode, machinename, componentname, COMPONENTDATAIDFROM summarizer_components where machinename = 'ABC2000' AND sitecode = 'ABC'ORDER BY ComponentdataID
SELECT * FROM summarizer_componenttallysWHERE ComponentdataID in('11112','11113','11114','11115','11116','11117')
Now, the deletions and it is important that this must be done in the correct order shown below.
DELETE FROM summarizer_componenttallysWHERE ComponentdataID in('11112','11113','11114','11115','11116','11117')
DELETE FROM summarizer_componentsWHERE machinename = 'ABC2000' AND sitecode = 'ABC'
Restart the SMS_Executive Service, and refresh the site status panel and you should see that those ghost entries have now been vanquished. I hope you see the same, else I would advise you to restore that backup and then do a bit more investigations into the source of the problem. Please also monitor for a while to ensure that these deleted components do not return as well, as it could then be that the sites are still replicating it up to the parent and central site. I hope the above helps you! If not, my apologies and maybe it's time to take a holiday! :)