FileEvidence
Some applications cannot be recognized by installer package information alone. It is sometimes necessary to examine files that form part of the software installation, for either of two reasons:
- Some files are intended to provide identification details about an application, sometimes in human-readable formats
- Examining executable files installed with the application may help with identification, even though this is not their primary purpose.
Of the first class, identification files may take various forms. For example, many IBM applications are correctly identified by specific files that IBM installs for this purpose. Oracle and Adobe are among other publishers using specific files to identify some applications. Thus the Application Recognition Library (ARL) requires this file information to correctly identify such applications. ISO/IEC 19770-2 SWID tags are also increasingly available, and these ID tags are another useful form of identification file. The BMC Discovery Inventory Agent by default does not capture the complete set of identity files.
Secondly, in addition to gathering those specific files that identify an application (and have no other function in the application), it is sometimes necessary to identify installed executable files that are part of the application. These may be the only way to identify an application, such as a particular edition or version of a product. A standard implementation of BMC Discovery does not track executable files.
With this pattern, the functionality of BMC Discovery is extended to gather identification (tag) files on all platforms, and executable file evidence on Windows platforms. Note that the pattern does not search network shares or NFS mounts; nor does it follow symlinks (because of the risk of self-referencing loops). It also skips any files or folders that are inaccessible. Within these constraints, it provides details of files matching the specification and found within the defined paths on the local file system.
- Tracking Windows executables using BMC Discovery is slow. It may be unacceptably slow to use for a wide range of directories, and you may require very targeted inventory gathering using this facility.
- Tracking executable files can produce a very large data set. Across large Windows server farms, the number of installation records can quickly run even into the millions, which may comprise a stress test for BMC Discovery implementations and concentrators, and (to a slightly lesser extent) for your FlexNet Manager Suite implementation.
Results
The file evidence gathered on Windows servers is somewhat richer than on UNIX-based servers.
- On both platforms, the pattern first collects the target directories from the pattern configuration file (under Flexera.FNMP.InventoryRawData.FileEvidenceConfigs).
- In the specified folders and their subfolders, the pattern retrieves:
- All files with extensions listed under File extensions to report as tag
files (assuming that Report software tag
files has its default value of true). For each matching file found,
BMC Discovery creates a
Detail
node linked to the host record. This happens for both Windows and UNIX-based systems. - On Windows only, and only when the setting for Report executable files on
Windows platforms has been changed to true, files with a
.exe extension from the same paths. For each executable
file found, by default a WMI query is used to retrieve the file’s name, version,
and manufacturer. A
DiscoveredWMI
node in BMC Discovery is created for each WMI query (essentially for each file). However, becauseDiscoveredWMI
nodes are ephemeral (may not survive future inventory gathering), the information is duplicated into aDetail
node under the host server for each file discovered there.
- All files with extensions listed under File extensions to report as tag
files (assuming that Report software tag
files has its default value of true). For each matching file found,
BMC Discovery creates a
By the appropriate means, then, a Detail
node
is created for each file evidence record, with the following properties
dependent on the collection method:
Property | Value | Notes |
---|---|---|
name
|
File path and name | |
type
|
FNMP_FileEvidence
|
|
size
|
File size | |
key
|
A unique key for this file, combining the values of name/type/host.key | |
version
|
The release number of the file | Available only on Windows servers when executables are tracked. |
company
|
The publisher of the application of which this file forms a part | Available only on Windows servers when executables are tracked. |
Configuration
In the FileEvidence
pattern, you may:
- Separately enable or disable collection
of:
- Identity tag files
- Executable files (remember to consider the potential volume of data for this option)
- Identify the file name extensions for tag files (but there is no need to identify executable file name extensions)
- Separately for Windows and UNIX-like hosts, specify the starting point(s) in the file systems for inventory scanning to begin (searches recurse through local subdirectories).
/opt
on
separate partitions. You must specify a search starting point within each target partition
on the file system. For example, the default values of ∕opt
,
∕var
, and ∕usr
are well suited for inventory gathering
with BMC Discovery.All configuration items are covered in the following procedure.
FlexNet Manager Suite (On-Premises)
2022 R1