Zoomed Image
USA
800 691 9120
UK
01225 704844

Multi-License Coverage

Software Asset Management Guide
Concepts

Multi-License Coverage

A single install can be covered by more than one license. This page explains when that happens, how the engine handles it, and how to read it in the position.

Why Multi-License Coverage Exists

Three common scenarios produce a need for multiple licenses to cover one consumption:

  1. Per-core licensing on big servers. A 32-core server may be covered by two 16-core licenses purchased in separate years. Neither license alone has enough capacity, but together they do.
  2. Volume top-ups. You bought 10 Adobe licenses in 2023 and 5 more in 2024. A single install can be covered by either license — the engine picks one. But across many installs, both licenses contribute capacity.
  3. Mixed license types for one product. You may have both per-user and per-computer Microsoft 365 licenses for the same product, perhaps for different parts of the business. The engine will allocate from whichever fits the consumption best by affinity.

How the Engine Splits Coverage

For per-core and per-processor licenses, the engine can split a single consumption across multiple licenses:

Multi-license coverage of a 32-core server A 32-core server consumption is fully covered by two 16-core licenses. The engine posts two grants, one against each license, totaling 32 cores of coverage.

Consumption Coverage

Server 32 cores License A Grant: 16 cores License B Grant: 16 cores Total: 32 cores 2 grants, same asset same consumption period

Two licenses combine to cover one consumption when neither alone has enough capacity.

For per-user and per-computer licenses, multi-license coverage means different installs use different licenses. Each install draws from one license at a time — the engine cannot split a single per-user or per-computer consumption across two licenses.

In the Licensing Position

Multi-license coverage shows up in the per-product summary as:

  • Seats — sum of capacity across all licenses for the product
  • Rights Allocated — sum of capacity actually used to cover consumptions
  • Outstanding Requirement — what is left over (zero if fully covered)

In the per-license view (the Licenses query), each license shows:

  • Its own capacity
  • How much of its capacity has been allocated to consumptions
  • How much remains unused

A license that is fully utilized has Allocated = Seats. A license with spare capacity has Allocated < Seats.

Tracing Which Licenses Cover a Specific Asset

From an asset's record, the Software tab shows which products are installed and which licenses cover each one. From the Licensing Position, click into a product to see the consumption list and the licenses providing coverage.

For audit trail purposes, the underlying grants are visible via the SQL instance dashboards under Licensing → Sql Server, and via the per-asset Software tab on each affected asset record.

When Coverage Is Incomplete

The engine is all-or-nothing per consumption. If the available licenses cannot fully cover a consumption, the engine does not partially grant — the consumption stays entirely in deficit until enough capacity is available to cover it completely.

For a 32-core server with only 24 cores of license available across all candidate licenses, the engine posts no grants at all for that server. The full 32 cores are outstanding, not 8.

This is intentional: a partially-licensed install is not a compliant install in any vendor's view. The position should reflect that bluntly. To resolve:

  • Buy at least 8 more cores so total available is ≥ 32, or
  • Remove the install from the over-large server, or
  • Free up an existing license seat (reclaim a license currently covering a different machine that no longer needs it)

Once total candidate capacity is enough to cover the consumption fully, the engine posts the grants on the next calculation — typically split across multiple licenses as described in How the Engine Splits Coverage above.