Percent of Hardware CIs installed but name and hostname do not match

Get Well Playbook

Remediating conflicting information within your CMDB

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: Analysis: The size of the problem

Play 2: Analysis: Single example record

Play 3: Remediation: List View

Play 4: Analysis / Remediation: Discovery gaps

Data Governance

Summary

Goal of this Playbook

To help identify and correct records which are showing they are installed, but the 'host_name' and 'name' fields are not in agreement.

Details about this playbook

Author John (Johnny) Walker Date 11/20/2020 Addresses HSD # HSD0003798 Applicable ServiceNow Releases All Time required Approximately 1 to 8 hours Audience

Configuration Manager or Configuration Management team

ServiceNow Admin or Discovery Admin

Problem Overview

Records within the CMDB should be accurate without any conflicting information within the records themselves. If the values in the 'name' and 'host_name' fields are in conflict, then the records are not reliable and consequently, all the processes making use of them (specifically Incident, Problem and Change Management) are drawn into question and rendered useless. These practices are designed to mitigate risk – but they can't do that when the underlying data is inaccurate or unreliable. A system only has to fail once for it to be ineffective.

How could the practices of Change, Problem or Incident Management stand up to any scrutiny if the records used in their processes contain conflicting information such as the name or hostname of the device being managed?

Executive Summary

How this playbook can help you achieve business goals

Identifying and correcting conflicting information within your CMDB will strengthen your position to make accurate and correct decisions regarding your business operations.

Inaccurate records within the CMDB can lead to undesired results in all the processes that rely upon them – there are many! How this playbook is structured

This Playbook is structured to guide you through 5 plays:

The first play is an analysis play to help make clear the size of the problem.

The second play is also an analysis play, this one intended to assist you with determining the origin of the data mismatch between 'name' and 'host_name' on a single example record.

The third play is fix or remediation play, using List View to correct a small number of records.

The fourth play is optional depending on if ServiceNow Discovery is part of your solution to keep records updated. If so, this play is designed to help you determine if your configuration items with these data mismatches are included within your Discovery Schedules.

The fifth play is Governance designed to help you monitor progress in remediating what you've uncovered in Play 1 & 2, and to help guard against future inaccuracies through automation.

Problem Analysis

Upstream Causes

Manually created records are likely to have poor data quality

Integrations/Third Party sources of data might be incorrectly updating records due to an error within the Import/Transform process

Consuming CMDB data from another system of record within your organization where there is very little data governance or accountability in place

Lack of coverage from a trusted source like ServiceNow Discovery to accurately update records on a recurring basis

Custom or customized Discovery Patterns which may not be setting the expected values in expected fields

Downstream Consequences

Data Consequence

Hostname mismatches can cause issues with Identification/Reconciliation

Records missing serial number AND having a name to hostname mismatch are exceedingly difficult to reconcile

Event Management could struggle to bind Configuration Items to alerts when the name or hostname is inaccurate

Operation Consequence

Bad data erodes trust in the accuracy of the CMDB Processes that rely on the accuracy of the CI data in the CMDB are compromised You might need to create special queries to filter data based on name or hostname, this additional effort will slow all daily operations Remediating inaccuracies and correcting record compression requires valuable time and expense

App Consequence

Most ServiceNow applications depend on accuracy within the CMDB and will be at risk when data is inaccurate Asset Management suffers due to duplicate assets or incorrect linkages between CI and Asset Event Management Alerts can't bind correctly to Cis if the data is not correct Change Requests are only reliable during an audit if the CMDB data is reliable List views will be cluttered with records that are incomplete, inaccurate or duplicated

Impact on Your Business

Having mismatching information within the records of the CMDB can create risk in a few areas:

Asset Management

If records are inaccurate, it could raise audit concerns

Increased MTTR

When Event Management fails to bind CIs to alerts, it will take longer to identify, and solve issues

Audit / Compliance

License calculation and reports may be inaccurate if there are duplicates due to mismatching fields

Process Automation

Digital workflows can fail when the data within records is not accurate or contains conflicting data

Better User Experience

Inaccurate data within the CMDB will lead to unhappy users who do not trust the system

Engagement Questions:

Consider the answers to these questions:

Have you noticed that many records exist with questionable data in the hostname field?

What process or criteria are you currently using to vet upstream data sources for accuracy?

When records are inaccurate due to an upstream data source, what is the intended process for a user to get it corrected?

Are you using a tool such as Discovery to remediate mismatches like these?

Have you considered a policy that all items should be Discovered - if at all possible - and that non-discovered devices should be an exception that requires validation?

If a discovery tool is NOT in place to collect and update these records on a regular basis, then what is the plan or intention for keeping things accurate and up to date?

Remediation Plays

Summary

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

Play Name

Analysis – Size of problem

What this play is about

Query and analyze the data from your instance

Required tasks

Run a report or use List View to view records with mismatching data

Analysis – Example Record

What this play is about

Update/Insert data in your instance which will result in improving the CMDB health of your instance

Required tasks

Adds, Updates or Removes Data that is not compliant

Remediation – List View

What this play is about

A small number of records can be corrected manually

Required tasks

Use List View to update a few records

Analysis / Remediation – Discovery gaps

What this play is about

Ensure that a given device is within a Discovery Schedule / Range

Required tasks

Install Discovery Schedule Search Tool

Data Governance

