SCCM 2012 – Customize / Extend Hardware Inventory

Overview

 SCCM 2012 has come a long way in terms of inventory management. It has come a long way since SMS days when the MOF file had to be deployed on each client to collect the inventory. In SCCM 2007, there was a sms_DEF.mof that was required to define the WMI classes that are to be inventoried.
In SCCM 2012, the concept of hardware inventory is fairly simple. You can define any WMI classes that are to be inventoried in SCCM Console as part of Client Agent settings. These client agent settings can be advertised on collections. This means that now you have the flexibility to customize the inventory gathering based on models, operating systems, business units etc
The client then reads all inventory information through WMI (Windows Management Instrumentation). The SCCM Client agent then imports these classes when it runs the machine policy refresh cycle. Therefore, the client now polls for any changes to the configuration chages from the server.

Detailed Step by Step procedure for extending Hardware Inventory in SCCM 2012
There are 8 key steps to extend inventory in SCCM:

1. Create the MOF file to extend inventory
2. Make a backup of the Inboxes\CliFiles.src\HInv\Configuration.MOF file on the CAS
3. Copy the contents of the MOF file between the two customer headings at the very bottom of the Configuration.MOF
4. Manually compile this modified Configuration.MOF file on a test client using MOFComp
5. Bring up properties of the Default Client Agent Settings on your CAS
   1. Select Hardware Inventory and click Set Classes
   2. Click Add and connect to \\WKS\root\CIMV2 (where WKS is the name of the client used above)
   3. Select <the class added> and press OK
6. Monitor PolicyPv.log on the primary to which the client reports indicate that it has updated policy to reflect the new class
7. pdate Machine Policy on the client side, allow a minute or two for that to process and then force a Hardware Inventory cycle
8. Once the data is relayed to the MP and procesed there, it should appear in Resource Explorer.

In the section below I will discuss each of these steps in detail.

Let me take a small example: We want to inventory "HKEY_LOCAL_MACHINE\SOFTWARE\Absolute Software Inc\" registry key with Esn (where Esn is a Reg_Sz or String value)

STEP 1 - Create the MOF file to extend inventory
This is where most of us run into issues. We must ensure that the correct MOF file is created. Here is a sample code for the registry that we want to inventory.

// Registry property provider #pragma namespace ("\\\\.\\root\\cimv2") #pragma deleteclass("Absolute_Software_Inc", NOFAIL) [DYNPROPS] Class Absolute_Software_Inc { [key] string KeyName; String Esn; }; [DYNPROPS] Instance of Absolute_Software_Inc { KeyName="Absolute Software Inc"; [PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Absolute Software Inc|Esn"),Dynamic,Provider("RegPropProv")] Esn; }; TAKE CARE OF WORD WRAP

It is important to understand how to create this MOF file, therefore let us look at it section by section.


#pragma namespace ("\\\\.\\root\\cimv2")
You must declare the namespace into which you will be adding the new class. You use the #pragma command to inform the MOF compiler that you will be using the specified namespace to add this object to. In this example, you enumerate the root \cimv2 namespace of the local computer. This is where the information for the new provider will be located.
Note the extra backslash characters in the definition of the namespace. The first backslash character specifies a special character that follows. The second backslash character defines the special character that you want to use. This is known as "escaping" special characters so that the MOF compiler will interpret them literally.


#pragma deleteclass("Absolute_Software_Inc", NOFAIL)
The #pragma deleteclass command is used in SMS/Configuration Manager hardware inventory modification to delete class information from WMI repositories. It is recommended to use deleteclass if you are testing new hardware inventory modifications and making changes to your mof edits during testing and want to start with a clean slate each time the client compiles the new mof file. When deleting WMI classes from clients that have already performed hardware inventories (especially if you have changed a Key field), you should also delete the class information stored in the site database as well.


[DYNPROPS]
The DynProps qualifier identifies a class as having properties that are maintained by the property provider identified by the Provider qualifier


Class Absolute_Software_Inc
{
[key] string KeyName;
String Esn;
};
Here we add the class definition in the root\cimv2\sms namespace to specify inventory collection. A new Class – Absolute_Software_Inc is defined. It also defines the KeyName variable with string datatype.


[DYNPROPS]
Instance of Absolute_Software_Inc
{
KeyName="Absolute Software Inc";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Absolute Software Inc|Esn"),Dynamic,Provider("RegPropProv")] Esn;
};


Next we instantiate the class, and define the properties of the class that need to be inventoried. The actual registry value that is retrieved is called the Property context. This value must have the same name as the registry value that you are enumerating. The name must be enclosed in quotation marks. The display name is the name by which the data will be referenced. MOF file syntax is derived from Microsoft® Visual C++ syntax for class definitions.


Step 2 – Take a backup of the Inboxes\CliFiles.src\HInv\Configuration.MOF file on the CAS
This is extremely important. The Configuration.MOF file must be backed up before before making any changes.


STEp 3 - Copy the contents of the MOF file between the two custom headings at the very bottom of the Configuration.MOF
Open the configuration.mof file and browse to the end of the file and look for the following content:


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


//========================
// Added extensions start
//========================


//========================
// Added extensions end
//========================


Copy paste the content of the MOF File created earlier between the Added extensions start.


Step 4- Manually compile this modified Configuration.MOF file on a test client using MOFComp.exe
Open command prompt and type the following command to compile the configuration.mof file on a TEST CLIENT.


mofcomp.exe -check Configuration.mof
This will check the syntax of the MOF File.

 mofcomp.exe Configuration.mof

 Step 5- Add hardware inventory in SCCM from the remote computer namespace
Open the SCCM Console On the Central Administration Site server and Click on Administration -> Client Settings -> Hardware Inventory -> Set Classes

Click on Add.

Click on Connect -> Select the name of the TEST CLIENT and enter the WMI Namespace as root\cimv2 and click on CONNECT

This should enumerate all the Classes including the one we just created – Absolute_Software_Inc

Select the Class that needs to be added and click on OK and it should show up in SCCM as well.

Step 6 - Monitor PolicyPv.log on the primary to which the client reports indicate that it has updated policy to reflect the new class
Update "Machine Policy Retrieval & Evaluation Cycle" on the client side. Allow a minute or two for that to process and then force a "Hardware Inventory" cycle.


Validate the InventoryAgent.log on the Test Client to see whether our class has been inventoried.

Similarly, policypv.log will report any updates to the inventory class.

Once the data is relayed to the MP and procesed there, it should appear in Resource Explorer.