Let Cloud Sherpas own Tony Fugere (@tonyfugere) show you how to regain control of your #ServiceNow environment.

ServiceNow Discovery 101: Introduction and Webinar Recap

ServiceNow Discovery is great tool for importing data into the CMDB. In the Discovery 101 series I will introduce some of the best tips to simplify the working experience within ServiceNow.

Welcome to the Discovery 101 series! Based on the success of my ServiceNow Admin 101 blog series, I decided to introduce readers to a new aspect of the ServiceNow platform: Discovery.

To start, you first need to understand the importance of a configuration management database (CMDB). In ServiceNow, Configuration Management provides a single system of record for IT and this information supports the CMDB. Why do we need a CMDB? Let’s take a look back to the points from our December Discovery webinar:


IT’s ability to make decisions around how to enhance, maintain and control our systems is directly linked to the CMDB. Having a full and accurate CMDB allows us to ensure IT can quickly see what systems are out there in the world and how they relate to each other. For example, if IT wants to upgrade ServerXYZ, what systems will be affected? Without a complete CMDB, IT has no idea!


Being able to integrate our CMDB into our ITIL core processes allows IT to quickly track their work and understand issues in the environment as well as how Incidents, Problems, Changes, Requests, Releases and other processes are affecting Configuration Items. Accurate information ensures dependable IT services and processes.

My biggest piece of advice? Make your CMDB project a process improvement project as well as a tool project.


So how does Discovery come into play here? ServiceNow Discovery is a data collection and processing application that imports data into the ServiceNow CMDB. With Discovery, you can easily create and update Configuration Items that are critical to the success of the CMDB and SACM processes.

ServiceNow Discovery improves the functionality of the CMDB by providing complete, accurate data about IT assets. Along with this, Discovery also finds important relationships between these assets (Configuration Items or CI’s). It utilizes common technologies (like SSH, WMI, SNMP, PowerShell, HTTPS, etc.) to provide a completely agentless method to gather data from systems on the network. To better illustrate how all of this works, let’s take a look at a visual depiction of the Discovery architecture:



The discovery schedule is the configuration necessary for Discovery to understand what systems need to be scanned and when the scan should occur. These can be set to run at a normal interval or run as a one-time job.


In order for a Discovery Schedule to understand which systems to scan, the schedule will have multiple IP addresses associated with it. This can be represented in the form of IP Ranges or Range Sets. I don’t want to re-write the Wiki here, but in short, Range Sets are akin to Variable Sets where the IP Ranges can be re-used across multiple schedules. Notice that the Range Set information is buried in-between Network Discovery topics. Unless a network topology is unknown, running a Network Discovery is usually not required. Also, one very handy tool in this space is the Quick Ranges tool that is present on the Range Set and Schedule form. You can read more on the Wiki.


MID stands for Management, Instrumentation and Discovery Server. It is a Java Virtual Machine server that runs as a Windows service or UNIX daemon and acts as a proxy of sorts to utilize communication and movement of data between ServiceNow and external applications, data sources and services (typically those found within a customer’s network or behind a firewall). Discovery relies on the MID server to do work on behalf of the ServiceNow instance.


These commands are configured by the ServiceNow platform and are the real meat of the agentless methods that allow Discovery to gather data. The MID Server will retrieve its to-do list via the ECC queue and trigger these commands out to the systems.


Once the command from the probe is successful, the data is returned to ServiceNow by the MID and the sensor processes it. The sensor is what allows the CMDB to become populated with data and relationships.


  • Port probe aka “Shazam” (what technologies is the device capable of using?)

  • Classification (what type of device is this?)

  • Identification (which CI is this in the CMDB or is it new?)

  • Exploration (what other information can we get out of this device? what relationships does it have with other devices?)


If you’re interested in learning more about the basics of Discovery and getting started with this application in ServiceNow, check out some of these helpful resources:

Where do we go from here? This article is a recap of the basics of Discovery. If you have time, review the Cloud Sherpas Discovery Webinar from December 2013. The next article in this series will include best practices and will dig deeper into the product.

What happened to the Admin 101 series? Don’t fret, we will be publishing a “back by popular demand” post soon!

Tony Fugere
TONY FUGERE 10 POSTSTony Fugere is a Service Delivery Manager for the ServiceNow Business Unit at Cloud Sherpas, and has over 10 years experience in IT and IT Service Management working with clients from a diverse set of industries. He has been working with the ServiceNow platform for over 3 years and has contributed to over 50 implementations/projects as a consultant. He has a vast wealth of knowledge around the ServiceNow platform, cloud enablement and adoption, programming, systems integration and database/system administration as he moved into management from the technical ranks.