CIs With Name Populated

Get Well Playbook

A guide for how to manage CIs with invalid or empty (unpopulated) names

Table of Contents

Summary

Goal of this Playbook

Audience

Problem Overview

Executive Summary

How this playbook can help you achieve business goals

How this playbook is structured

Problem Analysis

Upstream Causes

Downstream Consequences

Impact on Your Business

Engagement Questions

Remediation Plays

Summary

Play 1: Review your data

Play 2: Analyze your CI records

Play 3: Fix Play (Optional): Archive your data

Play 4: Fix Play (Optional): Correct CIs with duplicate names

Play 5: Fix Play (Optional): Troubleshoot Patterns

Data Governance

Summary

Goal of this Playbook

The Configuration Management Database (CMDB) needs a way to uniquely identify configuration items (CIs). Valid CI names are critical for using many of the features of the CMDB and other ServiceNow applications

The goal of this playbook is to help you manage those CIs that have empty (unpopulated) Name fields.

Scope

This instructions in this playbook assume that you have already set up and configured the CMDB Health. Setting up CMDB Health is outside the scope of this playbook. For information about setting up CMDB Health, see Setup and configure CMDB Health .

Note: Certain CI classes do not require a name value. They will be excluded from scoring here.

Details about this playbook

Author Michael Walker, Callan Bond Date 05/01/2025 Addresses HSD # HSD0003788, HSD0006974 Applicable ServiceNow Releases All Releases Time required Approximately 1 to 8 hours Audience

Configuration Manager or Configuration Management team

ServiceNow Admin or Discovery Admin Problem Overview

CIs in the CMDB are identified by what is entered in the Name field when a CI is created. An appropriate name must be entered in the Name field. If the field is left blank (unpopulated) the CI name is listed as "empty" on lists, forms, and reports.

Having all the CIs listed as "empty" makes it's difficult for you to distinguish one from another. You may not be able to select the one you want on form views, lookups, and bindings (such as those in Event Management). These empty CIs appear as duplicates, or they may become duplicates.

Without the CI names, you may see list views similar to this example when using the product

Executive Summary

How this playbook can help you achieve business goals

Having valid names for your CIs in the CMDB and all ServiceNow applications helps in the following ways:

Increases visibility into your infrastructure and services. This increased visibility gives you more control of your environment and allows you to make better decisions.

Better decisions can lead to improvement in the areas such as service impact analysis, asset management, compliance, and configuration management. For the CMDB, improves operational visibility by ensuring that the data in the CMDB is accurate.

Improves the reliability of the audit tool.

Improves the performance of the applications that rely on the CMDB.

How this playbook is structured

This playbook guides you through a series of tasks or processes called plays. These plays help you identify the CIs with invalid or empty (unpopulated) names, and how to remediate them. Each play is listed below:

Play 1: Review your data. Use this play to see a list the CIs in your CMDB that have invalid or empty (unpopulated) names.

Play 2: Analyze your CI records. Use this play to further analyze the CIs with invalid or empty (unpopulated) CIs.

Play 3: (Optional) Archive data you no longer need.

Play 4: (Optional) Correct the CIs with duplicate names.

Play 5: (Optional) Troubleshoot problems with the Discovery Patterns. This play also includes installing the Discovery Pattern Log Viewer tool.

Play 6: This is a data governance play. It include instructions for how to avoid creating CIs with invalid or empty (unpopulated) names in the future.

Problem Analysis

Upstream Causes

Invalid or empty (unpopulated) name fields for a CI could be a result of:

A failure of one or more Discovery patterns

Another field (such as host_name or fqdn) on the form is being used to provide the name.

The name field isn't set as mandatory. (The mandatory fields should always be set to true. )

A failure to enforce the use of mandatory fields.

A failure in the data import process. Procedural problems related to server / host retirement. Names might be accidentally reused.

Downstream Consequences

Data Consequence

List views with multiple, and identical, records all listed as empty records

Manual effort is required to remediate the empty records

Operation Consequence

You might need to create special queries to remediate any CIs with invalid or unpopulated names. Creating these queries increases overhead costs.

