ServiceNow London CMDB: 3 ways to resolve the missing CI relationships

In our first blog post on ServiceNow London CMDB, we discussed addressing the duplication of configuration items. We learned about ServiceNow CMDB that contains relevant information about components and the relationships between those components. In this blog post, we will talk about resolving the missing configuration items (CI) relationships from servers.

Challenge: Resolving the missing visibility of CIs

The missing relationship from ServiceNow CMDB is one of the issues that is often faced by developers. Visibility of your IT infrastructure is highly essential, especially when there is a rapid increase of CIs such as hardware, software, appliances, virtual machines, cloud services and mobile devices.

All CIs are consolidated into a single CMDB, considering unknown CIs, inconsistent parent-child relationships, or ill-defined missing CI. Missing CIs are encountered during the CMDB identification and reconciliation process. And once they are encountered, it becomes necessary to resolve them.

Missing CI is a very common issue, but the causes might be several. Here are some of the reasons why we face a missing CI issue.

• In case the Management, Instrumentation and Discovery (MID) server is down, and not in operating mode.
• In the occurrence of firewall issues. For instance, the device port is not accessible.
• During absolute chaos when the wrong IP is configured.

ServiceNow Discovery

ServiceNow Discovery tool helps to search applications and devices on your network, and then update the CMDB with relevant information. All discovered CIs are stored in cmdb_ci table (which is the parent table) and classified in various tables according to infrastructure.

In general, data including servers and it’s storage and configuration information, network devices (e.g. printers and routers), software programs, virtual machines, cloud services (e.g. Azure and AWS) and many more are collected through ServiceNow Discovery, and stored in ServiceNow CMDB.

Discovery collects unique data for each type of devices and stores them in related tables, fields, and relationships. Discovery identifies and classifies information about relationships between configuration items and manages this data by dividing into subclasses/tables using a relationship between them.

Solution: Three ways to check the missing CI relationship

Resolving the issue of missing CI is a high priority for any organization. In this section, we will see how it can be addressed. Here are three ways that can be used to fix all types of missing CIs.

The first way is to check the missing relationship by creating reports for different classes.

For example, take a cmdb_ci_windows_server table:

• Create reports for the server (cmdb_ci_windows_server) with filters which are running/installed/not decommissioned.
• Create another report for the cmdb_rel_ci table with filter child.class – windows server and relationship type – Runs on::Runs. It is important to make sure child.name is the first column.
• Export both the reports in Microsoft Excel.
• Put the reports in two different tabs – one sheet in one Excel.
• Run a VLOOKUP for the server name cmdb_ci_windows_server table and child.name in the cmdb_rel_ci table.
• A missing server in the relationship table indicates the missing relationship.
• You can follow the same procedure for all types of CIs.

This is an effective way to check for any missing CI relationship, but unfortunately it is time-consuming.

The second way is to use a GlideRecord query:

var servers = new GlideRecord(“cmdb_ci_win_server”);
servers.query(); //You can add filters as defined in reports as well
while (servers.next()) {
//Check the relationship exist for the specific server
var serverRel = new GlideRecord(“cmdb_rel_ci”);
serverRel.addQuery(“type.name”,”Runs on::Runs”); //Add another filter accordingly
serverRel.addQuery(“child”,servers.sys_id);
serverRel.query();
if(!serverRel.getRowCount())
{
//Then CI relationship is missing
}
}

The third way is using database views:

• Navigate to System Definition → Database Views.
• Create a new database view.
• Give a name to your file, say for example: u_missing_relationship.
• Give Label, say for example: Missing Relationship.
• Give Plural, say for example: Missing Relationships.
• Save the record.
• Now create/add a table to the database view.
• First table chooses cmdb_ci_win_server, variable prefix – ci, order – 100, left join – false.
• Create/add another table.
• Choose cmdb_rel_ci, variable prefix – rel, order – 200, left join – true, where clause – rel_parent = ci_sys_id || rel_child = ci_sys_id.
• Then click on ‘Try It’. (Note: It will take time to display the result based on your data).
• Add filter child is empty – if any, records are found here itself can be identified as ‘missing relationship’.
• Do the required steps to complete those missing relationships.

The last option is to refer about CI duplication. One of the possible reasons for missing CI Relationship is CI duplication. You can find the solution to duplication issues in our earlier blog post – ServiceNow London CMDB: Addressing the duplication of configuration items.

Insight
The occurrence of missing CI relationships is common in ServiceNow CMDB. Once the accurate profile of a particular CI is loaded and ensured, it becomes easy to resolve this matter. ServiceNow CI relationships are a major part of the CMDB as it is the relationship between the CIs that differentiate the CMDB from the asset database. If you wish to know more about how you can manage your data with ServiceNow, get in touch with our experts.

Co-author: Bhumi Gothi is a Senior Technical Analyst at Softweb Solutions. She has an extensive hands-on experience over different modules of ServiceNow.