Using Manual Discovery with Direct Inventory

FlexNet Manager Suite 2023 R1 (On-Premises)

In this approach, the direct inventory part of the process is unchanged, but the discovery device records are created manually ahead of the inventory-gathering process. You may resort to manual creation of discovered device records for testing purposes, or because a target device is temporarily unavailable.

Tip: You may also use this method when you want to re-use discovered device records created in earlier passes of inventory gathering, so that you by-pass discovery for this occasion.

The concepts in this scenario are straight-forward, and the direct inventory gathering itself is identical; but for consistency here is the scenario diagram, followed by the complete description.

The above diagram shows three database servers, two on Subnet1 and one on Subnet2. The Subnet1 is assigned to Inventory Beacon1 and Subnet2 is assigned to Inventory Beacon2. Note that in this diagram, DB1 and DB2 are running versions of Oracle Database compatible with the same OLEDB driver, as discussed in Direct Collection of Oracle Inventory; separately, DB3 may also be compatible, or may require a different version, which may be the reason that it is managed by a separate inventory beacon.

The following description assumes that all the prerequisites listed in Direct Collection of Oracle Inventory have been satisfied, including the installation of an appropriate version of the 32-bit OLEDB driver (one version per inventory beacon) for each target Oracle Database.

1. On each target Oracle server, set up the special "audit account" for collecting database inventory (see Credentials for Direct Collection of Oracle Inventory).
2. Record the credentials for the special audit account in the secure Password Manager on each applicable inventory beacon.
3. If a necessary discovered device record (one for each target Oracle server) does not yet exist, create it:
   1. For example, navigate to Discovery & Inventory > Create a Discovered Device (or use one of the other paths to open a new property sheet for a discovered device).
   2. Complete the identification data on the General tab of the discovered device properties.
      The details you supply are used later to attempt connection to this device, so (as always) accuracy is paramount.
   3. Switch to the Databases tab, select This device is running Oracle software, and create details for the listener(s) on this device, and as children of each listener, the service(s) it manages. (For more information, see Creating Listeners and Services in the online help.) When data entry is complete, remember to click Create to save the discovered device record.
      Tip: Because you are already identifying the services by name, you do not need to provide an administrative password for the listeners to request service names; and therefore, unlike the network scan method of discovery, this approach works with all versions of Oracle. (Of course, this service must accept the service user account and password that you have saved on the inventory beacon.)
      Repeat this until all the required discovered device records are available.
4. Create a rule that combines the use existing discovered device records with direct inventory. Navigate to Discovery & Inventory > Discovery and Inventory rules and use these settings:
   • Target: Create a target to identify all Oracle servers in your network. You can use subnet name, IP address, or pattern matching on the device name to identify devices in the target definition. In this case, be sure that all your manually-created (or previously existing) discovered devices are covered by the target.
   • Action: Create an action that includes these settings:
     • For Action type, choose Discovery and inventory.
     • In the Discovery of devices section, select Use previously discovered devices. (Although it is possible to mix discovery methods in the one action and rule, for simplicity the remainder of this description assumes that this is the only discovery selection you make).
       Tip: A shortcut instead of these two settings is to choose Inventory only for Action type.
     • Expand the Oracle database environments section, and ensure that Discover Oracle database environments is clear (not selected).
     • In the same section, select Gather Oracle database environment inventory. This is the switch to turn on direct inventory gathering for Oracle database instances.
   • Schedule: Specify the running schedule for this rule.

   This completes the initial configuration for using existing discovery records with direct inventory gathering for Oracle. The remainder of these steps cover normal operation.

5. Every 30 minutes, each inventory beacon asks the central application server whether there is any change in the discovered device records it holds. Where the records have been updated, the entire set is downloaded in a series of compressed .disco.gz files, so that each inventory beacon knows about all discovered devices, and can operate on those that match both its assigned subnets and the targets in any rule being executed.
6. By default, every 15 minutes each inventory beacon checks for any updates to its policy, which also transfers any changed discovery and inventory rules. (To adjust this download schedule, see Inventory Settings Page > Beacon Settings Section in the online help.) Each inventory beacon exercises only those rules that apply to its assigned subnet(s).
7. When the related schedule triggers an applicable rule:
   1. The inventory beacon reports to the central application server that the task is commencing. You can navigate to Discovery & Inventory > Discovery and Inventory Rules and click the rule name to view its status. Wait (while the remainder of the process takes place) until the Status field shows Completed. This process may take some time to complete and you may have to revisit or refresh the page from time to time.
   2. Because this rule specifies re-use of existing discovery records (only), the inventory beacon selects from the existing, downloaded records of discovered devices only those that match both its assigned subnet(s) and the rule targets.
   (In due course, the discovered device records are updated with new status results, and are therefore uploaded again as usual when the processes are complete.)
8. For each discovered device record within the scope of the inventory beacon, the FlexNet Beacon engine uses each listener port and service name to connect to each database instance, and collect Oracle Database inventory data. The results are saved into an .ndi inventory file (specific to Oracle inventory only) for each server.
9. Where Oracle inventory is collected, the FlexNet Beacon engine also executes the software scripts provided by Oracle Global Licensing and Advisory Services (GLAS) to gather software information about the Oracle Database installation. It is important to realize two things:
   • These are the same GLAS scripts, as amended from time to time, that are downloaded to the inventory beacon in the InventorySettings.xml file (which is saved in Program Files (x86)\Flexera Software\Inventory Beacon\Remote Execution\Public\Inventory). As always, they do not contribute to the collection of FlexNet inventory, but are used only for the preparation of an Oracle audit report (available to operators who have appropriate access rights in the Discovery & Inventory > Oracle Instances page, with more details available in the help for that page.)
   • However, the Oracle GLAS scripts include two separate parts: SQL queries to gather information from Oracle database instance(s); and scripts to execute on the target server and gather the required hardware information. With this direct connection method of inventory collection, there is no file transfer of any kind to the target server, so that the GLAS hardware scripts cannot be executed on the Oracle server by this method. In contrast, the GLAS SQL queries are executed during the direct connection to each database instance, and the resulting GLAS software data is uploaded to the central application server; but in the normal course of events, the absence of hardware data is unlikely to satisfy an Oracle audit. Therefore, if your strategy is to use only the direct method of inventory collection, you should also plan another method to execute the GLAS hardware scripts on each Oracle server. Alternatively, reconsider the local installation of either the full FlexNet inventory agent, or the lightweight FlexNet Inventory Scanner; or re-evaluate the Zero-footprint method of inventory collection. All of these methods conveniently collect, upload, and create audit-ready packages for all the software and hardware data required for database licensing by Oracle GLAS, and without additional effort on your part.
10. Immediately after inventory gathering, the inventory beacon compresses the .ndi file(s) and .disco files, and uploads them to the central application server (or, if it is a member of a hierarchy of inventory beacons, uploads the data to its parent in the hierarchy, and the upload is repeated until the data reaches the application server). It is initially stored in the inventory database.
11. In due course, the inventory import (to the compliance database) and license reconciliation process runs (typically overnight, although an operator in a role granting the Configure inventory data and reconcile right can also trigger a full import and reconciliation). Progress is visible on the System Tasks page.
12. The Discovery & Inventory > Oracle Instances page lists the database inventory for all servers discovered and inventoried up to the time of the latest reconciliation calculation.