Tool functions
As we have said there are three main categories of tool function in this arena:
  1. Collection of inventory
  2. Storage of licence/contract information
  3. Automation of processes

Within these categories sit tools that have been designed to do all sorts of things:
  • Inventory of hardware assets
  • Asset discovery
  • Server management
  • Software deployment
  • Security monitoring
  • Licence management
  • etc

When we use the term inventory tool we simply mean it is a tool that is capable of collecting information about installed software, either on PC's, servers or both.

Many of the tools that fall into the groups above are capable of producing an inventory, but it doesn't mean they are any good at SAM.

Hence our first word of warning comes right now.

Weakness 1

Be very wary of any tool that claims that its' inventory capabilities are going to enable your SAM programme if the tool was historically designed to do something else, like monitor the network from a security perspective, or deploy software (more below) etc

Why?
If the tool was not designed primarily with software inventory in mind then the intelligence of the tool from a licensing perspective is probably very basic.

To combat this issue, some tool vendors have focussed on making their inventory collection as licence friendly as possible.

'Audit tools' are a subset of inventory tools that have grown directly out of the SAM trade, their focus being on providing information specifically for licence reconciliation.

Examples would include (in no particular order):
  • ManageSoft
  • ExpressMetrix
  • Centennial Discovery

Tools like these are better at the licensing part of SAM than others that merely report an inventory.  The vendors building audit tools have seen the need for licence management and put a great deal of effort into ensuring their tool recognises as much useful information as possible as far as licensing goes.

That does not mean, however, that they are the complete answer.  There will always be a gap between what is detected by the tool (description of the installed application as defined by the publisher) and what your licence entitlement actually gives you the right to install.  More on this in The truth about audit tools

These tools often include 'discovery' capabilities where the tool detects machines automatically and then presents the option for the tool agent to be installed so that the machine can be scanned.  Such functionality can be very useful when building a map of your network, but they can cause network traffic that security tools get upset about and we have seen examples of such traffic having dramatic effects on the speed of the network.

Weakness 2

The other main area of weakness is that these tools are very bad, or totally incapable of monitoring systems that are licensed under user based models.  And to be fair it is very hard for them to do so as these systems all have different ways of recording active accounts and connections.

Our complaint with this is that often these tools are sold as the solution to all your licence management and SAM problems.  But if they can only deal with installed software (and they are not very good at that) then they are only able to deliver part of the solution at best.

Weakness 3

Tool vendors that say that their tool can do server inventory to power the licence reconciliation process are even more delusional than the desktop inventory guys.

There are three common reasons for this:
  1. Server licensing follows the standard install model less often than the desktop applications do.
  2. Server software has more installation variables  to confuse tools.
  3. Often server applications install client tools (e.g. MS SQL) on the desktops that manage them which will be picked up as a server installation by the tool.

Tools can be used to give an indication of what software is on a server.  But they are very bad at defining what licensing is required as a result of that information.  'The gap' that we discuss in The truth about audit tools is even greater with server software than desktop software.

We now look at other kinds of tools and assess their licence reconciliation capabilities...

A deployment tool's main task is to deploy software to machines on a network.  Examples would include:
  • Microsoft's SMS
  • Symantec's Altiris

Deployment tools usually have software inventory abilities, which is why they are often used in the licence management scenario.

We have been involved in projects in organisations that use these types of tool and there are two main problems:
1) The inventory recorded by the tool is very raw in terms of licensing intelligence, and so a great deal of work is then needed to 'teach' the tool from a licensing perspective to recognise licensable products in the right way.

2) Often they will only collect inventory of packages that the tool has actually deployed, i.e. anything that isn't deployed by the tool is ignored.

Clearly if your organisation has a deployment tool, ultimately it wants to deploy absolutely all software with the tool.  That way everything is manageable by the tool.  The problem is however that in the real world it is rarely the case that all software will be deployed in this way. There are usually legacy systems that require other approaches.  So whilst the deployment tool might get close it will almost always never cover 100% of your software estate.

Security monitoring tools should be left to do what they do best.  Just because they have a complete view of your network and machines does not mean that they can be of any use in the licence reconciliation role.  They are not intelligent in any way when it comes to licensing.

If the security tool has information as to the number of client machines (PC's) on your network then that can be of use in Defining your framework.  Otherwise do NOT try to manage licensing with information from a security tool, it will simply require way to much configuration.

Licence management tools do not have inventory capabilities, they are a repository (database) into which you put all your licensing information.  Their purpose is to focus on the reconciliation of software inventory data (import from an inventory tool) with licence entitlement data (manually input all info into the tool).

Often, inventory tools have some form of licence management functionality built in, so that you can match an inventory item to a licence, but their ability to manage licence entitlement properly is usually decidedly lacking (they are getting better) hence why separate licence management tools have been developed.

An example of a pure licence management tool is Software Organiser.

SO requires all licence details to be manually configured in the tool, then it will take a feed from an inventory tool, then you need to match one side to the other.

Again in theory this is a great way to do it.  But the same old problems arise in terms of configuration.  Descriptions of inventory and licences will always differ, so a lot of  initial work is required to set everything up and ensure that descriptions on both sides of the equation match.

If you spend the time configuring this process, then it will work from then on with each inventory tool import automatically.  Of course with each import there will be new files that are detected, so ongoing maintenance is required.

At the very least it is a lot of work to set up in the first instance and it will continue to take a lot of management if your software estate changes regularly, which nearly all organisations enjoy.

Conclusion

All of the tool types mentioned above will provide your organisation with plenty of information to then start managing your licence reconciliation process.

Your choice of tool will often depend on what other functionality you would like the tool to deliver.

But please bear in mind that if the tool was not designed with licence reconciliation as the focus from the beginning, then expect the results to be far from satisfactory in this area.

And expect a great deal of configuration with setting everything up and then continuous ongoing management to maintain the accuracy of the information.

We now investigate why this is the case in The truth about audit tools