Adopted: Implementation

IT Asset Management (Cloud)

"Adoption" refers to the process by which IT Asset Management installs the FlexNet Inventory Agent on target devices, based on rules that you set.

This approach bypasses the manual preparation of installation packages and their deployment using the third-party deployment tools. In this process, the configuration and deployment of FlexNet Inventory Agent is fully automated, and you do not need to understand the various code components involved, nor their many settings, nor do any custom configuration.

Tip: The trade-off is that, while not doing any custom configuration, you also cannot change the default installation location on the target device or choose the agent operation mode on UNIX-like devices. (In contrast, the Agent third-party deployment case allows for custom installation paths for the complete FlexNet Inventory Agent. The Agent third-party deployment also allows the user to configure whether the installed agent is running with full privilege or least privilege on UNIX-like devices.)

The main requirements for this Adopted case are targeting the devices through an inventory beacon, and arranging credentials to allow for installation.

To manage automated adoption of discovered devices (summary):

1. Ensure that you have the appropriate inventory beacons fully operational.

   To do this, go to the Beacons page (Data Collection > IT Assets Inventory Tasks > Beacons) and check the following properties for an existing inventory beacon:

   Property	Expected Value
   Beacon status	Operating normally
   Policy status	Up to date
   Connectivity status	Connected

   To deploy and configure a new inventory beacon, click Deploy a beacon. Consult the online help for these pages for more information.

2. Ensure that at least one inventory beacon is configured to cover the subnet containing the target inventory devices.
   While all inventory beacons receive all rules declared in the web interface of IT Asset Management (when they download the BeaconPolicy.xml file), each one enacts only those rules that apply to target devices that fall within their assigned subnet(s). This setting is availabe on the Beacons page (Data Collection > IT Assets Inventory Tasks > Beacons). See the online help there for more information.

   Tip: It is best practice to deploy an inventory beacon into each subnet that contains target inventory devices. This allows the inventory beacon to reliably use ARP or nbtstat requests to determine the MAC address of a discovered device (reliability of these results is reduced across separate subnets). Where, across subnets, only an IP address can be found for a device (that is, the device data is missing both a MAC address and a device name), a record is created for the discovered device; but because IP addresses may be dynamic, this is insufficient to allow merging with more complete records (which also contain either or both of the MAC address and a device name). Such complete discovery records may be created automatically when inventory is first returned from the locally-installed FlexNet Inventory Agent: not finding an existing, complete and matching discovered device record to link with the inventory device record, IT Asset Management automatically creates one. This means you may see multiple discovered device records with duplicate IP addresses: one record is complete (from inventory), and one or more others are missing identifying data (across subnets) as discussed. These cannot be merged automatically, and you are left with a manual task to clean up incomplete duplicate discovered device records. What's worse, if you have a rule to repeat the discovery process (for example, looking for newly-installed devices) and you still have incomplete discovery data from an inventory beacon reaching across subnet boundaries, the unmatched and incomplete record is recreated at each execution of the discovery rule.

   In contrast, having a local inventory beacon in the same subnet as target devices provides both the IP address and the MAC address, which is sufficient for matching discovered device records. If you must do discovery across subnet boundaries without a local inventory beacon, ensure that there are full DNS entries visible to the inventory beacon for all devices you intend to discover. This allows the inventory beacon to report both an IP address and a name (either the device name or a fully-qualified domain name [FQDN]), which combination is again sufficient for record matching.

3. If yours is a highly secure, locked down environment, you may need to open network ports on the target computer devices to allow for remote execution.
   Since the inventory beacons use standard ports to access target devices and remotely install the FlexNet Inventory Agent, the required ports are already available in many environments. (The ports are documented in the online help, under IT Asset Management Help > Inventory Beacons > Inventory Beacon Reference > Ports and URLs for Inventory Beacons. The default requirements for remote execution are ports 445 for SMB on Windows and 22 for SSH on Unix.)
4. Ensure adequate credentials are available for the remote execution process to run. There are two possible approaches for Windows devices:
   • You can register a domain administrator account that has installation privileges on all the target computer devices within the domain. This approach minimizes entries in the Password Manager.
   • You can record appropriate (potentially unique) credentials for each device in the Password Manager. With this approach, you should also add filters to limit the number of password attempts on each target device, so that the remote execution attempt is not terminated because it attempted too many credentials without success.

   These credentials must be recorded in the secure Password Manager available on each inventory beacon (for details, see the online help, under IT Asset Management Help > Inventory Beacons > Password Management Page).

   For UNIX-like devices, the ssh daemon must be installed, and you must either:

   • Record root credentials for the target device in the Password Manager on the applicable inventory beacon
   • Record non-root credentials for the target device in the Password Manager on the applicable inventory beacon, and additionally ensure that a tool to allow privilege escalation (such as sudo or priv) is installed on target devices and either:
     1. The use of that tool is configured in the Password Manager (in the extra fields exposed when you specify and SSH account type), or
     2. Target devices are configured to allow escalation of privileges without requiring an interactive password.
5. For gathering Oracle inventory from UNIX-like platforms, ensure that you have authorized FlexNet Inventory Agent version 13.2.0 or later for adoption and self-managed upgrades.
   Earlier versions of FlexNet Inventory Agent may fail to collect Oracle inventory on UNIX-like systems where permissions prevent global access to Oracle directories or files. For details about setting the permitted version of FlexNet Inventory Agent, see Adopted: Specifying an Installed Agent Upgrade.
