Common: Identifying Related Inventory

FlexNet Manager Suite 2021 R1 (On-Premises)
This topic applies to all forms of gathered inventory:
  • All forms of FlexNet inventory gathering, including all the cases covered in this document
  • Inventory imported from third-party tools, such as Microsoft SCCM, IBM ILMT, and others.
Before gathered data sets can be merged into distinct inventory records, the group (or set) of imported records that relate to a single device must be identified. This topic gives considerable detail about the process of matching records into sets that relate to a single device.

The process of grouping incoming inventory records into matched sets, such that each set relates to a single unique device, is controlled by an XML file (from which the examples below are taken). The process is:

  1. All incoming inventory records held in the staging tables are copied into memory for faster processing.
  2. An ordered list of assessments (called "Matchers") is applied to the incoming inventory records. Each Matcher is applied in turn:
    1. A Matcher preselects only those records that fit a list of conditions. Whenever a list of multiple conditions is present, every condition in the list must be matched.

      (Strictly speaking, conditions are an optional part of a Matcher, but they are ubiquitous. If ever there were no conditions, the subsequent tests in the Matcher would be applied to every inventory record currently left in the memory array.)

      Each Condition specifies an inventory Property, a testing Method, and one or more values used as the test cases. Those records that meet all the conditions in the list are used for further processing in this Matcher, while other records not meeting the current list of conditions are left aside for later reconsideration in other Matchers. In short, the list of conditions filters down the set of incoming inventory records to be assessed in the current Matcher.

      For example:
      <Condition Property="ComputerType" Method="InRange" Value="Computer, VMHost"/>
      This condition admits only computers and VM hosts for possible matching, and excludes VMs, remote devices, mobile devices, and VDI templates.
    2. The Matcher then tests the preselected processing candidates using a list of one or more rules. Every rule in the Matcher's list must be satisfied.
      Each Rule specifies that a named inventory Property must match across inventory records, using a defined matching Method (the methods include equal, not equal, like, set, and not set, with the default being equal). Pairs (or sets) of devices that pass all the rules are considered matched, and those that fail any rule in the list are set aside for later reconsideration in other Matchers.
      For example:
      <Rule Property="Manufacturer"/>
      <Rule Property="ModelNo"/>
      <Rule Property="FirmwareSerialNumber"/>
      This list of rules means that when each of these properties in turn has a common value across candidate records (because "equal" is the default when no Method is specified), inventory records from the preselected processing candidates are considered "matched", so that they refer to a single device.
    3. Any group of records that have been matched by this Matcher are now known to refer to a single device. They are removed from the testing pool, and are not subjected to any further assessment by other Matchers. Each matched group (or set) is queued up for import into the compliance database.
  3. After all Matchers have been processed in turn, the unmatched records left in the testing pool are known to be individual records each applying to a unique device, and these are now similarly queued for import into the compliance database.
  4. The queue of matched sets (including the sets with just a single member) are now tested for matching against the existing records in the compliance database. The exact same tests used to bunch up the incoming inventory records are now applied to align the matched sets with existing records.
    • If any Matcher in the XML file finds that an incoming set is matched to an existing record, that existing record is updated with values from the incoming set. The constraints about Primary source and latest inventory date are used to select which of the incoming set of records is used to update each property (see Common: Acting on Inventory Results).
    • If all Matchers fail to connect an incoming set with an existing record, a new inventory device record is created. Once again, properties are taken first from the Primary inventory source with gaps filled from secondary inventory sources; and competition is resolved by using the most recent inventory if there are multiples from the same priority source(s).
The tests used to match sets of inventory records to individual devices are listed in the following table. The Matchers run in order from top to bottom in this table. In each case, every Condition must be satisfied before an inventory record is included in an individual assessment; and then every Rule must be satisfied before two (or more) records are taken as matched, applying to a single device. Both Conditions and Rules assess Properties from (firstly) the incoming inventory records, which in the database have been staged in the appropriate staging tables:
  • ImportedComputer table
  • ImportedVirtualMachine table.
Thereafter, the incoming matched sets are compared against existing compliance records using the same set of Matchers. The database schema is described in the FlexNet Manager Suite Schema Reference PDF.
Table 1. Matchers
Candidates (Conditions) Assessment (Rules)

1. Matcher for physical computer with manufacturer, model and firmware serial number

  • VMType is not set
  • Manufacturer is set
  • ModelNo is set
  • FirmwareSerialNumber is set
Records have identical values for each of:
  • Manufacturer
  • ModelNo
  • FirmwareSerialNumber

2. Matcher for physical computer with manufacturer, host type and firmware serial number

  • VMType is not set
  • Manufacturer is set
  • HostType is set
  • FirmwareSerialNumber is set
Records have identical values for each of:
  • Manufacturer
  • HostType
  • FirmwareSerialNumber

3. Matcher for physical computer with machine ID

  • VMType is not set
  • MachineID is set
Records have identical:
  • MachineID

4. Matcher for physical computer with manufacturer, host ID and computer name

  • VMType is not set
  • Manufacturer is set
  • HostID is set
  • FirmwareSerialNumber is set
Records have identical values for each of:
  • Manufacturer
  • HostID
  • FirmwareSerialNumber

5. Matcher for vPar, LPAR and Zone with Partition ID

  • VMType is one of vPar, LPAR, or Zone
  • PartitionID is set
Records have identical values for each of:
  • VMType
  • PartitionID

6. Matcher for LPAR with firmware serial number and partition number

  • VMType is LPAR
  • FirmwareSerialNumber is set
  • PartitionNumber is set