Results in a poor user experience. Remediating and managing these invalid or unpopulated names interferes with moving forward with the business.

App Consequence

Invalid or empty (unpopulated) names can:

Affect binding for Event Management

Make selecting CIs for Incident Management and Change Management more difficult

Affect performance of your platform applications. Since most platform applications use CIs in some manner, having valid names for your CIs is essential.

Impact on Your Business

Invalid or empty (unpopulated) names can erode your trust the data in the CMDB. When your trust is eroded, your business is adversely affected in the following areas.

System Integrity

Untrustworthy data can lead to inaccurate decisions within the system.

Data Governance

Governance guidelines or processes are not being applied or followed.

Data Accuracy

You resort to using other systems to validate the data in the CMDB.

Engagement Questions:

Consider the answers to these questions:

Have you noticed any CIs with empty name fields?

Are the names in your CMDB accurate? Are the names useful?

How is the glide.required.attribute.enabled system property configured? By default, it is set to true.

Do you have a policy for naming CIs? If so, has it been approved by the appropriate management team? Is the policy posted somewhere people can find it?

Remediation Plays

Summary

The table below lists and summarizes each of the remediation plays in the playbook. Details are included later.

Play Name

Review your data

What this play is about

Review the CIs in your CMDB that have invalid or empty (unpopulated) names. This play includes a script you can use to see these CIs.

Required tasks

Use the script and review the script results.

Analyze your CI records

What this play is about

Continuing analyzing the records for your CIs. This play allows you to determine which CIs need names.

Required tasks

To determine those CIs, Navigation Modules (links) have been provided with an Update Set. Complete validation steps.

Archive your data (optional)

What this play is about

Describes using data archiving to store data you no longer need.

Required tasks

Complete the steps to archive your data. Complete the validation steps.

Correct CIs with duplicate names (Optional)

What this play is about

Explains the importance of using unique names for your CIs, the reason behind having unique names, and possible exceptions.

Required tasks

Use the Duplicate Names in CMDB Helper Scripts Update Set, or use the use the list editor to correct the names.

Troubleshoot Patterns (Optional)

What this play is about

Explains how to use the Pattern Logs to determine why CIs without valid names are being created.

Required tasks

Follow the troubleshooting tips. Install the Discovery Pattern Diagnostic View Tool.

Use the Discovery Pattern Log Viewer Tool

What this play is about

This is a continuation of troubleshooting patterns.

Required tasks

Continue using the Discovery Pattern Log Viewer Tool to troubleshoot Discovery patterns.

Data Governance

What this play is about

This play tells you how to set up a CI field as recommended.

Required tasks

Follow the instructions to set up a CI field as recommended. Complete the validation steps.

Play 1 - Review your data

What is this Play about?

This play lets you review the CIs in your CMDB that have invalid or empty (unpopulated) names. To find the state of your CIs’ health score and a list of details, use the CMDB and CSDM Data Foundations Dashboards .

Required tasks

Step 1 : If you are on Xanadu family release or higher, the CMDB and CSDM Data Foundations Dashboards are available out of box. If you are on a version previous to Xanadu, navigate to the ServiceNow Store, search for “CMDB Data Foundations”, and install the free Store app.

View the ServiceNow docs site to learn more about installing and configuring the Dashboards if you are setting them up for the first time.

Step 2: Navigate to the CMDB Data Foundation Dashboard

Step 3: Navigate to the “Data Management Practices” tab and review the “CIs with Names” metric.

This metric looks only at Operational records in the Hardware and VM instance classes. If your score shows 100%, there are no stale Cis in those classes so no further action is required. However, this metric should be reviewed monthly.

Play 2 - Analyze your CI Records

What is this Play about?

If you have Operational CI records without a Name, this play lets you review those CIs in more detail and determine possible courses of action for remediation.

There are two methods to look at the CIs in more detail in a list view:

