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.
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.)
-
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.)
-
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).
-
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