6. Set the schedule for operations of the FlexNet Inventory Agent in the Inventory Settings page (Data Collection > IT Assets Inventory Tasks > Inventory Settings).
7. Go to the Discovery and Inventory Rules page (Data Collection > IT Assets Inventory Tasks > Discovery and Inventory Rules), and create one or more rules to take inventory from target computing devices within your enterprise, and then at the beginning of the inventory process, adoption occurs when in policy for the target device.
   Rules consist of

   • Targets that identify sets of devices, and (for all the devices identified within a single target) specify policy about how to connect, whether to collect CAL evidence, whether to track application usage, and whether to adopt — all devices intended for adoption must be included in at least one target that has Allow these targets to be adopted selected (and at the same time, must not be included in any overlapping target for which Do not allow these targets to be adopted is selected, as a 'deny' always over-rides an 'allow').
     Tip: In the case of these policy settings such as adoption, targets need not be used in rules to have effect. Policy is determined by the net effect of the policy settings on all the targets that apply to a given device. This policy setting is a separate function of targets, independent of their possible use in rules. Secondly and separately, targets are also used to identify which devices a rule should act on. If a device is covered in at least one target used in a rule with an inventory gathering action (as listed next — this conditions ensures that an inventory beacon touches the target device), its adoption policy (allow or deny) can be specified in any overlapping target (overlapping because it covers the same device), regardless of whether the overlapping target is actually used in a rule.
   • Actions that declare what to do to the targeted devices — to ensure adoption, the relevant rule must include at least one of the following inventory settings when you create or edit an action (the action may also include discovery settings, or alternatively you may look in the Discovery of devices area and select Use previously discovered devices):
     • In the General devices discovery and inventory section (click the title bar to expand the section), Gather hardware and software inventory from all target devices selected
     • In the Microsoft Hyper-V discovery and inventory section, both the Discover Microsoft Hyper-V check box and the Gather Microsoft Hyper-V hardware and software inventory check box selected; and Hyper-V is then discovered on the device
     • In the Microsoft SQL Server discovery and inventory section, both the Discover Microsoft SQL Server check box and the Gather Microsoft SQL Server hardware and software inventory check box selected; and SQL Server is then discovered on the device.
   • A schedule for implementing the action on the targeted devices.
     Tip: Part of the art in this automated deployment may be in declaring a schedule that suits when the target devices are available (that is, running, connected to the network, and not too busy). Particularly with individual workstations and laptops, this may require some external process management. For example, you may communicate to users that they should leave target devices running overnight, or some similar arrangement. Since the discovery and adoption rules execute on a repeated schedule, there are many such 'windows' when devices can be automatically adopted.

   By specifying multiple targets, you can choose which computer devices are adopted. For more information, see the online help for these pages.

8. Wait for the execution of the rule(s), the installation of the FlexNet Inventory Agent, and the resultant data uploads.

   When the inventory beacon contacts a target device listed for gathering inventory, it checks the operating system and checks whether the full FlexNet Inventory Agent is already installed. On a target device that is listed in policy for adoption, but where the FlexNet Inventory Agent is not already present, the inventory beacon automatically installs the FlexNet Inventory Agent (that is, 'adopts' the device). No methods of inventory gathering other than by the locally-installed FlexNet Inventory Agent are ever used on target devices for which the policy (net of all targets) is adoption.

   To monitor progress and results, go to the System Tasks page (Data Collection > IT Assets Inventory Status > System Tasks), and see the online help there for more information. You can also go to the Discovery and Inventory Rules page (Data Collection > IT Assets Inventory Tasks > Discovery and Inventory Rules), and select the Rules tab. On that page, click the name of any rule to expose additional details, including a table of Adoption results.

   Tip: It is important to check for successful adoption. Should it happen for any reason that adoption fails, the fact that adoption has been set for the target device prevents inventory collection through (for example) the Zero-footprint process of inventory gathering. This combination may mean that no inventory is returned for the device at all.

When initial execution of the rules is successfully completed:

• On the adopted inventory device, the FlexNet Inventory Agent is by default installed:
  • On Windows, in C:\Program Files (x86)\ManageSoft
  • On UNIX-like platforms, in /opt/managesoft.
• The adopted devices are listed in the All Discovered Devices page (Inventory > Network Discovery > All Discovered Devices).After an inventory upload and import, the Agent installed column shows that the FlexNet Inventory Agent has been successfully deployed and is reporting.
• According to the global schedule you specified in the Inventory agent schedule section in the Inventory Settings page (Data Collection > IT Assets Inventory Tasks > Inventory Settings), your adopted devices start reporting inventory collected by the FlexNet Inventory Agent. After subsequent inventory imports and compliance calculations, the results are visible in the management and reporting views within IT Asset Management.
• The targets you declared to set policy for adoption now have no further effect on adopted devices (they do not, for example, unnecessarily cause repeated installations). Each installation of FlexNet Inventory Agent is a state-based machine controlled by its policy, prepared for it on demand by an inventory beacon. However, keeping the policy-setting targets in place is best practice, for at least two reasons:
  • If you remove a target that specifies a policy combination (adoption, connection, CAL evidence and usage tracking), you may inadvertently switch behaviors of the installed agents
  • The same policy setting in favor of adoption also prevents overlapping gathering of FlexNet inventory by other means, such as the Zero-footprint case.
• Any changes to policy settings affecting installed FlexNet Inventory Agents are transmitted to all inventory beacons, and automatically included in subsequent policy updates on the next policy request by each installed FlexNet Inventory Agent.
• Through policy, you can also control the self-update mechanism when new versions of the FlexNet Inventory Agent are ready to deploy (for details, see Adopted: Specifying an Installed Agent Upgrade).

Note: For UNIX-like platforms (only), you can manually update the preferences controlling the behavior of the installed FlexNet Inventory Agent. From a console or remote terminal connection, run the command:

/opt/managesoft/bin/managesoft-configure

This will prompt for configuration items.