Quick Background: We got badly hit by a virus, result was that we had to re-image around approx 500 PCs in which the SCCM client had been installed and was working fine. PCs have been reimaged using Ghost. PCs after reimage have the exact same computer account name and IP address. What I thought would happen: There would be an additional 500 PC entries in the database indicating no SCCM client installed and 500 existing entries marked as obsolete. Thus, I would simply deploy the client back out to the 500 new entries and delete the 500 obsolete records. What has actually happened: Around 40 PCs out of the 500 have done the above i.e. now have the obsolete tag against them. The remainder 470 PCs still show up in SCCM database as thinking they still have the client installed, when they dont. Heatbeat Discovery runs one a week and AD System Discovery runs once a day. There are no entries in the conflicting records node. So at the moment I have collections of PCs that indicate the PCs have the client installed, when I know that is not the case. I would like an accurate record of which PCs I need to roll the client back out to. I know I could just reinstall the client out to everyone again, but if something goes wrong and the client didnt install for whatever reason, I wouldnt have a quick visual indication i.e. Client = No turning into a Client = Yes because they all say Client = Yes at the moment. And around 75% of PCs are fine, so I dont want to touch them. Hope that makes sense! I simply want to know which PCs need the client reinstalled and its not clear how I can do this. And why have some PCs showed up as being obsolete, when most havent? Im confused I think part of the solution may be to do with reducing the Delete Aged Discovery Data task to say 20 days (as this all happened around 1 month ago), but Id like some clarification if what Im about to do is the right thing

Is there a ConfigMgr client in the image or comes the image without one? You could run the "Clear install flag" maintenance task (pay attention when using the automated client push installation). That will reset the "Client = yes" flag to "Client = no"for each system. Only clients that are sending heartbeat discovery (you could adjust the schedule to "1 day" to speed things up)will turn into "Client = yes".

Hi,The images do not haveSCCM client on it. We use client push to install SCCM clientafter PC has OS on it.Will look into enabling the "Clear install flag" task, it is currently not configured.Also noticed this error appearing in Event Viewer on server: Event ID 13032Many client computers have not reported back to the server in the last 30 days. 509 have been detected so far.Am i correct in thinking that when the "Clear install flag" is enabled and it changes the status of a system resource from Install= Yes to Install= No, the hardware/software data relating to the PC before the reimage will still exisit in the SCCM databse? what is the best way to remove this?

That maintenance task will only change the install flag. HINV/SINV data etc are not touched. You can use the "Delete aged ..." maintenance tasks to remove data or you could delete the entire client (resource) from the database.

This is my plan to clear out the database, please tell me if I am missing something out or being silly: 1. Enable the Clear Install Flag to 21 days. This means that after 21 days if PCs are not discovered by the Heartbeat discovery the Install = Yes will turn to Install = No. Any PCs that do not have the client installed cannot be Discovered by the Heartbeat. 2. Set the Heartbeat discovery to 1 week. So each PC that has the client installed must send an updated DDR every 7 days. 3. Reduce the Delete Aged Discovery Data from 90 days to 30 days. This will delete any hwinv/swinv data from the SCCM database associated with computer accounts not discovered in the last 30 days. Does this also delete the discovered resource as well from the collections so the computer account will not show up anywhere? If the PC is on the network but not got the client installed, it will be discovered again by AD system discovery anyway. 4. Enable the Delete Inactive Client Discovery Data to 30 days. 5. Enable Delete Obsolete Client Discovery Data to 30 days General question re above: When I set the time interval (for example reducing the Delete Aged Discovery Data to 30 days), does it start counting from the moment I do the change i.e. 30 days from the point of changing, or does it start deleting data right away from the last 30 days?

Our SCCM database is still showing and retaining data that i believe shouldhave been deletedas manyPC's no longer havethe client installed on them.I have carried out the 5 steps in my last post.Many PC's now correctly show the fact Client= No in the attributes when looking at my collections thanks toenabling the Clear Install Flag inpoint nr 1 in the above post, and they correctly do not show up if i am running any reports on the collection they are in.However, if i run Resource Explorer on any computer resource directly (one that does not have the client installed) it still gives me information relating to the computer before it was reimaged. This is very confusing. We are still receiving the below error in Event Viewer:"Many client computers have not reported back to the server in the last 30 days. 675 have been detected so far."Can anyone please point out what i need to do in order to get the database back into a reliable state.Thanks in advance

