Inventory or Compliance Settings–Making the Right Choice

Inventory, for both hardware and software, is a long standing capability of ConfigMgr. Both features work well and do what they claim –provide an inventory of either hardware or software on a system based on specific configurations. Inventory is also a very familiar component for anyone who has worked with any version of ConfigMgr. Because it is familiar it is often the automatic option used when doing anything ‘inventory-like’. But is it the best option? That is the question posed by this article.

Up front let me state that using inventory is not a bad option. Depending on specific business needs it may be the only option. But, it shouldn’t be the automatic option just because it is familiar.

ConfigMgr 2007 introduced the Desired Configuration Management feature, now renamed Compliance Settings in ConfigMgr 2012. Compliance Settings allows for quite a number of useful and cool options for enterprise environments and it can be used for some operations that are very inventory-like. With that in mind, let’s explore both options with a bit of history and detail. Keep an open mind as choosing the correct option will make for smoother and more useful operations. One other note, while this article does discuss inventory and compliance settings it is in no way exhaustive of the topics but is intended more to help the reader critically think through options instead of just ‘going with the default’. If you are unfamiliar with the inventory and compliance settings features, it is best to stop and fully understand these capabilities. After doing so this article will be more useful!

Before discussing Compliance Settings a reflection on inventory. Administrators don’t think much about inventory any longer. It’s automatic. Defaults are often accepted and that is how inventory operates. Where customizations are made it is often to add additional detail to the inventory vs. evaluating what actually needs to be collected. Add to this that inventory can be confusing, especially for those new to the discussion. What, exactly, is evaluated by hardware inventory? What is evaluated by software inventory? Well, that’s obvious. Hardware inventory evaluates information about hardware and software inventory evaluates information related to software. Those two silos are largely true but there are glaring places where they are not true. As an example, which inventory mechanism provides the detail visible in the installed software node?

Which inventory mechanism provides the detail visible in the System Console Usage node?

An answer of hardware inventory would be correct for both.

But, wait, hardware inventory is used to inventory both hardware, software and console usage? Yes. Then why is software inventory needed? The answer is that in many cases software inventory may well no longer be necessary. That decision ultimately is dependent on business requirements. Further discussion on that topic is below. Before proceeding a bit more discussion about hardware and software inventory.

Hardware Inventory
When initially introduced hardware inventory was all about hardware. Over the product iterations there were additional categories added to the mix to the point that hardware inventory might better be referred to as WMI inventory. Why WMI inventory? The reason is that hardware inventory is completely dependent on WMI as it’s only source for information. Every grouping of values in any hardware inventory node comes directly or indirectly through WMI. A quick look at the available hardware inventory classes will show just how true this is. A number of default classes are present and when selecting to add custom classes it is clear that the only option is to add from WMI.

OK, OK, I can hear the comments. Steve, you don’t have to just inventory from WMI. It is possible to inventory from the registry as well. After all, the installed applications class seen earlier is pulled directly from the registry. True – but THROUGH WMI. Let me state again – WMI is the sole source of information for hardware inventory. In addition to the ‘obvious’ WMI classes It is possible to programmatically create various providers in WMI that can be leveraged to pull information from other sources such as the registry.  The WMI registry provider is a programmatic method to access registry information through WMI.  So, in addition to the GUI customization options there is also the Configuration.MOF file located at %Program Files%\Microsoft Configuration Manager\inboxes\clifiles.src\hinv, which details all default classes that leverage the WMI Registry Provider for inventory collection.  This file is a good resource to know which classes pull their data from the WMI Registry provider and is an example of how to craft your own classes that reference registry information if needed.  Editing and understanding this file is beyond the scope of this discussion but a quick glance will show how the specific WMI provider, RegProv, is being leveraged to access a particular registry key. Further detail is given to indicate what items should be collected during inventory of that registry location.

So, hardware inventory relies on WMI exclusively. What does software inventory use and how is it different?

Software Inventory
Like hardware inventory, software inventory is done using WMI but the process is different. Specifically, software inventory leverages WMI by calling methods. These methods are responsible for scanning the system, collecting and reporting results. The important thing to know about software inventory is that it can, and often does, return a LOT of data and it may take hours to run. The reason for this is that while software inventory is running the hard disks are being constantly accessed to read data. This has the potential of interfering with user activity on the system so throttling is built in to slow down when a system is under load. The result can be a very long time period, sometimes hours, required to collect software inventory!

Compliance Settings
Compliance Settings is markedly different than inventory but has unique capabilities that make it very flexible and powerful. Like inventory, the use of compliance settings has ‘grown up’ as ConfigMgr has continued to develop. The focus of discussion here centers on the ability to build custom configuration items. Unlike inventory, where a significant number of preconfigured classes are default, Compliance Settings Configuration Items are a blank slate and requires administrator effort to build configurations of interest.

As a result, unintended clutter is avoided because only the specific items important to a given environment are configured. Compliance Settings evaluations will return a Boolean result for each item evaluated and configurations can be either judged to be compliant or non-compliant individually or in a group of settings. No actual data is collected or stored beyond the result of the evaluation. The result is a very efficient, focused and lean evaluation mechanism with myriad uses.

Inventory ‘Categories’
When considering inventory there are two broad categories of data evaluation – true inventory and detail checking (my descriptive categories, not official Microsoft categories). True inventory is a scenario where it is important that all specific details about a particular object being inventoried are collected and stored. For hardware inventory, as an example, there might be a need to store detail about the number and type of CPU sockets available on a system. For software inventory it might be important to store the file version, creation date, file size and filename.

