Issues with Uploads

FlexNet Manager Suite 2023 R1 (On-Premises)

Oracle inventory collected by the FlexNet inventory agent locally installed on the target inventory device (the Oracle server) must now successfully navigate a multi-part process:

• The compressed .ndi.gz files (and for Oracle inventory, an uncompressed .disco file) are uploaded from the target inventory device to an inventory beacon of its choosing. Keep in mind that this is attempted first by the tracker (ndtrack, the inventory component) and, if a transient problem causes a failure, it is retried overnight by the uploader (ndupload), each of which has its own log file.
• If there is a hierarchy of inventory beacons, the first must upload to its parent, and so on.
• The 'topmost' inventory beacon uploads to the central application server (or, in a multi-server implementation, the inventory server), where the receiving web service attempts to 'resolve' the uploaded files into the inventory database. (If the resolver is overloaded, the uploaded files may be temporarily staged on the disk on the same server, and resolved a few minutes later when the load subsides.)
• At the next full inventory import (typically scheduled overnight, immediately preceding the license compliance calculations), the latest inventory is imported from the inventory database into the compliance database.

Symptoms

Problems with the upload process may result in these shortcomings visible in the web interface for FlexNet Manager Suite:

• Device records for your Oracle servers missing from Discovery & Inventory > All Discovered Devices
• Hardware inventory records (or, in the case of a problem emerging later that disrupts ongoing operations, recent inventory records) missing from Discovery & Inventory > All Inventory
• Known database instances (that you have verified are still in existence and running/runnable) missing from Discovery & Inventory > Oracle Instances.

Keep in mind that inventory devices that disappear from imported inventory are assumed to have been decommissioned, and after a period may be automatically removed from the compliance database and therefore the web interface. So to start with, be sure that the Oracle server and its associated database instances that you thought were in place are still operational — otherwise, their absence from the record is an accurate depiction of the conditions in your computing estate.

To troubleshoot uploads of Oracle inventory:

1. On the target inventory device (the Oracle server), quickly identify whether the first stage of upload to an inventory beacon is failing.
   1. Check the upload of .disco files by seeing whether the staging folder is empty (it is cleared after a successful upload):
      • On Windows, check $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Common\Uploads\Discovery
      • On UNIX-like platforms, check /var/opt/managesoft/uploads/discovery/

      The presence of a .disco file here (more than a few minutes after inventory collection has run) means that upload is failing, at least for this file type (and typically then, for all file types).
   2. Check the upload of .ndi.gz files from their staging folder:
      • On Windows, check $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Common\Uploads\Inventories
      • On UNIX-like platforms, check /var/opt/managesoft/uploads/Inventories

      The presence of a .ndi.gz file here also means that the first stage of upload is failing. For failing uploads, continue with the next step, looking for problems reported in the log file(s). On the other hand, if both the Discovery and Inventories folders are empty, this indicates that the first stage of upload (to a selected inventory beacon) has succeeded; and if there is an upload problem, it may be further upstream. You also need to review the log files on this device (details in the next step), but in this case looking to identify the inventory beacon selected for the inventory upload, so that you can follow the chain.
2. Review the appropriate log files for problems with previous uploads, or to identify the inventory beacon that was selected for the upload.
   Remember that the FlexNet inventory agent has two ways to attempt uploads:

   • The inventory tracker component (ndtrack) attempts an upload immediately after completing inventory collection. Any issues with this attempt are logged in tracker.log.
   • To recover from transient issues, the uploader component attempts a catch-up overnight, and any issues here are logged in upload.log.

   Both these log files are saved in the same platform-specific location:

   • On Windows: $(TempDirectory)\ManageSoft\ (provided that the tracker is running as LocalSystem, this expands to C:\Windows\Temp\ManageSoft\)
   • On UNIX-like platforms: /var/opt/managesoft/log/.
   1. Review at least the first and possibly both of these log files.
      Look for the following markers of success (examples shown for the Oracle inventory file, but you may also find results for the general inventory, where the file name starts with system:

      • Uploading file 'deviceName at dateTime (Oracle).ndi.gz' to 
        'http://192.53.15.139/ManageSoftRL/Inventories'

        Important: Take note of the URL, which is one of the few ways to identify the inventory beacon used for any given upload (keeping in mind that FlexNet inventory agent chooses the optimum inventory beacon for each upload, and that it may select different servers at different times, depending on networking conditions). Identify the inventory beacon server from this IP address, as you may need to troubleshoot that server next.

      • Upload successful
        File 'deviceName at dateTime (Oracle).ndi.gz' removed from upload directory

        These indicate that the error is not local on this device, so that you need to troubleshoot further along the upload chain.
      If the log files indicate any networking or other problems for uploading, try to remedy these; and continue with the next substep. On the other hand, if this stage has been successful, move to the next server in the upload chain (skip to step 3).
   2. After making any corrections, re-run the tracker to collect updated inventory (and database discovery data), and monitor the staging folders (identified in step 1) for the creation and (after upload) removal of the files there.
      The platform-specific commands are:

      • For Windows: ndtrack -t machine (when run from the install directory)
      • For UNIX-like devices: /opt/managesoft/bin/ndtrack -t machine

      When inventory gathering is complete, repeat the review of logs for evidence of upload problems.
3. Switch to the inventory beacon identified in step 2a, and check that files aren't backed up in the incoming inventory folder %CommonAppData%\Flexera Software\Incoming\Inventories.
   An empty folder is a good sign, as each inventory beacon is scheduled to check for and try uploads from this folder to its parent device every minute throughout the day.
4. Review C:\Windows\Temp\ManageSoft\uploader.log on this inventory beacon for details of any networking issues, and note the URL of the next server in the upload chain. If this is another inventory beacon, repeat these reviews there, and so on until you exhaust the hierarchy of inventory beacons.
5. Once you have reached your application server (or inventory server, in a multi-server implementation), check C:\ProgramData\Flexera Software\Compliance\Logging\WebResolvers\dispatcher.log for any issues in resolving the inventory.
6. If you are unable to resolve upload problems, collect your logs together to seek further help (see Requesting Further Assistance).