In part two of our ServiceNow Discovery article series, we’re going to discuss additional ways to avoid common pitfalls that can impact the accuracy of your CMDB. ServiceNow Discovery, which is available as a separate subscription, acts as a crucial component for a healthy CMDB.

If you missed part one, never fear. Just click the link below.

Discovery Pitfalls – Article #1

In this week’s article, we’ll discuss the following pitfalls:

  • Discovering Too Much
  • Bad or Missing Identification Rules
  • No Process for Discovery Issues
  • Out-of-the-Box Patterns are Not Working

Pitfall #1

Your ServiceNow instance is too granular and discovers too much data.

Background

There is a lot of power and depth to ServiceNow Discovery. With customized pattern developments and extensions of hardware and software classes, a lot of information can be captured. However, just because discovery can capture a piece of hardware or application doesn’t necessarily justify population into your firm’s CMDB.

Many organizations fail to answer one of the most fundamental questions: What is the business need(s) and purpose of our CMDB? Understanding your requirements can help dictate how you populate the CMDB and identify data that is required.

Corrective Steps

  • Identify what you need from your CMDB. Is it for asset management? Change and Incident? Software audits?
  • Keep your discovery simple and expand only when warranted.
  • Ensure what you discover equates to values that you can report and discern.
  • If you wish to expand discovery, test this effort in your DEV instance and review if the data output is worthy for PROD.

Pitfall #2

Poor Identification Rules may impact data quality and cause duplications.

Background

Make sure to review the out-of-the-box (OOTB) identification rules on your discovered classes during ServiceNow Discovery implementation. Reviewing these rules will ensure that you have an accurate Configuration Item (CI) representation in your CMDB.

You may need to adjust these rules to avoid duplications and other anomalies. The goal is to ensure that Identification Rules maintain a unique representation of your CIs. It may be helpful to think of the rules like coalesce options in Transform Maps.

Corrective Steps

  • In the CI Class Manager, review the Identification Rules that will be populated from discovery.
  • Unless you want specific rules for specific classes, always review the class at the top of the hierarchy.
    • For instance, to review the server identification rules, you must examine the hardware rules, unless you want to change the rules specifically for the server class.
    • If you review the rule at the server class level in the CI Class Manager, it will display as a “derived” rule from the Hardware table.

Note: Some OOTB discovery patterns return a generic name for applications. An example might be JbossServer@servername.com. So, if you have multiple instances of the application running on a single server, you may get duplicate CI names from discovery.

Resolution may require returning the JVM middleware’s unique name instead. Again, it all depends on your data needs.

ServiceNow Discovery - Poor Identification Rules

Pitfall #3

Undefined processes for handling discovery issues, lost heartbeats, and errors can lower confidence in the accuracy of CMDB data.

Background

While the goal of ServiceNow Discovery is to automate and populate your CMDB, discovery does not always go as planned. There will invariably be anomalies with discovery.

In addition, if a reliable process is lacking for missed Configuration Items (CIs) or undiscovered endpoints, confidence in data accuracy suffers. Once confidence drops, it becomes a daunting challenge to correct this perception among CMDB users. Consequently, it is vital to establish a process around handling discovery anomalies.

Corrective Steps

  • Establish clear and concise processes for handling “troubled” CIs.
  • Automate with scheduled jobs or business rules to place action on CIs that are not discovered. For example, create an incident ticket for servers marked as active but haven’t been discovered in 14 days.
  • Incorporate an asset management process to retire/decommission CIs no longer in operation, ensuring the operational status values are updated.
  • Enable scheduled jobs for the CMDB Health Dashboard to report anomalies quickly.
  • Enable Data Certification efforts, which enforce validation to the CI and/or class owner.

Pitfall #4

Discovery Patterns provided by ServiceNow have errors or missing data.

Background

ServiceNow provides solid out-of-the-box (OOTB) discovery patterns. However, there will be times when these patterns fail or have data gaps. Most companies have some level of customization in their environment that can impact pattern accuracy. The good news is that organizations can customize or extend the standard patterns to fit their needs.

Corrective Steps

  • Capture discovery logs to review what errors or issues are occurring on a particular pattern.
  • In a lower environment, run Debug on the target pattern and target CI.
  • If warranted, enhance or extend the pattern to correct the error.
  • This may also require an update to particular entries in the CI Classification section.
  • Extend a pattern instead of changing the OOTB pattern. This ensures that future upgrades to patterns will occur while maintaining developed customizations.
ServiceNow Discovery - OOTB Patterns

Let Rego Be Your Guide

Do you have questions about ServiceNow Discovery or resolving issues in your ServiceNow CMDB? Rego’s experts guides are here to assist you.

Rego also offers webinars and half-day training classes for ServiceNow. Learn more about ServiceNow by visiting our articles and white papers page.

ServiceNow Discovery - Common Pitfalls and How to Avoid Them #1