CIs With Name Populated


Get Well Playbook

CIs With Name Populated

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 John Walker
Date 06/09/2020
Addresses HSD # HSD0003788, HSD0006974
Applicable ServiceNow Releases Madrid, New York, Orlando, Paris, Quebec
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.  This play includes a script you can use to see these CIs.

Required tasks

  1. Run the Script to see the CIs

  2. Review the results of the script.  Focus on this section of the results of the script. 

Play 2 - Analyze your CI Records

What is this Play about?

This play lets you 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.

With this play you continuing analyzing the records for your CIs.  This play allows you to determine which CIs need names.  To determine those CIs, Navigation Modules (links) have been provided in this CIsWithoutNames_UpdateSet.

There are two reports available if you navigate to Reports > View / Run and search for "getwell". One report is for Hardware and the other Applications. These are the higher priority items for this metric.

Example:

Required tasks

  1. Install the Update Set (above) to get the reports and help locate the high priority CIs without names.

  2. Optional - Use one of the reports from the Update Set to view records in Applications or Hardware classes.

    Example report:
  3. Optional - 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.  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

(You don’t need to delete the additional fields already included in the Selected column.  You can keep Installation directory, Configuration directory, Configuration file, and Version)

  1. 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. 

 

  1. 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.  This implies that resolving the problem isn’t urgent.  However, this still needs to be addressed to keep it from becoming urgent.

If you see a lot of records created without a name, check the Created on dates and see if there’s a pattern.  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 archiving to store data you no longer need.  For example, you can move the CIs with invalid or empty (unpopulated) names to archive storage to get them out of your way.  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.

  • 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

Follow the instructions in data archiving.

 

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

What this play is about

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

CIs in the CMDB should have unique names, and the names should be based on agreed-upon naming standards. 

However, there are some exceptions.  These exceptions include:

    • Identical artifacts (war files, virtual directories) used on many systems
    • VPN adapters on workstations
    • Disk drives and storage components
    • CPUs and memory modules
    • Switching and routing components
    • CIs in On order Status, created through Asset on-boarding

Most of these devices aren’t normally used directly within IT Service Management (ITSM) or other applications.

You can filter them out using Reference Qualifiers.  Names for ancillary components of workstations and servers aren’t unique because the components are either related to or contain references to their host machines, such as Linux or Windows servers. They often don’t have unique names since they are otherwise identical.  A reference or Relationship is used to distinguish them.

Devices that might be identically named, but perhaps should have unique names include the following classes:

    • Network printers
    • UPS devices
    • Video conferencing equipment  or large display screens

Devices that are used by teams (such as  Facilities Management) to report a malfunctioning device, could benefit from having unique names. Unique device names could help locate the device in the CMDB faster.

Attempting to find a specific CI when the name is not unique could be a frustrating experience.

Labels on a physical device (such as a printer) should match what is shown in the CMDB.

Required tasks

  1. Download the Duplicate Names in CMDB Helper Scripts Update Set

  2. Navigate to Retrieved Update Sets and use Import from XML to load the script.

  3. Preview the Update Set.

  4. Commit the Update Set.

  5. Reload the main window and then navigate to Configuration > Hardware Items with Duplicate Names. Depending on your environment, it may take a moment for the script to load.

    A window similar to the following appears.

  1. Review the items in the list to determine their source, or decide if you want to keep the name the same.

    Items such as iPads or iPhones may not need unique names. You can edit the cmdb.getwell.duplicate_names.hardware.ignore_list system property to add these to a whitelist.

    If you know or can determine the correct name for a record, use the list editor to correct the names. Only records with the same name appear on the list once you’ve changed the names.

 

Sync Data from another Field into Name

It may be true that Configuration Items 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:

    1. Fix the existing records - Fix Script

    2. 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

 

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

  1. Navigate to Configuration > CI Class Manager

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



  3. 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.

  1. Click on Application Class



  2. Click on Health

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



  4. 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.

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

  6. Navigate to Configuration > CMDB View.

  7. Click the CMDB Health Dashboard Jobs tab

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

  9. 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.