Adopted: Normal Operation

IT Asset Management (Cloud)

The operating procedures for the full FlexNet Inventory Agent deployed automatically through adoption are consistent across Microsoft Windows and UNIX-like systems, with some obvious distinctions in system dependencies like file paths. This topic assumes that adoption is complete (for those details, see Adopted: Implementation), and covers operations thereafter. 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.

Important: Adoption is not currently supported in IPv6 networks. However, after installation, operation of the FlexNet Inventory Agent within an IPv6 network is supported. Therefore, for IPv6 networks, see Agent Third-Party Deployment: Details and its following topics.

1. Normally only once (probably even before adoption, 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 IT Asset Management (go to the Inventory Settings page (Data Collection > IT Assets Inventory Tasks > 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 managed devices.

   Tip: Once discovery and adoption are completed, on-going inventory operations of the installed FlexNet Inventory Agent in the Adopted case are not controlled by inventory rules created in the web interface. This includes the schedules that form part of rules, which have no effect on post-adoption 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 Adopted 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.
3. Immediately upon first installation, and thereafter at a random time once every 12 hours, each FlexNet Inventory Agent asks an inventory beacon for its policy.
   (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	$(TempDirectory)\ManageSoft\
   UNIX-like platforms	/var/opt/managesoft/log

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	/var/opt/managesoft/tracker/inventories

   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	/var/opt/managesoft/uploads/Inventories

   If the FlexNet Inventory Agent has uncovered any Oracle services running on the local device (and, for UNIX-like target devices that have the FlexNet Inventory Agent running in the full privilege default operation mode, 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 saves the .ndi.gz file(s) to the folder %CommonAppData%\Flexera Software\Incoming\Inventories on the inventory beacon.

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

   • 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.)
     • 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.
   Tip: For ongoing operation of the full FlexNet Inventory Agent in the Adopted case, it is not required that the managed device is in a subnet assigned to the inventory beacon. (For the different requirements during discovery and adoption, see Adopted: Implementation.) At installation time, the adopting inventory beacon normally sets itself as the 'bootstrap' inventory beacon for the download of initial policy. Thereafter, the fail-over settings (linked in the downloaded policy) define every available inventory beacon (those with IIS configured for anonymous authentication), and the FlexNet Inventory Agent may contact 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 IT Asset Management (go to the Inventory Settings page (Data Collection > IT Assets Inventory Tasks > Inventory Settings), in the Beacon settings section, configure the Migration mode: Restrict inventory settings to targeted devices checkbox).
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, 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.
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 two ways:

    • Normally, the batch scheduler triggers an import daily (by default, at midnight, central application server time), with the license consumption calculation triggered thereafter. To customize this default time, go to the IT Asset Management Settings General page (Administration > IT Asset Management Settings > General) > Inventory tab > Managing the processing queue for imports and reconciliation.
    • An operator in the Administrator role can choose to import the waiting inventory and trigger license consumption calculation, or reconciliation, as soon as possible (go to the Reconcile page(Data Collection > Process Data > Reconcile)).