This post was originally published on 1 June 2016.
Let’s face it. We have been doing this same thing for the better part of 20 years, or even more. Software inventory functionality is the staple of system management tools, right there, next to the features for distribution of software.
So why, then, am I saying then that the thing you already have, and perhaps have had for a long, long time, is not good enough? What, really, you are missing out on?
The usual couple of ways of implementing the software inventory product, in the technical sense, are:
- Scan the executable files on the disk
- Scan/query the installed programs information Windows maintains
To understand where the deficiences lie in, let’s look at both of these methods little bit closer before discussing scenarios that these methods may miss.
To be clear, in this article series we are not concentrating on application monitoring solutions which change the problem domain a bit (to better or worse, depending on situation), but just purely from the standpoint of software inventory i.e. functionality that concerns itself of getting information what’s supposedly out there deployed in our organisation’s PCs.
File scanning, pure and simple – or is it so
Now, before Windows really had information recorded in structured manner what’s been installed, the only way to gather information about installed software was to scan the executables themselves on the disk. Before application suites got big and regular user had tens (if not hundreds) of different applications at his/her machine, this was somewhat manageable method. After all, there weren’t that many executables!
But considering the regular PC of the day, the amount of data gathered this way is staggering in any normal environment. There’s hundreds or thousands of PCs, and all of them have hundreds or thousands of executable files. Some of them belonging to the operating system itself (quite many, in fact), some of them installers and other not-actually-programs and rest of them belonging to number of different software products installed.
As an example, on my Windows PC, which admittedly has more software than typical user would have – but not hugely so – there’s 6378 different executable files on the C: drive. I certainly don’t have that many programs installed per-se. Oldish Microsoft Office version alone has north of 30 different .exe’s installed with it.
So while it may be that back in the day it was feasible to get some information about what’s deployed to the machine by inventorying individual “applications” (I put that in quotes because not all executable files on the disk are actual distinct end-user usable applications), in today’s world of proliferated software applications this doesn’t tell you anything sensible.
In fact, Microsoft purchased a company some years ago whose product’s (since known as Asset Inventory Services, part of Microsoft’s MDOP package) raison d’être was/is to link those executable to known products using a huge cloud-base database. To put it simply, facilitate knowing for example that particular msaccess.exe, version x.y.z and having certain other properties, on the disk of some machine belongs to Office 2010 Premium, English version. That sounds better than having 1000 lines of msaccess.exe in some Excel sheet, but still the whole premise of scanning executables and then trying guess what products they represent sounds little, well, backwards. And Microsoft was not alone in this with AIS, other Software Asset Management companies operate similiar knowledge databases about application executables and their relations.
But, as strange it may be, many of the software inventory solutions still does this sort of scanning. And most of them do not even have the benefit of having huge cloud database in the backend augmenting that information to something more sensible. If you happen to have one of these products, you are definitely looking at trees in a huge forest, but not really seeing the forest as it is!
Information recorded by Windows
Another, arguable better, approach in modern Windows systems is to simply ask from the Windows itself what applications – or products – it knows to be installed.
As the end-user of some machine, this is basically information that you would see when you look at the Add/Remove Programs or Program and Features –list, found from the Windows’ control panel. Information about product being installed is recorded by the installation program, be it some 3rd party installer technology or built-in Windows Installer (MSI) technology, by which the product ended up on the machine.
This information is bit more consolidated and more understandable than just scanning individual executables. Installer can elect to record some addition information about the installed product, along with the name and the version. Version here usually meaning the technical, internal, version number of the product such as 14.0 for Office 2010; where 2010 is really a marketing version.
Mostly every piece of information about the product recorded to Windows’ database of installed programs is optional, so depending on the level of interest from software vendor there might be more but there might be almost nothing for some products (no icon, maybe cryptic name, nothing to visually tell what the product is about).
Also, it could be that there’s nothing recorded at all if the installed did not elect to write entry to the registry!
Further, more complex products might install tens of different components, all showing up as individual software products in the installed programs list. And yet again, some system software components shared by multiple different applications, such as Visual C++ runtime libraries, show up here as installed “programs”.
Another matter entirely is the fact that this information must be explicitly written to the machine, as stated above. If there are applications that are run from the network share, maybe by placing the shortcuts for the user on the desktop, or simple utilities downloaded to machine and executed directory, these will not show up in the list of installed software, as known by Windows.
While these are the two main methods by which most software inventory products (standalone, or part of system management solution) report software, there’s clearly too much noise, and products not “installed” through actual installer might be missing.
But that’s not all there is for getting the information what’s been deployed to the machines. These days as the variety of application landscape has expanded from the days of yore, some new type of application deployment methodologies and usage exists which just may be missing from your software inventory depending on which method is used for getting that information.
In the follow-up articles, we will be examining these potential corner-case application installs and deployments your traditional software inventory solution might not show you at all!
