Introduction
A Configuration Management Database (CMDB), in short, is a vital component in successful IT Service Management (ITSM). The main function of a CMDB is to store a thorough catalog of an organization’s IT infrastructure. When working with ServiceNow, properly maintaining its integrity is critical to successfully delivering any business need, including IT operations service management and asset management. The goal of this blog post is to look closer at a few important ServiceNow CMDB concepts, like its CI Class Manager and Identification and Reconciliation Engine (IRE), to further aid in your mastery of ServiceNow configuration items.
CI Identification Rules: Ensuring Uniqueness
CI Identification Rules are a set of criteria that ServiceNow uses to uniquely identify Configuration Items within the CMDB. These rules specify how a CI is recognized using unique attributes (e.g., Serial Number, Name, MAC Address, Device ID, Object ID) or a combination of attributes. Properly defined identification rules are crucial for maintaining CMDB data quality by preventing duplicate CIs .
Accessing Identification Rules:
Via CI Class Manager: Navigate to the desired CI class and select the 'Identification Rule' tab to view identifier entries for that specific class.
Via Application Navigator: Go to 'Identification/Reconciliation > CI identifiers' to view identifier entries across all CI classes.
How Identification Rules Work:
Each identifier entry has a 'Priority' value. The IRE evaluates entries in increasing order of priority. For example, if an entry combines 'Serial Number' and 'Serial Number Type', the IRE first checks for existing CIs with this combination. If a match is found, the CI is updated, and no further entries are evaluated. If no match is found, the IRE proceeds to the next identifier entry. If no match is found after evaluating all entries, a new CI is created
Configuring New Identification Rules:
New identification rules can be configured in the CI Class Manager by using the 'Replace' button and then 'Add' under 'Identifier Entries'. You can choose attributes from the main table, a lookup table, or a combination. It's essential to specify the 'Priority' and 'Criterion Attributes' for each entry
CI Class Manager: Your Central Hub for Configuration Items CI Class Manager acts as an interface in ServiceNow that allows for unparalleled visibility and control of Configuration Items (CIs). The CI Class Manager enables administrators and sn_cmdb_admin roles to:CI Classes: Define different types of Configuration Items.
Class Hierarchy and Relationships: Define parent-child relationships for classes (e.g., cmdb_ci -> hardware -> computer -> server -> Windows server).
CI Attributes: Access and control the properties that are characteristic of each CI class.
Managed-by Groups: A class-level assignment of group ownership, which cascades to all CIs in this class. Note: A CI with a relationship to a Technical Service Offering (TSO) will override this setting and use the group associated with the TSO.
Extensibility and Model Configuration: Configure how CI classes can be extended and integrated with other models.
Identification/Reconciliation Rules: Determine the rules that govern the identification and updating of CIs, with the aim of ensuring data accuracy.
Only users who have the admin or sn_cmdb_admin roles can create new CI classes. Attributes are passed on through inheritance of classes, and new attributes can be added based on the appropriate class level and not the levels the classes have been inherited to.
How Identification Rules Work:
Each identifier entry has a 'Priority' value. The IRE evaluates entries in increasing order of priority. For example, if an entry combines 'Serial Number' and 'Serial Number Type', the IRE first checks for existing CIs with this combination. If a match is found, the CI is updated, and no further entries are evaluated. If no match is found, the IRE proceeds to the next identifier entry. If no match is found after evaluating all entries, a new CI is created .
Configuring New Identification Rules:
New identification rules can be configured in the CI Class Manager by using the 'Replace' button and then 'Add' under 'Identifier Entries'. You can choose attributes from the main table, a lookup table, or a combination. It's essential to specify the 'Priority' and 'Criterion Attributes' for each entry
Best Practices for CI Identification Rules:
- Review Out-of-the-Box (OOB) Rules: Alter the OOB rules based on the distinctive features available within each data source
Unique and Unchanging Attributes: The attributes should be unique and unchanged across the CI’s lifecycle.
Leverage Combinations: Use multiple attributes to identify things in combination.
Service Graph Connectors:Utilize Service Graph connectors to support third-party data integration.
Integration Hub ETL: Use this feature for manual data import to leverage IRE.
Periodic Review: Periodically review and update identification rules as your IT infrastructure changes
Identification Inclusion Rules:
These are the advanced rules which can restrict the CIs taken into consideration for identification. For example, you might create a rule specifying that you want to process CIs with 'Operational' status. These rules are set under 'Inclusion Rule (Advanced)' tab in CI Class Manager
CI Reconciliation Rules: Resolving Data Conflicts CI Reconciliation Rules are crucial for maintaining CMDB integrity when multiple data sources update the same CI. These rules determine which source has the authority to update specific CI attributes, resolving conflicts and discrepancies .
Accessing Reconciliation Rules:
Via CI Class Manager: Navigate to the desired CI class and select the 'Reconciliation Rules' tab.
Via Application Navigator: Go to 'Identification/Reconciliation > Reconciliation Definitions' to view rules across all CI classes.
Configuring Reconciliation Rules:
In the CI Class Manager, under the 'Reconciliation Rules' tab, you can add new rules. This involves specifying each 'Discovery source' and its 'Priority'. A higher priority value indicates greater authority. For example, ServiceNow Discovery might have a higher priority than a manual entry .
Types of Reconciliation Rules:
Static Rules: Set a manual value for the discovery source priority (for example, SCCM = 100, LANDesk = 90). The source with the highest priority will have the privilege to update the attributes. For these rules, the user can choose the attributes individually. Static rules are normally used.
Dynamic Rules: Choose the value by using dynamic rules like 'First reported', 'Most reported', 'Last reported', and 'Smallest/Largest values'. Dynamic rules take precedence over static rules if both are given.
Data Refresh Rules (Staleness Rules): Keeping Your CMDB Current Data Refresh Rules, also known as Staleness Rules, define when a CI is considered stale due to a lack of updates from its expected discovery source over a defined period (e.g., 14 days). These rules are essential for:
•Detecting missing or broken discovery processes.
•Identifying retired or disconnected devices.
•Ensuring the CMDB data remains current and accurate.
Recompute: Recompute is a forced recalculation based on changes to reconciliation rules. It's used when a rule changes and you need an immediate impact rather than waiting for the next scheduled job. This process deletes, updates, or recalculates attribute values based on the new rules.
If you found this article useful, please mark it as Helpful. It helps others find the content more easily 👍🙂
