Hardware Inventory isn’t a huge topic, but there are a lot of details — far more than I could cover in a single post. The intent of this post is to cover a significant change from SMS 2003 to ConfigMgr 2007: the separation of reporting classes and data classes into two files.

The first thing I usually tell folks is that hardware inventory isn’t really hardware inventory, it’s inventory from the WMI repository. WMI is most often associated with hardware and most of the default information stored in WMI is hardware related, but not all of it. This is, of course, significant when you look at the Resource Explorer and see Add/Remove Programs under it or when you want to extend inventory in Config to collect registry values and are told that it is handled by the hardware inventory process. Definitely a potential cause for confusion also.

Also, ConfigMgr does not pull everything available from WMI, it pulls a selected subset as defined in the sms_def.mof file (located in <Installation Dir>inboxesclifiles.srchinv). SMS_DEF.mof is a plain text file that you can edit with notepad or any text editor. It is in a special format called Managed Object Format (MOF); MOF files are part of the WBEM/CIM standard and not Microsoft proprietary. The MOF file format is fully documented on MSDN: http://msdn.microsoft.com/en-us/library/aa823192%28VS.85%29.aspx.

Unless you are extending a MOF file, you don’t need to be intimately familiar with the format details. The main thing to know is that MOF files define classes of information, similar to classes in object-oriented programming. Each class can have properties and methods, although for data collection we don’t really care about methods.

This brings us to our two files: SMS_DEF.mof and Configuration.mof.

SMS_DEF.mof defines “reporting” classes. These classes exist (or are created by ConfigMgr) in the WMI namespace rootCIMV2SMS and specify where the actual data we are interested in is stored. It does this by creating classes in this namespace that are (nearly) identical in definition to the class that holds or provides the real data; a.k.a., the data classes. Here’s an example snippet of a reporting class from SMS_DEF.mof:

[ SMS_Report  (TRUE),
SMS_Group_Name ("Computer System"),
SMS_Class_ID   ("MICROSOFT|COMPUTER_SYSTEM|1.0") ]

class Win32_ComputerSystem : SMS_Class_Template
{
[SMS_Report (FALSE)  ] uint16  AdminPasswordStatus;
[SMS_Report (FALSE)  ] boolean AutomaticResetBootOption;
[SMS_Report (FALSE)  ] boolean AutomaticResetCapability;
[SMS_Report (FALSE)  ] uint16  BootOptionOnLimit;
[SMS_Report (FALSE)  ] uint16  BootOptionOnWatchDog;
[SMS_Report (FALSE)  ] boolean BootROMSupported;
[SMS_Report (FALSE)  ] string  BootupState;
[SMS_Report (FALSE)  ] string  Caption;
[SMS_Report (FALSE)  ] uint16  ChassisBootupState;
[SMS_Report (TRUE)  ] sint16  CurrentTimeZone;
}

ConfigMgr matches up the names of the reporting classes to the names of data classes and then sucks out the data from the data classes. The above snippet instructs ConfigMgr to pull data from the Win32_ComputerSystem data class. The boolean value of a special qualifier, SMS_REPORT, on a reporting class and its properties tells ConfigMgr which classes and properties to actually inventory. SMS_DEF.mof by default defines a large number of reporting classes and their properties that ConfigMgr takes no action on. If you decide that you want that information, just flip the SMS_REPORT qualifier from FALSE to TRUE. That change will go out during the next policy interval and the clients will report the info during their next hardware inventory cycle.

The SMS_DEF.mof file is converted into policies by the site and distributed to clients as part of the policy distribution process. The SMS_DEF.mof file is not distributed to clients in its raw form. Also, note that no data is normally stored using the reporting classes. These classes are simply “road-signs” telling ConfigMgr which data classes to pull data from.

Configuration.mof is new to ConfigMgr and splits out the definition of data classes from the reporting classes.  Data classes are usually located in rootCIMV2. Most data classes used by ConfigMgr by default already exist in the repository because they are just default Windows WMI classes. Thus, there is no definition for the majority of data classes in Configuration.mof — they already exist. It is also worth noting that “data class” is a ConfigMgr only term that refers to the WMI classes that ConfigMgr pulls data from. There’s nothing inherently special or particular to ConfigMgr about these classes; they are normal WMI classes available to anyone or thing that queries WMI.

In contrast to SMS_DEF.mof, the Configuration.mof is delivered in its entirety, embedded in the policy, to each client. The Configuration.mof file is then automatically compiled and added to the WMI repository using mofcomp.exe. Although Configuration.mof file is specific to ConfigMgr, as I said above, the classes it creates are not special in any way nor is the process used to create them — this is all just standard WMI configuration.

Data can be statically populated in the data classes or populated using a dynamic process — similar to object-oriented programming or database design, the classes themselves do not actually store data, rather instances of the classes store the data. The classes just define how to store the data and what it looks like. There are many dynamic methods to populate data including WMI providers, like the registry provider, or VBScripts. All of the default WMI classes (and presumably those provided by other applications) populate their own classes automatically through their own processes.

One of the takeaways from this is that if you want to extend the hardware inventory in ConfigMgr you must add a reporting class and a data class. The reporting class is always defined in SMS_DEF.mof and, to reiterate, tells ConfigMgr where the data lives that it should retrieve. The data class, on the other hand, can either be defined in Configuration.mof or through any WMI extension process. Why the difference? Because remember that data classes are not in any specific to ConfigMgr, they are just WMI classes so you can create these any way that you like — ConfigMgr just sucks the data out of them as defined by the SMS_DEF.mof file.

In addition to defining the data class (either via Configuration.mof or some other process) you must also populate these classes with data — this can be done on the fly with a dynamic provider like the registry provide, a VBScript, a custom WMI provider, or any other way you want to write data into WMI.

To sum up quickly, SMS_DEF.mof
defines where to collect data from in WMI via the use of reporting classes and Configuration.mof defines how the actual data is stored in WMI using data classes.

Configuration.mof vs. SMS_DEF.mof