RegKeyToMof v2.6

Mark Cochrane's RegKeyToMof v2.6

Update: changed the version to 2.6

Original article at : http://myitforum.com/cs2/blogs/skissinger/archive/2011/02/18/mark-cochrane-s-regkeytomof-v2-6.aspx


Mark has updated his excellent RegKeytoMof utility for custom regkey MOF edit creations. The coolest part about it is a better method of pulling in registry keys from the 64-bit registry section.
I'm in love with it, because of how the end result is that there is only 1 table and 1 view in your database, making report writing that much easier (fewer joins).
Major kudos go to Jonas Hettich for figuring out the intricasies of how this type of mof edit works.
This blog entry will step through how to use RegKeytoMof to create a (fictitious) custom mof entry for "ABCStuff"
Below is a screen shot of the registry of a x86 computer, and a x64 computer.

How to Use RegKeytoMof:

1. While on either the x64 computer or the x86 computer, launch "RegKeyToMofv2.5.exe"
2. Browse to "Software\ABCStuff"
3. Change the ClassGroup and ClassName to be values you want
   a. For me, I always change the group to be "CUSTOM", however, if you work for ACME Corporation, you may want to change it to "ACMECorp" for example.  It's really simply a label.
   b. Change the ClassName to be something unique, and no spaces is recommended.  For this edit, I'm going to use "ABCStuff"
4. Check the box about "Enable 64bits"

Screen shot of the work so far:

Now we have a very, very close base.  Most of the time you could copy the contents of the tabs "SCCM Configuration.mof" and "SCCM sms_def.mof" directly to the bottom of your inboxes\clifiles.src\hinv files, and be golden.
However, for this particular mof edit, I made sure to add in some special cases, that might trip you up.  As mentioned, most of the time you won't have these special cases.
Three things:

1. I'm asking for the value of the (Default) regkey.  that requires a manual edit.
2. one of the values I want "MultiSZIWant", contains multiple strings.  In order to pull that information in nicely, there is another manual edit.
3. one of the values I want "BinaryIwant", also needs a manual edit.

5. To adjust for the (Default) regkey, a label is required.  There are 6 places to put in that label; 4 places in configuration.mof, and 2 in sms_def.mof.
6. To adjust for the multiple string values, there is 4 places to put in braces [], 2 places in configuration.mof, and 2 in sms_def.mof.
7. To adjust for the binary value, there is 4 places to put in braces [], 2 places in configuration.mof, and 2 in sms_def.mof.
Attached is the completed mof edit. 
Notes: I decided to label the default value "TheDefault"  so search for that in the files to see how that was accomplished.  For the multi-values, search for the [] to see where those should be placed.
8. Now follow the wiki, on updating your mof files and confirming the edit worked:
9. Now that you have data in your database, here's a sample sql query, and the resulting report.
 
To interpret what that means...
   9a. workstation1 is a 32-bit OS, and as such, does not have WMI provider architechture that would try to report on 64-bit regkeys (this line in the
sms_def.mof edit:  SMS_Context_1("__ProviderArchitecture=64|uint32").  For that reason, there is only 1 row of data returned for workstation1.
   9b. workstation2 is a 64-bit OS, and does have both providerarchitechtures, 32 and 64.  So it will *attempt* to report on registry keys in both areas, that's why there are two rows of data, but the attributes that correspond to registry keys are null for those that don't exist, and contain data for the ones that do exist.
From a collection query creation standpoint, or from a reporting standpoint, having to look only in 1 location when you design your SQL or WQL queries is a very cool and timesaving thing.  Not only to you, but your database has 1 less table, view, and stored procedures