Basic steps to be performed:
- Necessary at all?
- Obtain Edits
- Stage the ability for Clients to know HOW to report
- Stage the ability for Client to know WHAT to report
- Customize Client Settings
Side Note: These instructions are written from the standpoint that you will have only 1 primary site server, not a CAS site and child primary sites. Since in general most companies won’t need a CAS unless they are hugely multinational, or have more than 100,000 clients, a single site is the expected norm. For those companies that will have a CAS, any different steps will be mentioned.
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 registry key 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 regkey value as reported by HINV (Hardware Inventory), you could instead make that regkey value a parameter of the deployment.
Just a suggestion that perhaps you don’t need a hardware inventory edit at all!
Custom Registry Keys – individual, not dynamic used in this example
Mark Cochrane’s RegKeytoMof 3.0 or higher is required. Older versions do not have the tab with the necessary edits for use with ConfigMgr 2012.
On a workstation or server which has the regkeys you need, use RegkeytoMof.
- Start by browsing to the registry to the location containing the registry keys. Note that “HKeyCurrentUser” cannot be used, because the ConfigMgr Client is doing the regkey query, and it likely will not have the CurrentUser key you wanted to gather.
- Change the ClassName to something that makes sense. Try to keep it short, no spaces.
Stage the ability for Clients to know HOW to report
On your ConfigMgr 2012 Beta 2 Primary site Server, browse to <installed location>\inboxes\clifiles.src\hinv (If you have a CAS, browse to the CAS\Inboxes\clifiles.src\hinv, not a child primary)
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.
So, in regkeytomof, on the “ConfMgr12, Configuration.mof” tab, copy and paste the entire contents of that tab, without any changes, 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 reasons:
- You missed something in the copy/paste, even missing the last } will cause a rejection.
- You used special characters in the group name or class name.
- Sometimes it is unavoidable to make modifications to the configuration.mof results. For example, if you have a regkey which has a space, or has special characters, or is a reserved word, you may have to change the ‘label’ to be something acceptable.
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) abcsoftwareHinvReport.mof
From RegkeyToMof, the “ConfMgr12,to import in Admin/ Agent Settings/ HardwareInventory/ SetClasses/ Import ” tab, copy and paste the contents into Notepad.
Save the file, remembering the location you saved it into.
Launch your ConfigMgr 2012 Beta 2 Console (If you have a CAS, it is recommended that you connect the console to a child site), 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 ABCSoftwareHinvReporting.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 “All Windows 7 Customizations”. 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 ABCSoftware, and ABCSoftware 64)
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 Windows 7 computers, assign it to that collection. If you don’t have a Windows 7 –specific collection, of course make one first, then assign it.
If you need to ensure that the edit works as you expect on both X86 and X64 targets, test on both types. But the steps are essentially this:
- On a client that should deserve to report on these registry keys, 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 the regkey information was successfully received.
Note: the views will be called something like “v_gs_custom_abcsoftware0″ and “v_gs_custom_abcsoftware640″. 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|ABCsoftware|1.0″) to just be “ABCSOFTWARE”