Extending hardware inventory in SCCM2012

Following is a post on how to extend the hardware inventory in SCCM2012. This is a tad different from 2007, and is very useful if you e.g. wants to know what sound drivers that are currently installed in your environment, and based on that knowledge, wants to update the very same driver. (Note: This can be done with pretty much any driver. Just extend the HW inventory as necessary)

First off, you need to locate where this information is stored. All driver classes are stored in the registry as a subkey to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class and in this instance the sound driver is {4D36E96C-E325-11CE-BFC1-08002BE10318}.

With this in place, you have to decide what regkeys you find relevant to inventory. In this example following keys is relevant: DriverDate, DriverDesc and DriverVersion. Inventorying these keys will tell you information about the date, description and version of the sound driver on any system in your environment. (Note: The keys to inventory might differs from OS to OS. This is done in Windows 7)

So, I know what to inventory – how do I do it?

1) First off you need to stage your clients the ability to know HOW to report. This is done on your CM2012 server where you browse to <install location>\inboxes\clifiles.src\hinv and edit the configuration.mof (I’m usually making a backup manually before editing this)

2) In the bottom of the configuration.mof file you find the below section. It’s in this section you will add your edits (My edits in italic). You will recognize the path of the registry keys, and the name of the subkeys to inventory.

// Added extensions start

pragma namespace (“\\\\.\\root\\cimv2“)
#pragma deleteclass(“KRSoundDrivers”, NOFAIL)
[dynamic, provider(“RegProv”), ClassContext(“Local|HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Class\\{4D36E96C-E325-11CE-BFC1-08002BE10318}”)]
Class KRSoundDrivers
[key] string KeyName;
[PropertyContext(“DriverDate”)] String DriverDate;
[PropertyContext(“DriverVersion”)] String DriverVersion;
[PropertyContext(“DriverDesc”)] String DriverDesc;
[PropertyContext(“Driver”)] String Driver;

// Added extensions end

3) When doing changes to configuration.mof I strongly recommend to monitor the dataldr.log. Immediately after saving your changes, the log file will show following entry: Configuratin.Mof change detected. The entries following will tell you if your changes got accepted or rejected. If they got rejected you most likely have got something wrong in your spelling, or in your C/P.

4) Assuming everything is fine so far, it’s time to tell the clients WHAT to report. This is done in the Client Settings in your CM2012 console (Administration -> Client Settings). Open up Notepad, and C/P below text and save it as SoundDriver.mof. This will be imported into your Client Settings in CM2012

#pragma namespace (“\\\\.\\root\\cimv2\\SMS“)
#pragma deleteclass(“KRSoundDrivers”, NOFAIL)
Class KRSoundDrivers: SMS_Class_Template
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String DriverDate;
[SMS_Report(TRUE)] String DriverVersion;
[SMS_Report(TRUE)] String DriverDesc;
[SMS_Report(TRUE)] String Driver;

5)  Import the SoundDriver.mof to the Client Settings. Follow the screenshots.




6) Verify the changes on the client. Refresh the policy on the client, and run a HW inventory. Monitor the InventoryAgent.log to verify the changes being picked up. Running a resource explorer on the client will now show this, and everything is OK:

Resource Explorer


ConfigMgr 2012 client update during OSD

After updating my ConfigMgr 2012 SP1 with the latest CU from Microsoft (http://support.microsoft.com/kb/2817245), a new update for the console and client was created as well. These can be distributed to the distribution points and deployed as any other packages, everything quite easy.

What you might want to consider as well, is to make sure that the ConfigMgr client is updated during OSD for new installations. This is done through the step ” Setup Windows and Configuration Manager” in your task sequence.

Different from ConfigMgr 2007, the hotfixes for the client is no longer created within the existing client installation package directory (<SCCM2012 Install Directory>\Client), but is instead created in <SCCM2012 Install Directory>\Hotfix>. What does it mean? It means that you have to modify the existing client package, or create a new, to be able to patch the ConfigMgr client during the mentioned step in your task sequence.

I will explain in steps what I did:

Step 1: Install the CU, and verify that the client packages is created.

Step 2: Copy the actual hotfix from the hotfix folder (<SCCM2012 Install Directory>\Hotfix\KB2817245\Client\i386\configmgr2012ac-sp1-kb2817245-i386.msp), and create a new subfolder to the client installation folder called Hotfix. (<SCCM2012 Install Directory>\Client\i386\hotfix). Put the copy of the hotfix in this folder, and update the package on your distribution points.

Step 3: In the step “Setup Windows and Configuration Manager” of your task sequence, make following installation properties: PATCH=”%_SMSTSMDataPath%\OSD\<replace with client package id>\i386\hotfix\KB2817245\configmgr2012ac-sp1-kb2817245-i386.msp”