Can anyone please point out what i need to do in order to get the database back into a reliable state. I suggest calling CSS (Microsoft support) so that they can assist you. Your problem goes far beyond the possibilities of a forum, because you were running in an very uncommon situation.

Hi Torsten,I didnt think we were in an uncommon situation. I would have thought that many people use ghost to reimage PC's back to a previous image using the same IP and computer name. AmI correct in thinking that SCCM should have created a new object for these reimaged PC's once they had been discovered, and the duplicate existing older objects would have been marked as obsolete. Then we should have been able to delete the obsolete ojects which would have deleted the associated HW/SWinv in the database. Then turned our attention to rolling out the client back out the the PC's and the databse would be populated with relevant data.Obviously this hasnt happened in our environment but should it have done so?

Hi gjs010. I've been told the same about our "unusual" setup. It is really frustrating that what seems like the simplest way to integrate SCCM into an existing infrastructure doesn't seem to be recognized as a reasonable approach.

Hi gjs010. I've been told the same about our "unusual" setup. It is really frustrating that what seems like the simplest way to integrate SCCM into an existing infrastructure doesn't seem to be recognized as a reasonable approach. What are you talking about exactly? Your issue seems not virus-related. Please provide some details so we can assist you. Integrating ConfigMgr into an existing infrastructure is not an unsolvable problem.

Seems like the title of the post may have made it seem like your issue were related to a virus which is probably why Torsten said you should call CSS. After reading through this I don't see anything related to a virus that plays a part in your question so here goes my best effort at an answer.... While using Ghost to reimage computers and giving them the same computer name they had before is not an "unusual setup" it is also not an ideal one. SCCM works best if you use it's OSD. Of course that's not an option for many people and using Ghost will work just fine. It does seem to take a little time for things to get working on a computer again after it's been reimaged. What I suggest you do is ensure all built-in maintenance tasks are enabled, lower heartbeat to once per day and lower clear install flag to 7 days. Make sure client push install is enabled and run AD System Discovery. You should see those "new" computers being added to the database now. The client should install on them automatically. If you look in the console there's a good chance you will see those computer names in there twice wait a few days and the install flag will be cleared on the old one. I usually have a collection of all computers without the client installed. At that point you could do a delete special to get them gone or just have a little patience and the maintenance tasks will take care of everything for you. John Marcum | http://www.TrueSec.com/en/Training.htm | http://myitforum.com/cs2/blogs/jmarcum

@Torsten: I'm sorry, I didn't read the title of the thread before I hijacked it. :P All I'm saying is that when I describe my use of Ghost to reimage machines and ask the forums why they don't get new clients installed, I've been told that my setup is too specialized and I find that hard to believe. @John: Thank you for the thorough response! This is exactly what I have been trying to accomplish. The problem is that when our PCs get reimaged, the users expect the software to be reinstalled in a number of hours, not days or weeks. It is not me who is impatient for the clients to become active, but those I support. I was just hoping there was a faster (automatic) method to bring the clients back online. I'd love to use OSD, but haven't found the architecture very easy to understand. All departments are silos at the university I work at, and I am not privy to how the AD server roles are assigned, so reconfiguring DHCP to forward PXE traffic to the SCCM box has been hampered by the bureaucracy. Thanks, Mike

In my experience you are not going to get that to happen in a matter of hours. It takes awhile for things to get straightened out. You don't need to configure anything in DHCP for the PXE service point to work. You do howver need to configuration changes on the routers. Of course there's also options that do not require using PXE. If you go with OSD and integrate MDT the apps can be back on those boxes before the user ever logs in the first time. John Marcum | http://www.TrueSec.com/en/Training.htm | http://myitforum.com/cs2/blogs/jmarcum

you're raising my hopes again John. When we deployed SCCM a year ago I had every intention of enabling OSD, but the bureaucratic environment, and trouble I had finding helpful documentation thwarted my efforts. Now I spend my time deleting old SCCM objects and deploying software. Can you share a good resource that will help me get OSD/MDT working? Our environment is 2003. Thanks!

The best resource around for getting MDT/OSD running is Johans class. Go to truesec.com for more info. If you can't make it to his class get his free cd from deploymentcd.com and of course catch all his sessions at MMS. John Marcum | http://www.TrueSec.com/en/Training.htm | http://myitforum.com/cs2/blogs/jmarcum