ConfigMgr Console
Creating Custom Hardware Inventory Tips
Garth JonesTopics: ConfigMgr Console, Endpoint Insights
Say goodbye to spreadsheets for software and hardware tracking.
Endpoint Insights can effortlessly provide full software and hardware inventories for you so you can make educated decisions about your next moves.
Creating Custom Hardware Inventory Tips
Over the years, from Systems Management Server 1.1 (SMS) to Microsoft Configuration Manager (ConfigMgr) current branch, I have created hundreds of custom hardware inventory classes. Along the way, I have also made a lot of mistakes when importing/creating these classes. Up to this point, however, I have honed my skills to where I can essentially create any new class in just a “few” minutes.
Of course, I’m over-exaggerating about the time it takes, but you get the idea! In this blog post, I’ll share with you some of my tips for creating custom hardware inventory classes.
ConfigMgr Hardware Inventory
What Is It?
In a nutshell, hardware inventory is inventory that comes from a computer. In ConfigMgr terms, it is made up of two things. Windows Management Interface (WMI) classes and the Computer Setting. The Computer Setting tells a ConfigMgr computer what to inventory, whereas, WMI classes are what is inventoried.
Creating Custom Hardware Inventory
ConfigMgr inventories a lot of details from a computer, but there is always something more that someone wants. If you are in a similar situation, you may be considering a new (custom) hardware inventory class too. This is where these tips will help. First, you need to know that there are four methods available to you.
- You can import an existing WMI class.
- If you don’t want to import an existing WMI class, you can create a new one.
- Adding a property to an existing default (MEMCM) WMI class is another option.
- You can also inventory a registry key.
Next, you need to decide which method best suits your needs. Below, I give you more information about each one.
Importing an Existing WMI Class
If the details that you are looking for already exist within a WMI class, then importing the data (via the console) might seem like the easiest method without any risk. I know this method is what most people will consider choosing, however, although it is simple to do, keep in mind that it does come with some risk. This is especially true if the data type is incorrectly identified.
Problems can range from absolutely no inventory being collected to the wrong data getting inventoried. As I see it, there are two significant problems with this method:
- What happens when this data (properties) is added in the next ConfigMgr upgrade?
- The import function doesn’t always understand all different data types and can incorrectly assign the wrong data type.
I often see folks reaching out in the forums trying to get answers for problems associated with importing an existing WMI class. So, it’s not necessarily a trouble-free method.
Create a New Custom Inventory WMI Class
This is the easiest option and the one with the least amount of risk. Why? You will never have any issues with this method because a new custom WMI class will likely never conflict with a ConfigMgr class. Best of all, this method is fully supported by the ConfigMgr team. This means that you can add more custom inventory without it affecting your ConfigMgr support. This is the method that I recommend.
However, there are still a few things that you need to remember before you start creating a new custom class.
- The SMS Group Name must be unique.
- Make sure that your SMS Class name is also unique. You can do this by pre-appending your company’s initials. This makes it unique.
- Use your own company name within the SMS_Class_ID. Notice, in the example below, that I added my company’s name, “Enhansoft.”
- Not all WMI property types can be used by ConfigMgr, for example: Real32.
What can go wrong when creating the class? I have yet to see anything catastrophic. At worst, you need to remove the class and start over. Make sure that you test your new class to ensure that it is collecting the details you want. You don’t want to leave this step to days or months later.
This is what one of my custom inventory WMI classes looks like:
[ SMS_Report (TRUE),SMS_Group_Name (“Warranty Summary”),
SMS_Class_ID (“Enhansoft|Warranty|1.0”),
Namespace (“\\\\.\\root\\cimv2”) ]
class ES_Warranty : SMS_Class_Template
Adding a Property to an Existing Default (ConfigMgr) WMI Class
If you choose this method, you can either update the client setting in order to add the additional property, or you can edit the configuration.mof file and add the property.
In my opinion, this is the riskiest option. The main reason why it is risky is very simple. What happens when the product team adds this property in an update? In the best-case scenario nothing happens. But, in the worst-case scenario you have a bad upgrade and the whole system is left in an unknown state. Unfortunately, this happened to me and I needed to rebuild my lab! So, believe me when I say that this is the option with the highest risk factor. Can you imagine if this happened in a production environment?
How do you add a property to an existing WMI class safely?
You need to clone the class in order to create a new one with the property you want. This prevents any issues from arising later on. If you go this route, you are actually creating a new class (Method #2). The one downside to cloning a WMI class and adding a new property to it is that you end up with extra data within your database. There are ways, however, to limit the extra data to just the new properties and to the property keys for that class. This means, though, that you will need to “join” the data with the default class anytime you want to use it.
Inventory a Registry Key
This option is really the same thing as creating a new custom inventory WMI class (Method #2). The process is fairly simple if you use RegKeyToMof. It will do 99% of the work for you. I put together a guide on how to do this in my blog post called, How to Use RegKeyToMof.
The Last Word
Take it from someone who has created a lot of custom inventory classes and who has learned from his mistakes along the way. I have never had any problems with ConfigMgr updates or upgrades after creating custom hardware inventory WMI classes (Method #2). The same cannot be said for adding a property to an existing WMI class or, based on what I see in the forums, importing an existing WMI class.
Please feel free to contact me at @GarthMJ if you have any additional questions.
