ServiceNow London CMDB: Addressing the duplication of configuration items

ServiceNow London’s configuration management database (CMDB) plays a vital role in an organization’s IT services. It contains all relevant information about the hardware and software components and the relationships between those components. The CMDB also provides a structured and organized view of all the configured data, so that organizations can examine data easily.

Within the CMDB, the components of an information system are referred to as configuration items (CI). In fact, CI can be easily referred to as any IT component, including software, hardware, documentation, and personnel, as well as the combination of dependencies between them. There’s always a need for IT teams to implement processes to interrogate the state of the CIs with the aim to specify, control and track them with any changes made to them comprehensively.

Challenge: Duplication impacts the company’s IT structure.

Just like any other CMDB, the ServiceNow CMDB also faces one particular challenge associated with the growing CMDB data. It is often increasingly tough for administrators to keep track of CMDB modules and as well as track the relevant data. It gets more and more challenging to ensure that your CMDB remains accurate.

The only way to prevent this challenge is to be prepared to address the associated complexity and dynamic nature of an organization’s IT environment, meaning they need to continuously move and upgrade (i.e. server names and IP addresses should commonly be repurposed when new projects arrive) as required.

The management of duplicate CIs in the ServiceNow CMDB is definitely a serious problem for organizations. Here are some of the business challenges that many enterprises face. Firstly, duplicate CIs make it difficult to report on incident change and problem trends. And, it can be costlier for enterprises to spend on new licenses and maintenance activities. Moreover, you will fail to leverage accurate inventory asset reports and it may harm the productivity of your operations. Finally, the duplication of CI can erode the trust developed in the configuration management.
Resolving the duplicate CIs is one of the high priorities for any organization’s configuration management team. Let’s see how we can check on duplicate CIs in the CMDB and resolve this issue.

There are many ways to insert CI records into the CMDB without any checking to see if another CI with the same attribute already exists. There are two mechanisms, namely, the REST Explorer and Glide Record objects that is often used to insert records into tables where there are no rules of checking with identification. For better or worse, in such scenarios, the CI records with identical attributes will always find a way into the CMDB.

Solution: How to resolve CI duplication

Duplicate CIs are encountered during the CMDB identification and reconciliation process. And once they are encountered, each set of duplicate CIs is grouped in a de-duplication task for remediation. The cause of this might be weak identification rules. There are a number of ways in which IT teams can detect and merge the duplicate CIs.

One way to detect duplicate CIs is by creating background scripts. For instance, you can check the unique field in the form which should be unique for each record of your table. It can be your mac address, IP address or asset tag. Run the script and you will find the dupes in front of you.

The second way is the most practiced; some discovery issues may be resolved by a one-time delete. You may delete a duplicate server record if it matches all of the following criteria:
— No tasks are associated with the CI.

If tasks are associated with both of the duplicate records, merge these records using the following steps:

• i. Select the newer record as the record to be deleted.
• ii. Change the name of the record you plan to delete.
• iii. Merge all relevant data to the older record.
• iv. Delete the duplicate record.
• v. After deletion, revisit the duplicate CI after a few days to ensure that the issue did not recur. If so, continue troubleshooting.

During the CI identification method in the CMDB, duplicate CIs are determined by the following properties:

• glide.identification_engine.skip_duplicates: True by default.
• glide.identification_engine.skip_duplicates.threshold: set to 5 by default.

To modify these properties we need to add them to the System Properties (sys_properties) table, where the numbers of duplicate CIs are detected. You can configure these properties so duplicated CIs are automatically reconciled, skipping duplication.

If glide.identification_engine.skip_duplicates is true, and the numbers of duplicate CIs are lesser than the threshold specified by glide.identification_engine.skip_duplicates.threshold, then the oldest of the duplicate CIs are picked as a match and gets updated.

The rest of the duplicate CIs are tagged as duplicates by setting the cmdb_ci’s discovery_source field as ‘Duplicate’. During matching, the identification engine filters out any CIs in which statediscovery_source=Duplicate. If glide.identification_engine.skip_duplicates is false, then matching of duplicate CIs fails with an error, and none of the duplicate CIs are updated.

ServiceNow Discovery

ServiceNow’s Discovery tool helps to identify the computers and devices that are connected to your network. It functions to configure the connected computers and devices with their current status and updates the CMDB.

Discovery tool enables IT teams, to take a more hands-off approach for their configuration management. Although it generates automated discovery in the IT environment, it does not completely eliminate manual entry. For instance, the IT teams may still require monitoring of some details such as the renewal of hardware and more.

ServiceNow Discovery helps to prevent duplication of CIs. Each CI item records unique identified based field values that are specified in the CI identifier rule. The CI is identified as ‘duplicate’ if the field value of another record is of the same class. By default, the CIs of hardware class and its subclasses including a computer, server, Unix server, Windows server, all use an OS serial number as the unique identifier.

For instance, when ServiceNow Discovery discovers a CI, the sensors and patterns use the internal function (SNC.IdentificationEngineScriptableApi.createOrUpdateCI) to send the CI to the CMDB. If there was already an existing CI with the same attributes for that particular class, it is overwritten; else a new CI is generated.

Duplicate CI Remediator

Enterprise can largely benefit from the ServiceNow Duplicate CI Remediator — a system wizard that guides through the reconciliation process. It aims to provide detailed information about duplicate CIs including the attributes, relationships, and related items to retain and to reconcile.
IT teams can leverage the CMDBDuplicateTaskUtils API to manually create a de-duplication task for duplicate CIs which are not configured to be detected in the system. After initiation of this step, you can then remediate those tasks using the Duplicate CI Remediator that is similar to remediating a system generated during the de-duplication task.

Benefits of resolving CI duplication

Resolving CI duplication should be one of the high priorities for organizations as it has an impact on the overall value-addition of the CMDB within an organization. One of the main benefits is that IT teams will be able to leverage populating configuration items into the CMDB, along with the following benefits:
Enterprises will benefit from improved processes such as incident management, change management, and problem management by providing an overall impact analysis of CI to their business applications. Additionally, they will also benefit from reduced time to recovery of outages of applications because it will be easier to understand the application topology and all their dependencies.

Enterprises will be able to improve the effectiveness of monitoring tools by associating business impact with detected problems associated with infrastructure components.

Importantly, enterprises will be able to practice effective strategic planning with their data. It will be easier to move, consolidate, and optimize the hardware without any disruption to the business that depends on it. Moreover, enterprises will be able to better manage and control the costs of IT assets since there is an accurate understanding of what assets are deployed and used.

Organizations will always be prepared with their data compliance and audit reports that are required from IT organizations. And finally, an organization will achieve better control of configuration changes that are needed for on-going maintenance of software and hardware.

The Final Say
When your processes align with your CMDB accurately and efficiently, your organization will gain many benefits with minimal efforts. There is a huge value of clarity associated with correct information that describes the CIs in the CMDB, and it will fundamentally change the way IT communications operate within your organization.

Watch out for our next blog on ServiceNow London CMDB — server relationship challenge and get extra guidance from our consulting experts.

Co-author: Gazal Jain is a ServiceNow developer at Softweb Solutions. She has extensive hands-on experience over different modules of ServiceNow.

Originally published at https://www.softwebsolutions.com on January 29, 2019.