Table of Contents
Where to Get IBM ILMT Support
When something goes wrong with ILMT, your first question is usually "who do I call?" The answer depends on what kind of problem you are dealing with and how fast you need it fixed.
IBM Official Support
IBM offers support for ILMT through the IBM Support Portal. You open a case, search technotes, and download patches from IBM Fix Central. The documentation is thorough and the knowledge base covers most known issues with detailed resolution steps.
Here is the honest part. ILMT is a free tool. IBM provides it at no license cost to Passport Advantage customers, and that changes the support dynamic. ILMT cases do not generate revenue for IBM the way a Db2 or WebSphere support ticket does. In practice, this means response times can be slow. We have seen cases where a straightforward ILMT question took two to three weeks to get a meaningful response. For critical issues during an audit, that timeline does not work.
That said, IBM support is still the right channel for genuine product bugs, upgrade issues, and problems that require access to the ILMT source code or internal engineering. If ILMT is crashing after an upgrade or producing corrupted Audit Snapshots, IBM is the only party that can provide a fix at the product level.
Community Resources
The IBM Community forums (specifically the BigFix and ILMT sections) are surprisingly useful. Other ILMT administrators post questions and share solutions. IBM employees occasionally respond as well, though not on any guaranteed timeline. For common configuration issues, a forum search often turns up someone who hit the same problem and documented their fix.
Third-Party Specialists
This is where companies like ours come in. Independent ILMT consultants work with the tool every day across dozens of client environments. We see the same problems repeatedly, so we can usually diagnose and fix them faster than IBM's general support queue. The trade-off is cost. IBM support is included with your Passport Advantage agreement, while third-party help is a paid service. But when you need a problem solved this week instead of next month, that cost is often worth it.
The 10 Most Common ILMT Problems
We work with ILMT environments across Europe, and after years of doing this, we can confidently say that 90% of ILMT problems fall into the same ten categories. Here they are, with practical steps to troubleshoot each one.
1. Agents Not Reporting
This is the most common ILMT problem by a wide margin. A BigFix agent stops sending data to the server, and ILMT loses visibility into that endpoint. If the endpoint runs IBM software, you now have a gap in your compliance data.
Start by checking the BESClient service on the affected machine. Is it running? If not, restart it. If it is running but still not reporting, the issue is almost always network-related. The agent communicates with its BigFix relay on port 52311 (TCP). Firewall changes, network segmentation updates, or VPN configuration changes can all block this traffic without anyone noticing.
Open the BigFix console and look at the "Last Report Time" column for the affected endpoints. If it shows more than 7 days ago, that agent needs attention. In large environments, we recommend building a BigFix dashboard or automatic alert that flags agents silent for more than 48 hours. Waiting until an audit to discover that 15% of your agents have been offline for months is a painful experience.
2. Software Catalog Outdated
ILMT identifies IBM software by matching file signatures against its built-in catalog. IBM updates this catalog regularly to cover new product releases, fix misidentifications, and improve detection accuracy. When your catalog is out of date, ILMT starts showing "unknown" entries for products it should recognize, or it misidentifies one product as another.
The fix is straightforward. The current distribution channel is the BigFix Inventory fixlet site, the catalog lands there automatically and you apply it with a fixlet. For older ILMT 9.x installations and disconnected environments, you can still download the catalog package and import it manually. Either way, IBM releases catalog updates every few weeks and updating quarterly is the minimum we recommend for production. Just make sure someone actually owns this task, because in practice nobody does and the catalog quietly falls six months behind.
3. PVU Count Suddenly Spikes
You generate a report and the PVU numbers for a product have jumped dramatically compared to last month. Before you panic, check three things.
First, look at VM configuration changes. Did someone increase the vCPU count on a VM running IBM software? ILMT calculates PVU based on the peak capacity during the reporting period, so a temporary increase for performance testing still counts. Second, check for DRS migrations. In VMware environments with Dynamic Resource Scheduler enabled, a VM can migrate to a host with more physical cores. That changes the PVU calculation even if the VM's own vCPU count did not change. Third, verify the processor mapping. ILMT uses IBM's PVU table to convert processor cores to PVU values. If a new server model was added to your environment and ILMT does not have the correct mapping, the PVU calculation may be wrong.
Open the ILMT hardware inventory for the affected server and compare the current processor information with the previous reporting period. The answer is usually there.
4. Reports Show 0 PVU for Known IBM Products
You know WebSphere is running on a server, but ILMT reports show 0 PVU for it. This is a bundling rule issue. The product is detected by the scanner, but it is mapped to the wrong license metric or excluded from PVU calculations because of how the bundling configuration is set up.
Check the software catalog bundling configuration in ILMT. Sometimes a product is assigned to a bundle that sets its PVU contribution to zero because IBM considers it included with another product. If your actual entitlements do not match that bundling assumption, the report is misleading. This is one of those issues that looks harmless but creates serious problems during an audit. An auditor who sees 0 PVU for a product that clearly requires licensing will dig deeper.
5. ILMT Server Performance Degradation
ILMT was fast when you first deployed it. Now data imports take hours, the web interface is sluggish, and generating an Audit Snapshot brings the server to its knees. This is a database growth problem.
ILMT stores historical scan data, and over time that database grows. Environments with more than 5,000 endpoints are especially prone to this. The solution is a combination of database maintenance (reorganizing tables, updating statistics), archiving old data that is no longer needed for compliance purposes, and potentially increasing the server's CPU and memory resources. IBM's documentation includes specific guidance on database maintenance schedules for ILMT. If you have never run maintenance tasks on your ILMT database, start there. If performance problems push you toward a resilient setup, the high availability and DR approach for ILMT is a different conversation than a performance fix, and it is worth understanding the supported options.
6. Duplicate Entries in Software Catalog
The same IBM product appears multiple times in your ILMT reports, sometimes with different license metrics. This typically happens when custom software signatures conflict with IBM's built-in catalog entries. If someone created a custom signature for a product that IBM later added to the official catalog, you end up with two entries.
Review your custom signatures and compare them against the current official catalog. Remove any custom entries that duplicate what IBM's catalog already covers. After cleaning up, reimport the catalog and let ILMT reprocess the data. The duplicates should resolve on the next import cycle.
7. VMware Virtualization Data Missing
ILMT shows "unknown" for the virtualization type on servers that you know are VMware virtual machines. This means ILMT cannot determine the physical host where those VMs are running, and without that information, it cannot calculate sub-capacity PVU values. Those VMs default to full-capacity calculations in your reports.
The root cause is almost always the BigFix VM Manager tool. This component connects to your vCenter and pulls VM-to-host mapping data that ILMT needs. The same pattern applies to Hyper-V and Nutanix AHV, each has a dedicated VM Manager connector in recent BigFix Inventory versions. Hyper-V in particular changed over the years: older ILMT versions relied on the BigFix agent on the Hyper-V host, newer versions support a native VM Manager connection. If you run a mixed estate, verify which method each cluster is using. Either the VM Manager tool is not configured at all, the vCenter credentials have expired, or the vCenter connection is blocked by a firewall. Check the VM Manager configuration in the BigFix console, verify the credentials, and make sure the BigFix server can reach your vCenter on the required ports. In environments where the VMware team and the ILMT team are separate groups, this integration often breaks silently because nobody owns the connection between the two systems.
8. PowerVM LPAR Data Incomplete
If you run IBM software on Power Systems, ILMT needs data from the Hardware Management Console (HMC) to calculate sub-capacity values for your LPARs. When this data is missing or incomplete, ILMT defaults to full-capacity licensing for the affected Power Systems. On a POWER9 server with 24 cores at 120 PVU per core, the difference between sub-capacity and full-capacity can be enormous.
Check the HMC connection configuration in ILMT. The most common causes are HMC credentials that were changed during routine maintenance without updating the ILMT configuration, network connectivity changes between the ILMT server and the HMC, or HMC firmware updates that changed the API behavior. If you recently upgraded your HMC firmware, verify that the ILMT connection still works afterward.
9. ILMT Upgrade Breaks Reports
You upgraded ILMT to the latest version and now your historical reports look different. PVU numbers changed, products that were previously identified correctly now show different values, or the Audit Snapshot format has changed. This is frustrating but it does happen.
IBM sometimes changes calculation methodology, catalog matching logic, or report formats between ILMT versions. The upgrade itself is not broken. The new version is simply interpreting the same data differently. Before upgrading, always review the ILMT release notes for your target version. They document changes to calculation behavior and known issues. If you are in the middle of an audit or approaching a compliance review, postpone the upgrade until after that process is complete. And always test upgrades in a non-production ILMT instance first if you have one available.
10. Agent Deployed but Not Scanning
The BigFix agent is installed and reporting to the server. You can see the endpoint in the BigFix console. But ILMT has no software scan data for that machine. The agent is healthy, so what is going on?
The BigFix agent being online does not automatically mean it is running software scans. The software scan is a separate action that needs to be targeted to the endpoint through the BigFix console. Check the scan action status for the affected machine. Look for the ILMT software scan fixlet and verify it has been activated and successfully applied. In environments where new servers are added regularly, it is easy to miss targeting the scan action to new endpoints, especially if the deployment process does not include a step for BigFix scan activation.
Stuck on an ILMT Problem?
Send us a description of the issue and we will tell you whether it is something you can fix yourself or whether you need hands-on help. No sales pitch, just a straight answer.
Describe Your IssueWhen to Call for Help vs Fix It Yourself
Not every ILMT problem requires outside help. Here is an honest breakdown of what you can handle internally and what is worth escalating.
Fix It Yourself
Agent connectivity issues are the most common ILMT problem and usually the most straightforward to resolve. If BESClient is stopped, restart it. If a firewall is blocking port 52311, work with your network team to open it. These are operational tasks that your infrastructure team can handle with basic BigFix knowledge.
Catalog updates are also a do-it-yourself task. Download the latest catalog, apply it through the BigFix fixlet, and verify the import completed. It takes about 30 minutes of active work.
Depends on Complexity
Catalog problems beyond simple updates fall into a gray area. If you have duplicate entries, conflicting custom signatures, or products that ILMT is misidentifying, the fix requires understanding how ILMT's catalog matching works at a technical level. Some organizations have this expertise in-house. Many do not.
VMware and PowerVM integration issues are similar. If the fix is "update the vCenter password in VM Manager," you do not need help. If the fix involves redesigning how ILMT collects virtualization data across multiple vCenters in different network zones, that is a different conversation.
Get Expert Help
Audit-related data issues are where mistakes get expensive. If your ILMT data has gaps, incorrect PVU calculations, or missing servers, and you are facing an IBM audit or compliance review, get professional help. The cost of a consultant reviewing your data is a fraction of what an audit finding for unlicensed software would cost. We have seen organizations try to fix their ILMT data themselves before an audit and make it worse by deleting data or reconfiguring bundling rules incorrectly.
If your ILMT has been neglected for six months or more, a professional review is almost always faster than troubleshooting piece by piece. An experienced consultant can assess the entire environment in a few days and produce a prioritized remediation plan. Doing the same thing internally, without the pattern recognition that comes from seeing dozens of ILMT environments, typically takes weeks.
IBM ILMT Support Resources
Here are the key resources you should bookmark if you manage an ILMT environment.
IBM ILMT Documentation is the official product documentation hosted on IBM's Knowledge Center. It covers installation, configuration, troubleshooting, and report interpretation. The documentation is detailed but can be hard to navigate. Start with the troubleshooting section when you have a specific problem.
IBM Fix Central is where you download ILMT patches, updates, and catalog files. Bookmark this page because you will need it every time you update the software catalog or apply a maintenance release.
BigFix Forum is the most active community resource for BigFix and ILMT questions. It used to live under IBM's community umbrella and now runs under HCL since the 2019 divestiture. The archive is continuous, old threads are still there, and the same ILMT engineers still answer questions.
ILMT Release Notes are published with each new version and interim fix. Always read these before upgrading. They document new features, bug fixes, known issues, and changes to calculation methodology that could affect your reports.
IBM PVU Table lists the PVU values for every processor model that IBM recognizes. This table is updated when new processor models are released. If ILMT is showing unexpected PVU values for a new server model, check whether the PVU table in your ILMT installation is current.
Need Ongoing ILMT Support?
Our Managed ILMT Services cover agent monitoring, catalog updates, quarterly reporting, and issue resolution. You focus on your business while we keep ILMT healthy.
Ask About Managed ServicesPreventing ILMT Problems Before They Start
Most ILMT problems we see are preventable. They happen because nobody is actively maintaining the system. ILMT is one of those tools that works quietly in the background until it does not, and by then you have months of accumulated issues to untangle.
Here is a practical prevention checklist.
Monthly: Agent health check. Review the BigFix console for agents that have not reported in the last 7 days. Set up an automated alert if your BigFix version supports it. Fix non-reporting agents immediately rather than letting the list grow. This single habit prevents the most common ILMT problem.
Quarterly: Software catalog update. Download and apply the latest catalog from IBM. Verify the import completed without errors. Review any new "unknown" entries that appeared after the update and investigate them. A current catalog means accurate product identification.
Quarterly: Report review. Generate an Audit Snapshot and review it for anomalies. Look for unexpected PVU spikes, products showing 0 PVU, servers with no data, and any entries showing "unknown" virtualization. Catching these issues quarterly means you only ever have three months of data to investigate, not three years.
Ongoing: Document your ILMT configuration. Record the vCenter connections, HMC configurations, custom bundling rules, and any non-default settings in your ILMT environment. When the person who originally configured ILMT leaves the company (and they will), this documentation is the difference between a smooth handover and starting from scratch.
Before any upgrade: Test in non-production first. If you have a test ILMT environment, upgrade it first and verify that reports look correct before touching production. If you do not have a test environment, at minimum generate a full Audit Snapshot before the upgrade so you have a baseline to compare against afterward.