Matching licences to installed software sounds simple and is not. Three activities decide whether it works: normalising the inventory, understanding how the software is actually used, and applying entitlement to the result.
Once you have an accurate inventory of your software and have calculated your entitlement, the next job is to match the two together.
Matching licences to installed software sounds like a fairly simple process. It is not. Licensing is complex, every publisher enforces a different model, and the rules that decide how many licences you need are frequently not visible in the inventory at all.
Three activities decide whether this works:
Each is dealt with below.
At this stage you have to rationalise what could be thousands of different software products into a list of licensable products and their install counts. Those are not the same thing, and the gap between them is where most of the difficulty lives.
Raw inventory gives you executables, display names and version strings — the same product appearing under four publisher spellings, editions that are licensed differently sitting under one name, and a long tail of components that are installed but require no licence at all. Normalisation is the work of turning that into something you can count against a contract.
Done by hand, this requires deep knowledge of each publisher’s product line and, in particular, of which products actually need licensing. The original version of this post estimated several days per publisher, and multiplied across your publisher list that is a serious commitment of specialist time.
That is the part that has changed, and it is worth being clear about it. Recognition now resolves against the Software Recognition Database — over 3.5 million normalised publisher, product and version titles, centrally maintained and categorised, and paired with a recognition service that carries release, end-of-support and extended-support dates. Software identification tags with UNSPSC classification are read where publishers provide them. Publisher names are normalised and versions recognised automatically.
What that removes is the cataloguing. What it does not remove is judgement. Deciding that a particular installation is out of scope, or that a component belongs to a bundle you already hold, is still a decision someone has to make and record. The difference is that it is now a decision on an exception rather than a data-entry exercise across the whole portfolio.
It is not necessarily the number of deployments of a product that has to be understood, but how it is used. The key considerations:
This is one of the hardest areas for any organisation, because answering it means understanding product use rights and the terms and conditions governing how a particular licence may be used.
Those questions are still the right ones. They are, however, no longer questions you have to answer entirely from documents.
Assignment types cover per device, per processor and per core, so the counting basis is a property of the licence rather than an assumption in a spreadsheet. Microsoft server licensing handles device and user CALs, named users and external connectors alongside SQL Server and Windows Server core and processor licensing, with cluster and virtualisation awareness — because the hard part of Microsoft licensing is the server room, not the desktop. For Oracle, processor types and core factors, licence pools with hosting rights and geographic rules, cover-down logic for Enterprise Edition and options-and-packs evidence with override are all modelled explicitly. IBM sub-capacity brings PVU and Virtual Processor Core metrics, an ILMT connector with compliance gap analysis, and enforcement of the thirty-minute inventory cycle that sub-capacity licensing actually requires.
The Citrix, Terminal Server and VDI question is handled by Access Control rules for streamed applications, with remote usage tracked per device on Terminal Server and RDS.
And on the usage question underneath all of this: file-based metering records first-used and last-used per title, with a percentage-used figure computed over a rolling ninety-day window. That is what separates “installed on four hundred machines” from “opened on ninety of them since March” — and it is the number that turns an analysis into an optimisation.
Once you know what is deployed, how it is used, and therefore how many licences are required, you can apply entitlement to requirement and produce an Effective Licence Position.
That involves applying downgrade and down-edition rights, understanding secondary use rights, and excluding deployments that do not require a licence — developer machines being the classic example.
Each of those is a named capability rather than a manual adjustment. Downgrade rights and second-use entitlement are handled by the engine. There is an explicit Exclude From Licensing workflow for MSDN, development, training and second-use devices, so exclusions are recorded with a reason and an audit trail instead of quietly disappearing from a spreadsheet. The position itself is expressed as purchased, used, available, required, variance and exposure, with overspend and additional-licences-required calculated alongside each other — the two directions of error being equally worth knowing about.
The important structural change is that this is a continuous position rather than a point-in-time reconciliation. An ELP produced as a project is accurate on the day it is signed off and decaying by the end of the week. One that is computed continuously is something you can act on.
These steps bring both operational and cost benefits.
The operational benefit is that the argument stops. When the inventory is normalised, the usage is measured and the entitlement is modelled, there is one number and it is defensible. Audit preparation becomes a report rather than a programme of work.
The cost benefit is in two parts. Harvesting is the obvious one: licences held by people who have not opened the software in ninety days are recoverable, and recovering them is cheaper than buying more. The less obvious one is avoided purchase — knowing that you already hold entitlement, or downgrade rights that cover a requirement, before the renewal conversation rather than after it.
Neither is available to an organisation that only knows what is installed. Optimisation begins where the inventory stops.
Other posts covering the same ground.
More than forty seasoned software asset management professionals were asked for one piece of advice for someone starting out in a SAM role. Their answers fell into four categories, and none of them was "buy a tool".
Most SAM programmes are built on Active Directory and an agent deployment, which means they are built on a list that is already wrong. Discovery is not a preliminary step to software asset management — it is the foundation the rest of it stands on.
SCCM is good at what it was built for and was never built for software asset management. You do not have to throw it away to close the gap — but you do have to know precisely where the gap is.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.