In part three of our ServiceNow Discovery article series, we’ll cover more ways to ensure that your CMDB is accurate by avoiding any pitfalls during the discovery process. ServiceNow Discovery is available as a separate subscription and serves as a critical component for a healthy ServiceNow CMDB.

Discovery Pitfalls – Article #1
Discovery Pitfalls – Article #2

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

  • Poor Requirements Gathering
  • No Location Alignment with Discovery
  • Poor MID Server Placement
  • Reconciliations Rules Are Not Set
  • Volatile and Fluid Networks
  • Core Discovery Patterns are Not Enabled
  • Confusion with Virtual Classes 

Pitfall #1

Lack of research and requirements gathering results in poor CMDB representation from ServiceNow Discovery.

Background

ServiceNow Discovery can provide a robust and accurate representation of your environment. However, this success requires various components.

The following steps are critical for a successful discovery deployment.

Corrective Steps

  • Determine Scope: A critical component in your discovery successes is the establishment of a clearly defined scope.
    • What are the business needs of Configuration Item (CI) discovery?
    • What modules will it support? IT Service Management? Application Portfolio Management? Software Asset Management?
    • As a rule, we suggest that you start simple and small. Expand only when business needs require it.
  • Proper Access: Ensure you have credentials in place for all CI classes that you want to discovery. Each credential platform has unique requirements. For example, network devices may require the discovery of MID servers in their Access Control List (ACL).
    • ServiceNow’s documentation does a solid job in describing with each type of credential requires.
  • Ownership: It is vital that all CI classes have ownership. In other words, there must be a group that manages, supports, and approves the CI classes.
    • Don’t populate a CI class with discovery until ownership has been identified.
    • Someone must be held accountable to the data in the CMDB.
  • Validation: As a by-product of establishing ownership, each CI class will need to have routine validation/certification.
    • ServiceNow offers both data certification workflows and CMDB Health reporting jobs to help determine the accuracy and data health of your CI classes. Take advantage of these offerings.
    • Failing to ensure accuracy of the discovered data will translate into lower confidence levels.
  • Review Existing Integrations: Make sure to review any existing data streams that are currently populating your CMDB, especially ones that might conflict or cause duplication to ServiceNow Discovery.
    • There’s nothing wrong with having multiple integration points, but you do need to establish clear identification and data precedence rules so that there is successful data synergy.

Pitfall #2

Discovery fails to associate location information to CIs.

Background

ServiceNow can automate location association with discovery. This functionality provides exceptional reporting and grouping for CIs and classes, but only if location information is established correctly.

Corrective Steps

  • Determine how your locations/offices should be identified in ServiceNow.
    • The location table can be manually updated or managed by an outside source like Workday.
  • If possible, normalize your location names to represent unique identifiers.
  • Associate your discovery schedules to a location. This assumes the target networks for a particular schedule are for a single location.
  • If you populate the IP Networks table, ensure each subnet is associated with a location.

Pitfall #3

Discovery efforts are slow, and individual networks timeout when discovery runs.

Background

Failure to place your discovery MID servers close to the target networks can impact discovery speed, resulting in more overhead and traffic across your network environments.

It’s a good rule to physically place MID servers close to end devices, if possible. Note that ServiceNow allows you to have an unlimited number of MID servers with no impact on your license.

Corrective Steps

  • Make sure you have a solid understanding of your network environment.
    • This includes identifying any firewalls or DMZs.
  • Try to group your discovery by geography and DMZ/non-DMZ configuration.
  • Look for subnets that sit well within a target group.
  • Set up MID servers in these groupings.
  • If your firm has a global footprint, we strong suggest incorporating local MID servers by region.

Pitfall #4

Multiple data sources are updating CIs; the data sources and CIs target the same attributes, resulting in potential attributes being overwritten by each source. This can cause inconsistencies and issues.

Background

Many environments do not have a single discovery tool. Rather, there are multiple data sources that require integration to the CMDB. If these sources, including ServiceNow discovery, do not have any prioritization configured, data inaccuracies can occur.

