What Can Be Used for FlexNet Inventory Collection

FlexNet Manager Suite 2020 R1 (On-Premises)
There are two distinct code entities available for the collection of inventory (both software and hardware inventory) by FlexNet Manager Suite within your enterprise:
  • The complete, most powerful, backward-compatible entity is called the FlexNet inventory agent. Whenever this name is used within this document, it always means the complete agent. The complete FlexNet inventory agent is the entity that is deployed automatically by FlexNet Manager Suite onto target inventory devices, if you choose to allow it. Its purposes are:
    • To take inventory of both the hardware and software on a computing device, and return an XML document (.ndi) describing this inventory
    • By default, to return additional files for extended discovery and inventory tasks, such as taking inventory of any Oracle Database discovered on the local computer
    • To optionally track usage of applications on the same device, based on watching specified files that form part of the application.
  • The smaller footprint option, with reduced functionality that covers inventory collection most simply, is called FlexNet inventory core components. Although this includes the same core executable (ndtrack) as the complete FlexNet inventory agent, we consistently use this distinct name, FlexNet inventory core components, to help clarify the reduced set of functionality and differences in deployment and management. Its sole purpose is:
    • To take inventory of both the hardware and software on a computing device, and return an XML document (.ndi) describing this inventory.
      Tip: If you are deploying the FlexNet inventory core components yourself, it is possible to deploy an additional special-purpose file to add the extended discovery and inventory tasks mentioned above; but this is not included by default.
This clear distinction between the two distinct code entities is fundamental.
Tip: For those looking for the lightweight FlexNet Inventory Scanner, this is not a separate code entity, but an easy method of delivering the FlexNet inventory core components and cleaning them up when "our work here is done". More detail follows in later topics.
Already we can see that, alone, the distinction between code entities is not enough to fully define the functionality set, since operational contexts also make a difference. For example, the FlexNet inventory core components are included as a standard element with each FlexNet inventory beacon.
  • On one hand, this explains why inventory collection managed by the inventory beacon (remote from the target device) cannot collect application usage information, in contrast to the FlexNet inventory agent which (locally installed on the target device, with additional monitoring capabilities) can track usage. The distinction explains the missing functionality.
  • On the other hand, the FlexNet inventory core components achieve more when operating on an inventory beacon than they do if you deploy them to another file share. This is because the inventory beacon provides additional code (installed as part of FlexNet Beacon) and integration services available only in this context.

As another example, as noted above, the FlexNet inventory core components can be delivered as the FlexNet Inventory Scanner.

Therefore, a full understanding of available functionality (and management needs) requires both knowledge of the different code entities, and knowledge of contexts. The question of contexts and delivery methods is discussed shortly, in Deployment Overview: Where to, and How. But first, some more insight into the differences between these two basic code entities.

A note about 'agents'

The word "agent" can be used with different scope. For example, the FlexNet inventory agent is a scope that includes several executables performing different functions. For example, one of these is ndupload, which is also colloquially called the "upload agent". Both the large scope and the small scope of the word "agent" fit the general definition of a software "agent": a software program that runs on a computer to collect information and transfer it to a central location. However, for clarity, this document reserves the word "agent" for the larger scope of the entire FlexNet inventory agent, referring to the smaller elements as either "elements", "components", or as individual "executables".

In every case, whether invoked as part of the FlexNet inventory agent or through the FlexNet inventory core components, the executable ndtrack (amongst others) runs in the context (memory) of the target inventory device. For this reason, this document does not describe use of any of these approaches as "agentless". Some people like to use this term to mean that nothing is permanently installed on the target device, and indeed there are deployment scenarios available that avoid such a permanent footprint. But the relevant code elements still execute in the context of the target machine. (Some other kinds of specialized inventory collection by FlexNet Manager Suite are truly agentless, in the sense that no 'agent' code element executes in the target context. Examples include an inventory beacon executing remote discovery and inventory for Oracle, Oracle VM, and VMware, which make use of services already available on the target machines. In these cases, execution is in the context of the inventory beacon, using the API offered by the installed software.)

Differences

Here are the key differences between the FlexNet inventory agent and the FlexNet inventory core components, using the Windows platform as our example (UNIX-like platforms support equivalent functionality).
Function FlexNet inventory agent FlexNet inventory core components
Included executables*
Tip: The full FlexNet inventory agent includes several components present for backward compatibility, so that the latest FlexNet inventory agent can function in earlier implementations during migration, for example.
Each case (FlexNet inventory agent and FlexNet inventory core components) also includes additional configuration files and libraries, here omitted for clarity.
  • ndtrack.exe
  • getSystemId.exe
  • mgspolicy.exe
  • mgssecsvc.exe (and its plug-ins mgsusageag and vdiendpoint)
  • ndinit.exe
  • ndlaunch.exe
  • ndschedag.exe
  • ndsens.exe
  • ndtask.exe
  • ndupload.exe
  • getSystemId.exe
  • UsageTechnicianTool.exe
Still included, but now deprecated:
  • mgsdl.exe
  • mgsmsilist.exe
  • mgspostpone.exe
  • reboot.exe
  • ndtrack.exe
  • getSystemId.exe

Inventory types

  • Machine
  • User (Windows only, backward compatibility only)
  • Machine
  • User (Windows command line only, backward compatibility only)

Policy, rules, and settings

Set in the web interface, automatically managed through the inventory beacons, and applied automatically as specified.

None included. Must be either:
  • Manually managed, usually through changing the command lines for scheduled tasks and the like
  • Managed by the FlexNet Beacon code (see Deployment Overview: Where to, and How for further details).

Scheduling (inventory collection)

Built in (follows schedule set in the web interface).

Can be used for high-frequency inventory gathering for IBM PVU licensing.

None. Must be scheduled using external tools (including FlexNet Beacon).

Updates

Self-updating to a version set either in the web interface, or by using a supplied command line tool.

None. Third-party deployments must be managed independently (presumably using the same deployment tools as were used in the initial deployment). (Components installed with FlexNet Beacon are also updated with future self-updates of the inventory beacon.)

Upload behavior (for collected inventory)

On by default

Off by default. To turn on requires:
  • Windows: Custom command line
  • UNIX: Custom command line or setting in ndtrack.ini.
(On an inventory beacon, the FlexNet Beacon manages uploads.)

Usage tracking

Available, subject to configuration.

Not supported.

* The functions of some of the key executables included in the FlexNet inventory agent are as follows:
  • The core component for inventory collection, ndtrack, which can optionally also immediately upload the gathered inventory to an inventory beacon
  • The upload component (ndupload), which retries transfers of the inventory results to an inventory beacon to recover from transient network issues
  • The schedule component (ndschedag) to coordinate execution of the other components
  • The task management component (ndtask), functionally identical with mstask (part of the Microsoft Task Scheduler) but available across platforms
  • The policy component (mgspolicy), responsible for managing the various rules that the control the overall FlexNet inventory agent
  • The installation component (ndlaunch) which downloads policy, schedule, self-update and other packages required for operation
  • The service component (ndinit, available only on Windows) is automatically initialized as a service on machine reboot, and is responsible for starting ndtask. On UNIX-like platforms, ndtask is the service, which is initialized in platform-specific ways after a reboot.
For more details about the relationships between these components, see Agent Architecture.

FlexNet Manager Suite (On-Premises)

2020 R1