This is the 4th part in a series designed to help you build a style-based SQL Reporting Services (SRS) reporting system using a DB, an RDL template and SRS (similar to CSS or cascading stylesheet like functionality)
I've heard some chatter lately about people deleting records from the SCCM 2012 console but noticing they're still in the underlying SYSTEM_DISC table.
Here's what's happening:
When you delete a computer from the console, the SYSTEM_DISC table won't get that record deleted, it will get updated so DECOMMISSIONED0 = 1 (this is different than SCCM 2007 where a deletion in the console will trigger a cascade of deletions from all relevant inventory and discovery tables where that resource has records)
At this point when you query v_R_System, you'll notice the machine is gone but this is because v_R_System gets it's data from the vSMS_R_SYSTEM view. vSMS_R_SYSTEM has a filter criteria in it to remove any decommissioned records so they won't show up when you query the view:
select * from System_DISC where Decommissioned0=0
Here's WHY it's happening:
This actually makes sense if you think about it. SCCM is the world leader in my opinion for configuration management scalability. So when you're building a solution like this for a company that has 400K-500K clients, you have to consider there's a lot of reimaging and a lot of VMs in labs that continually get reverted back to previous snapshots, etc. I have seen instances where companies have actually run out of ResourceIDs because SCCM 2007 didn't re-use unused ResourceIDs, it just incremented it and gave you a new one. Also, in scenarios where those machines are getting reimaged/reverted, then may also find that all the machine history is gone for those boxes that are reimaged/reverted.
But, in SCCM 2012, if it only flags a record as decommissioned then when that machine comes back online, SCCM will be able to flag that old record as DECOMMISSIONED0 = 0 again and it will show up in the inventory, essentially reusing the same ResourceID. Then the history for that previously decommissioned resource will still be there and SQL didn't have to chug through all the cascading deletions. This can be incredibly helpful for OSD scenarios and for VM scenarios where the same machine might get clobbered a few dozen times per day.
All in all, I think this is a really nice improvement.