What is this play about

Use reporting or dashboards to monitor these types of inaccuracies

Play Steps

Use the Report from Play 1 to schedule a report or add to a Dashboard

Play 1 - The size of the problem

What this Play is about

This play involves installing an Update Set which contains:

One Script Include for use within Reports and List Views

One List View layout for help viewing the correct columns

One Report for "Servers with Name and HostName Mismatches"

Two Modules (Navigation menu items) for easy use of these tools Feel free to perform these steps in a recent clone from your Production instance. It is also safe to load into Production; however, doing so will add two items to the Configuration section of your navigation menu. These can be deactivated if the menu items are not desirable within Production. Often these issues should be troubleshot within Production since the audit logs might not be available unless they were also transferred with the clone.

Required tasks

Option 1:

Install CMDB and CSDM Data Foundations Dashboard from the ServiceNow App Store

Navigate to the CMDB Data Foundations Dashboard module in the left navigation menu

Select the Data Management Practices tab

Select the Server CI Names not Reflecting Hostname report to view a list of Server CIs with name not matching hostname. If you see a count of zero then this playbook is not applicable to you

Option 2:

Import and Commit the "HSD0003798 Server Name Hostname Mismatch Report" Update Set

Reload the Navigation window (your browser) to refresh the Modules in the menu

Navigate to Configuration > HSD0003798 - Report: Servers w/Name Hostname Mismatch

Review the results of the report which are grouped by Class. In this example, there are records in Windows Server, Linux Server and the Server class. Example:

You can click into any of the "slices" on this pie chart to see the records in List View

Continue to the next applicable Play section to remediate your findings

Play 2 - Analysis: Single example record

What this Play is about

This play will help you read the audit logs to determine where data discrepancies originate from

Required tasks

Open any record from the previous analysis play and let the Form View load

Open the context menu (hamburger) and select History -> List

If "List" is not one of the options under History, you should verify that Audit is enabled on the particular class of record you have opened.

Example:

On the Record History page, scroll to the bottom and Sort by Update time in reverse

Example:

Click the magnifier icon in the Audit History related list to open the search fields on each column header

Search using "*name" in the Label column to narrow to the audit results to just the fields we care about: Name and Host name

Example:

Notice the following in the example above:

Update number is zero for both entries. That means these values (name and host name) were both present as shown when the record was inserted. Each increment of the Update number is another update to the glide record. Since these both read 0, they were both the original values in these fields.

Since the example is just the insert of the record, all the updates appear as the same user: System Administrator.

The next example is a record where an update has been made recently

Example:

Notice in this example that Johnny Walker has updated the Host name field. Both the Old and the New vales are shown here in the Audit History, along with the Update time

Audit history is a powerful tool in diagnosing the what, who and when of record updates.

Play 3: Remediation: List View

What this Play is about

This play will help remediate a small number of records using List View. If you have a larger number of records, a Discovery tool should be used instead.

Note: This play assumes you have installed the Update Set listed in Play 1.

Required tasks

Navigate to Configuration > HSD0003798 - List View: Servers w/Name Hostname Mismatch

Notice in this example we are taken to the Servers list with the HSD0003798 view

Example:

Notice also in this example that the values in Host name do not start with the same value as the name. Host name should be the Name followed by a domain.

What is commonly seen is a record like the one pictured below

Example:

Notice in the example above that the record has a Host name, an actual host name, but the Name attribute reflects the Model information. Also take note that the Most recent discovery field is empty. That means whatever inserted a host name on this record wasn't using the IRE. It was most likely a manual update.

To remediate this single record, you would simply List Edit the name field and put "actual" in the place of the placeholder model information (since in this example, the name is "actual").

Updating many records in this way would be time consuming. It is better to take advantage of a Discovery source. Proceed to the next play for help searching Discovery Schedules and Ranges to ensure there aren't any gaps in your Discovery coverage.

Play 4: Analysis / Remediation of Discovery gaps

What this Play is about

This play is about ensuring that your devices are included within Discovery Ranges and Schedules

Note: This play assumes you are making use of ServiceNow Discovery or a third-party discovery source

Required tasks

See the Discovery Schedule Search Tool knowledge article for instructions on installing and using this tool to determine if there are any "gaps" in your Discovery Schedules or Ranges

If data for your device is coming through an integration with a third-party data source, you should troubleshoot that or contact the vendor for the provided integration to get their support

If there is no "gap" in your Discovery Schedules, then you might need to troubleshoot a pattern if the information gathered is not accurate

Data Governance

What is this Play about ?

You can make use of the provided report within Play 1 to ensure that either progress is being made in remediating these records, or that these problems aren't growing again after you have cleaned them up.

Note: This play assumes you have installed the Update Set from Play 1.

Consider the following:

The CMDB is only as good as it is accurate. Data discrepancies should be the exception - not the norm

Data Certification allows for regular governance and tasks sent to persons responsible for maintaining CMDB accuracy

CMDB accuracy and integrity sometimes requires saying "no" to the ingest of data where there are known to be errors or inconsistencies

New Network Ranges are added to infrastructure from time to time. Consider modifying your processes and procedures to ensure that your Discovery Administrators are kept informed of these changes

You can Schedule or Automate the generation of the report from Play 1

You can add the report from Play 1 to a Dashboard

Congratulations You have completed this Get Well Playbook.