Agent Third-Party Deployment: Normal Operation

FlexNet Manager Suite 2022 R1 (On-Premises)

This topic assumes that deployment and installation is complete (for those details, see Agent Third-Party Deployment: Implementation and its subtopics), and describes operations thereafter (to help you decide whether to proceed with this particular case). It describes the operation of FlexNet inventory agent once you have used your preferred third-party tool to deploy it into locations within your computer estate where each installation can access one or more inventory beacons, and function normally (labeled the Agent third-party deployment case for short). These computer devices are to become "inventory devices" within FlexNet Manager Suite.

The operating procedures for the full FlexNet inventory agent deployed in this way are consistent across Microsoft Windows and UNIX-like systems, with some obvious distinctions in system dependencies like file paths. The entire process is covered, including what happens to the collected data after it is uploaded by the FlexNet inventory agent. Each numbered step provides a summary point, followed by further specific details that you can skip over until needed.

  1. Normally only once (probably even before deploying FlexNet inventory agent, although you can certainly change it later if required), you set the schedule for operations of the FlexNet inventory agent in the web interface of FlexNet Manager Suite (navigate to Discovery & Inventory > Settings, in the Inventory agent schedule section).
    This schedule is automatically downloaded to all inventory beacons for delivery to installed FlexNet inventory agents on your inventory devices.
    Tip: Inventory operations of the installed FlexNet inventory agent in the Agent third-party deployment case are never controlled by inventory rules created in the web interface. This includes the schedules that form part of rules, which have no effect on inventory gathering by the installed FlexNet inventory agent (which is a state-based device, self-managing to align with its policy). It is for this reason that the schedule for on-going inventory operations in the Agent third-party deployment case are set as described above, rather than as part of discovery and inventory rules.
  2. Components of the FlexNet inventory agent are triggered by a long-running process (ndinit on Windows, and ndtask on UNIX-like platforms). The process is restarted automatically after a machine reboot.
    For more information about the services on UNIX-like platforms, see Agent Third-Party Deployment: Services on UNIX. For full architectural details of the FlexNet inventory agent, see Agent Architecture.
  3. Immediately upon first installation, each FlexNet inventory agent asks its bootstrap inventory beacon for its initial policy. Thereafter at a random time once every 12 hours, it checks for policy updates.
    The bootstrap inventory beacon is the one you identified in the bootstrap configuration file (mgssetup.ini for Windows devices or mgsft_rollout_response for UNIX-like systems). Once the initial policy is successfully downloaded, the installed FlexNet inventory agent has a complete list of all existing inventory beacons, and makes future policy update requests to the most appropriate one (by default, this is one in the same Active Directory site with the fastest ping response time at each upload time; but if these conditions cannot be met, it may be a random choice). Any inventory beacon will respond to a query from any installed FlexNet inventory agent (and calculate and provide a policy file for it), provided that the system is not in migration mode. Migration mode is set in the web interface for FlexNet Manager Suite (navigate to Discovery & Inventory > Settings > Beacon settings > Migration mode: Restrict inventory settings to targeted devices).
    (For details of the policy file, see Policy Files (.npl).) The FlexNet inventory agent downloads and checks the package files that are linked in the downloaded policy. The package files are very small and quick to download and process, and each identifies the version of its related content file. If the FlexNet inventory agent determines that no content files have changed since they were last collected, no further downloads take place at this time. If anything has changed, the changed content is downloaded and the appropriate settings on the inventory device are updated. These potential downloads include any change to the operational schedule for inventory collection.
  4. If usage tracking is in policy for this device, the usage component monitors the running processes on the system, recording the number of times, and for how long, each process is run.
    This component does not have any noticeable impact on system performance. (Each application being tracked adds about 250 bytes of compressed data to the upload packages.) It looks up the OS-standard installation data (such as MSI on Windows, RPM on Linux, and so on) to associate a process with the installation evidence and file paths. Technically, the usage component mgsusageag is a daemon on UNIX-like systems, and on Windows it's a plug-in to mgssecsvc.exe, which starts as a Windows service at system start-up (for further details, refer back to Agent Architecture). After the results are uploaded, usage can be reported only against applications for which there is an independent installation record. (Usage results are not used to create an installation record, since the application may have been removed within the time window where usage is tracked.)
  5. Apart from usage tracking, the FlexNet inventory agent sits dormant on the target inventory device until the scheduled time for inventory collection.
    The scheduled to-do list is managed by the ndtask component (this is a cross-platform component matching the functionality of mstask). When a schedule trigger fires, ndtask runs ndschedag (passing it a GUID for the required action), and for inventory collection ndschedag runs the ndtrack component. Notice that ndschedag provides its own logging in scheduler.log, in the following default directories (there are several LogFile preferences that can override these default locations):

    Windows platforms


    UNIX-like platforms

  6. The ndtrack executable by default runs at low priority to collect software and hardware inventory details on the local device.
    This means that higher priority tasks are not interrupted, so that there is minimal impact on system performance. Inventory details are saved in an .ndi file on the local file system on the inventory device, by default:

    Windows platforms

    $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Tracker\Inventories

    UNIX-like platforms

    This location may be altered with the MachineInventoryDirectory preference. 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, in a separate directory:

    Windows platforms

    $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Common\Uploads\Inventories

    UNIX-like platforms

    If the FlexNet inventory agent has uncovered any Oracle services running on the local device (and, for UNIX-like target devices, only when the FlexNet inventory agent is running as root), a second .ndi.gz file of Oracle inventory is also generated, and saved in the same directory (an uncompressed version is not saved). As well, the Oracle discovery is reported in an uncompressed .disco file, saved in the Discovery directory (a peer of the Inventories directory in the uploads set). Since the behavior of the installed FlexNet inventory agent is not controlled by inventory rules set in the web interface, this Oracle discovery and inventory does not rely on those rules, and will occur even when no rules for Oracle inventory collection exist, provided that:
    • InventorySettings.xml is available to the FlexNet inventory agent (in the folder identified in the InventorySettingsPath preference setting, which defaults on Windows to $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Tracker\InventorySettings\ and on UNIX-like platforms to /var/opt/managesoft/tracker/inventorysettings — if either the preference or the file is missing, Oracle inventory is skipped)
    • For UNIX-like target devices, the FlexNet inventory agent is running as root (for the installed FlexNet inventory agent, all Oracle discovery and database inventory gathering are blocked for any non-root account).
    Tip: A system trace on the UNIX version of ndtrack shows that it reads /etc/passwd. The UNIX ndtrack uses the setpwent() and getpwent() library calls to obtain the pw_name, pw_dir and pw_shell properties for each user. In particular, ntrack uses the pw_dir property (each user's home directory) to find user-based installation evidence for BEA and InstallAnywhere installation technologies.
  7. After collecting the hardware and software inventory, ndtrack immediately attempts to transfer the compressed inventory file(s) to an inventory beacon.

    The upload is a background process that does not take priority away from other current tasks running on the inventory device. The destination for the upload is ManageSoftRL (a web service on the inventory beacon), which on free-standing inventory beacons saves the .ndi.gz file(s) to the folder %CommonAppData%\Flexera Software\Incoming\Inventories on the inventory beacon.

    Tip: If the inventory beacon is co-located on your central application server (or in large-scale systems, the batch server), the ManageSoftRL web service does not save to disk, but instead saves directly to the database as described in step 9.
    (The upload functionality is shared between the ndtrack and ndupload components. Because the upload here is attempted as part of inventory collection, upload logging for this event is in the ndtrack or tracker logs, in the path given in step #task_wwh_42l_y5__d39e181.)
    • If the initial upload is unsuccessful for any reason, there is a catch-up task on the inventory device that triggers a retry of the upload. (If there are no files awaiting upload at catch-up time, this process shuts down immediately.)
      • Timing: The catchup schedule is internal (downloaded to the FlexNet inventory agent in the .nds schedule referenced in policy), and cannot be modified in any user interface. The task is called Upload Client Files and occurs once daily within a one hour window, the start time for which is randomized by the inventory beacon when it regenerates the schedule file after each update of beacon policy (that is, after each change to rules or schedules in the web interface for FlexNet Manager Suite). If the inventory device is turned off at the time, there is also a catch-up on machine restart.
      • Logging: For this catch-up, the upload uses the ndupload component, so that logging for the catchup attempt is in the ndupload logs.
    • Once the upload is successful (either originally or in catch-up), the copy of each compressed inventory file in the ...\Uploads\Inventories folder on the inventory device is deleted (meaning that the absence of files after the upload is a sign of success, and the continued presence of files after upload attempts is a sign of failure, with stale .ndi.gz files overwritten at the next inventory collection). After success, the process continues below.
  8. 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.
  9. 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).
  10. 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).

FlexNet Manager Suite (On-Premises)

2022 R1