Zero-Footprint: Normal Operation

IT Asset Management (Cloud)
Because of the requirement that no executables are permanently installed on target inventory devices in the Zero-footprint case, there are some variations across platforms in how the remote execution operates. However, the principles of the process are consistent. This description assumes that you have configured the system to allow for Zero-footprint discovery and inventory collection (described in Zero-Footprint: Implementation). The entire operational process is covered, including what happens to the collected data after it uploaded to the inventory beacon and beyond. Each numbered step provides a summary point, followed by further specific details that you can skip over until needed.
Important: This method of discovery and inventory gathering is not currently supported in IPv6 networks.

The process always begins with discovery, and moves directly to inventory gathering from the appropriate devices.

  1. On the schedule declared an the applicable rule, the FlexNet Beacon engine conducts a sweep of its assigned subnet.
    This sweep may use either (or both) of:
    • A network scan, with testing of a specified list of ports (this method is mandatory for discovery and inventory of UNIX-like machines)
    • A scan by the Windows Computer Browser service.
    To reivew or update your choice, go to the Discovery and Inventory Rules page (Data Collection > IT Assets Inventory Tasks > Discovery and Inventory Rules), click the Actions tab, click the pencil icon to edit an action, and then go to the Discovery of devices section.
    A set of IP addresses is returned.
  2. Each IP address is assessed as follows:
    1. Is the IP address within a subnet that is assigned to this inventory beacon?
      If not, the IP address is discarded, and the next one is processed. Log files for the work of the FlexNet Beacon engine are saved in %CommonAppData%\Flexera Software\Compliance\Logging\BeaconEngine.
    2. Is this IP address matched by the target in the rule (for which the action includes discovery and inventory gathering) that has been triggered?
      If not, the IP address is discarded.
    3. Appropriate ports are probed.
      There may be several reasons why ports are probed:
      • If the action settings included Discover devices using network scan, there is a list of default ports, including for example port 22 (for SSH on UNIX-like platforms) and port 135 (for NetBIOS on Windows), and others. You may have added additional ports to this set.
      • Additional parts of the action definition, such as Oracle VM discovery and inventory, Microsoft SQL Server discovery and inventory, VMware discovery and inventory, and so on may also specify ports, on which specialized probes are conducted to identify the services you are checking for.
      • If you have selected TNS names file as a discovery method in the Oracle discovery and inventory section of the action specification, and there is a tnsnames.ora file present in %CommonAppData%\Flexera Software\Repository\TNSNames\ on the inventory beacon, the servers (and ports) identified in that file are also probed as part of discovery. (If there are multiple .ora files, each is processed in turn.)
    4. Are there credentials for this device recorded in the local Password Manager on the inventory beacon?
      This is confirmed by a successful log in. If not, the IP address is discarded.
    5. With successful login, a query is used to identify the operating system on the device (so that appropriate command lines can be constructed), and a check is made for the presence of the FlexNet Inventory Agent.
      • For Windows devices, the status of the ndinit service is checked. If it is present, this also gives the installed version of the FlexNet Inventory Agent, and an indication of its healthy operation.
      • For UNIX-like devices, the following command is used both to identify the operating system type and to determine whether the device is already adopted (such that the FlexNet Inventory Agent is already installed on the device, as shown by the ETCPVersion result):
        /bin/sh -c "PATH=$PATH:/bin:/usr/bin; 
        echo \"UnameKernel=`uname`\"; 
        [ -r /etc/managesoft.ini ] && 
        grep ETCPVersion /etc/managesoft.ini || echo \"ETCPVersion=NONE\"”
      If found by these means, the FlexNet Inventory Agent is logged in the inventory database as installed on the discovered device.
      Note: The discovery of the installed FlexNet Inventory Agent by this means does not have the impacts that you may imagine:
      • It does not cause its appearance in the web interface for IT Asset Management, and in particular does not drive the result shown in the Agent installed column of the All Discovered Devices page (Inventory > Network Discovery > All Discovered Devices). (This column is derived from inventory results, not from discovery results, allowing for results from third-party inventory tools to also be reflected in the column.)
      • It does not influence the decision about whether to apply any Zero-footprint inventory gathering specified in the current rule to the device. When specified, this kind of inventory gathering goes ahead on all devices except those for which their policy specifies adoption. As a consequence, if you have used third-party tools (or manual effort) to deploy the full FlexNet Inventory Agent to this device, and the device is outside the policy for adoption but inside the target(s) for a rule specifying Zero-footprint inventory gathering, then you collect inventory from both methods: Zero-footprint inventory gathering, and inventory taken by the locally-installed FlexNet Inventory Agent. While uncommon, it is then possible that your customized settings could cause resulting data to flip-flop based on which inventory method was used most recently.
      The main purpose of this discovery check for an installed FlexNet Inventory Agent comes in the next step, in the adoption check.
    This completes discovery, and any device still under consideration is included in the list of discovered devices visible in the web interface of IT Asset Management. Meanwhile, if the rule included any inventory gathering as part of its action, the process continues.
  3. If, in the General hardware and software inventory section of the action settings for the relevant rule, the Gather hardware and software inventory check box is selected, the FlexNet Beacon engine checks the BeaconPolicy.xml file to see whether the current device is listed (in the net result of all targets) for adoption.
    • If the device policy is for adoption, two consequences follow:
      1. The discovery result for an installed FlexNet Inventory Agent is assessed. If the FlexNet Inventory Agent is not present, adoption is initiated immediately.
      2. When the FlexNet Inventory Agent is present (or adoption has been initiated in this pass), the Zero-footprint inventory process is terminated for this device, and the process moves onto the next device in the list. (If this device was targeted for Microsoft SQL Server or Microsoft Hyper-V inventory collection, these forms of Zero-footprint inventory collection are also terminated in this case, and are left to the installed FlexNet Inventory Agent.)
    • If the device is not targeted for adoption (or specifically excluded from adoption in at least one target), the process continues.
      Tip: The adoption test is entirely based on target policy settings in the web interface. This means that, if you deployed the FlexNet Inventory Agent independently (the Agent third-party deployment case) and also include the device in a target for inventory gathering in the Zero-footprint case, inventory gathering proceeds twice for this device.
  4. The method of gathering general hardware and software inventory varies across platforms:
    Microsoft Windows:
    1. The FlexNet Beacon engine, which is still logged into the target device, creates and runs a Windows service (with the display name mgs-GUID, executing mgsreservice.exe).
    2. The service executes the ndtrack.exe inventory component from the inventory beacon file share mgsRET$.
      The executables are available on the inventory beacon in the default path %ProgramFiles%\Flexera Software\Inventory Beacon\RemoteExecution\Public\Inventory (defined in the Windows share mgsRET$) .
    3. Because the command line parameters passed to ndtrack included the -o UploadLocation preference that identified the parent inventory beacon, the ndtrack component immediately attempts an upload of the collected inventory.
      On the inventory beacon, uploaded FlexNet inventory files are saved in %CommonAppData%\Flexera Software\Incoming\Inventories.
      Tip: Since only one inventory beacon is identified in the preference, there is no fail-over should the specified inventory beacon be unavailable for any reason, including that it requires credentials not known to ndtrack. (Fail-over inventory beacons are identified only for installed FlexNet Inventory Agents that are self-managing based on collected device policy, in either the Adopted case or the Agent third-party deployment case.)
    4. The service is closed down.
    The following artifacts remain on the target inventory device, and are over-written on the next execution of the same process:
    • An uncompressed inventory (.ndi) file is left in %ProgramData%\ManageSoft Corp\ManageSoft\Tracker\ZeroTouch
    • A tracker.log log file is saved on the target inventory device in C:\Windows\temp\ManageSoft.

    UNIX-like platforms

    1. The FlexNet Beacon engine, which is still logged into the target device, executes sudo to elevate its privileges to root level.
      Tip: It is technically possible to run Zero-footprint inventory collection from UNIX-like devices as a non-root user; but this prevents collection of complete inventory (for details, see Zero-Footprint: Non-Root Accounts).
    2. The FlexNet Beacon engine then executes ssh to establish a secure link.
    3. The engine then uses scp to copy the FlexNet inventory core components to the target device.
      For convenience in dealing with the variety of target platforms, these are deployed in the form of ndtrack.sh, a 'self-installing' script. This is available on the inventory beacon in the default path %ProgramFiles%\Flexera Software\Inventory Beacon\RemoteExecution\Public\Inventory.
      Tip: The same directory may also contain ndtrack.ini, a configuration file (for UNIX-like machines only, and only in the Zero-footprint or FlexNet Inventory Scanner cases) that may contain preferences applicable to ndtrack. With the restriction that preferences apply only to this one component, this file has the same schema as config.ini, the substitute registry for agent preferences for the cases where the FlexNet Inventory Agent is locally installed on the target device (see, for example, Agent Third-Party Deployment: Updating config.ini on a UNIX Device). However, there are no fail-over settings included in ndtrack.ini, for the reasons noted below. It is not mandatory to supply this file, since ndtrack.sh has built-in default settings that provide all necessary values beside those supplied in the command line. However, if you wish to override any of these default values, you can customize the ndtrack.ini file available in this same folder as ndtrack.sh.
    4. The ndtrack.sh script is executed, identifies the particular platform, and unzips the appropriate executable either into the home directory of the root account or (if that home directory is /) into /var/tmp.
    5. The ndtrack component collects the inventory.
    6. Because the command line parameters passed to ndtrack included the -o UploadLocation preference that identified the parent inventory beacon, the ndtrack component immediately attempts an upload of the collected inventory.
      On the inventory beacon, uploaded FlexNet inventory files are saved in %CommonAppData%\Flexera Software\Incoming\Inventories.
      Tip: Since only one inventory beacon is identified in the preference, there is no fail-over should the specified inventory beacon be unavailable for any reason, including that it requires credentials not known to ndtrack. (Fail-over inventory beacons are identified only for installed FlexNet Inventory Agents that are self-managing based on collected device policy, in either the Adopted case or the Agent third-party deployment case.)
    7. The FlexNet Beacon engine, still running as root, deletes the executable, deletes the ndtrack.sh script, and logs out.
    The following artifacts remain on the target inventory device, and are over-written on the next execution of the same process:
    • An uncompressed inventory (.ndi) file is leftwhen inventory collection is (as usual) run as root, in /var/tmp/flexera/tracker; or if inventory collection is run as another user, in /var/tmp/flexera.userName/tracker
    • Log files are saved on the target inventory device when inventory collection is (as usual) run as root, in /var/tmp/flexera/log; or if inventory collection is run as another user, in /var/tmp/flexera.userName/log. One called ndtrack.log is created by the shell script wrapper, and tracker.log is the logging output from the ndtrack component itself.
  5. In parallel with the above process for general hardware and software inventory, the FlexNet Beacon engine also conducts specialized inventory gathering on discovered devices matching the specifications in the action for the rule being executed.
    These are the devices for which inventory gathering has been specified for VMware, Microsoft Hyper-V, Citrix Virtual Desktops, Oracle Database environments or Oracle VM infrastructure. Each type of inventory gathering creates its own .ndi inventory file. These are added to the uploaded general inventory files in %CommonAppData%\Flexera Software\Incoming\Inventories.
  6. 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.
  7. On the application server, the web service ManageSoftRL receives the uploaded inventory file(s).
    These are processed immediately, being loaded into the internal inventory database.
  8. On the next inventory import and license consumption calculation, the inventory 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)).

IT Asset Management (Cloud)

Current