Let Cloud Sherpas own Tony Fugere (@tonyfugere) show you how to regain control of your #ServiceNow environment.
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:
ENHANCE, MAINTAIN AND CONTROL ENVIRONMENT
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!
INTEGRATE WITH ITIL CORE PROCESSES
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.
DISCOVERY 101 RECAP
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:
KEY COMPONENTS OF SERVICENOW DISCOVERY
DISCOVERY SCHEDULES
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.
IP NETWORKS AND RANGE SETS
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 SERVER
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.
PROBES
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.
SENSORS
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.
BASIC PHASES OF DISCOVERY (P.C.I.E.)
-
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?)
READY TO LEARN MORE?
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!
SNC Development 