Introduction
In the complex environment of contemporary IT, a reliable and trustworthy Configuration Management Database (CMDB) is the backbone of effective IT Service Management (ITSM). The CMDB in ServiceNow is the common repository for all Configuration Items (CIs), providing a single point of visibility for the entire IT environment. But it is often difficult to ensure the integrity and accuracy of this vital information, especially when multiple sources of data are contributing to the CMDB. This blog post will explore three key areas of CMDB health: CI Classification, CI Reclassification, and CMDB Deduplication, and provide best practices and the critical importance of the Identification and Reconciliation Engine (IRE) of ServiceNow in ensuring data accuracy.
1. CI Classification: The Building Block of a Healthy CMDB
CI Classification is the basic process of assigning a Configuration Item to its respective category in the ServiceNow CMDB structure. For example, a generic server may first be categorized as "Server," but as more information is gathered, it may be further categorized into a more detailed category such as "Windows Server" or "Linux Server." This detailed categorization is essential for several reasons:
- Data Accuracy: Correct categorization helps ensure that CIs inherit the right properties and relationships specific to their respective category, resulting in a more accurate and trustworthy data set.
- Better Reporting: Detailed categorization helps provide accurate reporting and analysis based on specific types of CIs, providing valuable input for IT operations and strategic planning.
- Better Discovery: Correct categorization helps discovery tools provide the right information and correctly identify CI types, optimizing the discovery process.
- Correct Dependency Mapping: It helps provide accurate mapping of services and their underlying infrastructure components, which is critical for impact analysis and root cause analysis.
2. Understanding CI Reclassification: Adapting to Change
CI Reclassification is the process of changing a CI's class after its initial discovery or reconciliation. This is a dynamic process, usually triggered by automated discovery software or manual changes, which may be a result of changes in the CI itself. There are three main types of reclassification, as classified by ServiceNow:
2.1. Upgrade: Moving Towards Specificity
Upgrade reclassification is the process of upgrading a CI from a generic class to a more specific class. This is usually done when a CI, such as a "Server" CI, is reclassified as a "Windows Server" or "Linux Server" based on its operating system. This type of reclassification is usually beneficial in terms of accuracy, as the CI can now inherit properties and relationships from its new, more specific class.
2.2. Downgrade: The Risk of Data Loss
Downgrade reclassification is the process of downgrading a CI from a specific class to a generic class (e.g., "Windows Server" to "Server"). This is usually done when specific properties are no longer applicable or when the CI is less defined. This type of reclassification is highly risky, as properties specific to the original class may be lost or become inaccessible.
2.3. Switch: Navigating Peer Classes
Switch reclassification is the process of switching a CI from one peer class to another (e.g., from a "Windows Server" to a "Linux Server"). This is essentially a downgrade to a common parent class (e.g., "Server") and then an upgrade to the new peer class. This type of reclassification is also highly risky, as properties may be lost if they are not common to both classes.
Here is a graphical representation of the above types of reclassification:
Automation and System Properties
The main automation tool for CI reclassification is the Identification and Reconciliation Engine (IRE). The IRE's operations are controlled by certain system properties that can be set to manage reclassification operations:
- glide.class.upgrade.enabled: This property determines the ability of the IRE to conduct upgrade reclassifications (default = true).
- glide.class.downgrade.enabled: This property determines the ability of the IRE to conduct downgrade reclassifications (default = true).
- glide.class.switch.enabled: This property determines the ability of the IRE to conduct switch reclassifications (default = true).
Also, there are Reclassification Restriction Rules that can be set to restrict certain class modifications, thus minimizing the risk of data loss or incorrect reclassifications.
3. CMDB Deduplication: Keeping Data Honest
You usually find issues related to duplicate Configuration Items (CIs) while working on CMDB problems, especially when a lot of data enters your system from different sources with no clear identification standards. It can be a disaster to work with this kind of duplicate data, and you might end up making wrong decisions. The causes of duplicate CIs are:
Automated Discovery: When data from different tools such as ServiceNow Discovery, SCCM, Intune, and AD is used, duplicate records can arise due to poor reconciliation.
Third Party Integrations: Another possible source of duplicate data is external system integrations.
Manual CI Creation: Human errors during manual creation of CI can result in additional copies.
Import Sets: Defects in import sets, such as missing identifiers, result in duplicate data.
Weak Identification Rules (IRE): Poor set up of IRE rules is another significant contributor to duplicates.
What is a Duplicate CI?
A CI is a duplicate if two or more CIs have identical values for the same Identification Rule. Matching occurs on a per-class basis and follows the priority set of identifiers. The IRE has three outcomes:
No match: a new CI is created.
One match: the existing CI is updated. - More than one match: when a duplicate match exists, a Deduplication Task is scheduled. Usually, the oldest CI by creation date is assigned as Primary CI, and all others are marked as duplicate CIs.
Role of Identification Rules (IRE)
Identification Rules
A set of Identification Rules dictates the manner in which the ServiceNow system will determine whether to create, modify, or mark a CI as a duplicate. Identification Rules also identify which is the Primary CI and which are the duplicates. Key points regarding IRE:
- "IRE operates even if Discovery isn't present."
- Discovery increases the accuracy of deduplication.
- Only the first matching identifier rule applies.
- Such identifiers can include items such as Serial Number, Serial Number and Type, MAC Address, and Name.
Warning: Weakly configured IRE implementations result in numerous duplicates; well-configured IRE implementations keep the CMDB free of duplicates.
Task Creation and Remediation for Deduplication
A deduplication task is only generated after a defined threshold of duplication is achieved. This task identifies the duplicate CIs, the attributes used to identify them, as well as the identifying rule. Due to the risks associated with data, deduplication tasks cannot be auto-fixed. There are two primary methods to remediate deduplication:
5.1. Wizard
This method works best when you are dealing with only a handful of duplicates and you do it by hand:
- Pick the Main CI: Decide which CI to keep.
- Merge Attributes: Merge all the attributes found in the duplicates to the original CI.
- Merge Relationships: Combine the relationships present in the dupes.
- Determine the course to take with the duplicate: the choices are delete, retire, or keep with changes.
The manual method using the wizard is accurate; however, it becomes very time-consuming if there are many duplicate values.
5.2. Template
Templates are great for large-scale deduplication jobs because they run automatically:
- Choose Main CI Selection Logic: Set criteria to determine the winning CI (for example, the choice of the oldest, or the one with the most relationships).
- Set Attribute Merge Rules: Define the attribute merge rules.
- Set Relationship Merge Rules: Determine how relationships should be merged.
- Define Delete/R Retain Behavior: Determine how to handle duplicates.
- Auto-apply to Matching Classes: Enable the template to apply itself to matching CI classes.
Caution: Templates are powerful and dangerous in a misconfigured way, but awesome for creating a thousand duplicate entries.
The following diagram illustrates the IRE process, which includes deduplication.
Conclusion
A well-maintained and accurate ServiceNow CMDB is a fundamental requirement for facilitating effective IT operations as well as informed decisions within the IT infrastructure of any business domain. By adopting the best practices related to the process of CI Classification, Reclassification, as well as CMDB Deduplication, any business domain is sure to derive benefits within the realm of its IT infrastructure by leveraging the Identification and Reconciliation Engine. The IRE can assist in ensuring that the CMDB always remains a trusted source of truth within the IT ecosystem of a business domain. Thus, being proactive towards adopting the best practices within the realm of CMDB Deduplication augurs well for the IT process as a whole within the business domain in consideration.
If you found this article useful, please mark it as Helpful. It helps others find the content more easily 👍🙂
