ConfigMgr2012Beta2 Hardware Inventory Custom WMI

Disclaimer: These instructions worked on Beta 2. No guarantees about RC, RTM, or honestly, if they will work in anyone else’s Lab environment but my own. Your mileage may vary.

Basic steps to be performed:

1. Necessary at all?
2. Truly Custom, or a pre-existing class?
3. Obtain Edits
4. Stage the ability for Clients to know HOW to report
5. Stage the ability for Client to know WHAT to report
6. Customize Client Settings
7. Confirmation

Necessary at all?

Before you start, have you evaluated whether or not you actually need a hardware inventory edit at all? Depending upon your past knowledge of how ConfigMgr 2007 or SMS 2003 worked, you may have gotten into the habit of thinking you need to know the custom WMI entry so you can create collections around that information. In ConfigMgr 2012, using the new Application Deployment Method, that may no longer be necessary. Instead of creating a collection with a certain custom WMI value as reported by HINV (Hardware Inventory), you could instead make that custom WMI value a parameter of the deployment.

Just a suggestion that perhaps you don’t need a hardware inventory edit at all!

Truly Custom, or a pre-existing class?

This document is for truly custom WMI edits, the type where a change to configuration.mof is necessary. It may be all you want to do is pull in an existing WMI class, one that already exists. If you are unsure, follow the online Technet documentation on Custom Hardware Inventory Edits. If following those instructions about Add a Class work, you do not need these instructions.

Obtain Edits for Custom WMI Classes

There are very few Custom WMI edits out there. Some of them are located on http://www.mofmaster.com, like the SQL version one, or the ServiceLTD one. It’s rare that you would make up your own, custom WMI edit without finding one to suit your purposes already available online. If you are unsure if what you need is a Custom WMI Class type, your best bet might be to post a query in the myitforum.com Forums, and see what other people advise you to do.

For demonstration purposes, the SQL version Custom WMI mof edit from ConfigMgr 2007, located, here, will be used: http://myitforum.com/cs2/blogs/skissinger/archive/2010/12/20/installed-sql-05-and-08-version-information-via-configmgr-hardware-inventory.aspx

Stage the ability for Clients to know HOW to report

On your ConfigMgr 2012 Beta 2 Server, browse to <installed location>\inboxes\clifiles.src\hinv

Potentially unnecessary paranoia step: copy the existing configuration.mof to a backup location. You don’t necessarily need to; a backup will be taken for you and placed in <installed location>\data\hinvarchive. But sometimes paranoia is a good thing.

Using the latest trace exe (trace is located in <your beta2 source files>\Tools), open up <installed location>\logs\dataldr.log

Using Notepad, open up <installed location>\inboxes\clifiles.src\hinv\configuration.mof. Scroll all the way to the bottom. Near the bottom are some comments (Comments are started with two // characters) indicating that is where custom Extensions, like the ones we are doing here, should be placed.

From the Blog entry above, copy and paste ONLY the sections that start with //=================================

//Add the below two sections to the bottom of Configuration.mof
//=================================

Save the modified configuration.mof.

Back in your open trace32 view of dataldr.log, monitor that log file to confirm your edit has been accepted, and not rejected. If rejected, potential rejection reason is that you missed something in the copy/paste, even missing the last } will cause a rejection.

Stage the ability for Client to know WHAT to report

To be clear, this step, on purpose, is to just stage the ability, not actually enable it. Why we don’t enable it immediately will make sense in a later step.

Open up a notepad to a new entry. Do a file, Save As, and change the type from txt to “all”, and save the empty file to a known location as (using this example) SQLHinvReporting.mof.

From the Blog entry above, copy and paste ONLY the section starting with:

//=================================
//Add these two sections to the bottom of sms_def.mof

And ending prior to the section that says:
//=================================
//Add the below two sections to the bottom of Configuration.mof

Save the File.

Launch your ConfigMgr 2012 Beta 2 Console, using an account with appropriate security rights to edit inventory data.

Go to Administration, client Settings.

Right-click on “Default Client Agent Settings”, Properties

Click on “Hardware Inventory” on the left.

Click on “Set Classes…”

Click on “Import…” and browse to find your saved, modified mof file (in this example, it was called SQLHinvReporting.mof)

After importing, you will notice that those new classes are by default set to TRUE. Uncheck them so that by default they are set to False in your “Default Client Agent Settings”. This will make sense in the next step.

Hit OK until you are back to client settings.

Customize Client Settings

In your Configmgr 2012 Beta 2 console, if you have not already done so, choose “create custom client settings”, and create ‘Custom Client Device Settings’.

Give it an appropriate name, like “Any box with SQL in Add Remove Programs”. Check on the box for “Hardware Inventory”.

On the left, click on the now-available Hardware Inventory.

Click on “Set Classes…”

Check on the boxes for your custom classes (in this example, the SQL Property, and SQL Property Legacy)

Note: If you cannot check the boxes on, then in the earlier step above, in “Default Client Agent Settings”, you forgot to uncheck them there. Go back to that step, and uncheck them there.

Hit OK until you are back to Client Settings

If you have not already done so (this is a brand new Client Device Setting), right-click on this customization, and Assign it to an appropriate collection. For example, if this information should only be gathered from Computers which indicate sql is installed, assign it to that collection. If you don’t have a SQL installed –specific collection, of course make one first, then assign it.

Note you do NOT have to make a custom Client Device Setting. You could make it be by default enabled for every single client in your enterprise, by leaving it enabled on the ‘default client agent setting’. But for demonstration purposes, this guide assumes you would want to have customized Hinv settings, that could then be targeted to a subset of clients.

Confirmation

The steps are essentially this:

On a client that should deserve to report on these WMI Classes, do machine policy refreshes. Monitor the client’s policyagent.log to confirm that it does pick up a new policy.

On the client, after you’ve confirmed the policy has been received, invoke a Hardware Inventory action. Monitor the client’s inventoryagent.log to watch for the select statement indicating that it is reporting on the new classes.

On the server, monitor dataldr.log for that client’s inventory; once you see it pass through dataldr.log, you can now run reports, queries, or use Resource Explorer to confirm that information was successfully received.

Note: the views will be called something like v_gs_custom_sql_property<some more characters> and v_gs_custom_sql_property_legacy<some more characters>. If that *really* bothers you, having the word “custom” in there, prior to saving and importing the Reporting section (the “HOW” section), modify the SMS_Class_ID from being something like (“CUSTOM|SQLProperty|1.0”) to just be “SQLProperty”