Method 1: Click on the “CIs Missing Names” historical graph widget in the CMDB Data Foundations Dashboard to review individual records. Once the PA widget is open, click on “Show Records” in the upper right. Method 2: Navigate to list view on cmdb_ci_hardware or cmdb_ci_appl to see when and where the CI was created and who created it. In this method you must reapply the filters to get to the same list of CIs. The filter conditions are: Name is empty (null) Operational status is Operational. You may use another lifecycle stage field or value if your organization does not use the Operational Status field with out of the box value of Operational to denote an active CI. In either method you can now do use the following steps to do further analysis to determine root cause of the CIs not having names.

Step 1: You can personalize (using the gear icon) the list columns to include these fields in the view:

Name Class Created Created by Updated Updated by Most recent discovery Operational status Discovery source

Step 2: Use the Group by the Class field to sort the items.

Sorting the items by group shows you the relevant classes.

This example shows that the 683 records without names are all located in two classes: Tomcat WAR and IIS Virtual Directory.

Note the following points:

Do not assume that all the items in either class need names. Look at the total number of these items without the filter of Name = NULL.

After changing the condition filter, there are now 99,938 records, indicating that only some CIs need names.

Step 3: Sort the results by Created in reverse (Z-A) and then hover the cursor over the Created field to how long ago these CIs were created.

In the above example, the records were created 5 months ago, and the number isn't increasing significantly. It is recommended that operational data (e.g., hardware or VMs) in the CMDB be kept current. Normally, operational CIs are discovered through automated means every day (or week at the latest), so the Updated date is typically 1 – 7 days old. If data is stale, it should be remediated (e.g., Discovery schedules created or fixed) or Retired (use Data Manager to retire). Refer to KB0829106 for more information on managing Stale CI data.

Step 4: Check for a pattern with the Created on dates. For example, maybe the records are created at the same cadence (nightly, weekly, Tuesdays and Thursdays) as the Discovery schedules or the third-party discovery sources. If that's true, then the records may be created by the MID server account.

The remediation steps you take depend on the root cause.

For Discovery, investigate the Discovery or Pattern Logs for the relevant hosts and applications and make the appropriate corrections. The fundamentals of Discovery Pattern design and troubleshooting are outside the scope of this playbook. To diagnose a Discovery Pattern issue related to missing names, see Fix Play 5. Also, schedule time with your Discovery Administrator when you complete Fix Play 5. For Integrations, review Import Sets and Transform Histories to determine the cause. Note that integrations might be configured as Scheduled Data Imports and should be configured to run as an ID specifically for that purpose. This assists in reading audit logs to troubleshoot the individual updates to field values on each record. If under System Import Sets > Scheduled Imports you see an active record for the import or integration in question, open the record and check the setting of the Run as field. This should be a reference to a user id specifically for that import. Note these points about scheduled imports: Do not run imports using a person's account It is difficult to read audit logs if imports have no Run as value, and are thus running as System Run imports as their own user account with the import_admin role Manual Entry might still be allowing records to be created when they are incomplete.

Play 3: Fix Play (Optional): Archive your data

You can use Data Manager to Retire and Archive data you no longer need. For example, if you determine that the CIs with invalid or empty (unpopulated) names were created in error or now have correct, named versions stored as other CIs, you may decide to create a policy to Retire and Archive them. Later, if you decide you need these records again, you can always get them back.

When you archive records, keep the following points in mind.

Decide if you want to take the time to add names for stale CIs. Check to see how recently the CI has been updated. If the records are incomplete, the records may not be worth archiving. You may also use Data Manager to delete incorrect data that has been populated into your CMDB. Refer to ServiceNow docs for full details on using Data Manager to create a Retirement policy. Be sure to follow your company's policies on retaining data. Retention period is set in Data Manager when creating an Archive policy. If you decide to keep these records, give them accurate names. Then run the Analysis Play script again to see how many invalid or empty (unpopulated) CIs you still have. When you archive records, keep the following points in mind.

Decide if you want to take the time to add names for stale CIs. Check to see how recently the CI has been updated.

If the records are incomplete, the records may not be worth archiving.

Be sure to follow your company's policies on retaining data.

If you decide to keep these records, give them accurate names. Then run the Analysis Play script again to see how many invalid or empty (unpopulated) CIs you still have. Required tasks

