Customizing with MOF Files

  • Article

MOF files are appropriate for static management data or dynamic management data. Static data includes details such as the computer user's phone number, office number, and name. Dynamic data includes details such as Microsoft SQL Server(tm) database sizes and applications installed with Windows Installer.

On This Page

Using MOF Extensions for Static Data
Using MOF Extensions for Dynamic Data
Using MOF Extensions with Namespaces Other Than root\CIMv2
Best Practices for MOF Extensions

Using MOF Extensions for Static Data

You can create MOF files by using a text editor. When you have defined a MOF file that stores the data you require, you can use that MOF file as a template so that similar data is defined in the same manner. For example, when you are setting up a new computer, you could copy the template file to the new computer, edit the data contained within the file to reflect the new computer, and then save and compile the new file. Compiling the MOF places the data in WMI. SMS can then collect the data from WMI and store the information in the SMS site database along with the other inventory data for that computer.

MOFs that store static data must do two things:

  1. Define the data class.

  2. Define the data (instances), as in this example:

    #pragma namespace ("\\\\.\\root\\CIMv2")
class Static_MOF
{
        [key]
        string user;
        string office;
        string phone_number;
};
instance of Static_MOF
{
        user = "John Smith";
        office = "Building 4, Room 26";
        phone_number = "(425) 707-9791";
};
instance of Static_MOF
{
        user = "Denise Smith";
        office = "Building 4, Room 26";
        phone_number = "(425) 707-9790";
};

After you edit the MOF file on the client computer to enter the data, the file must be compiled by using the Mofcomp.exe command, as in this example:

Mofcomp.exe <path>\SMS_def.mof

You can edit and compile the file repeatedly, but because it is a manual process, you might not want to use this process for data that changes frequently.

Also, SMS_def.mof must be extended to include a reporting class for the collected data. For example, add the following MOF to SMS_def.mof:

#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
[ SMS_Report     (TRUE),
  SMS_Group_Name ("Static AssetInfo MOF"),
  SMS_Class_ID   ("MICROSOFT|Static_MOF|1.0")]
class Static_MOF : SMS_Class_Template
{
    [SMS_Report(TRUE), key]
        string user;
    [SMS_Report(TRUE)]
        string office;
    [SMS_Report(TRUE)]
        string phone_number;
};

Using MOF Extensions for Dynamic Data

MOF extensions for dynamic data are much like MOF extensions for static data, except that they do not include the data itself. Instead, they provide details for WMI to retrieve the data using WMI providers. For more information about WMI providers, see Appendix B, "Windows Management Instrumentation," and the Microsoft Windows Management Instrumentation Software Development Kit, which is available for download at https://msdn.microsoft.com.

You can create MOF files with details for WMI to retrieve data by using a text editor. Compiling the MOF places the hardware inventory rules in WMI. SMS can then collect the data from WMI based on the hardware inventory rules and store the information in the SMS site database along with the other inventory data for that computer.

You can add MOFs that are used to collect dynamic data to SMS_def.mof. The reporting class part of the MOF must be added to SMS_def.mof. The data class part of the MOF can be added to SMS_def.mof for Legacy Clients. For Advanced Clients, the data class part of the MOF must be distributed to the clients and compiled using the WMI MOFcomp.exe tool. You can use SMS software distribution to do this. If the data class uses a WMI provider that is not standard on the clients, the WMI provider must also be distributed to all clients.

MOFs that provide hardware inventory rules for dynamic data must do two things:

  1. Define any providers the data class might require, if the providers are not already defined in the MOF file

  2. Define the data class

Also, SMS_def.mof must be extended to include a reporting class for the collected data.

After you edit the MOF file to enter the data, the file must be compiled using the MOFcomp.exe tool. You can edit and compile the MOF file repeatedly, but because the data is automatically collected, you would do this only to correct errors with the MOF.

The examples in the "Common MOF Extensions" section later in this chapter are all examples of MOF extensions for dynamic data. Adjusting an example to serve your needs might be easier than reading the relevant WMI SDK documentation.

Using MOF Extensions with Namespaces Other Than root\CIMv2

The SMS Hardware Inventory Client Agent typically collects data from the root\CIMv2 namespace. Data that you want hardware inventory to collect might be located in other namespaces. This is often true for systems that have their own WMI providers, such as SQL Server, Microsoft Exchange, and Microsoft Internet Information Services.

The Hardware Inventory Client Agent on the Legacy Client cannot access namespaces other than root\CIMv2. However, the WMI View Provider can be used to make data from those namespaces available in the root\CIMv2 namespace. For information about using the View Provider, see the WMI SDK. For an example of using the View Provider, see the "Collecting SQL Server Information" section later in this chapter.

