Zero-Footprint: Implementation
The Zero-footprint case does not require any software deployment, since the FlexNet inventory core components are installed on every inventory beacon as part of the FlexNet Beacon code installation. However, there are preliminary configuration steps needed to allow remote execution to proceed.
To configure remote execution:
-
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.
-
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.
-
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 gather inventory, 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.)
-
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, thessh
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
orpriv
) is installed on target devices and either:- The use of that tool is configured in the Password Manager (in the extra fields exposed when you specify and SSH account type), or
- Target devices are configured to allow escalation of privileges without requiring an interactive password.
-
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 to
collect inventory from them.
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 —
for the Zero-footprint case, it is critical that
either
- The target device is not included in any target that has Allow these targets to be adopted selected; or
- The target device is included in an active target for which Do not allow these targets to be adopted is selected (as a 'deny' always over-rides an 'allow'). This may be the easier condition to set and maintain over time.
- Actions that declare what to do to the targeted devices — to ensure discovery and inventory collection, the relevant action must ensure that, in the General devices discovery and inventory section (click the title bar to expand the section), one or both of the Discover ... check boxes is selected, and Gather hardware and software inventory is selected. In addition, other specialized kinds of inventory may be selected, depending on the target inventory device. By specifying multiple rules, you can customize actions to gather all required inventory types while minimizing activity on any individual target device.
- A schedule for implementing the action on the targeted devices.
- 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 —
for the Zero-footprint case, it is critical that
either
IT Asset Management (Cloud)
Current