When it comes to your ServiceNow Configuration Management Database (CMDB), accuracy is everything. An optimized CMDB supports the entire ServiceNow ecosystem, facilitates enhanced data analysis, and faster incident resolution. ServiceNow Discovery locates devices and applications on your network and updates the CMDB with this information. Discovery is available as a separate subscription from the rest of the Now Platform and acts as a crucial component for a healthy CMDB.

The following document highlights some of the discovery pitfalls that may negatively affect the accuracy of the ServiceNow CMDB. Avoiding these challenges can help you create a more reliable representation of your ServiceNow environment.

We’ll be creating a series of articles designed to help you avoid – and resolve – these ServiceNow Discovery pitfalls.

This week’s topics:

  • Unknown Subnets
  • Linux Simple Network Management Protocol (SNMP) and SSH Confusion
  • Incorrect Network Device Classification
  • Discovery Overlap

Pitfall #1

Unknown or Missing Subnets/Networks


Failure to have a full understanding of your environment may lead to gaps in your ServiceNow Discovery. The ServiceNow Discovery is agentless, which allows you to target all active endpoints across subnets and see what is active on the network. As a result, it is vital to have a solid foundation of all networks across your firm.

Corrective Steps

  • Obtain a full listing by working with your network team.
  • Populate your subnets in the IP Networks table in ServiceNow.
  • ServiceNow offers integration to systems like Infoblox to further integrate your network data with the CMDB.
  • If you don’t have a good grasp of your network, you can set up a unique discovery schedule that targets Networks.
    • Set up proper SNMP credentials to make sure the router/switch discovery is correct.
    • Create a discovery schedule that targets Networks.
    • Add IP ranges for discovery. This can include subnets and/or large IP range guesses.
    • Once completed, it returns a listing of subnets known/seen by the target router.
ServiceNow Discovery - CMDB

Pitfall #2

Linux servers are discovered as both SNMP and servers, creating Linux SNMP and SSH confusion. This may cause a Linux server to flip-flop classes.

Some Linux servers may be configured to allow both SSH and SNMP interrogation, periodically changing the Configuration Item (CI) class in ServiceNow.

Corrective Steps
• Avoid enabling SNMP access to Linux servers.

How to Stop/Disable SNMP Service

Stop SNMP Service:

  1. Use SSH to access your server with root login
  2. Enter command #service snmpd stop (enter the command after the # symbol)

Disable SNMP Service from Running and Operating System Startup:

  1. Use SSH to access your server with root login
  2. Enter command #chkconfig snmpd off (enter the command after the # symbol)

Pitfall #3

SNMP devices are incorrectly classified as routers or switches in ServiceNow, causing incorrect network device classification. Wireless components are a good example.

When ServiceNow Discovery determines that an active endpoint is an SNMP-enabled device, it will try to classify the device. The two primary classifications are routers and switches. However, other network classifications could be targeted: wireless controllers, access points, UPSs, VoIP phones, etc.

If the SNMP Object Identifier (OID) is not populated in ServiceNow, the system may perform a “best guess” device classification, causing data confusion and inaccuracies.

Corrective Steps
To avoid network device confusion, perform the following steps:

  • Add the appropriate entries to the SNMP OID Classification table.
  • For added details specific to a particular class/model, create both a new SNMP classification and discovery pattern.

Pitfall #4

Different discovery efforts overlap.

When configuring an automated, scheduled discovery in ServiceNow, it is important to organize what and when you are running discovery. Overlaps can add performance hits on your MID servers, plus add unneeded overhead and processes to your instance.

Corrective Steps

  • Organize and group your target networks by location, if possible.
  • Avoid targeting very large subnets (ex. /16) and target smaller groups like /24.
  • Review performance history on your MID Server(s) to ensure proper balance and processing. Use the MID Server Dashboard for performance details.
  • It’s always good practice to test your discovery approach in your DEV instance for analysis before shifting to PROD.

Let Rego Be Your Guide

Do you have questions about ServiceNow Discovery or CMDB? Rego’s industry experts are here to help. Our real-world examples and experience are designed to increase the value of your ServiceNow investment.

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