Modifying SMS_DEF.MOF and Configuration.MOF to pull information from a 64-bit registry

  • Article

Recently had the occasion to modify the SMS_DEF.MOF and Configuration.MOF files to pull information from a native 64-bit registry.  It’s a relatively simple process – there are even some classes, like addremove and virtual machines, that are default and give examples to do this.  Below are the relevant sections from each file for my project.

SMS_DEF.MOF
---------------
#pragma namespace ("\\\\.\\root\\cimv2\\sms")

[ SMS_Report(TRUE),
  SMS_Group_Name("Widget Build"),
  SMS_Class_ID("MICROSOFT|Widget_Build|1.0"),
  SMS_Context_1 ("__ProviderArchitecture=32|uint32"),
SMS_Context_2 ("__RequiredArchitecture=true|boolean") ]

class Win32Reg_Widget_Build : SMS_Class_Template
{
    [SMS_Report (TRUE), key ]     
    string IndexKey;
    [SMS_Report (TRUE) ]          
    string Widget_Product;
    [SMS_Report (TRUE) ]          
    string Widget_Release_Date;
    [SMS_Report (TRUE) ]          
    string Widget_Type;
};

#pragma namespace ("\\\\.\\root\\cimv2\\sms")

[ SMS_Report(TRUE),
  SMS_Group_Name("Widget Build 64"),
  SMS_Class_ID("MICROSOFT|Widget_Build_64|1.0"),
  SMS_Context_1 ("__ProviderArchitecture=64|uint32"),
SMS_Context_2 ("__RequiredArchitecture=true|boolean") ]

class Win32Reg_Widget_Build_64 : SMS_Class_Template
{
    [SMS_Report (TRUE), key ]     
    string IndexKey;
    [SMS_Report (TRUE) ]          
    string Widget_Product;
    [SMS_Report (TRUE) ]          
    string Widget_Release_Date;
    [SMS_Report (TRUE) ]          
    string Widget_Type;
};

Configuration.MOF
------------------
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("Win32Reg_Widget_Build", NOFAIL)
[DYNPROPS]
class Win32Reg_Widget_Build
{
    [Key]
    string IndexKey;
    string Widget_Product;
    string Widget_Release_Date;
    string Widget_Type;
};

[DYNPROPS]
instance of Win32Reg_Widget_Build
{
    IndexKey="Widget Build Data";

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Product"),      Dynamic, Provider("RegPropProv")] 
    Widget_Product;

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Release_Date"),      Dynamic, Provider("RegPropProv")] 
    Widget_Release_Date;

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Type"),      Dynamic, Provider("RegPropProv")] 
    Widget_Type;
};

#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("Win32Reg_Widget_Build_64", NOFAIL)
[DYNPROPS]
class Win32Reg_Widget_Build_64
{
    [Key]
    string IndexKey;
    string Widget_Product;
    string Widget_Release_Date;
    string Widget_Type;
};

[DYNPROPS]
instance of Win32Reg_Widget_Build_64
{
    IndexKey="Widget Build Data 64";
    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Product"),       Dynamic, Provider("RegPropProv")] 
    Widget_Product;

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Release_Date"),      Dynamic, Provider("RegPropProv")] 
    Widget_Release_Date;

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Type"),      Dynamic, Provider("RegPropProv")] 
    Widget_Type;
};

From the above you notice that to pull both 32-bit and 64-bit information we need a section in the control files for each platform.  Also notice the bolded text – this is the key to pulling data from 64-bit systems so make sure you include it.  Using the example above works in my lab but there have been reports of problems so be aware.  If you don’t want to worry about it just add your registry information under the wow6432node and use 32-bit MOF extensions to pull the data.  A very cool GUI based utility to auto-build these extensions on 32-bit systems is in referenced in my previous post.