The Hardware Inventory Client Agent on the Advanced Client can access namespaces other than root\CIMv2 by using a reporting class qualifier. When defining your MOF extensions, add the Namespace qualifier to your hardware inventory rules. The following example demonstrates using the Namespace qualifier:

        #pragma namespace ("\\\\.\\root\\CIMv2\\sms")
[SMS_Report(TRUE),
    SMS_Group_Name("Registered GUIDs"),
    SMS_Class_ID("Microsoft|Registered GUIDs|1.0"),
    Namespace("\\\\\\\\.\\\\root\\\\WMI")]
class RegisteredGuids : SMS_Class_Template
{
    [SMS_Report(TRUE), key]
    string InstanceName;
    [SMS_Report(TRUE)]
    boolean Active;
    [SMS_Report(TRUE)]
    uint32 GuidType;
    [SMS_Report(TRUE)]
    uint32 LoggerId;
    [SMS_Report(TRUE)]
    uint32 EnableLevel;
    [SMS_Report(TRUE)]
    uint32 EnableFlags;
    [SMS_Report(TRUE)]
    boolean IsEnabled;
};

Best Practices for MOF Extensions

Here are some best practices for extending SMS hardware inventory using MOFs:

  • Back up your current MOF file before making changes to it.

  • After you add your own classes to SMS_def.mof, do not use MOF Manager to further customize SMS_def.mof. All further customizations, including enabling and disabling the reporting of classes or properties, should then be done by editing the file with a text editor.

  • If you add your MOF to SMS_def.mof, you should add your MOF to the end of SMS_def.mof. This minimizes the possibility of your extensions interfering with the hardware inventory rules that Microsoft supplies.

  • Ensure that data hardware inventory rules always compile into the root\CIMv2 namespace and the reporting hardware inventory rules compile into the root\CIMv2\SMS namespace. The #pragma namespace lines define which namespace the following lines compile into, so their placement is important.

  • The class name for the reporting class must be identical to the class name of the data class.

  • The reporting class must have all the same key properties as the data class. The other properties do not need to be included in the reporting class. However, any properties that are included must have the same data type in both the data and reporting classes.

  • The reporting class must be based on the SMS_Class_Template class. The " SMS_Class_Template" clause, as illustrated in the example MOFs, ensures this.

  • Providers must be defined only once in a MOF. If you merge MOFs, remove redundant hardware inventory rules.

  • When creating reporting hardware inventory rules, consider using the data class definition as a starting point. Use Wbemdump.exe or MOF Generator in CIM Studio to export the data class definition to a MOF file. Both of these tools are included in the Windows Management Instrumentation SDK. Then edit that MOF file to put the class in the CIMv2\SMS namespace and add in the qualifiers that SMS requires. Use SMS_def.mof as your source for examples.

  • Test MOF extensions on individual clients in a lab environment before deploying more broadly. This testing allows you to ensure the MOF accomplishes exactly what you want. You should watch to ensure that the MOF does not return too much data. However, the reporting class changes must be added to the site-wide SMS_def.mof. Otherwise, the site does not load the data. Your testing should be done in your test lab before being deployed on any clients in the production environment.

  • For clients that fail to return data for the extension you create, use Wbemtest.exe or CIM Studio, as described in Appendix B, "Windows Management Instrumentation," to ensure that the data class contains instances. If the data class does not contain instances but should contain extensions, correct the problem with the data class part of your extension.

  • On the Legacy Client, review the Hinv32.log on any clients that fail to return data for your hardware inventory extension. A "CLASS - Process Class:" line should be listed for your extension, and there should be no error messages related to your class after it. If you do see error messages, correct the problem with the reporting class part of your extension.

    On the Advanced Client, review the Inventoryagent.log file. In particular, look at the "Inventory: Query =" lines.

  • The data class you create does not have any SMS-specific requirements. Create the data class by using the documentation for the provider that provides the class data, the WMI SDK, and any other WMI documentation.

  • The WMI registry provider has three variations, as instance, property, and event providers. Use the variant that is appropriate for your requirement. The Power_Mgmt MOF in the "Finding Computers That Are Laptops" section later in this chapter is an example of a registry property provider MOF. The Hotfixes MOF in the "Finding Hotfix Information" section later in this chapter is an example of a registry instances provider.

    The registry instances provider is appropriate when you need to collect an unpredictable but consistently formatted set of registry values under a predetermined registry key. But most registry entries do not fit this description. They are trees of keys that have predictable names and inconsistent data types or names. For more information about the WMI registry provider, see the WMI SDK.

  • Ensure that all reporting classes are included in the SMS_def.mof. Data for reporting classes that are only defined at the Advanced Clients is ignored at the site server.

For More Information

Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.