Inventory in a Complex World – Understanding the Tools, Goals and Environments for Inventory

By Bruce P. McDowell

It’s pretty much a cliché in the IT asset management world that you have to know what you need to manage before you can manage it; you’ll likely hear something along those lines in at least a half dozen sessions at any IAITAM conference and in any ITAM-related research paper from Gartner. It follows, then, that inventory is the foundation for many if not most ITAM initiatives.

But what data do you need, and how do you choose from the dozens of tools on the market? This article will guide you through the different types of inventory techniques available, and how the different types of data may be used – separately and in combination – to achieve your desired results. You’ll be ready to make an informed choice when it’s time to talk to inventory tool vendors.

Plan First, Tool-Up Later

The history of inventory in the IT realm is filled with multiple tools, each of which does part of the job well, has its own set of political fans, but fails to federate with the other data sets. Lots of money gets spent on data that overlaps in less than useful ways, but could be managed more efficiently. Sometimes a CMDB or other repository is added in – at additional expense – to bring everything together, if possible. That’s a story of lots of money spent and lots of frustration generated.

There is much to be said for taking the time to plan first before spending money, learning what data is needed and the tools that best fit the environment. Even in an efficient environment, most organizations will end up with “at least two inventory tools to scan all internal device types.”

If you look at the various inventory-consuming groups within your organization, you’ll likely find several competing needs:

  • If you look at the various inventory-consuming groups within your organization, you’ll likely find several competing needs:
  • The service desk needs data that shows changes over time on individual devices to help diagnose failures
  • The configuration management team needs to track which patches have been deployed and which haven’t
  • The service desk and configuration management will each be interested in what devices have been updated with the latest versions of software
  • The software license management team will be looking for too few software purchases to support active installations, as well as too much purchased software as compared to instances in use

Perform a comprehensive business and technical assessment at the beginning of the process. Ask the different groups what data they need and how they will use it. Find out how often the data needs to be refreshed and plan your inventory schedule accordingly; the service desk will ask for nearly real-time updates, while license management might only need monthly scan cycles – the solution probably lies somewhere in between.

Discovery vs. Inventory

There are two primary types of data-gathering that are often clumped together and called inventory. However, there is a difference in the amount of data returned and how the data is generated.

Discovery (or autodiscovery) starts with a scan of a range of IP addresses looking for active devices. For each device that responds to a ping, additional tests are performed to elicit some low level hardware and software data.

Inventory is a complete accounting of all hardware and software associated with a device. A variety of methods may be used to gather the inventory data, and these will be discussed in detail a bit later.

For discovery, tests may include such industry protocols as WMI (Windows Management Instrumentation), WinAPI (Windows API) and SNMP (Simple Network Management Protocol). Depending on permissions available on a device, the information returned may include:

  • Device manufacturer and model
  • Serial number and asset tag
  • Operating system manufacturer, version and service pack
  • Networking information (IP, DNS, MAC)

SNMP reads the Management Information Base (MIB) from network devices – hubs, routers, switches, printers – to provide information about devices from which further hardware and software information will not be obtained. But some MIBs may include additional information; for example, from network printers, the MIB can return the number of pages printed, percentage of toner remaining, and so forth. Discovery can, therefore, provide an interesting perspective on network devices.

Discovery is almost universally an agentless process. Sometimes, however, an agentless discovery utility is included with an agent-based inventory tool and has the ability to interrogate the agent on a device. In such configurations, discovery is able to identify devices that do not have an installed agent and to therefore help to close the gap on a complete inventory. While 100% coverage of inventory is nearly mythical, you can come closer by using discovery as one of your inventory methods.

Inventory – It’s in the Details

[Note – the next sections focus almost entirely on Microsoft Windows-based devices. This is simply because the vast majority of devices managed through ITAM projects fall into this category. A section later looks briefly at other platforms such as Linux / UNIX and Macintosh.]

There has been a lot of evolution over the last 20+ years on the hardware inventory side of the story. When PC inventory first got started, the management APIs noted above didn’t yet exist. Hardware recognition was a matter of coding device-specific tests. WinAPI, WMI and other standards have made hardware inventory much easier and quite consistent among the various tools. You even see a standard (VESA) that allows automatic recognition of monitors, including serial numbers and diagonal screen size. So, to a very great extent, hardware inventory recognition has been commoditized.

For software inventory, the premium is – somewhat obviously – on recognizing applications. At the user interface, we see a button that launches an application. In the file system, however, there may be dozens of folders containing hundreds of files that need to be rolled up into one line item in the inventory. There are several ways to accomplish this:

