After Discovery classifies a CI, it uses identifiers to determine if the device already
exists in the CMDB.
Discovery launches
special identity probes that accumulate identification data for each device and feed that data
into the identifiers, which determine the action that Discovery must take for each device.
Identifiers accurately determine the identity of the device to prevent the creation of duplicate
CIs. This identification step only takes place for the Configuration item type of discovery, not
for the other types of discovery.
The identity probe in the base Discovery system can be configured to ask the device for
information such as its serial numbers, name, and network identification. The results of this
scan are processed by an identity sensor, which then passes the results to the identifier. The
identifier then attempts to find a matching device in the CMDB. If the identifier finds a
matching CI, the identifier either updates that CI or does nothing. If the identifier cannot
find a matching CI, it either creates a new CI or does nothing. If Discovery is configured to
continue, the identifier launches the exploration probes configured in the classification record
to gather additional information about the device. Exploration probes can be multiprobes or
simple probes.
Important: Serial numbers are necessary for
accurate asset tracking. If you modified baseline probes, sensors, or patterns, verify
that they still discover serial numbers. In addition, do not configure sensors or patterns
to modify the serial number syntax, such as adding a custom prefix. Non-standard serial
numbers can lead to inaccurate asset tracking.
This diagram shows the processing flow for classifying and probing devices with identifiers
configured.
CMDB identifier tables
Table
Description
Identifier [cmdb_identifier]
Stores all identifier rules.
Identifier Entry [cmdb_identifier_entry]
Stores all the identifier attributes.
Identifier rules
The default Discovery system contains
these identifier rules, each of which is associated with a specific CI type (the
sys_class_name field on the CI record) or the table in the
Applies to field and contains the appropriate attributes for discovering
CIs from the specified table. Where necessary to discover all possible occurrences of an
attribute, tables from related lists (Search on tables) are included in
the rule. For more information, see Create or edit a CI identification
rule .
Table 1. CMDB identifier rules
Rule
Applies to table/attributes
Search on table/attributes
ESX Server Rule
ESX Server [cmdb_ci_esx_server]
none
Hardware Rule
Hardware [cmdb_ci_hardware]
serial_number
serial_number_type
name
ip_address
mac_address
Serial Number [cmdb_serial_number]
serial_number
serial_number_type
Network Adapter [cmdb_ci_network_adapter]
Storage Server Rule
Storage Server [cmdb_ci_storage_server]
cim_object_path
name
serial_number
serial_number_type
mac_address
ip_address
Serial Number [cmdb_serial_number]
serial_number
serial_number_type
Network Adapter [cmdb_ci_network_adapter]
WBEM Service Rule
WBEM Service [cmdb_ci_wbem_service]
none
Matching strategy for the hardware rule
The sys_class_name cannot be an attribute for independent rules, such
as cmdb_ci_hardware. If your Discovery identification strategy depends on matching a CI with a
specific class, you must create a new rule for each class you want to use for matching and
specify that class in the Applies to field of the Identifier form.
For example, you can create an identifier for a Linux server with different attributes than
the Hardware Rule. You might want to use the machine name, IP address, and MAC address for
identification. This is a solution for networks that use NIC
bonding or
teaming to increase available bandwidth. Bonded interfaces appear to be the same
physical device and share the same IP and MAC addresses. The use of the
name attribute allows Discovery to differentiate between the individual
interfaces in the bonded channel.
Caution: If you create an identifier with the
name attribute, avoid changing adapter names. Discovery will be unable
to resolve existing CIs for renamed adapters. Discovery labels the Install Status of that CI as
"Absent" and creates another CI.
Your new rule would look like this:
Figure 1. Linux identifier ruleEvaluation order for Discovery identifiers
Custom identifiers must have different Order values than those of the default
identifiers. Discovery parses identifiers
and attributes in sequence from low order numbers to high. You can create identifiers to run
before or after the default identifiers, or mixed in with the identifiers from the base system.
To prevent any identifier or rule from running, disable it by clearing the
Active check box. The evaluation order for CMDB identifiers is
established within each rule and only controls the parsing order of the attributes in that rule.
Figure 2. Evaluation order in CMDB identifier rulesProperties for processing duplicate CIs
You can control how Discovery handles duplicate CIs with properties installed with
Identification and Reconciliation. Use the
glide.identification_engine.skip_duplicates and
glide.identification_engine.skip_duplicates.threshold properties. For more
information, see Properties for Identification and
Reconciliation .
Properties that control identifier versions
All instances use identifiers from the CMDB Identification and
Reconciliation framework. Upgrades from pre-Geneva versions still preserve the legacy
identifiers, but you can switch to the new identifiers using a property:
glide.discovery.use_cmdb_identifiers. If you upgraded from a pre-Geneva
version, you must manually add this property and set it to
true to use
the new identifiers. If you upgraded from Geneva or later releases, this property is available
in the System Properties [sys_properties] table. To preserve functionality in custom legacy
identifiers, convert them to the new CMDB identifier rules format before enabling this property.
The system does not reconfigure your custom identifiers to the new framework
automatically.
Note: When Service Mapping is active, the new identifiers from the CMDB
Identification and Reconciliation framework are always used regardless of the property
value.
