What is IBM Installation Manager (IIM) evidence?

This article describes how the FlexNet Inventory Agent gathers evidence of packages installed using IBM Installation Manager (IIM) technology.

IBM Installation Manager is an installation technology developed by IBM. Details of software packages installed by IBM Installation Manager are recorded in specific files that the FlexNet Inventory Agent looks for and gathers data from. This evidence is imported and appears in Flexera One IT Asset Management or FlexNet Manager Suite as installer evidence with a type of "IIM". This data may be matched by installer evidence recognition rules in the Application Recognition Library to recognize installations of associated applications.

How the FlexNet Inventory Agent gathers IBM Installation Manager (IIM) evidence

Files with the following specific names that are found on the filesystem during the inventory gathering process are treated as potentially containing data related to packages installed by IBM Installation Manager technologies:

InstallationManager.dat
config.ini
installed.xml

Additional operating system-specific checks are also performed to pick up additional files that may fall outside the scope of scanned directories:

Windows operating systems:
- The registry entry HKLM\Software\WOW6432Node\IBM\Installation Manager\appDataLocation is read to identify a directory.
- Any installed.xml file in that directory is added to the investigation list.
UNIX-like operating systems:
- The file /etc/.ibm/registry/InstallationManager.dat, which is the standard data location, is searched.
- The user home’s /etc/.ibm/registry/InstallationManager.dat subdirectory is also checked if present.
- Any discovered InstallationManager.dat files are analyzed to locate config.ini files.
- config.ini files are then scanned for references to installed.xml files.

How are software details recorded?

IBM Installation Manager installed.xml files contain details about software packages that are installed on the device. Details are stored in an XML structure similar to the following abbreviated example:

<location id='IBM Tivoli Storage Manager' kind='product' path='C:\Program Files\Tivoli\TSM'>
  <property name='user.license,com.tivoli.dsm.server' value='tsm'/>
  <package kind='offering' name='IBM Tivoli Storage Manager device driver' id='com.tivoli.dsm.devices' [...]>
    <property name='cic.info.version' value='7.1.1.20141123_0819'/>
    <property name='vendor.name' value='IBM'/>
[...]

Package details extracted by the FlexNet Inventory Agent for inclusion in the gathered inventory data include:

Name is taken from package/@name
Version is taken from package/property[@name='cic.info.version']/@value
Publisher is taken from package/property[@name='vendor.name']/@value

These details are used to create an IIM package record in the inventory NDI file generated by the inventory gathering process. For example, the details from the sample installed.xml file illustrated above result in the following information being recorded in the inventory NDI file:

<Package Name="IBM Tivoli Storage Manager device driver" Evidence="IIM" Version="7.1.1.20141123_0819">
	<Property Name="InstallLocation" Value="C:\Program Files\Tivoli\TSM"/>
	<Property Name="Publisher" Value="IBM"/>
</Package>

Identifying where IIM evidence has come from on a device

When the FlexNet Inventory Agent's inventory gathering process finds an installed.xml file on the filesystem during a filesystem scan, details of the path are noted in the tracker.log log file with messages similar to the following:

[2026-03-07T12:09:32+1100 (G, 0)] {42568} Scanning directory 'C:\' for files
[2026-03-07T12:09:32+1100 (G, 0)] {42568} The file 'C:\Path\installed.xml' has been detected as a possible package registry
[2026-03-07T12:09:32+1100 (G, 0)] {42568} Finished tracking files

Note: No logging of this nature is generated showing details of installed.xml files found based on path details obtained from well-known locations, such as through the ...\Installation Manager\appDataLocation registry entry on Windows, or details found in InstallationManager.dat files.

Review the contents of each installed.xml file listed in the logging to identify which specific file(s) contain evidence of interest.

On devices running Unix-like operating systems, a command like the following can also be used to find installed.xml files and search for particular details in them:

find / -name installed.xml -print0 | xargs -0 grep -H 'IBM Tivioli Storage Manager device driver'

Additional diagnostics

Additional diagnostic tracing information from the inventory gathering process can be obtained by enabling the +Inventory/FileSystemScanListener and +Inventory/Tracker/Package agent trace flags in the etcp.trace file. Instructions on how to do this are located here: How to enable FlexNet Manager Suite diagnostic tracing.

This style of diagnostic tracing can help to identify exactly where installed.xml files have been found (including files that were not found through a filesystem scan, and so were not referenced in the tracker.log file), and what package details have been retrieved. For example:

2026-03-07T17:45:43, pid 40184, thread 34304 (Inventory/FileSystemScanListener/General): CFileSystemScanListener - listener "IM" listing file "C:\Path\installed.xml" as REG_SYSTEM.
2026-03-07T17:45:43, pid 40184, thread 34304 (Inventory/FileSystemScanListener/General): CFileSystemScanListener - listener "IM" listing file "C:\Path\installed.xml".
2026-03-07T17:45:43, pid 40184, thread 34304 (Inventory/Tracker/Package): Package tracked: IBM Tivoli Storage Manager device drivers

What if details are incorrect?

Generally IIM evidence information about installed components contained within installed.xml files is assumed to be trustworthy. However, some IIM evidence may be an unreliable indicator of what is currently installed on computers, especially in environments where software components have been removed simply by deleting files from a filesystem without also taking appropriate action to remove details of the components from installed.xml files.

If this is found to be a consistent problem for particular evidence, the relevant installer evidence rule in the ARL can be marked as Ignored. This will prevent the rules from being used to recognize installations on any devices. Note that this may also result in legitimate installations associated with that evidence failing to be recognized, so apply this technique with caution. In general, it is better to implement processes to cleanly uninstall software components in a way that updates details in installed.xml files appropriately.