Top 10 Gotchas When Licensing IBM Software and SaaS and how to avoid them

Top 10 Gotchas when licensing IBM Software and how to avoid them


IBM licensing for both cloud and on-premises can be complex and mistakes costly.   What follows are 10 of the most common IBM licensing “gotchas” I’ve encounter over the many license compliance projects I’ve done.  I’ve included recommendations to pre-empt or reduce the impact.

By sharing these common licensing mistakes I am hoping you might recognize them if they surface in your organization and do something about it before the become a compliance problem later.

Top 10 IBM Licensing Gotchas

IBM license reviews (audit) are a standard business practice  and all clients should expect one every 3-4 years

#01 Not configuring IBM license metric tool (ILMT*) correctly

Most organizations will take advantage of IBM sub capacity licensing to reduce the number of processors or core they need to license in a virtualized environment.  The default installation of ILMT will always require additional configuration to ensure the reports correctly reflect your license usage.  Product Bundling needs to be implemented.  DR, Standby, decommissioned servers need to be correctly handled.  False positives found, verified and excluded.


This initial  configuration of ILMT should be done by someone expert in IBM licensing, especially  if there are many products or there are a large number of servers.  Ongoing maintenance can then be handed over to a trained ILMT administrator.

#02  Not maintaining IBM license metric tool (ILMT*)

The IBM license metric tool (ILMT), required to measure sup-capacity licensing, is constantly being updated with new versions of ILMT.  To ensure your quarterly reports are correct and will not be challenged in an audit you need to ensure ILMT is upgraded quarterly.  If your version of ILMT falls behind it becomes more complex to upgrade as well as the risk of error in your license reporting.  If it falls too far behind (>1 year) an auditor may decide to report everything at full capacity which is a major financial risk.


Schedule the upgrade of ILMT quarterly in advance with a supporting runbook (steps to follow).  Make it a routine task.

#03  Not resolving ILMT errors in a timely manner.

When collecting deployment details in a complex network you can expect issues to arise.   Agents failing to respond, VM Manager passwords expiring, servers without an agent deployed, etc.   These issues are to be expected and are not a problem when resolved quickly.  The problems arise when they are not resolved and allowed to compound.  The dashboard in ILMT will highlight many of the most common issues and should be monitored weekly/monthly.


A task to review ILMT should be scheduled monthly (automatically created in helpdesk system).  A runbook of ILMT checks should be developed including fixes to most common problems.

#04 Not reviewing quarterly sub-capacity reports in sufficient detail

One of your obligations  when availing of the lower costs of IBM sub capacity licensing is to generate and store quarterly reports from ILMT.  These reports are evidence of your consumption and that ILMT is up to date and correctly configured.

A common error made by organization is they fail to generate and store the reports, also known as an audit snapshot, every quarter.  A more serious mistake is to generate the audit snap shots but to fail to check what the reports are showing.  The audit snapshot is made up of a number of files that need to be carefully reviewed to ensure they are reporting your compliance.  If not, you need to remediate the issues and rerun the report until it’s correct.


Generate the audit snapshot reports every month and review for any issues.  A runbook detailing the steps in reviewing an ILMT audit snapshot will help accelerate this process.

#05 Assuming the license requirements remain the same after upgrading an IBM product

One of the benefits of pay IBM S&S is that you get access to new features and  bug fixes in upgrades to the product.  A product upgrade may have new features but it can also have different entitlements, use rights, supporting programs or components.   A supporting program (bundled product) that was free in one version of the product may not be free in the upgrade.  Product upgrades can also unexpected impact ILMT and your license counts.


Before you upgrade a product make a detailed comparison between the license information for the original product and the new version.  Pay particular attention to the list of supporting programs that are included and excluded from upgrade. Ensure ILMT correctly reflects the usages of the new product after upgrade.

#06 Not considering the impact of upgrading server infrastructure on processor based licensing

The infrastructure on which you deploy IBM products will change over time.  Extra nodes added to a cluster, extra processors added to a node, addition cores assigned to a VM.  Any change to the processors and cores assigned to a virtual machine (VM) will have an impact on IBM processor based licensing (PVU, RVU & vCPU).  This is fine if its an intentional decision by the business but very often the license impact is not considered in pursuit of a technical solution.  The unbudgeted cost can be very significant depending on the change.


The SAM team should be represented on the Change Advisory Board (CAB).  Any changes to server infrastructure should require a review by the person responsible for IBM licensing and indeed the wider SAM team.

#07 Not upgrading the operating systems or underlying infrastructure

One of the requirements for lower cost sub capacity licensing is that the operating systems and virtualization technology is “eligible”.  A list of maintained by IBM of Eligible Virtualization Technology and Operating systems.  This list is updated on a continuous basis. What often gets over looked by organization is that operating systems and virtualization technologies get removed from the list as well as added.  Typically when the vendor announces they no longer supports a technology it gets removed from the IBM list also.


At least once a year check the Eligible Virtualization Technology and Operating systems document to see if any of your operating systems or virtualization technologies have been dropped from support.  If you are aware of servers running old operating system highlight the license risk (significant cost of full capacity licensing)  to the business and look to priorities those servers for upgrade.

#08 Not having ILMT agents on VMs with IBM products deployed (including Public Cloud)

The IT network of most organization is continuously growing.  This is especially true for virtualized environments or where you are using public cloud (Azure, AWS, etc.).  The problems arise when you run IBM software on newly created servers without deploying an ILMT agent to measure license consumption.  This gives a false measure of deployment and when it is discovered during an audit the costs can be a significant.


Periodically reconcile ILMT data with another data source to ensure there are agents on all IBM hosts.  Good sources to compare data against are CMDB, Active Directory, SAM/DevOps tools, ServiceNow or cyber security tools.

#09 Not managing the number of authorized user to an IBM application

Where an IBM product relies on an Authorized User license you are required to manage the users that have access.  Most on-premise applications record but do not restrict the users that can login and use a product.  Where Active Directory security groups have been setup to manage access they still need regular updates


At least annually verify the user counts in the AD security groups are less than your entitlement.  Where available check the application audit logs to be confident you have sufficient licenses for products and modules accessed.

#10 Not providing IBM license training of technical teams

As the proverb goes, “an ounce of prevention is worth a pound of cure” and this is so true when it comes to enterprise license training of the IT administrator.  Training your System  Administrators,  DBAs, IT architects and Developers on IBM licensing fundamentals can be hugely beneficial.  How processors are linked to license , how changes in virtualization configurations impact license demand, the importance of maintaining ILMT, etc.  Not only can it prevent unexpected increase in license demand, very often the technical resources can highlight areas to reduce IBM license demand.


Provide foundation level license training to technical staff on an annual basis.  In particular for administrators who have the ability to make changes to servers and infrastructure.


Now that you are aware of some of the most common IBM licensing gotchas I hope you take action.  The fixes in many cases are relatively easy and the return on investment will be huge for your company.

I’ve shared with you the most common IBM licensing mistakes but there are many more that can arise.  We check for all of these potentially mistakes as part of our IBM License Compliance Review.  Click the link to find out more.

Reference / Other reading

*Note:  ILMT tool has been reference throughout this post.  Your organization may be using BigFix or Flexera as your SAM tool.  The same recommendations apply.