At times, I have had customers contact me with concerns that their Configuration Manager 2012 environment is very slow or in some cases that the database is running out of space. When assessing the source of this, I have found that these customers are using the Inventory system in Configuration Manager to collect significant amounts of hardware and/or software inventory which end up heavily taxing their system.
When I point this out to them, they often don’t have any business reason for collecting all of this data and we are able to discuss business requirements and only gathering the data that the business needs. Others have good business reasons for collecting this information and we are able to talk about the frequency with which this data is collected and how to properly scale their environment to accommodate their needed inventory.
In this blog, I am going to talk briefly about how to configure both hardware and software inventory, how to set the frequency of inventory collection, and then show a technique for assessing how much data is being submitted as a result of the chosen configuration. The goal is to help administrators only collect the inventory they truly need, only submit it at a frequency that is acceptable to their business requirements, and be able to predict how much data this will end up sending once these requirements are implemented.
Configuring Hardware Inventory
Hardware Inventory uses a process of querying WMI on each managed client to gather data on those devices. Depending on which classes are enabled, ConfigMgr can collect significant amounts of data on each managed client. Hardware Inventory is collected by default with the specific information to be collected determined by the Default Client Settings that are applied to all managed devices.
To get to the Default Client Settings, navigate to the Administration context within the ConfigMgr admin console and select Client Settings. In the middle of the console, select Default Client Settings and choose Properties. The Hardware Inventory item shows the various default settings for each managed device in the site as shown below:
![image]( "image")
By selecting the ‘Set Classes’ button shown above, it is possible to see the default hardware classes that are collected for every managed client. In the resulting window (shown below) it is also possible to configure which hardware classes should be collected in the environment.
![image]( "image")
By looking at the default settings, we can easily see that ConfigMgr will collect hardware inventory every 7 days. Because these are the Default Client Settings, these will be applied to all managed clients unless a change is made.
To change the Hardware Inventory settings, there are two options:
- Modify Default Client Settings - If a change is needed universally for all managed clients, modifications can be made directly in the Default Client Settings itself. However, if this is done it is always a good idea to take note of what the original setting was in case it needs to be put back in place in the future.
- Create Custom Client settings – if only certain groups of clients within the environment require different settings from the defaults, it is possible to create custom client settings and deploy these to a collection containing the specified managed clients.
If a client is part of a collection that receives custom settings, it will still apply the Default Client Settings. But then it will apply any custom client settings targeted to it in the order of priority. Default Client Settings has the lowest priority at 10,000 so any custom settings should be set to a higher priority to allow them to process last. In this way, any custom settings that are different from the default settings will overwrite the value of the default settings when they are applied.
To create custom settings, simply right-click the Client Settings icon in the admin console and choose the category of client settings desired (either user or device). Then select the categories of settings you with to configure in the custom settings. Once you set the values for each of these categories, you can deploy the custom settings to a collection of your choice and they will apply to any client in that collection.
Hardware Inventory and WMI
The information gathered by the hardware inventory process is pulled from WMI on each managed client. The decision about what specific information will be populated to WMI on a client is determined by the list of classes configured via Client Settings as shown above.
To see the hardware inventory held in WMI on a client, first download WMI Explorer 2.0. As of this writing, this is the newest version of the very popular WMI Explorer tool that makes interacting with WMI simple. Once this tool is downloaded, open it and connect to the computer of choice by typing in the computer name in the upper left-hand corner and selecting ‘Connect’ (NOTE: it may be necessary to run WMI Explorer as an administrator in order to see every namespace of interest).
After connecting, navigate to the ROOT\ccm\Policy\Machine\ActualConfig namespace. In the Classes window, select InventoryDataItem to see the specific information that hardware inventory gathers on a client machine.
![image]( "image")
Each type of information gathered is listed within an instance of the InventoryDataItem class as shown below:
![image]( "image")
By selecting an instance and looking at the Properties page, several bits of information is available. For example, in the screenshot above, we can see that the Win32_PhysicalMemory class is being collected and that its information can be located in the \ROOT\cimv2 namespace. The ‘Properties’ property indicates which properties of Win32_PhysicalMemory should be returned as part of hardware inventory.
When ConfigMgr runs, it uses the information in the InventoryDataItem class to learn what specific classes of hardware it should collect (ItemClass property of the instance). It then checks the ‘Namespace’ property of the instance to learn where the actual data is stored (for Win32_PhysicalMemory we see it’s stored in \ROOT\cimv2). Then it checks to see which specific properties it should be interested in by checking Properties. With this information, inventory collection can proceed.
Interestingly, while it might not be immediately obvious, the programs listed in Control Panel under Programs and Features are included as part of hardware inventory and not software inventory. This is because the registry key (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall) referencing these programs is considered part of hardware and is collected by default.
Hardware Inventory and MOF Files
Managed Object Format (MOF) is the language leveraged by WMI to describe its classes (known as Common Information Model, or CIM, classes). MOF files are used by WMI to implement new classes. It’s important to understand at the outset that WMI classes are not part of ConfigMgr. It’s just that ConfigMgr uses these classes (and also adds new classes) in order to gather inventory.
In ConfigMgr 2007, there were two .mof files that administrators had to keep track of. These were:
- sms_def.mof – this file included the classes that were already present in WMI separate from ConfigMgr. The purpose of the file was to set which of these classes would be included in the hardware inventory process.
- configuration.mof – for custom classes (those not already in WMI on the client machine), it was necessary to have them added. Configuration.mof was a file that directed each client to update its WMI repository with additional custom classes that would then become available for hardware inventory.
In ConfigMgr 2012, sms_def.mof has gone away and is now replaced by the Classes list accessible through Client Settings (as seen above). Whereas in 2007, it would be necessary to open sms_def.mof and set the desired classes to a value of TRUE, it is now only necessary to open Client Settings, navigate to Hardware Inventory, select the Set Classes button, and select the checkboxes beside the classes that are of interest (specifying also which properties of each class should be returned as part of hardware inventory).
Unlike sms_def.mof, configuration.mof is still around in 2012. As before, this file is managed by the ConfigMgr server at the top of the hierarchy (either a stand-alone Primary or a CAS) and is distributed as part of the policy request to every device participating in the hierarchy. To locate this file on the CAS in my lab, I navigated in the file structure as shown below:
![image]( "image")
In part, this is what configuration.mof looks like when edited with Notepad:
![image]( "image")
Notice that the file specifically states its purpose, which is to define custom classes for inventory reporting. In the snippet above, we can see the first of these classes listed. We can see the namespace where this class should be stored in WMI, where the content is on the client itself (in this, example, the registry key which we described in the previous section), and the properties that hardware inventory should care about for each of the items found within this registry key.
If the goal is to begin collecting inventory information that is already present in the WMI repository of the clients in the hierarchy, the process is to use ‘Set Classes’ in the Client Settings. If the need is to create a custom class altogether, the configuration.mof file should be used.
Configuration.mof contains many custom classes that are added by default, but if there becomes a need to include additional custom classes, these can be added into configuration.mof by inserting the new information in the section below:
![image]( "image")
Discussing everything about creating customer .mof files is beyond scope for this present article, but if you want to see an excellent site where many customer .mof files can be found and there is a great deal of information about creating and using custom .mof files, check out Sherry Kissinger’s blog found here.
Configuring Software Inventory
Turning to Software Inventory, we can immediately see there are several differences. First, software inventory is not collected by default. If we want to use it, we have to configure and enable it. Second, software inventory does not use WMI to gather its information. Instead, it performs a scan on the client machine to look for the categories of software we have decided to inventory.
To configure software inventory, we still go into Client Settings in the admin console. Here, the default settings are as shown below:
![image]( "image")
Note that while software inventory is enabled by default, nothing is being collected. This is by design because of the potential impact that software inventory can impose on our hierarchy and its underlying network. In most cases, unless there is a compelling reason to collect software inventory, it may be better to stick to just gathering hardware inventory. But if there are compelling business reason that require us to gather software inventory, we can. The guideline here, however, is to be conservative. Only gather what you need from the necessary machines, searching only the relevant file paths (I have heard horror stories of admins who decided to collect every file type on every computer for their entire hierarchy. Not only does this cripple the performance in ConfigMgr, but it will grow your SQL database considerably and unnecessarily).
To demonstrate configuring software inventory, let’s come up with a scenario. In our company, we have a group that does testing work for a customer of ours. They develop several different web-based pieces of software and employ us to provide design validation, testing and feedback. Because our customer will deploy their software to kiosks in their retail stores nationally, one of the conditions of the contract is that the testing takes place on computers with fixed builds that contain only approved types of files. We have solutions in place to restrict every other file type, but have decided we would like to use software inventory to identify the presence of .mp3 files on these test computers (so we can have these files removed if necessary).
Scenarios like this are not unheard of, and while it does not present us with a strict requirement to use software inventory, it provides us with enough conditions to illustrate the task.
The first step will be to set up ConfigMgr so that we only inventory the computers which are part of the contract with this particular customer. To do that, we will create a device collection called ‘Kiosk Testing’ and add the specified devices to it (how to create and populate collections is not the purpose of this present article, but if helped is needed in this area here is a good link that should provide the necessary guidance).
Once our collection is in place and populated, it’s time to configure our software inventory settings. To start with, we want to create a custom Client Settings agent (we don’t want to collect inventory on every computer in our company and if we applied our software inventory settings to Default Client Settings, every computer would receive them). We’ll call our custom Client Settings “Kiosk Project” and we’ll select just the Software Inventory category.
Opening the custom client settings agent, we see the following:
![image]( "image")
Our first step is to configure the schedule, and we decide that inventorying once a week is fine (no changes needed). We further decide that the reporting detail is acceptable and we leave it at “Full details’. All that’s left is to decide what file types to inventory, where we want to scan for those files, and determine if we want to collect those files as well.
We start by selecting ‘Set Types’ where we can tell ConfigMgr what we want to inventory. We select the starburst symbol and then make the selections shown below:
![image]( "image")
As the screenshot illustrates, we are able to specify that we want to inventory targeted devices for all .mp3 files, and that we’re searching the root of the C: drive and every subfolder. We’re excluding certain files and folders, which is fine for this illustration.
Once we set this, we can consider whether we want to configure software inventory to collect any files. By doing this, we would actually make copies of these files and store them in our ConfigMgr database. We recognize that we can limit the file collection so that it stops when the total size of collected files exceeds a value we have specified. The settings we can configure are shown below:
![image]( "image")
For our purposes this isn’t necessary, so we don’t worry about this step.
Ours is only a fictional scenario, but I hope it helps illustrate some of the fundamental types of questions that should be asked when configuring software inventory.
Assessing the Impact of Inventory Collection
As I mentioned previously, enterprising admins might try to collect everything in their environment after setting up ConfigMgr 2012 for the first time and this may have less than stellar results. So is there any way to determine what the impact of our inventory settings will be? It turns out that there is.
When working with inventory, clients create files containing the hardware and software inventory data they’ve been asked to report. They submit these to their management point which passes the information on. Depending on the size of these files (which is determined by how much or how little data is being collected), this may result in a negative experience, either due to slower network performance, bloated database, etc.
To get a sense of how big the files will be that are coming from each client, the following procedure can help calculate what file sizes should be expected from each client (NOTE: Do this in a test lab rather than production if at all possible).
- After setting the hardware and software inventory of interest, select several clients that will act as test clients
- On each of the clients, navigate to %systemroot%\CCM\Temp and create a file called archive_reports.sms (make sure your file extensions are not hidden. If necessary, set this in Control Panel\Folder Options)
- Go into the Configuration Manager app in Control Panel on each client, select the Actions tab, and run the Hardware and Software Inventory tasks as shown below:
![image]( "image")
NOTE: If you want, you can also run the Discovery Data Collection Cycle to evaluate the size of this data that will be sent from the client.
- At this point, go to the folder where archive_reports.sms was created and there should be several XML files as shown below
![image]( "image")
By looking at the size of these files, it can be determined how much information the client will be sending when it runs hardware and software inventory. For details on the actual contents of each file, they can be opened for review in Internet Explorer
Once we’re done setting our inventory settings so that we are content that the size of the files is not going to cause problems in our environment, we need to delete archive_reports.sms (it should only be there during our evaluations or troubleshooting).
Summary
Inventory in Configuration Manager is usually something that can be set up and allowed to run automatically. But at times there is a need to do additional work as I’ve described here. The guideline, as in all things with Configuration Manager, is to only set things up that are needed and plan/test thoroughly in advance. Doing this will help ensure there are no problems once the design has moved into production.
![]()
How can I use Windows PowerShell to find information about a DVD drive that is attached to 
Use the Get-VMDVDDrive cmdlet, for example:
