Collecting Inventory from Instances

FlexNet Manager Suite 2022 R2 (On-Premises)
The Amazon connector gathers useful information, but it cannot gather information valuable for license consumption calculations from each of the instances running in your AWS cloud. To gather useful inventory from all instances, best practice is to include the FlexNet inventory agent (release 13.2.buildNumber or later) in the Amazon Machine Image (AMI) from which your devices are instantiated. For details, see the AWS documentation, Create a Standard Amazon Machine Image Using Sysprep for Windows, or for Linux Creating an Amazon EBS-Backed Linux AMI. For additional guidance about the kinds of customizations your AMI may need (depending on the life expectancy of instances to be launched from the image), see either:

Unique device naming is critical

It is critical to your license management in AWS to ensure that each instance is uniquely named on instantiation. If you do not do this, incoming inventory reports are not differentiated, and are interpreted as updated inventory from a single device, named with the default device name provided by the base image.

One easy way that appears to give each instance a unique name different from its AMI is through the AWS Ec2 Launch Settings dialog, by selecting the Set Computer Name check box (or setting the Boolean in the LaunchConfig.json file). However, be aware that, since this name is of the form ip-hexInternalIP, the name may not be unique over time, particularly if you have short-life instances. If an internal IP address is dropped when a first instance is shut down, and reused for another instance that is instantiated later, then these different instances are overlaid in the FlexNet inventory database as being updates to the same device (having the same name). However, when the inventory records are then imported over time into the compliance database, they are differentiated by their different instance IDs, producing separate (duplicate) device records with the same device name. Therefore, the following topics provide another way to get a truly unique name for each device reported in inventory; and recommended best practice is to always leave the Set Computer Name check box clear. At the very least, use this convenient AWS method for naming instances only when you deem the risk of duplicate device records in FlexNet Manager Suite to be low enough to ignore (or you are prepared to manually fix any duplicate inventory device records that do occur).

To ensure a device name for each instance that is unique over time, methods vary across platforms, and are detailed in following topics. In summary:

  • The easiest method on Windows is to use Sysprep when creating your AMI, leaving the name unset so that a new name is provided on instantiation.
  • For Linux, if you already provide for unique Hostname values on all your instances, no further action is required; and otherwise, a little extra preparation can ensure that the unique InstanceID for each instance is also returned in inventory as the MachineID, where it differentiates all returned inventory as coming from devices with distinct names.

Schedule specialization

Scheduling inventory collection by the locally-installed FlexNet inventory agent requires that you take either of two different approaches, based the 'life expectancy' of each instance:
  • Short-lived, on-demand instances may not have a long enough life cycle for default FlexNet inventory processes to come to full operation. For these short-lived instances, consider a customized default schedule and configuration file in the AMI that will:
    • Provide an upload location (ManageSoftRL) for inventory collection
    • Omit any download location, since the instance life-cycle is projected to be too short to require any policy update or system-wide schedule update
    • Trigger inventory collection on start-up, followed immediately by inventory upload to the defined ManageSoftRL (this cycle might typically require 3-5 minutes all up, a figure which may change based on other customizations you may want to include in your AMI)
    • Provide a back-up schedule of daily inventory collection, covering off the possibility that, unexpectedly, this instance now needs to run for a longer period.
    Keep in mind, as well, that removing the normal paths for policy update also removes the normal updates to InventorySettings.xml, which includes a range of advanced capabilities for FlexNet inventory agent, including Oracle inventory collection and advanced inventory techniques for Microsoft and other vendors. Your strategy therefore includes embedding your most recently downloaded InventorySettings.xml in your AMI (and later, updating it as required). For more guidance on customizing short-lived instances, see Configuring an AMI for Short-Lived Instances.
  • Instances with longer life spans can be managed exactly as you manage third-party installations on other inventory devices (particularly virtual machines) within your enterprise. These instances do not require a custom schedule, since they can share the same schedule for local inventory collection that applies throughout your enterprise. You do still need to consider customizations built into the AMI for these instances, such as providing a bootstrap inventory beacon with upload and download locations, as well as giving the instance its unique device name. For more details, see Configuring an AMI for Longer-Life Instances.

Planning your inventory beacons

The final major question is the location of your inventory beacon(s) for uploading inventory data from these instances. Depending on the reliability of network communications between your cloud-based instances and your own enterprise network, you may choose either:
  • To run (at least) one instance within your AWS cloud as an inventory beacon, ready 24/7 for any of your instances in the cloud to upload their inventory. This is especially valuable for short-lived instances, where the locally-installed FlexNet inventory agent has no opportunity to retry uploads around any network failures; and where fast network speeds may best support your planned short life-cycle for these instances. The cloud-based inventory beacon can then provide a more rugged upload to your enterprise network, since it has longer up-time and built-in mechanisms for retrying any uploads that are interrupted by transient networking issues. As always, this inventory beacon must have Internet access so that it can connect to the central application server for FlexNet Manager Suite to upload collected inventories and download changed policies. This approach also enables running the Amazon connector without having to create an IAM User.
  • Run an inventory beacon within your enterprise network (or even, potentially, in a demilitarized zone outside your firewall), to which all the cloud-based instances have network access, allowing them to upload their inventory files as and when needed. This approach may be most helpful for direct inventory of Oracle Database in Amazon RDS, since it allows the inventory beacon to be 'steered' to the appropriate AWS region, limiting its inventory collection and uploads in a way similar to managing subnets in your local network. If you have a large number of Oracle Databases spread across various Amazon RDS regions, or a large number of EC2 instances to upload from, consider installing multiple inventory beacons and 'filtering' each one appropriately.