Establishing data reconciliation and precedence rules can determine what should be updated and by whom.

Corrective Steps

  • Ensure all of the data integrations have a corresponding entry in the discovery_source field.
  • In the CI Class Manager, find the target class. An example target class might be the Windows server.
  • Select Reconciliation Rules.
  • Add the required Discovery Sources, indicating which one has the highest priority for CI updates.
ServiceNow Discovery - OOTB Patterns
  • Indicate which attributes should be targeted for updates. Be specific or Apply to all attributes.
ServiceNow Discovery - OOTB Patterns

Pitfall #5

CMDB population from volatile and fluid networks (i.e., Labs) is causing data noise and inaccuracies. 

Background

Due to the nature of these test beds, devices are often built and stood down frequently. These actions wreak havoc on the accuracy of discovery if brought into the CMDB.

Unless there is a strong business justification to represent Lab/Test networks, it is advisable to ignore and skip these subnets for discovery. If your organization opts to include them, ensure that they are accurately maintained in the CMDB.

Corrective Steps

  • Identify your Lab or Test networks and ensure they are not associated with any Discovery Schedules.
  • Validate that these networks do not contain any production devices or software required to tracking for audit purposes.
  • Set up IP exclusion ranges if you have built Discovery Range Sets.

Remember: If you incorporate these unique networks for discovery, establish a clearly defined process for handling active and retired devices to ensure your CMDB accurately represents unique networks.

Pitfall #6

The core discovery patterns are not being utilized for discovery.

Background

ServiceNow has shifted away from probes and sensors, focusing on using patterns instead.

Although probes and sensors are still used for the initial discovery interrogation (Shazaam), the CMDB population is handled by discovery patterns. Any future updates will be targeted on these patterns.

Starting in the ServiceNow New York release, migration steps can be shifted to discovery patterns. If your instance is earlier than New York, it will be necessary to upgrade your platform to New York or higher.

Corrective Steps

  • Ensure your instance is on New York or higher.
  • If on New York, a prerequisite script will need to be run first. Note that you must log on to access this script: KB0750351
    • Ensure the requirements of the above script are met.
  • Next, follow these instructions to perform the migration:

Remember to always run the script in lower environments and validate before running in your production instance.

Pitfall #7

Confusion with Virtual Classes 

Background

Discovery of virtual devices can be confusing, as both a virtual machine instance and server CI are created–typically with the same CI name.  This scenario can occur within ITSM processes, such as choosing a server CI for an upcoming change or incident.  You may see two identical CI names. 

Common Pitfalls - Identical CI Names

The following information explains why confusion with virtual classes may occur. 

Background

ServiceNow Discovery is capable of capturing detailed virtual CIs and relationship by using a read-access credential for vCenter discovery.  Details such as the following can be captured:

  • ESX Servers 
  • Virtual Machine instances 
  • Datacenters
  • Resource Pools

Click here for more information about ServiceNow discovery for VMware vCenter.

In parallel, ServiceNow discovery can also capture virtual servers via the standard discovery credential for servers. The end result may show two CIs with the same name, such as one produced by server discovery and another produced by vCenter discovery.

The below example shows both “duplicate” CIs and their relationship to each other.

Duplicate CIs and Their Relationship

Corrective Steps

The good news is that each CI is housed in a separate CI classification and typically does not impact reporting, CMDB dashboards, and CMDB health scores.

However, for CI lookups like in Incident, Problem, Change, you may need to revise the lookup filters. Typically, most companies want to align tickets and support to an actual server CI.

Duplicate CIs and Their Relationship

Rego’s ServiceNow consultants are frequently asked why it’s necessary to use server discovery to discover the virtual server if it’s already represented from vCenter.

vCenter discovery returns basic information about the virtual server; only ten attributes are returned (Virtual machine (vm) discovery). Remember that these attributes don’t include the serial number, operating system, or any services or applications running on the server. Plus, the only relationships captured are specific for the virtual configurations. That’s why server discovery remains essential. 

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