ILMT deployment & the 90-day rule.

What is ILMT, and why it is mandatory.

ILMT, the IBM License Metric Tool, is the free software IBM provides to discover installed IBM products, identify the virtual and physical processor capacity available to each, and produce the audit reports that substantiate a sub-capacity claim. Admodum is an independent, buyer-side software licensing advisory firm, and this page explains how to deploy and run ILMT so your sub-capacity position holds.

ILMT matters because sub-capacity is conditional, not automatic. The right to license only the virtual cores a product can use, rather than every physical core in the server, is granted under Passport Advantage and is contingent on holding ILMT evidence. Without it, IBM defaults to full capacity, and in large virtualised estates that default routinely multiplies the required count three to five times. ILMT is therefore not an IT housekeeping tool; it is the financial control that keeps an IBM bill defensible.

This page is part of the IBM sub-capacity licensing pillar. Read it alongside IBM PVU licensing explained, which sets out the metric ILMT measures, and the Passport Advantage agreement structure, which is where the obligation originates.

Deploying ILMT: scope and configuration.

A correct ILMT deployment is defined by coverage, not installation. The tool can be running and still leave you exposed if it does not see the whole estate.

ILMT discovers software through agents installed on managed endpoints, or through agentless scanning, and builds an inventory of IBM products mapped to the virtual machines and physical hosts that bound their capacity. The configuration that matters for compliance is straightforward to state and easy to get wrong: every host that runs, or could run, a sub-capacity-eligible IBM product must be in scope; the discovery schedule must run frequently enough to capture peak capacity, typically at least every thirty minutes; and the product catalogue and ILMT version must be current enough to recognise the products actually deployed.

The most common configuration failure is a coverage gap. A new cluster is built and never added to ILMT; an acquired business's hosts are migrated in without extending the scan; a cloud project is stood up outside the discovery boundary. In each case ILMT is "deployed", but the affected hosts default to full capacity because there is no evidence for them. Coverage must be treated as a live control with an owner, reconciled against the infrastructure inventory at every change.

The choice between agent-based and agentless discovery is operational rather than contractual; IBM accepts either, provided coverage is complete. Agents give richer, more reliable data on each endpoint but add a deployment and maintenance burden; agentless scanning is lighter to roll out but depends on credentials and network reach to every host. Many estates run a hybrid, agents where they can, agentless where they must, and the only test that matters is whether the combined result accounts for every host that could run an eligible IBM product. A deployment that leaves even a handful of hosts unscanned has, for those hosts, no defence against a full-capacity assessment.

Equally, the ILMT product catalogue and software signatures must be kept current. IBM updates the catalogue as products and versions change, and an ILMT instance running an outdated catalogue may fail to recognise a newly deployed product, recording it as unknown or not at all. Scheduling regular catalogue and version updates is therefore part of basic coverage hygiene, not an optional refinement.

The 90-day rule in detail.

The 90-day rule is the timing condition at the heart of sub-capacity. ILMT must be installed and collecting data within ninety days of the first sub-capacity-eligible product being deployed in a virtualised environment.

The subtlety that catches diligent teams is when the clock starts. It does not start when procurement signs, nor when IT decides to adopt ILMT; it starts the day the first eligible product goes live in a virtual environment. New build-outs, acquisitions and lift-and-shift cloud migrations routinely breach the window because nobody owned the clock at the moment of deployment. The defensive posture is to make ILMT coverage a gate in the deployment process, so that no eligible product reaches production without discovery in place.

Equally important, the conditions are continuous. Passing the ninety-day test at deployment is necessary but not sufficient; ILMT must keep reporting for every quarter you wish to claim sub-capacity. A product correctly reported for years but dropped from coverage for two quarters carries, on IBM's reading, a two-quarter full-capacity exposure regardless of the earlier record.

Reporting, sign-off and two-year retention.

ILMT data is only evidence if it is turned into retained, signed reports. The reporting discipline is what an IBM licence review actually examines.

The practical failure here is reports that are generated but never retained, or a retention archive with gaps. When IBM asks for two years of quarterly reports and the customer can produce only the most recent, the missing quarters are treated as periods without evidence. Treat the report archive as a financial record: owned, version-controlled, and complete. The wider evidence pack a buyer should hold is set out in the sub-capacity pillar and the audit playbook at surviving an IBM software licence review.

Failure modes and approved alternatives.

Most ILMT exposure comes from a short list of avoidable failures, and there are defined alternatives for the cases where ILMT itself is impractical.

• Late install. The ninety-day window is breached on a new environment, so full capacity applies from day one.
• Incomplete scanning. Hosts are missing from coverage and default to full capacity even where the product was correctly sized.
• Lapsed agents or stale version. Reporting silently stops, or a product is too new for the installed ILMT to recognise, leaving an evidence gap.
• No retention. Reports are generated but not kept for two years, so historical quarters cannot be defended.

Where ILMT cannot be used, IBM recognises a limited set of alternatives. Certain verified software-asset-management tools, such as Flexera, are accepted for sub-capacity reporting; the IBM Licensing Service provides container-native metering for Cloud Paks; and enterprises below roughly a thousand employees may use a documented manual calculation. None of these removes the underlying obligation to hold complete, retained, accurate capacity evidence; they only change the instrument that satisfies it. A senior Admodum advisor can confirm which route is defensible for your estate, at the IBM practice, the IBM knowledge hub, or directly via contact.