If the CIs with no Names have not been updated for more than 60 days, refer to KB0829106 for more information on managing Stale CI data.

Play 4: Fix Play (Optional): Correct CIs with duplicate names

Configuration Items can have another attribute populated with data which would be an excellent candidate for use as the name of the CI.

Examples include:

IIS Virtual Directories have the alias field populated from the AppFriendlyName attribute in IIS Server records may be using the host_name field instead of name Using data from another field is a two step process:

Fix the existing records - Fix Script Keep future updates to those records in sync - Business Rule Fix Existing Records

Existing records can have these values copied over once using a Fix Script

Keep future records in Sync

To keep these records updated going forward, the source updating the alternate field should be amended to also update the name field.

A quick means to sync this field data could also include using a lightweight Business Rule. Lightweight means that care should always be taken to NOT burden the CMDB with Business Rule execution.

Good Business Rules should:

Have narrowly defined conditions on when they run Have thoughtfully selected placement among the tables they run on Have meaningful names to describe what they are doing Have clearly notated scripting to denote their intent Rules like this should run early (lower order number) so that the data is in both fields before later rules (higher numbers) execute Avoid calling gr.update() in any Business Rule - remember that a BR is running because update (or insert) is already happening An example Business Rule to sync the host_name and name fields on the cmdb_ci_server is attached to this article . It is not marked as active so that it can be reviewed & edited prior to use in your environment.

Example Business Rule - Narrowly controlled execution

Business Rule Example - Scripting with meaningful comments

over once using a Fix Script

Keep future records in Sync

To keep these records updated going forward, the source updating the alternate field should be amended to also update the name field.

A quick means to sync this field data could also include using a lightweight Business Rule. Lightweight means that care should always be taken to NOT burden the CMDB with Business Rule execution.

Good Business Rules should:

Have narrowly defined conditions on when they run

Have thoughtfully selected placement among the tables they run on

Have meaningful names to describe what they are doing

Have clearly notated scripting to denote their intent

Rules like this should run early (lower order number) so that the data is in both fields before later rules (higher numbers) execute

Avoid calling gr.update() in any Business Rule - remember that a BR is running because update (or insert) is already happening An example Business Rule to sync the host_name and name fields on the cmdb_ci_server is attached to this article . It is not marked as active so that it can be reviewed & edited prior to use in your environment.

Example Business Rule - Narrowly controlled execution

Business Rule Example - Scripting with meaningful comments

Play 5: Fix Play (Optional): Troubleshoot Patterns

An advanced article with an example of Pattern Diagnosis & Adjustment is available at KB0830050

This should be completed by a Discovery Administrator or client resource with Discovery skills

Data Governance

What is this Play about ?

This play tells you how to set up a CI field as recommended. For more information about setting up recommended fields, see Set a CI field to be recommended .

Required tasks

Navigate to Configuration > CI Class Manager

At the Welcome to CI Class Manager window, click either Hierarchy or Open Hierarchy .

In the Search CI Classes input, type "Tomcat WAR". When the results load, notice the hierarchy of the CDMB tables. We want to tell the system that fields like name are required / recommended. It makes sense to place this requirement on all Applications.

Notice the hierarchy of the CDMB tables in the search results. Because you want the Name field to be a required field, apply this requirement to all Applications.

Click on Application Class

Click on Health

Click on Completeness underneath Health. Then select the Recommended Fields tab.

Add fields here to suggest that high-value attributes such as name are populated. The field could also be set as required, but this may preclude users from otherwise updating the records when they are opened in Form View unless they also populate any required fields. Since they may not know all of these values, take care when setting fields to Required (in the Dictionary) since it can interfere with the user's ability to interact with the record otherwise.

Click Save in the bottom right-hand side and continue to Verification steps

Navigate to Configuration > CMDB View .

Click the CMDB Health Dashboard Jobs tab

Open the CMDB Health Dashboard – Completeness Score Calculation scheduled job.

Click Execute Now The amount of time required to complete this job depends on the number of records.

When the job has completed, check the CMDB View Dashboard - CMDB Completeness Scorecard to see the adjusted completeness scores.

Congratulations

You have completed this Get Well Playbook.