CMDB Identification & Reconciliation

The Identification and Reconciliation also known as the Identification Reconciliation Engine (IRE). It provides a centralized method for identifying and reconciling data from different data sources. 

Reconciliation Rule: It is used for updating the data if new values are from a more trusted source than existing data.

I&R helps to maintain the integrity of the CMDB by managing duplicate CIs and controlling updates to CIs when multiple data sources such as Discovery, Service Mapping, Import Sets, and REST integrations are used to create and update CI records.

If you are using multiple data source to import data into CMDB table then it will increases the risk of inconsistencies through duplicate records.

To maintain the integrity of the CMDB, it is important to identify CIs and services correctly so that the new records are created only for CIs that are truly new to the CMDB.

I and R rules help to prevent duplication of CI records, reconcile CI attributes, reclassify CIs, and allow only authoritative data sources to update CI records in the CMDB.

Identification Rules

The most efficient way to populate the CMDB is with an automated discovery tool such as ServiceNow Discovery or a 3rd party discovery tool such as SCCM. 

Identification rule applies to a CI class and it can be single or multiple with different priority.

If additional rules are required to be created beyond the default identification rules,

It is recommend to create good rules that are set with the highest priority for the strongest identifier entries. 

Common Inaccuracies in the CMDB

• Duplicate CIs: Multiple CIs are in the CMDB that represent a single CI. This situation may occur if the identification rules for CIs do not ensure that each CI is uniquely expressed with identifier entries that do not change.

• Overloaded CIs: an opposite problem to duplicate CIs, overloaded CIs are when different CIs are identified as the same CI and one CI is created when several CIs should’ve been created.

Both of these problems occur when the attributes used to identify configuration items do not properly represent the identity of a CI. 

Hardware Rule:

Hardware identification rule used to manage all hardware inserts and updates into the CMDB. This includes any CI inserted or updated into the Hardware table (cmdb_ci_hardware) or any of its extended tables such as the Server table (cmdb_ci_server)

Good and Bad Application Identification Rules:

In below scenario if you go with name then it’s consider as bad identifier and if you go with config file name or installation directory or configure file path then it’s a good identifier.

Example for Bad identifier

Example for Good identifier

Reconciliation Definition and Data Source Precedence Rules

Understanding and controlling which data sources are updating CMDB data is crucial to trusting the data in the CMDB. 

Reconciliation Rules

Reconciliation rules specify which data sources can update a table or a set of table attributes, and they can be defined at the parent and/or the child class level. It is always good practice to ensure that there is a reconciliation rule in place for each data source that is authorized to update CIs in the CMDB.

Data Source	Applies To	Attribute
ServiceNow	cmdb_ci_win_server	RAM
Import Set	cmdb_ci_win_server	RAM
LANDesk	cmdb_ci_win_server	RAM

Above data source will update the windows server RAM attribute.

Data Source	Applies To	Attribute
ServiceNow	cmdb_ci_win_server	—
Import Set	cmdb_ci_win_server	—
LANDesk	cmdb_ci_win_server	—

Above data source will update the windows server data.

Let’s take an example.

Data Source	CI Details
LANDesk	Name: Win Server0001 RAM: 8GB (CI Inserted)
Import Set	Name: Win Server0001 RAM: 12GB (CI Updated with 12GB)
ServiceNow	Name: Win Server0001 RAM: 32GB (CI Updated with 32GB)
Import Set	Name: Win Server0001 RAM: 12GB (CI Updated with 12GB)

To overcome from above scenario ServiceNow have Data Source Precedence Rules

Data Source Precedence Rules

If multiple data sources are authorized to update the same class or the same class attributes in the CMDB, data source precedence rules can be set up for each data source in order to allow customers to control which data source they consider to be the authoritative source of truth for a specific class or class attribute. Without data source precedence rules, data sources can overwrite each other’s modifications.

For example let’s take same scenario with order

Data Source	Applies To	Order
ServiceNow	cmdb_ci_win_server	100
Import Set	cmdb_ci_win_server	200
LANDesk	cmdb_ci_win_server	300

Data Source	CI Details
LANDesk	Name: Win Server0001 RAM: 8GB (CI Inserted)
Import Set	Name: Win Server0001 RAM: 12GB (CI Updated with 12GB)
ServiceNow	Name: Win Server0001 RAM: 32GB (CI Updated with 32GB)
Import Set	Name: Win Server0001 RAM: 12GB (Update not allowed due to higher order)