By contrast detail checking is a scenario where the need is only to evaluate whether a particular configuration is present or absent. In the hardware example it might suffice to know whether a system has a single CPU socket vs. multiples without storing potentially redundant extra information. For the software example it might be sufficient to know that a particular file exists and with a specific version while the additional effort to store the file attributes is redundant.

The Challenge
With the discussion framed its decision time! Specifically, which method of data collection is actually needed to satisfy the business requirements of inventory across the environment? And, why do you really care?

In any scenario It is a good idea to only build what is needed to satisfy business needs. For inventory, collecting detail beyond what is needed will add complexity, may increase privacy or regulatory concerns, can impact performance on local clients and servers and may result in an expansion of the database beyond what is really needed. With a larger database the backup and restore times will increase as will storage costs. Accordingly, and as a general rule, start small and add where needed. That approach is far easier than starting large with plans to eliminate excess data in the future!

Remember, just because data can be collected in a certain way doesn’t mean that way is the best or most efficient! As an example, if business requirements dictate that ‘true inventory’ be performed and all of the associated attributes stored then that route is easily accomplished using standard inventory techniques. If ‘detail checking’ style ‘inventory’ is sufficient there are multiple advantages to be gained in terms of flexibility, speed and efficiency. Remember, ‘true inventory’ collects and stores the data requested where ‘detail checking’ simply stores a Boolean value indicating whether a particular configuration is present but no data is collected.  Regardless of the method chosen, rich reporting can be brought to bear to make full use of the data.

Deciding which method to use is totally up to the needs of a specific organization. Experience has shown that quite often both methods of data collection are needed and useful. When choosing the path to follow for a given scenario consider a few points.

Considerations
Familiar
Standard inventory has been a part of ConfigMgr for a long time and is familiar to most administrators. It might be easier to just configure something to be collected by inventory and move on but that approach may not be the most efficient and, over time, may result in inefficiencies being introduced to the overall environment.

Efficiency
Compliance settings will likely be more efficient than inventory. As already stated, Compliance Settings allows for focused vs. more broad based detection scenarios. In scenarios where the data of interest is a known quantity, Compliance Settings may be the better choice compared to traditional inventory.

Flexibility
With traditional inventory, systems across the environment largely run their evaluations according to the same schedules. At each scheduled evaluation all configured items are re-examined and processed. With Compliance Settings the administrator has a choice – either run at the global evaluation interval or according to an independent schedule suitable for the item being evaluated. There is also a difference in the data being returned between inventory and compliance settings. Inventory is engineered to be efficient but due to how it works will return larger data sets than what is returned by compliance settings.

Database Bloat
Disclaimer: Queries are given below to pull certain data from the ConfigMgr SQL database. These queries are safe because they are only ‘read-only’ select queries. The results, however, may inspire administrators to make changes to the database based on perceived inefficiencies. Changes to the database are only supported when working with a Microsoft support resource. The vast majority of changes that may be needed to the database can be managed using the console and that is your safer and supported option. Making changes directly in the database requires a full understanding of the database and, if done incorrectly, can have significant negative impacts on a ConfigMgr environment.

Compliance settings evaluations return a yes/no type of response by sending state messages. Inventory results will return a substantial list of data in most environments that can consume significant database space. As a quick example just look at the number of rows of data that are currently in the softwarefiles database table for your environment by opening SQL and running the following query against the ConfigMgr database.

Even small to medium environments will store millions of rows of data for just software inventory! This does not include the size consumed by hardware inventory. In fact, the software inventory tables are generally some of the biggest in the entire database! The point?  If you don’t need software inventory don’t collect it.  If you do need software inventory be sure collection is properly focused to just the data that is required.

It is also interesting to know what the largest tables are in the database. The query below will pull that information.

Note that this query will sort by the tables with the largest row count. Tables with large row count may or may not equate to the biggest tables but it is an interesting view. In addition to row count the query does pull total size of a table so with slight modification it would be possible to sort the list based on true space used by the tables.

In a typical environment the software inventory tables and status message tables (which is another discussion entirely) will be near the very top of the list. In my lab, the result is as follows. The top consumer in my admittedly small lab where software inventory is disabled is historical hardware inventory data for tracking process information. So, while hardware inventory data may not be at the top of the list it still may be very impactful to the overall size of the database. The way hardware inventory data is stored compared to software inventory is different. The various hardware inventory classes store their information in <HardwareInventoryClass>_DATA and <HardwareInventoryClass>_HIST tables. To truly see how much database space is being consumed by just hardware inventory requires adding up all of the space consumed by all of these table combined.

While SQL is capable of efficiently working with extremely large databases there can be an impact to performance when maintaining such a large database, including slow data performance due to improper indexing (make sure the ConfigMgr indexing task is enabled – it is disabled by default), long backup and restore times and more.

Tuning
To operating efficiently software operation and performance needs to be tuned. Inventory is no different but tuning in this category is often overlooked. What information is being inventoried by the inventory process? What hardware classes and associated attributes are enabled for collection? Do you know? Probably not. Is the software inventory process fine tune and focused? In most environments, no. The general rule of thumb is that if there is no specific need to inventory something then don’t do it. Properly tuning the inventory collection process will improve efficiency and focus of inventory operations. It will also help reduce unnecessary bloat of the database. Using compliance settings tends to encourage a more focused approach since configurations are intentional.

Comments

• Anonymous
  August 10, 2015
  Great post Steve. For registry inventory, I've started using PowerShell script compliance settings to write the desired registry values to a custom WMI class, which can then be easily selected in client policy for inclusion in hardware inventory. I find this to be much easier than editing the configuration.mof. What are your thoughts on this approach?

• Anonymous
  October 18, 2015
  Kevin, that works great where you need to inventory the item vs. just check its status.