What is Oracle Universal Installer (OUI) evidence?

This article describes how the FlexNet Inventory Agent gathers evidence of packages that have been installed using Oracle Universal Installer (OUI) technology, and how you can locate source OUI data to review the information.

How the FlexNet Inventory Agent gathers Oracle Universal Installer (OUI) evidence

Locating OUI evidence

Oracle Universal Installer technology records details of software components it has installed using files with the following names:

comps.xml
oraInst.loc
inventory.xml

The ndtrack inventory gathering process in the FlexNet Inventory Agent scans the filesystem for files with these names and retrieves relevant information from them. This information is included in inventory and may be recognized by installer evidence rules in the Application Recognition Library (ARL) for recognizing application installations.

comps.xml files

Files named comps.xml are the primary files where OUI data that is gathered in inventory data is found.

These files contain COMP elements elements listing installed software components. These elements include attributes and child elements:

EXT_NAME element - used as the Name property for installer evidence
VER attribute - used as the Version property for installer evidence
INST_LOC attribute, which identifies the nominal installation directory (often with an appended extra package ID value) of the component.
INSTALL_TIME attribute, which identifies the installation date of the component.

Installer evidence details included in inventory based on OUI data always have a hard-coded publisher value of "Oracle Corporation".

Example component COMP information from a comps.xml file

<COMP NAME="oracle.server" VER="11.2.0.1.0" BUILD_NUMBER="0" REP_VER="0.0.0.0.0" RELEASE="Production" INV_LOC="Components/oracle.server/11.2.0.1.0/1/" LANGS="en" XML_INV_LOC="Components21/oracle.server/11.2.0.1.0/" ACT_INST_VER="11.2.0.1.0" DEINST_VER="11.2.0.0.0" INSTALL_TIME="2011.Jun.02 20:39:31 EST" INST_LOC="/u/oracle/app/oracle/product/11.2.0/dbhome_1/oracle.server">
  <EXT_NAME>Oracle Database 11g</EXT_NAME>
  <DESC>Installs an optional preconfigured starter database, product options, management tools, networking services, utilities, and basic client software for an Oracle Database server. This option also supports Automatic Storage Management database configuration.</DESC>
  <DESCID>COMPONENT_DESC</DESCID>
  <STG_INFO OSP_VER="10.2.0.0.0"/>
</COMP>

Package details in an inventory .ndi file generated from the above example would look like the following:

<Package Name="Oracle Database 11g" Evidence="OUI" Version="11.2.0.1.0" InstallDate="20250602T203931">
  <Property Name="InstallLocation" Value="/u/oracle/app/oracle/product/11.2.0/dbhome_1/oracle.server"/>
  <Property Name="Publisher" Value="Oracle Corporation"/>
</Package>

Installation directories that does not exist

Sometimes comps.xml files are not updated when other files related to a software component are removed. When this occurs, the component may be recognized as installed based on the OUI data even though no files related to the component remain on the device.

FlexNet Inventory Agent versions 2021 R1 (17.0) and later only return evidence from comps.xml files where the directory specified in the INST_LOC attribute exists.

Note: Oracle Universal Installer often (but not always) adds another directory name that does not exist to the end of the path specified by the INST_LOC attribute in comps.xml files. For this reason, the last name in the INST_LOC path is ignored when perform the directory existence check.

For example: a comps.xml file will commonly include details like the following for an installation of the oracle.server package in the path /u/oracle/app/oracle/product/11.2.0/dbhome_1:
<COMP NAME="oracle.server" [...] INST_LOC="/u/oracle/app/oracle/product/11.2.0/dbhome_1/oracle.server">
The "oracle.server" name at the end of the path is ignored, so the package is considered installed and evidence returned in gathered inventory as long as the /u/oracle/app/oracle/product/11.2.0/dbhome_1 directory exists on the filesystem.

Agent versions prior to 2021 R1 (17.0) return all evidence as specified in the comps.xml file, regardless of whether referenced installation directories actually exist.

oraInst.loc files

The oraInst.loc files contains an inventory_loc entry which identifies an "inventory location" directory.

A ContentsXML/inventory.xml file is expected to appear under this directory.

Example inventory_loc location from an oraInst.loc file

inventory_loc=/u/oracle/app/oraInventory
inst_group=oinstall

In this example, the following file would be expected to appear on the filesystem: /u/oracle/app/oraInventory/ContentsXML/inventory.xml

inventory.xml files

The inventory.xml file contains HOME elements that contain a LOC attribute that identifies a directory under which comps.xml files may be found.

A inventory/ContentsXML/comps.xml file may appear under this directory.

Each home directory includes an inventory/ContentsXML/comps.xml file.

Example inventory.xml file

<HOME_LIST>
  <HOME NAME="OraDb11g_home1" LOC="/u/oracle/app/oracle/product/11.2.0/dbhome_1" TYPE="O" IDX="1"/>
</HOME_LIST>

In this example, the following file may exist: /u/oracle/app/oracle/product/11.2.0/dbhome_1/inventory/ContentsXML/comps.xml

Note that the inventory gathering process performed by the FlexNet Inventory Agent will gather details from any comps.xml files that are found on the filesystem. These files do not need to be in a location identified by the oraInst.loc and inventory.xml files to be considered. Information about these files is just noted here for reference.

Identifying where OUI evidence has been found on a device

When the FlexNet Inventory Agent's inventory gathering process finds a comps.xml file on the filesystem, details of the path are included in the tracker.log log file generated by the process.

Typical default tracker.log file locations are:

Devices running Windows operating systems: C:\Windows\ManageSoft\tracker.log
Devices running Unix-like operating systems: /var/opt/managesoft/log/tracker.log

Messages like the following in the tracker.log show path details:

[2018/04/15 01:24:20 AM (G, 0)] {2940} The file 'C:\oracle\inventory\ContentsXML\comps.xml' has been detected as a possible package registry

Review the contents of each comps.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 comps.xml files and search for particular details in them:

find / -name comps.xml -print0 | xargs -0 grep -H 'Oracle Database 11g'

Additional diagnostics

Additional diagnostic tracing information from the inventory gathering process can be obtained by enabling the +Inventory/Packaging/OracleUniversalInstaller agent trace flag 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 which comps.xml file contains which OUI evidence. For example:

2026-09-28T17:49:34, pid 34124, thread 33560 (Inventory/Packaging/OracleUniversalInstaller): Parsing OUI comps.xml file: 'C:\oracle\inventory\ContentsXML\comps.xml'
[...]
2026-09-28T17:49:34, pid 34124, thread 33560 (Inventory/Packaging/OracleUniversalInstaller): OUI package: name 'Java Development Kit', version '1.6.0.75.0' does not exist in location 'D:\oracle\product\12.1.0\dbhome_1\jdk', package path 'D:\oracle\product\12.1.0\dbhome_1' or the location is empty, skipping.

Ignoring Application Recognition Library (ARL) rules for recognizing unwanted OUI evidence

Generally OUI evidence information about installed components contained within comps.xml files is assumed to be trustworthy. However, some OUI 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 comps.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 comps.xml files appropriately.