Version Resource Block (VRB) or File Headers: Embedded in many files on a device is the Version Resource Block. (Right click on an executable and pull up the Details tab in Windows 7 or the Version tab in XP.) The level of detail that can be filled in is everything you need for recognition – product name and version, manufacturer, language and a bunch of other stuff. The problem is when, over time, information has not been filled in consistently and, often, not at all. As with ARP, VRB data has improved over time, but a recognition engine still needs to perform a lot of normalization to come away with accurate results.

Proprietary Application Signature Database: A number of applications with inventory use a database of application signatures for recognition. Using raw data from a file scan, a variety of factors are compared to the available fingerprints to differentiate versions, language editions, and so forth. This type of recognition has the best chance of differentiating components of a suite from stand-alone installations of an application also associated with the suite. (An example of this is a copy of Microsoft Access installed separately from a copy of the Office Home and Business Suite. That combination gives the appearance of an installation of Office Professional, but that’s not what is licensed.) It’s necessary that such fingerprint databases be updated on a regular basis by the vendor, quarterly at a minimum, but more often is better.

Add / Remove Programs (ARP): The Control Panel feature for managing software on a device can be mined for a list of installed applications. It seems like a convenient idea, but there are issues. ARP has always been prone to delivering false positives and negatives, though accuracy is decidedly better in recent versions of Windows than, for example, Windows NT. Still, not all software is added to a device by way of an installation process, so not all software shows up in the ARP list. It’s also fairly easy to find software in the ARP list that is no longer installed; we’ve all seen users who decide they don’t need an application anymore and simply drag a folder into the trash can. Also, ARP does not deliver usage data; you can’t count the old XP classifications such as “rarely used” as usage.

The Registry: Honestly, the registry is even less reliable than the ARP database. Many applications leave registry entries behind on uninstall “just in case” the application is ever reinstalled. In the meantime, all that junk is lying there as clutter. A software scan based entirely on this could return a monumental pile of false positives. Plus, any application not installed using the Windows installer may not write anything to the registry, so no recognition is possible there. However, when specific queries for known data can be directed into the registry, it becomes the best source for drawing relationships such as that between point products and the suite in which they are included.

ISO 19770-2: First ratified in October 2009, this ISO standard defines a method for tagging software with a file containing all the information necessary to recognize an application. In theory, all an inventory tool would need to do is scan a drive for files with the SWIDTAG file extension and that would compile a complete software inventory of the device. In practice, over the last 3+ years, only a handful of software manufacturers have started installing the tag files with their applications, and even fewer inventory vendors have added tag files to their recognition methodologies. The future is somewhat brighter as Microsoft has committed to publishing tags. Longer term, tag files are not being retrofitted for software published in the past, and adoption by all software manufacturers is a very long way off. Tag files may be generated internally by end-users, but that’s a lot of work to fill in the gaps that will linger for quite a while.

Which is the best method for software recognition? There’s no straightforward answer. No recognition process will recognize every application out-of-the-box. You’ll need to test in your environment to make sure you’re finding the software titles you need to manage. It’s important to be able add recognition for your internally developed software and for software particular to your line of business. You’d like the vendor to add recognition at your request, though don’t expect them to add every little shareware utility you’re using.

Another nice feature of software recognition to look for is some assistance in filtering your software inventory for the differing needs of the configuration and license management groups. At the configuration management level, you want to know about every piece of software whether there are licensing implications or not. At this level, every instance of Java, .NET or Adobe Acrobat Reader has some potential significance.

However, when you turn to license management, a lot of this granularity becomes irrelevant. Free software like Acrobat Reader can go away. Minor versions, language editions and service packs may be compressed into a single line for the version purchased. Some tools do this automatically, while others provide the facilities for you to make these decisions, or engage consultants to help with the work.

One final area of increasing importance for software recognition is the virtualization of applications. When software is virtualized, the raw data used for software recognition is lost. You could create a custom fingerprint based on the virtualized executable or, if your inventory tool recognizes ISO tag files, you could create and deploy tags with your virtual apps. One way or another, for now you’ll need to make some accommodation to make sure virtualized software is included in your inventory count.

Agentless or Installed Agent?

Back in the day, we used to get a lot of push-back from customers about installing an agent to generate inventory data. “Oh we couldn’t possibly use up that much hard disk space on every machine!” At that time, we were talking about 2-3 MB for the agent, but it was on a 200 MB drive and disk space was more expensive. Well, that argument is no longer as relevant, even with some agents occupying north of 50 MB. But there is still push back over adding “yet another agent” to machines.

While agentless inventory is attractive because you don’t have to install anything on each device, it does have limitations insofar as what hardware and software may be discovered. And, since it’s driven by an IP address or authoritative source crawl, it will only return data for devices that are turned on at the scheduled scan time. An installed agent, on the other hand, using permissions granted to installed applications, will usually generate more comprehensive hardware and software data. Also, the installed agent can still run the inventory scan even if the device is not attached to the network at the scheduled scan time and upload data later.

