Table of Contents
Before You Start: Planning Your ILMT Deployment
We have deployed ILMT in environments ranging from 30 endpoints to over 15,000. The single biggest factor that determines whether an installation goes smoothly or turns into a months-long project is planning. Before you download a single installer, you need to understand the size of your environment and what resources ILMT will require.
Start by categorizing your deployment. A small environment is anything under 100 endpoints. Medium covers 100 to 1,000 endpoints. Large means 1,000 or more. These tiers matter because they directly affect your hardware requirements, your BigFix architecture, and how long the project will take.
For a small environment under 100 endpoints, you can run both the BigFix server and the ILMT server on a single machine. Allocate at least 4 GB of RAM, 2 CPU cores, and 80 GB of disk space. This is a reasonable starting point for a proof of concept or for organizations with a limited IBM software footprint.
Medium environments need separate servers. The BigFix server should have at least 8 GB of RAM, 4 CPU cores, and 200 GB of disk space. The ILMT server needs its own machine with 8 GB of RAM, 4 cores, and 100 GB of storage. ILMT uses its own embedded DB2 instance for data storage, and that database grows as your environment and reporting history expand. Do not underestimate disk requirements here. We have seen installations run out of space within six months because someone provisioned based on day-one data volumes rather than projected growth.
Large environments require even more careful planning. You will likely need BigFix relays to distribute agent communication load, especially if you have remote sites or data centers separated by WAN links. A relay is essentially a local distribution point that agents connect to instead of reaching back to the central BigFix server for every request. Without relays, large environments overwhelm the central server and agents start failing to report. Plan one relay per remote site or per 500 to 1,000 agents at a minimum.
Network planning deserves its own attention. BigFix agents communicate with the server (or relay) on TCP port 52311 by default. The ILMT server needs access to the BigFix database, typically over TCP port 50000 for DB2 or 1433 for SQL Server. If your environment spans multiple network zones with firewalls between them, document these flows early and get firewall rules opened before you start installing anything. Firewall issues are the number one cause of stalled deployments we see in the field.
Step 1: Deploy BigFix Server
BigFix is the foundation of any ILMT deployment. Without a functioning BigFix infrastructure, ILMT has nothing to work with. The BigFix server is what collects data from every endpoint in your environment and stores it centrally. ILMT then reads that data to produce its license compliance reports.
One detail many organizations overlook: Passport Advantage customers are entitled to use BigFix Inventory at no additional license cost, specifically for the purpose of sub-capacity reporting. The entitlement is called IBM License Metric Tool. The software you install might be labelled BigFix Inventory (HCL branding) or IBM License Metric Tool (IBM branding) depending on how you obtained it, same codebase, certified as equivalent for sub-capacity. This is not a full BigFix Lifecycle or BigFix Compliance license. You can run the scans, generate the reports, and operate the platform for license metric purposes. If BigFix Inventory does not fit your environment, there are other approved alternatives to ILMT IBM accepts for sub-capacity reporting. Using the same BigFix agents and server for patching, OS hardening, or software distribution requires a separate commercial BigFix license. Mixing the two is a common compliance gap we find during client audits. Download the installer from IBM's Passport Advantage website or IBM Fix Central.
The BigFix server runs on either Windows Server or Red Hat Enterprise Linux. For Windows, supported versions include Windows Server 2019 and 2022 (Windows Server 2016 is still supported on older BigFix releases but has reached the end of Microsoft's mainstream support, we no longer recommend new deployments on it). For Linux, BigFix Platform 10 and 11 support RHEL 8 on x86_64, and you will need IBM DB2 11.5.x as the database backend. Which one to pick depends on what your team already runs well. Windows deployments are still more common in the field because BigFix lived on Windows for years before Linux support arrived. If your organization is Linux-first and has no strong Windows ops bench, the RHEL install is a viable and supported path. The installation wizard differs between the two platforms, but the resulting functionality is the same.
For Windows installations, the database backend can be Microsoft SQL Server or IBM DB2. For new installations, SQL Server Express works for small environments as a starting point, with one warning: it is capped at 10 GB per database. A BigFix deployment with even a few hundred endpoints hits that ceiling inside a year. Medium and large deployments should use SQL Server Standard or Enterprise from day one, or IBM DB2, which BigFix also supports. Rebuilding a BigFix database because SQL Express ran out of room is not an experience anyone wants. The installation wizard guides you through the database configuration, certificate generation, and initial server setup.
During installation, you will create a masthead file that acts as the trust anchor for all BigFix agents. Agents use this masthead to verify they are communicating with a legitimate server. Keep this file safe. You will need it every time you deploy a new agent.
After the server is running, activate the BigFix Inventory site. This site contains the fixlets (automated tasks) that enable software scanning, catalog management, and the data collection that ILMT depends on. Without this site activated, BigFix will manage your endpoints but will not collect the software inventory data that ILMT needs.
Step 2: Roll Out BigFix Agents
This step takes the longest in almost every deployment we have done. The technical installation of the BigFix agent on a single machine is straightforward. Getting it deployed to every server where IBM software runs, across different operating systems, network segments, and organizational boundaries, is where the real effort lives.
BigFix agents are available for the common enterprise platforms: Windows Server, RHEL, SLES, Ubuntu, AIX, and IBM i. Solaris and HP-UX coverage exists for older BigFix versions but has been narrowing, Solaris 10 in particular was removed from the IBM Eligible Virtualization Technology list, so even if the agent runs, the sub-capacity math does not. If you run IBM software on one of these platforms, verify the current support matrix before assuming you have sub-capacity rights. The agent itself is lightweight, typically consuming 50 to 100 MB of RAM and minimal CPU. It runs as a system service and survives reboots automatically.
You have several options for deploying agents at scale. The BigFix Client Deploy Tool is IBM's own solution for remote agent installation. It works well when you have administrator credentials for target machines and network connectivity on port 52311. For Windows environments, Group Policy (GPO) deployment works reliably. Package the agent MSI into a GPO and assign it to the appropriate Organizational Units. If your organization uses SCCM or another software distribution tool, you can push the BigFix agent package through your existing infrastructure.
For Linux and AIX servers, scripted installations are common. A simple SSH-based script that copies the agent package, installs it, configures the server address, and starts the service can deploy agents to dozens of servers in minutes. Include the masthead file in your deployment package so agents can authenticate with the BigFix server on first contact.
Here is the critical point that we cannot emphasize enough: you must deploy agents to every server where IBM software runs. Every single one. This includes production servers, development servers, test environments, staging environments, disaster recovery servers, and any machine where someone might have installed an IBM product. If a server runs IBM software but does not have a BigFix agent, ILMT does not know that server exists. During an audit, an IBM auditor who discovers unmonitored servers running IBM software will treat that as a compliance gap. We have seen organizations that carefully covered their production environment but completely forgot about their development and test labs, which sometimes had more IBM software installed than production.
After deploying agents, verify they are all checking in with the BigFix server. The BigFix console shows agent status, including the last time each agent reported. Any agent that has not reported within 24 hours needs investigation. Common causes include firewall blocks, DNS resolution failures, incorrect server address in the agent configuration, or the agent service not running.
Need Help Planning Your ILMT Deployment?
We have done this hundreds of times across environments of every size. Tell us about your infrastructure and we will help you plan the right architecture. No commitment required.
Get Deployment GuidanceStep 3: Install ILMT Server
With BigFix running and agents reporting, you can now install the ILMT server itself. ILMT under its BigFix Inventory 10/11 branding runs on Linux, currently RHEL 8 and 9, and SLES 15 (RHEL 7 and SLES 12 reached end of mainstream support and you should not use them for new deployments). It is a web-based application that you access through a browser after installation.
ILMT ships with an embedded DB2 instance that it uses for its own data store. This is separate from whatever database your BigFix server uses. The embedded DB2 handles ILMT's configuration data, imported scan results, and report data. You do not need to install or configure DB2 separately. The ILMT installer takes care of it. You will also need a Java Development Kit (JDK) on the ILMT server. IBM's installer includes a bundled JDK, so in most cases this is handled automatically as well.
The installation itself is wizard-driven. You run the installer, accept the license agreement, choose your installation directory, configure the connection to your BigFix server's database, set up the ILMT administrator account, and let the wizard finish. The wizard itself takes under an hour. The part people underestimate is everything around it: provisioning the VM to spec, opening firewall rules to the BigFix database, preparing the OS prerequisites, setting up backup, configuring the initial catalog import, connecting the VM Managers. For a properly planned deployment, budget half a day to a full day between handing over an empty VM and looking at a working ILMT. Significantly less than that usually means something was skipped.
If your business case needs resilience, read up on ILMT high availability and disaster recovery before designing the server layout. ILMT runs as a single instance and the supported patterns (warm standby, virtualization HA) shape what you provision here.
One common mistake we see with medium and large environments: installing the ILMT server on the same machine as the BigFix server. This works for small setups under 100 endpoints. Beyond that, the two applications compete for CPU, memory, and disk I/O. BigFix is constantly receiving data from agents and writing to its database. ILMT periodically runs large data imports that consume significant resources. Running both on the same server leads to slow report generation, import timeouts, and general instability. Give them separate machines.
After installation, log into the ILMT web interface and verify the connection to your BigFix server. ILMT should show the total number of connected endpoints and their reporting status. If the endpoint count does not match what you see in the BigFix console, check the database connection settings and firewall rules between the ILMT server and the BigFix database.
Step 4: Configure Software Catalog and Scans
ILMT identifies IBM software by matching files, registry entries, and other markers on your endpoints against a software catalog that IBM maintains. This catalog contains thousands of signatures for IBM products across all versions and platforms. Without a current catalog, ILMT cannot accurately identify what is installed in your environment.
Your first task after installation is importing the latest software catalog. You can download the catalog from IBM's Fix Central or through the BigFix Inventory site. Import it into ILMT through the web interface. IBM updates the catalog roughly every quarter, sometimes more frequently. Set a reminder to check for catalog updates regularly. An outdated catalog means ILMT may miss newly released IBM products or fail to recognize updated versions of existing ones.
Next, configure your scan schedule. ILMT relies on two types of scans that run through BigFix agents. The software inventory scan identifies what software is installed on each endpoint. The capacity scan captures hardware and virtualization configuration data. Both scans need to run regularly. We recommend scheduling the software inventory scan at least once a week and the capacity scan daily. The scans themselves are lightweight and typically complete within a few minutes per endpoint.
The third critical configuration is the VM Manager connection. This is where ILMT gets its virtualization data. For VMware environments, you need to configure a connection to your vCenter server. ILMT uses this to map virtual machines to physical hosts, which is essential for calculating sub-capacity PVU values. For IBM PowerVM environments, ILMT connects to the Hardware Management Console (HMC). For Microsoft Hyper-V, the BigFix agent on the Hyper-V host collects the necessary data automatically, but you still need to ensure the agent is deployed on every Hyper-V host.
Getting the VM Manager right is critical. If ILMT cannot determine which physical host a VM runs on, it cannot calculate the physical capacity of that host. Without that information, ILMT defaults to full-capacity calculations for the affected VMs. We have seen organizations lose their sub-capacity benefit for entire VMware clusters because the vCenter connection was broken and nobody noticed for months. Test the VM Manager connection after configuration and verify that ILMT shows the correct host-to-VM mappings in its topology view.
Step 5: Generate Your First Reports
Once the initial data import completes (give it at least 24 to 48 hours for agents to run their first scans and for ILMT to import the data), you are ready to generate your first reports. Start with the Audit Snapshot, because that is the report IBM will ask for if you are ever audited.
Run the Audit Snapshot and review it carefully. Your first report will almost certainly have issues. That is completely normal. Here is what you should expect to find and what to do about it.
Missing agents. Some servers that should have BigFix agents will not appear in the report. Cross-reference the ILMT endpoint list against your server inventory. Any server running IBM software that does not show up in ILMT is a gap that needs to be closed. Go back to Step 2 and deploy agents to those machines.
Unknown or uncategorized products. ILMT may detect software installations it cannot map to a specific IBM product. This usually means the software catalog does not have a signature for that particular version, or the installed files do not match any known pattern. Check if a newer catalog version is available. If the software is genuinely not an IBM product, you can exclude it from reports.
Higher PVU counts than expected. Your initial PVU numbers may be higher than you anticipated. This often happens because ILMT is counting products you did not know were installed, or because the VM Manager configuration is incomplete and some VMs are being calculated at full capacity. Investigate each case individually.
Virtualization topology gaps. If ILMT shows VMs without a known host, the VM Manager connection needs attention. These "orphan" VMs will be charged at full-capacity rates in the report. Verify your vCenter, HMC, or Hyper-V host connections.
Do not panic about the initial findings. The first report is a diagnostic tool, not a compliance verdict. Fix the issues you find, wait for the next data import cycle, and generate another report. Each iteration should look cleaner than the last. Most environments reach a stable, accurate state within two to four weeks of active tuning.
Struggling with Your First ILMT Reports?
Interpreting ILMT data after a fresh installation is one of the most common reasons organizations contact us. We can review your initial reports and help you get to a clean baseline.
Request a Report ReviewCommon Installation Mistakes
After years of deploying and inheriting ILMT environments, we have seen the same mistakes over and over. Avoiding these will save you significant time and frustration.
Using the Wrong DB2 Version
ILMT is specific about which DB2 versions it supports. Installing an unsupported version leads to obscure errors during setup or, worse, silent data corruption that only surfaces months later. Always check the ILMT system requirements document for the exact DB2 version matrix before you start. If you are using the embedded DB2 that ships with the ILMT installer, this is handled for you. Problems arise when organizations try to use an existing DB2 instance that happens to be a different version.
Insufficient Disk Space for Scan Data
Scan data accumulates over time. Every software inventory scan and capacity scan produces data that BigFix stores and ILMT imports. For a medium environment running weekly scans, expect the BigFix database to grow by several gigabytes per month. The ILMT database grows as well, especially if you retain historical data for long reporting periods. We recommend provisioning at least twice the initial disk allocation and setting up monitoring alerts at 70% utilization. Running out of disk space on the BigFix or ILMT server is one of the fastest ways to create gaps in your compliance data.
Relays Not Configured for Remote Sites
If you have servers in multiple data centers or network zones connected by WAN links, you need BigFix relays. Without relays, every agent communicates directly with the central BigFix server. This works fine on a local network. Over a WAN connection, it leads to slow agent check-ins, failed scan uploads, and significant bandwidth consumption. A single relay at each remote site solves all of these problems. Install the relay on a Windows or Linux server at the remote site, point local agents to it, and the relay handles all communication with the central server.
Forgetting VM Manager Configuration
We see this in nearly half the inherited environments we review. The BigFix server is running, agents are deployed, ILMT is generating reports, but the VM Manager connection was never configured or stopped working at some point. The result: every VM in the affected virtualization cluster shows up at full-capacity PVU values. The ILMT admin may not even notice because the reports still look "complete." They just show much higher PVU consumption than necessary. Always verify the VM Manager connection as part of your post-installation checks, and monitor it on an ongoing basis.
Skipping Dev and Test Environments
Development and test servers are just as relevant for IBM license compliance as production servers. If a developer installed DB2 or WebSphere on a test VM, that installation consumes PVUs. IBM's licensing terms do not distinguish between production and non-production use unless you hold a specific non-production license. Deploy BigFix agents to every server in every environment. We have seen audit findings where the majority of the compliance gap came from unmonitored dev and test servers, not from production at all.
Assuming BigFix Agents Cover Everything
Some machines cannot host a BigFix agent. IBM i LPARs, locked-down appliances, legacy platforms that lost agent support, VMs in segregated networks where no inbound BigFix communication is allowed. We have seen organizations leave these machines out of ILMT entirely because "ILMT cannot see them." That is a compliance gap waiting to become an audit finding.
The correct answer is the disconnected scanner. ILMT ships with a scanner package you deploy locally on these machines (through SSH, scripted install, or whatever mechanism fits the platform). The scanner produces a signed results file. You transfer the file to the ILMT server on a schedule and ILMT imports it alongside the BigFix data. It is more manual than the standard flow and requires operational discipline to keep current, but it keeps the compliance picture complete. Plan for it during the deployment rather than discovering it during an audit.