Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

Demystifying Resource Manager and the 7.1 CMDB a bit...

Created: 27 Jun 2012 • Updated: 27 Jun 2012
KSchroeder's picture
0 0 Votes
Login to vote

So as we are working on our 7.1 migration from 6.x, we have encountered various mysteries and oddities in the way the database schema changed in 7.x (at least in 7.1, never looked very closely at 7.0).  One of these came up while we were working on recreating some filters (and reports) and we found that while Resource Manager for a particular machine shows "Notebook" for the "Chassis Package Type" in the Hardware > Chassis Inventory, the DB table Inv_HW_Chassis just has the numeric value from WMI (documented in this Technet article).  However, we ALSO found that there is a view RMV_HW_Chassis that has the "friendly" chassis type information that you would normally have to use a CASE statement to report on, along with a lot of other handy columns, like CPU "real" descriptions such as "Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz" (including MHz, processor count, core count), video/soundcard, memory MB (and total/available slots).  If you go into the DB with SSMS 2008, right click the Inv_HW_Chassis table, and click "View Dependencies", you'll see all the tables/views/etc that are dependent on that table.  That's how I found RMV_HW_Chassis. 

Incidentally, there are several other RMV_XXXX_XXXXXX views in the database; my interpretation is that the RMV stands for "Resource Manager View", as this info is used to localize certain fields in the Resource Manager, including the "Chassis Package Type" field in the Chassis Hardware inventory. You can test it by changing your primary IE language to French or Spanish, then view various Inventory classes in Resource Manager for a machine after refreshing the page in the Resource Manager; some of the items will be localized to that language.

As for creating filters based on those views...maybe not a good idea, as there are several function calls and multiple joins to other tables to get the same information.  However, if you need reports which are localized at least to some degree, then it might be useful (not sure though if the localization would come through in a report view, or if it would use the language setting of the database...?)