Choosing between these alternative places for your inventory beacon(s) may require balancing questions of security and performance against cost. Whichever choice you make, a good practice is to use a DNS alias to identify the inventory beacon(s) , so that you can quickly and easily make changes without disrupting the rest of your infrastructure.
Tip: As for all communication between your enterprise network and the AWS network, an Amazon Virtual Private Cloud (VPC) is required for either of the above architectures; and if you require a link from your inventory beacon in the AWS cloud to your central application server in your datacenter, consider a hardware VPN connection as well (see the AWS documentation for details).
Keep in mind that an inventory beacon does not normally initiate ('push') communication to FlexNet inventory agents installed on your AWS instances. (The only exceptions are for the 'remote execution' tasks known as adoption and zero footprint inventory collection, neither of which you expect to use in a cloud environment.) Since all other communications are initiated by the FlexNet inventory agent ('pull' communications, such as policy updates, collection of self-update packages, and the upload of inventory), this means that your implementation only needs to point the FlexNet inventory agent on each instance to its bootstrap inventory beacon (as described in following topics). You do not need to know details like the IP addresses (public or private) for the instances reporting inventory through the FlexNet inventory agent.

Inventory records and exceptions

After a full inventory import and license reconciliation, you can expect to see records created/updated in FlexNet Manager Suite as follows:
  • For every instance where the locally-installed FlexNet inventory agent has uploaded inventory, an inventory device record
  • Similarly, for every instance reporting inventory through a third-party tool, such as Microsoft Endpoint Configuration Manager (previously Microsoft SCCM), an inventory device record
  • For every cloud instance appearing in EC2 data from the Amazon connector, regardless of whether it appears in uploaded inventory or not, a cloud instance record in the CloudServiceInstance table (and of those, the ones that also have an inventory device record show a link to it in the Cloud Service Provider Inventory page)
  • For every installation of Oracle Database in Amazon RDS, a linked pair of discovered device and inventory device records
  • For dedicated hosts identified through the Amazon connector (and only dedicated hosts, not any other kind of host), an inventory device record for the host.
You will not find inventory device records for any of the following:
  • A cloud instance that does not report inventory
  • A host device that is anything other than a dedicate host (such as a default host, or a host for dedicated instances)
  • Any instance that you have terminated.
Terminated instances are a special case.
  1. Before termination, the running instance may have had an inventory device record (provided that it was reporting inventory).
  2. When you terminate the instance, AWS keeps the terminated instance visible through the API for about an hour, and if you have implemented your Amazon connector on an inventory beacon with the default 30 minute schedule, the termination is imported through the Amazon connector, and the record in the CloudServiceInstance table is updated with the terminated status. (This record, with its terminated status, is visible in the Cloud Service Provider Inventory page, if you set the filters on that page appropriately.)
  3. At the next full inventory import (by default, overnight, immediately before the license compliance calculations), any inventory device record linked to a terminated instance is deleted, because you do not want terminated instances consuming from your licenses.
  4. Of course, the terminated instance no longer reports inventory; but its previously-recorded inventory is still in the inventory database (and in normal processes is not cleaned up for a while). Although the next full import (typically the next night) normally imports records from the inventory database, for terminated instances this is prevented by the terminated flag in the CloudServiceInstance table. This prevents the deleted inventory device record from reappearing.
Should you ever need to review the software previously installed on a terminated instance, you can:
  1. Navigate to Discovery & Inventory > Cloud Service Provider Inventory.
  2. Change the default filter (top left) for Include terminated instances to Yes.
  3. Optionally, filter the Last known state column to show only Terminated.
  4. Optionally, use other filters, such as Instances reported in an appropriate period, or the Instance type and Instance region columns, to narrow your search for this instance.
  5. Check the Image ID column to identify the original image from which this instance was launched (you may need to drag this column out of the column chooser).
  6. Through your AWS console, identify this AMI, and inspect its software load and resulting license impacts.

Data integration

Inventory from a hosted EC2 instance may come from multiple sources, and must be integrated correctly. Various rules are used depending on the sources being combined:
  • Amazon connector + current FlexNet inventory agent are linked by:
    • CloudServiceProviderID (displayed as the Cloud service provider name in the web interface)
    • Instance ID
  • Amazon connector + other inventory sources (such as legacy versions of FlexNet inventory agent, or third-party inventory tools, neither of which provides the instance ID) are linked by:
    • MAC address (provided that the MAC address is unique in the unmatched inventory and cloud data).
Matching of the incoming data with existing inventory device records (that is, determining whether this is an update to an existing record, or a new record) uses the standard device matching rules, with the Cloud service provider and Instance ID checked as last priority.
Finally, the merging of data between the Amazon connector and the current FlexNet inventory agent uses these priorities:
  1. If one source contains a data point that the other does not, the data is used.
  2. If both sources contain the same data point but with different values, the data with the most recent inventory date is used.
  3. If different values were imported on the same day, the FlexNet inventory agent is given priority if it has been set as the primary inventory source.
  4. Otherwise, the data is used from the most recently created inventory source, with the winning source visible in the inventory device properties as Last inventory source.

FlexNet Manager Suite (On-Premises)

2022 R2