Discovery identifiers
Summarize
Summary of Discovery identifiers
Discovery identifiers in ServiceNow are used after Discovery classifies a configuration item (CI) to determine if that device already exists in the CMDB. Discovery runs identity probes to collect identification data such as serial numbers, names, and network information. This data is processed by sensors and fed into identifiers, which then decide whether to update an existing CI, create a new one, or take no action. This identification process applies only to the Configuration item type of Discovery.
Show less
Accurate identification is crucial to avoid duplicate CIs and maintain reliable asset tracking. Serial numbers play a vital role in this accuracy, so modifications to baseline probes, sensors, or patterns must ensure serial numbers are still discovered and not altered with custom prefixes or syntax changes.
Key Features
- Identifier Rules: Stored in CMDB tables, these rules specify attributes to match CIs based on their type. Examples include rules for ESX Servers, Hardware, Storage Servers, and WBEM Services, each looking at attributes like serial numbers, IP addresses, MAC addresses, and names.
- Custom Identifier Rules: Customers can create custom rules for specific classes or CI types, enabling tailored identification strategies. For instance, a Linux server may be identified using machine name, IP, and MAC address to differentiate bonded network interfaces.
- Evaluation Order: Identifiers are processed sequentially by their order value. Custom identifiers must have unique order values and can be enabled or disabled to control their execution.
- Duplicate CI Handling: Properties such as
glide.identificationengine.skipduplicatesand its threshold allow configuration of how Discovery manages duplicates during identification. - Identifier Versions: The system supports legacy identifiers from pre-Geneva releases and the newer CMDB Identification and Reconciliation framework. Customers upgrading must enable the
glide.discovery.usecmdbidentifiersproperty and convert custom identifiers to the new format to use the updated framework. Service Mapping always uses the new framework identifiers. - Identity Probes and Sensors: Identity probes are multi-probes running commands to collect identification data with a single authentication. Customers can create and configure custom identity multi-probes and associated multi-sensors to identify CIs not covered by default probes.
Practical Implications for ServiceNow Customers
- Ensure serial numbers are accurately discovered and remain unmodified for precise asset tracking.
- Customize identifier rules to improve CI matching, especially in environments with complex network setups like NIC bonding.
- Manage the evaluation order of identifiers to fine-tune CI identification and avoid conflicts.
- Leverage properties to handle duplicate CIs according to organizational policies.
- During upgrades, proactively migrate custom identifiers to the new framework and enable the relevant property to maintain Discovery functionality.
- Create custom identity probes and sensors when default Discovery probes do not adequately identify specific device types.
After Discovery classifies a configuration item (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 avoid 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.
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.
| Rule | Applies to table/attributes | Search on table/attributes |
|---|---|---|
| ESX Server Rule | ESX Server [cmdb_ci_esx_server]: correlation_id | none |
| Hardware Rule | Hardware [cmdb_ci_hardware]
|
|
| Storage Server Rule | Storage Server [cmdb_ci_storage_server]
|
|
| WBEM Service Rule | WBEM Service [cmdb_ci_wbem_service]: cim_object_path | 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 rule for each class you want to use for matching and specify that class in the Applies to field of the Identifier form.
Evaluation 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 avoid 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.
Properties 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
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.