Agent Third-Party Deployment: Normal Operation

IT Asset Management (Cloud)

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 IT Asset Management.

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

5. 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.
6. 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 #task_wwh_42l_y5__d40e171.)

   • 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.
7. 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.
8. 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.
9. 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)).