Agent Architecture

IT Asset Management (Cloud)
This architectural diagram and the following notes give more insight into the interactions between the various components of the complete FlexNet Inventory Agent. In the diagram:
  • Each box with a heavier outline represents one of the code components of the FlexNet Inventory Agent, combining a heading about purpose with the name of an executable. The numbers refer to the corresponding notes below the diagram.
  • Fine red arrows indicate the process of invocation: the component where the arrow starts invokes the component where the arrow ends.
  • The various file types created by components are identified by their file name extensions on the Microsoft Windows platform.
  • Green arrows indicate which components are responsible for uploading the files produced; but see also the notes, as methods vary.
  • Where there are variations between Microsoft Windows and UNIX-like platforms, the diagram favors the Windows presentation, and differences are explained in the notes below.


  1. The ndinit component exists only on Windows. It is automatically initialized as a service on machine reboot, and is responsible for starting ndtask and, on reconnection to the network, ndsens.
  2. The ndtask component is functionally identical with mstask (part of the Microsoft Task Scheduler), but is available across platforms. On UNIX-like platforms, it runs as a service. It functions rather like a to-do list, but does not start tasks directly. Instead, it invokes the ndschedag component to trigger tasks when required.
  3. The schedule component (ndschedag) has two main functions:
    • When handed a new schedule and invoked by flxconfig, ndschedag unpacks the contents of the schedule file (see Schedule Files (.nds)) and saves the details in separate task files (.nts) for use by ndtask. It then sends an IPC message to ndtask to process the updated task list.
    • When a specified task is triggered, ndschedag is always invoked (most often by ndtask, and occasionally on Windows by ndsens), and then coordinates execution of the appropriate components (in particular, inventory gathering, policy updates, and data uploads).
  4. The ndsens component (available only on Windows) is invoked only when the network connection is reestablished for the device on which the FlexNet Inventory Agent is running. When, after a disconnection, the device reconnects to the network, ndsens next invokes ndschedag to check for any scheduled events with an OnConnect trigger type (these are normally the Update Machine Policy, Update Client Settings, and Upload Client Files events). There is no equivalent functionality for the FlexNet Inventory Agent installed on UNIX-like machines.
  5. All inventory gathering and discovery work on the local device is the responsibility of the tracker, or ndtrack. Once triggered by ndschedag, this collects inventory data in .ndi files, and discovery data in .disco files. Depending on configuration, compressed archives of .ndi files are produced, and archives of .disco files may also be produced. By default (in the case of the full FlexNet Inventory Agent), the tracker also tries an immediate upload of gathered data files to the ManageSoftRL file share on its chosen inventory beacon. If configuration or some transient networking problem prevents this upload, the files are saved on the local file system, where they are subsequently picked up by the ndupload component. The tracker also invokes other components of the FlexNet Inventory Agent, such as getSystemId on Windows and a supplied version of dmidecode on certain legacy Linux platforms. For more information about operating system elements that are also invoked by the tracker, see the platform-specific listings under Common: Child Processes Invoked by the Tracker.
  6. The agent configuration component (flxconfig) manages obtaining agent configuration settings from a beacon that control the overall FlexNet Inventory Agent. This component replaces both mgspolicy and ndlaunch from previous agent versions. The agent configuration component is responsible for the following:
    • Agent configuration settings for inventory, usage, upload, configuration.
    • The list of failover beacons to which the FlexNet Inventory Agent may upload or download data ('available' inventory beacons are generally those with IIS configured for anonymous authentication).
    • The current version of InventorySettings.xml.
    • The agent schedule, which is either of:
      • The default global schedule set for all installed agents in the web interface of IT Asset Management.
      • The special schedule used for the FlexNet Inventory Agent on devices linked to IBM PVU licenses, when IT Asset Management is configured for 30-minute inventory updates and sub-capacity license calculations (as an alternative to ILMT).
    • Agent upgrade packages that support self-upgrade of the FlexNet Inventory Agent.
      • On Unix platforms, the agent now also includes a new component, flxupgrade, that is responsible for installing the upgrade obtained by flxconfig. This allows for self-upgrade for least privilege agent configurations. (To support self-upgrade for least privilege agents, flxupgrade must be added to the local sudoers file. If self-upgrade functionality is not used, this change is unnecessary.)
  7. The upload component (ndupload) is responsible for most uploads from the local device to its chosen inventory beacon, using the same ManageSoftRL file share mentioned above. (When, instead, the tracker uploads discovery and inventory results, it is using a shared library of common code from ndupload, so that the upload functionality is identical. This integration supports uploads in other configuration of the tracker, such as in the Core deployment case and the Zero-footprint case, when the separate ndupload component is not available.) The uploader may be invoked directly by other components to upload files handed off through the command line; or it may be invoked by the scheduler to look in defined folders on the local device and upload all files present there. In this way, ndupload provides a scheduled catch-up service to upload files which the tracker failed to upload, and saved on disk instead. (And it also follows that the absence of the separate ndupload component in the Core deployment and Zero-footprint cases means that there can be no catch-up uploads after a transient failure of uploads by the tracker.)
  8. Another service that runs exclusively on Microsoft Windows is mgssecsvc (there is no equivalent on UNIX-like platforms). Like ndinit, it is automatically initialized as a service on machine reboot. It exists solely as a wrapper for its child processes (which are implemented as DLLs on Windows, and so are running whenever the service is running).
  9. The component that monitors application usage (when you have usage tracking configured) is mgsusageag, which is a library exercised by mgssecsvc on Windows. On UNIX-like platforms, mgsusageag is a service in its own right. Because of the ephemeral nature of usage data, mgsusageag invokes the uploader any time it has usage data (an .mmi file) to upload. This means that application usage data is uploaded asynchronously with relation to the upload schedule saved on the local device.

IT Asset Management (Cloud)

Current