But the big deciding factor in the agentless vs. agent debate is pretty simple: do you want software usage data or not? If you are committed to using software asset management to cut costs, then the answer to that question must be “YES!” Software usage analysis lets you look for under-utilized or completely unused installations of applications and reallocate them to users who will use the software. Usage analysis can also be used to cut down on maintenance costs. In aggregate, looking at software usage can save a company over 20% on license costs for many applications.

Another area in the agent issue I hear about a lot is placing a management agent on servers. Customers are fairly polarized over that, either strongly against agents on servers or not caring so much. But, server software does need to be counted in the inventory and software license calculations, and some agents can generate usage data for applications run from servers. One middle group is an inventory-only agent available from some vendors. Instead of a full-blown management agent supporting polices and software distribution, the inventory-only agent does exactly what its name implies – only inventory. As such, it is perceived as less invasive and at least generates data on installed software.

Finally, in many environments, there will be at least a handful of devices that are not ever connected to the network and will have to be inventoried manually. Many inventory tools include portable collection utilities that can be deployed by thumb drive to such devices. Data is then loaded into the inventory database in batches. And for those of you with portions of the enterprise designated as “Top Secret” or above – and I’ve worked for a few of those customers – well, at least the auditors can’t go into those areas either!

Having an agent on each device also helps with the Moves-Adds-Changes process. If a device has not reported inventory for some period of time, this device may have been removed from the environment. Once the removal is confirmed, the licenses for software on that device can be “harvested” and reused for other devices. It’s especially useful to process all the lost devices out of the system in time for contract renewals for expensive applications; it doesn’t help the bottom line to be paying for maintenance on software that is no longer in use.

Other Platforms

While Windows-based operating systems are found on the largest percentage of devices to be inventoried, there are several other platforms of interest for inventory. Two receive a lot more attention in the press than others:

Mobile devices: Mobile is one of the hottest topics in IT these days. A variety of tools have been introduced in the last couple of years to manage them, including providing inventory. One challenge will be to sort out the company-owned from the personally-owned devices that have been allowed into the work environment. Likely, some of the software on the personal devices will be on corporate licenses so you have to count it. As messy as this gets, it’s a persuasive argument for companies to provide mobile devices to employees.

Virtual desktops: Virtual desktops are another big up-and-coming trend. The issues of inventory and software usage are the same as they are for physical devices, but with the added complexity of devices that “appear” at the beginning of a work session and “disappear” at the end of the session. While the session is alive, you have copies of software active for which you need licenses. You should also collect information on software usage inside of those temporary sessions for the same reasons you collect usage data and analyze it for the physical world. But there are some logistical challenges introduced by virtualization that I’ve tried to wrap my head around with the technology that I use every day and I have yet to come up with a reasonable solution.

And then there are a few more items to cover before wrapping up:

Macintosh devices: These devices represent a fairly small percentage of overall enterprise devices, but bring the same type of software licensing concerns as Windows devices. Also, the types of software used on Macs – design and engineering in particular – tend to be relatively more expensive on average, so you’ll want to include them in your inventory plans. Inventory recognition for Macs is pretty simple and most vendors include agents or utilities to cover them. You should not expect inventory and software licensing for Macs to be much different from Windows devices.

Linux and UNIX: Mostly found running servers, there is somewhat less urgency to running a detailed application scan the way you would for Windows workstations. That works out well for us technically since the way applications are built for these operating systems doesn’t work particularly well with traditional inventory methods; applications on UNIX / Linux platforms tend to have far more files installed. However, the number of installed applications found on such servers is usually pretty small, so counting them is straight forward. The issue, however, is not how many are installed so much as how much they are being used. Licensing for server software is usually fairly complicated, and there are application vendors who specialize in this area.

Mainframe: Software for mainframes falls into a similar category as Linux / UNIX. Once again, certain vendors specialize in this area and should be consulted if your needs run this way.


Inventory is a core competency that any software asset management tool must provide before you can begin to reconcile purchasing data and calculate compliance. Start by identifying the data you need for the various constituencies in your environment, and then look for a tool that can deliver on your requirements. You may not find a single tool to do the whole job, especially if you manage some of the more challenging platforms. But, with planning, you’ll find a strong foundation on which to build your ITAM projects.

About the Author

In 1990, Bruce was a founder of Tally Systems, helping to bring the first hardware / software inventory tool to market and later working with the professional services group, managing on-site inventories for Fortune 1000 companies and product implementations. After Novell acquired Tally Systems in 2005, Bruce worked in a number of roles including Product Management for the inventory, recognition and asset management components of ZENworks. Since 2009, Bruce has been an independent consultant working on configuration and asset management projects mainly based around Novell’s ZENworks product line. He has also developed and presents several courses for Novell Training.