Collecting Inventory from Instances

FlexNet Manager Suite (Cloud)

The connector to Microsoft Azure gathers useful information, but it cannot gather information valuable for license consumption calculations from each of the instances running in your Azure 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 Microsoft Azure managed VM image from which your devices are instantiated. For details, see the Azure documentation Create a managed image of a generalized VM in Azure for Windows, or for Linux see How to create an image of a virtual machine or VHD.

Unique device naming is critical

It is critical to your license management in Microsoft Azure 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.

By default, the internal name of a virtual machine is the same as the external name given to it when it is created. While you can change the internal name of a virtual machine, you cannot change the external name of the virtual machine as displayed in the Azure portal.

Resource names for virtual machines are immutable. So, if you need to change names, you need to redeploy your virtual machine. You can do this by deleting the current virtual machine, while maintaining the current virtual machine disks, and then creating a new virtual machine using the correct name and point it to the previously maintained disks.

To ensure a device name for each instance that is unique over time, methods vary across platforms. In summary:

  • The easiest method on Windows is to use Sysprep when creating your managed VM image, 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:
  • 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 managed VM image)
  • Provide a back-up schedule of daily inventory collection.
  • 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 managed VM image (and later, updating it as required). For more guidance on customizing instances, see Configuring an Azure VM Image for 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 Azure 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 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 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.
  • 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.
Choosing between these alternative places for your inventory beacon 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, 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 Microsoft Azure 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 Azure cloud to your central application server in your datacenter, consider a hardware VPN connection as well (see the Microsoft Azure documentation for details).
Keep in mind that an inventory beacon does not normally initiate ('push') communication to FlexNet inventory agents installed on your Microsoft Azure 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. You do not need to known 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 SCCM), an inventory device record
  • For every cloud instance appearing in data from the Azure PowerShell 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 dedicated hosts identified through the Azure PowerShell 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, Microsoft Azure keeps the terminated instance visible through the API for about an hour, and if you have implemented your Azure PowerShell connector on an inventory beacon with the default 30 minute schedule, the termination is imported through the 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 Azure console, identify this managed VM image, and inspect its software load and resulting license impacts.

Data integration

Inventory from a hosted instance may come from multiple sources, and must be integrated correctly. Various rules are used depending on the sources being combined:
  • PowerShell connector + current FlexNet inventory agent are linked by:
    • CloudServiceProviderID (displayed as the Cloud service provider name in the web interface)
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 PowerShell 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 (Cloud)

Current