Core deployment: Normal Operation

FlexNet Manager Suite 2020 R1 (On-Premises)

For details about deployment and configuration of the FlexNet inventory core components, see Core deployment: Implementation. To help you decide whether to proceed with that process, this topic describes the resulting operation in some detail, assuming that you have deployed the FlexNet inventory core components into locations within your Windows computer estate where each installation can access one or more inventory beacons, and function normally. Furthermore, you have configured a Microsoft scheduled task to invoke the tracker component (ndtrack.exe) on each inventory device, setting the appropriate command line parameters.

The entire process is covered, including what happens to the collected data after it uploaded by the FlexNet inventory core components. Each numbered step provides a summary point, followed by further specific details that you can skip over until needed.

Tip: Inventory operations of the installed FlexNet inventory core components in the Core deployment case are never controlled by inventory rules created in the web interface of FlexNet Manager Suite. The results of those settings are distributed through policy, and the FlexNet inventory core components do not include any mechanism for requesting, downloading, or applying policy. To have the target inventory device managed through settings in the web interface, switch instead to either of the Adopted case or the Agent third-party deployment case.

1. The FlexNet inventory core components sit dormant on the target inventory device until your custom scheduled task triggers the ndtrack.exe component to collect inventory.
2. In accordance with the command-line parameters included in the invocation, the tracker collects the hardware and software inventory from its local device.
   By default, the tracker runs at low priority so that higher priority tasks are not interrupted, and there is minimal impact on system performance. Inventory details are saved in two ways:

   • An.ndi file is saved (by default) in $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Tracker\Inventories. This directory preserves the local copy of the inventory file (where you can inspect its contents) until it is over-written at the next inventory collection by the same account (since inventory file naming reflects the account running the inventory collection).
   • At the same time, a compressed (.ndi.gz) copy of the file is also saved, ready for upload, by default in $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Common\Uploads\Inventories. (If this file is subsequently uploaded successfully, it is removed; but if there is a failure it remains in this directory until over-written at the next inventory collection by the same account.)
3. If the tracker has been configured for Oracle inventory (because you also deployed the InventorySettings.xml file), and has uncovered any Oracle services running on the local device, and the tracker is running as root, additional files are created:
   • A second .ndi.gz file of Oracle inventory is also generated, and saved in $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Common\Uploads\Inventories (an uncompressed version is not saved).
   • As well, the Oracle discovery is reported in an uncompressed .disco file, saved in the $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Common\Uploads\Discovery directory.

   Note: On UNIX-like platforms, Oracle discovery and inventory gathering is only possible when the tracker (ndtrack executable) is running as root.
4. After collecting the hardware and software inventory, ndtrack immediately attempts to transfer the compressed inventory file(s) to an inventory beacon.
   • The inventory beacon is the one identified in the command-line parameters when the tracker was invoked (either of the UploadLocation or UploadSettings options may have been used).
   • If the upload succeeds, the compressed inventory files are removed from $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Common\Uploads\Inventories.
   • Results are logged to $(TempDirectory)\ManageSoft\tracker.log by default (although there are other command line options that can modify this).
   • The upload is a background process that does not take priority away from other current tasks running on the inventory device.
   • If the initial upload is unsuccessful for any reason, there is no attempt at a catch-up upload overnight (that functionality requires the full FlexNet inventory agent). Either you may script a catch-up, or the compressed files are left in place, and are overwritten at the next inventory collection trigger using the same account name.
5. FlexNet Beacon (the code entity on the inventory beacon) uploads the inventory data to its parent on a schedule set by the Microsoft Scheduled Task Upload FlexNet logs and inventories (by default, repeating every minute throughout the day).
   The checking cycle when the folder is empty is very quick and does not perceptibly load the inventory beacon, even though it is frequently repeated. The parent of an inventory beacon may be the central application server, or another inventory beacon if these have been arranged in a hierarchy. In the latter case, each inventory beacon in turn repeats the upload process until the data reaches the application server.
6. On the application server (or, in a scaled-up system with separate servers, the inventory server), the web service ManageSoftRL receives the uploaded packages for both inventory and (if configured) usage tracking (and other uploaded files).
   These are processed immediately, being loaded into the internal operations databases: inventory (.ndi) and usage (.mmi) files are loaded into the inventory database; any Oracle discovery (.disco) file is loaded into the compliance database. If the service gets overloaded, it will temporarily spool incoming files to its local %CommonAppData%\Flexera Software\Incoming\Inventories directory (or the peer Discovery folder for any Oracle discovery file). From these folders, file import is resumed under the control of Microsoft scheduled tasks (for example, Import inventories, which is triggered every 10 minutes).
7. On the next inventory import and license consumption calculation, the inventory and usage data is collected from the inventory database, socialized as necessary, and imported into the compliance database. Here it is used in license calculations, and made available in management views and reports.
   This import step can be triggered in one of three ways:

   • Normally, the batch scheduler triggers an import daily (by default, at 2am local time on your application server), with the license consumption calculation triggered thereafter. This default time is configurable by editing the Microsoft scheduled task Inventory import and license reconcile on your application server (or, in larger implementations, batch server).
   • An operator in the Administrator role can choose to import the waiting inventory and trigger license consumption calculation, or reconciliation, as soon as possible (navigate to License Compliance > Reconcile).
   • For testing, a knowledgeable system administrator could use a command line on your application server (or, in a scaled-up system, your batch server) like:

     BatchProcessTask.exe run InventoryImport

     (for details, see the Server Scheduling chapter in the FlexNet Manager Suite System Reference PDF).