ILMT Remediation: A Step by Step Plan

A broken ILMT deployment quietly converts your sub-capacity claim into full-capacity exposure. Remediation is not a reinstall, it is a disciplined sequence that rebuilds a defensible measurement record. This is the plan we run before IBM ever sees the data.

Why ILMT remediation matters

IBM permits sub-capacity licensing only when an approved tool measures virtual core usage, is deployed within 90 days of first eligible deployment, runs continuously, and produces quarterly reports retained for two years. Miss any one of those conditions and IBM defaults to full-capacity charging on the entire physical host. A neglected ILMT environment fails silently: agents stop reporting, installs sit miscategorized, and reports never get signed. Remediation restores each of those conditions in an order that produces evidence, not just a healthier console.

Step one: inventory the gaps

Start by mapping every server that should be under sub-capacity against what ILMT actually sees. The goal is to surface three failure classes before touching anything: hosts with no agent, agents installed but not reporting, and reporting agents whose software classification is wrong. Document the gaps with dates, because the lookback window is measured in time, not in current state.

• Coverage gaps: eligible hosts with no functioning agent at all.
• Reporting gaps: agents present but silent, which void the claim for every period they were dark.
• Classification gaps: installs ILMT bundled, split or named incorrectly.

Step two: restore continuous reporting

Redeploy and reconnect agents so that data flows without interruption. Continuity is the part IBM scrutinizes hardest, because a single quarter of missing data can reopen full-capacity charging for that window. Confirm the scan and upload schedules are running and that the server is retaining history rather than rolling it off.

Step three: correct the software classification

ILMT routinely miscategorizes installs and needs manual correction. Reconcile every bundled component to its parent product, confirm each install is assigned the right metric, and remove phantom installs that inflate your count. Classification is where most over-reporting lives, and it is the step that most directly lowers an honest PVU number.

Step four: rebuild and retain the reports

Generate the quarterly sub-capacity reports, have them reviewed, and retain them for the full two years IBM requires. A report that exists but was never reviewed is weaker evidence than one with a clear sign off trail. Treat the retained reports as the artifact you would hand an auditor, because that is exactly what they are.

Step five: hold the posture

Remediation is not a one time project. Assign ownership, set a recurring review, and watch for agents that go dark after server rebuilds or migrations. A standing posture is cheaper than a second remediation under audit pressure.