Managing unclassed hardware
Summarize
Summary of Managing unclassed hardware
An asset is designated as unclassed hardware when it fails to match an existing configuration item (CI) in the Configuration Management Database (CMDB) during import, using defined lookup rules. This situation arises during the initial import from scanner integrations.
Show less
Key Features
- Creation Process: During import, USEM searches for CI matches in the CMDB. If no match is found, the Identification and Reconciliation Engine (IRE) generates a new CI under the cmdbciunclassedhardware class.
- Discovery Behavior: When Discovery encounters an asset already listed as unclassed hardware, it creates a new classified CI instead of reclassifying the existing one, due to reliance on the hardware CI's name.
- Challenges with Duplication: Discrepancies between naming conventions (e.g., FQDN vs. hostname) hinder IRE's ability to recognize the unclassed hardware and the newly discovered asset as the same entity, resulting in duplicate CIs.
- IRE Activation Note: When IRE is active, reclassification of items directly from discovered items is not supported.
Key Outcomes
ServiceNow customers can anticipate that unclassed hardware may lead to duplicate CIs if naming conventions do not align. Understanding this process helps in managing asset classification effectively and minimizing redundancy in the CMDB. Customers should ensure consistent naming across systems to facilitate accurate identification and mapping of assets.
An asset is classified as unclassed hardware when it cannot be matched to an existing configuration item (CI) in the Configuration Management Database (CMDB) using defined lookup rules during import.
How unclassed hardware is created
- USEM automatically uses host data to search for matches in the CMDB. The lookup rules are used to identify configuration items (CIs) and add them to the finding record to aid in remediation.
- If no match is found based on the lookup rules, the Identification and Reconciliation engine (IRE) applies its own identification rules defined on the hardware class and all its children.
- The IRE then creates a new CI under the
cmdb_ci_unclassed_hardwareclass. - When Discovery finds this asset, instead of reclassifying the existing unclassed hardware, it creates a CI. This is because the identification rule relies on the name of the hardware CI.
The challenge with reclassification and duplication
- Name Field Discrepancy: The identification rules heavily rely on the name field of the hardware CI.
- Inconsistent Naming: The name used by Unified Security Exposure Management (e.g., FQDN or NetBIOS name) might differ from the name used by Discovery (e.g., just the hostname).
- Result: This discrepancy prevents IRE from recognizing the unclassed hardware and the newly discovered asset as the same entity, leading to the creation of a duplicate CI under a new class rather than reclassifying the original.
"className": "cmdb_ci_unclassed_hardware",
"values": {
"name": "asset01.company.com",//from NetBios,
"mac_address": "1a:5e:2c:0e:42:f3",
"fqdn": "asset01.company.com",
"ip_address": "133.10.3.123"
}
"settings": {
"updateWithoutSwitch": true
}
"className": "cmdb_ci_cmdb_ci_win_server"
"values": {
"name": "asset01",
"mac_address": "1a:5e:2c:0e:42:f3",
"fqdn": "asset01.company.com",
"ip_address": "133.10.3.123",
"os_domain": "company"
}
"settings": {
"updateWithoutSwitch": false
}
In this scenario, the existing Unclassed Hardware CI is not reclassified as a Windows Server. Instead, a new CI is created under Windows Server. This is because the identification rule depends on the Hardware CI’s name. As you can see from the payloads, the name received from Unified Security Exposure Management matches the FQDN/NETBIOS, whereas the Discovery payload provides only the host name.