Records have identical values for each of:
  • FirmwareSerialNumber
  • PartitionNumber

7. Matcher for LPAR with Machine ID and partition number

  • VMType is LPAR
  • MachineID is set
  • PartitionNumber is set
Records have identical values for each of:
  • MachineID
  • PartitionNumber

8. Matcher for vPar, nPar and LPAR with machine ID and partition name

  • VMType is one of vPar, LPAR, or Zone
  • VMName is set
  • MachineID is set
Records have identical values for each of:
  • MachineID
  • VMType
  • VMName

9. Matcher for vPar, nPar, LPAR and Zone with partition name and firmware serial number

  • VMType is one of vPar, nPar, LPAR, or Zone
  • FirmwareSerialNumber is set
  • VMName is set
Records have identical values for each of:
  • FirmwareSerialNumber
  • VMType
  • VMName

10. Matcher for Zones with host ID and partition name

  • VMType is Zone
  • HostID is set
  • VMName is set
Records have identical values for each of:
  • HostID
  • VMName

11. Matcher for computers using HostIdentifyingNumber, HostType and Manufacturer

  • HostIdentifyingNumber is set
  • HostType is set
  • Manufacturer is set
Records have identical values for each of:
  • HostIdentifyingNumber
  • HostType
  • Manufacturer

12. Matcher for computers using HostIdentifyingNumber and HostType when Manufacturer not provided

  • HostIdentifyingNumber is set
  • HostType is set
  • Manufacturer is null in either or both of the records being compared
Records have identical values for each of:
  • HostIdentifyingNumber
  • HostType

13. Matcher for computers using HostIdentifyingNumber and Manufacturer when HostType not provided

  • HostIdentifyingNumber is set
  • HostType is null in either or both of the records being compared
  • Manufacturer is set
Records have identical values for each of:
  • HostIdentifyingNumber
  • Manufacturer

14. Matcher for computers using HostIdentifyingNumber when HostType and Manufacturer are not provided

  • HostIdentifyingNumber is set
  • HostType is null in either or both of the records being compared
  • Manufacturer is null in either or both of the records being compared
Records have identical values for:
  • HostIdentifyingNumber

15. Matcher for VMware ESX Servers via UUID

  • OperatingSystem contains vmware (see note 1)
  • UUID is set
Records have identical values for:
  • UUID (see note 2)

16. Matcher for computers using the serial number and computer name

  • UntrustedSerialNo is false
  • SerialNo is set
  • ComputerName is set
Records have identical values for each of:
  • SerialNo
  • ComputerName

17. Matcher for computers using the agent ID which IBM ILMT uses for tracking operating environments

  • ILMTAgentID is set
Records have identical values for:
  • ILMTAgentID

18. Matcher for incomplete computers using computer name and domain details

  • The ObjectType is Incomplete (see note 3)
  • ComputerName is set
  • ComplianceDomainID is set
Records have identical values for each of:
  • ComputerName
  • ComplianceDomainID

19. Matcher for incomplete computers using computer name where no domain is available

  • The ObjectType is Incomplete (see note 3)
  • ComputerName is set
  • ComplianceDomainID is null in either or both of the records being compared
Records have identical values for:
  • ComputerName

20. Matcher for unmatched computers without hardware details using computer name and domain details

  • The ObjectType is Unmatched (see note 3)
  • ComputerName is set
  • ComplianceDomainID is set
Records have identical values for each of:
  • ComputerName
  • ComplianceDomainID

21. Matcher for unmatched computers using computer name where no domain is available

  • The ObjectType is Unmatched (see note 3)
  • ComputerName is set
  • ComplianceDomainID is null in either or both of the records being compared
Records have identical values for:
  • ComputerName
Note:
  1. For Condition checks, the method "contains" tests whether the value of the property under test includes the test string in any position.
  2. In this case, the test method is BigOrLittleEndianEqual. This means that the two compared values are normalized for byte order before the comparison for equality.
  3. Here, ObjectType is an intermediate value calculated during import and not saved to the compliance database. It may be Complete (default), Incomplete, or Unmatched.
Tip: The XML file of Matchers is located on your batch server (or, in smaller implementations, on whichever server hosts this functionality, such as your processing server or your single application server), in %ProgramData%\Flexera Software\Compliance\ImportProcedures\Inventory\Matcher\Computer.xml. Do not edit this file, as any changes may be over-written in the next product upgrade.
While you should not edit the factory-supplied Computer.xmlfile, there is a supported method to integrate a custom Matcher into the process described above. To customize a Matcher:
  1. Create your own Computer.xml file with the root Matchers element:
    <?xml version="1.0" encoding="utf-8"?>
    <Matchers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    
    </Matchers>
  2. In the gap, insert your custom Matcher element, modeled on the factory-supplied ones in the standard (unchanged) file.
  3. Set the Order attribute of your Matcher so that it will fall in the correct place between the standard Matchers. For example, if you wish to override the current Matcher with Order="30", set your Order="25" so that your custom Matcher runs first, "stealing" the candidates it needs and removing matched sets from the pool before the standard Order="30" Matcher runs. (You do not need to remove the standard Matcher, since if it has no suitable candidates to match, it runs with no net effect, and little impact on performance.) The standard Matchers are ordered with numbering gaps that accommodate 'insertions' like this.
  4. Save your file separately in %ProgramData%\Flexera Software\Compliance\ImportProcedures\CustomInventory\Matcher\Computer.xml.
Both the standard Computer.xml file and your customized one are read from their separate locations, their Matchers are merged into a single ordered list, and executed in the process as described above.

FlexNet Manager Suite (On-Premises)

2021 R1