Perhaps the most important aspect of fully utilizing IBM’s ILMT (or Big Fix Inventory) tool is to be able to accurately create bundling relationships. For those that are unfamiliar, bundling is the process where users confirm the specific IBM Product that each discovered software instance relates to. In a generic sense, each confirmed bundling creates a record in the database that specifically identifies which purchased license is used to cover each discovered software instance.
Sometimes, however, a software signature is discovered, that is identified in some way as “inappropriate” – as bundling it to a product would falsely increase the amount of licensing required to cover that product.
Reasons for this inappropriateness are varied, and new scenarios can be identified at any time.
Some examples include:
• Products that have already been uninstalled – but certain registry or XML signatures continue to scan
• Components of an IBM product that are used and licensed by third party software developers as part of one of their products (e.g., Cognos, DB2, etc.)
• Components that are discovered on servers that are used exclusively as code repository file systems
• Components that are misidentified or in some other way disputed – where an IBM Service Request ticket has been submitted and addressed with no effective remediation recommendations provided.
• Certain cases where software installations are in place as Disaster Recovery backup*
In these and similar cases, something needs to be done to avoid potential over counting; and there are 2 options available: Exclusion and Suppression.
The function of Exclusion allows the software instance to continue to scan – and show up on reporting, but as a No Charge instance. Suppression on the other hand, effectively removes the instance from being considered for bundling or other tool analytic functions. So, the question really is: which process to use?
Regardless, it is up to the ILMT/BFI tool user to control the implementation of these options – to avoid inappropriately undercounting their software.
To do this, I suggest the following Best Practice rules for use:
1) Use these options only as a last resort. If signature files continue to scan – after uninstallation, investigate and remove them manually (if possible). If you have code repositories – confirm that the software versions are still current – if not, then uninstallation is preferred.
2) Only use the Suppression functionality for the limited case where the discovered signature is truly a “False Positive” – Otherwise, stick to Exclusions.
3) For both functions, you can enter a comment to explain the reason why these actions were taken. Do this for every exclusion or suppression, but do so in the following manner:
a) Identify who executed the Exclusion/Suppression and the Date when it was invoked
b) Briefly state a reason – and include the IBM service request ticket number if appropriate.
c) If you were able to research online, any “evidence” for your conclusion that the instance should not be counted – include a URL link to that information as well.
d) Keep a list of any reasons that will “pop up” again in the future, so you can reuse the same text for future Exclusions/Suppressions
e) Take advantage of the “rules definitions” functionality if appropriate
For Example:
By creating a policy for the use of these functions in a uniform manner, users will maintain control over their ILMT/BFI data and reporting. Also, note that both functionalities can be reversed – in case they were applied in error.
The Exclusion and Suppression functionality in ILMT and BFI are there to make your reporting and bundling as accurate as possible, but if used haphazardly or inappropriately, they can be a source of confusion, risk and error. If you keep these well controlled, they are valuable functions that will serve you well.
* See IBM documentation for complete rules regarding Backup licensing
If you’d like to learn more about bundling best practices contact us!