Discovery

Introduction
The ServiceNow Discovery applications find servers, computers and other devices which
are connected to an enterprise’s network. When Discovery finds a computer or device, it
explores the device’s configuration, provisioning, and current status and updates the CMDB
accordingly. On computer systems, Discovery also identifies the software that is running
and any TCP connections between computer systems. Discovery creates all the
relationships between computer systems (such as an application on one server that uses a
database on another server).

Discovery is agent-less: ​meaning that it does not require any permanent software to be
installed on any computer or device for those devices to be discovered.

Discovery_admin: ​Can access the “Discovery” and “Discovery Definition” applications to

configure, monitor and run Discovery operations
MID Servers
Discovery communications cover how your instance talks to the MID Servers and
how the MID Servers talk to your devices.
The MID Server is installed on the local internal network. All communications between the
MID Server and the instance are done via SOAP over HTTPS. Since we use the highly
secure and common protocol HTTPS, the MID Server can connect to the instance directly
without having to open any additional ports on the firewall. The MID Server can also be
configured to communicate through a proxy server if certain restrictions apply.
The MID Server is deployed in the internal network, so it can, with proper login credentials,
connect directly to discoverable devices.

Where to put Mid Servers

A Mid Server should be placed within each network segment, within each physical location
to be discovered.

External Connectivity Requirements

The Mid Server communicates securely on port 443 to Your ServiceNow instance and
requires no inbound connections.
Additionally, ensure the MID server can connect to install.service-now.com to download
and install updates.

Prerequisites - MID Servers

System Requirements
● Windows: To discover Windows-based servers, run Service Mapping patterns, or execute
Orchestration commands on Windows devices, the MID Server must be installed on a
Windows server. The MID Server supports all Windows Server 2008, 2012, and 2016
editions, virtual machines, and 64-bit systems. Linux
● The MID Server was tested on Linux Red Hat 6, Ubuntu 12, and CentOS 6. Linux MID
Servers support virtual machines and 64-bit systems. On 64-bit Linux systems, you must
install the 32-bit GNU C library (glibc).

The minimum suggested configuration is:

● 8 GB of available RAM
● 2+ GHZ CPU (Multi-core preferred)
● 40 GB of disk space per MID Server
 The following phases occur during the Discovery life-cycle. Each phase follows
the other in a logical flow:

● Port Scan phase:

The ServiceNow instance initiates Discovery and launches the Shazzam probe. The
Shazzam probe runs on the MID Server to scan port addresses to find open port addresses
for a given range of IP addresses. On the instance, a Shazzam sensor determines which
devices are active for discovery based on known protocols. The instance also launches the
classifier probes.

● Classification phase:
The MID Server uses known credentials for the given protocol. It probes each active
device, gathers additional classification information, and sends it to the ServiceNow
instance. On the instance, the classifier sensor determines what identity probe to run for
this device class, and then the instance launches the identity probe.

● Identification phase:
The MID Server probes each classified device, gathers additional identity information, and
returns the information to the ServiceNow instance. On the instance, the identity sensor
processes the information and queries the CMDB for a matching device. The instance
launches the appropriate exploration probes.

● Exploration phase:
The MID Server probes devices for more detailed information and sends it to the
ServiceNow instance. The exploration sensors of the instance process results, updates the
CMDB, and trigger additional probes as necessary.
Best Practices
Configure and deploy MID Servers: Configure and monitor your MID Servers
properly for an effective discovery process.
● Determine the size of your enterprise network.
● Place your MID Servers at the right locations with appropriate computer configurations.
● Monitor performance of your MID Servers continuously.

Create a robust credentials strategy

● Align your credentials strategy with network and security teams to avoid project delays.
● Use credential-less discovery to get basic configuration data about devices and apps.
● Run a full discovery to complete the CMDB update process.
● Create a credentials ordering mechanism to speed up the discovery process.

Automate Discovery with schedules

● Create schedules that complete in finite time for both on-premises and cloud infrastructure.
● Prioritize scans based on critical business service or geographic needs.
● Use MID Server clusters and behaviors to optimize schedule performance.

Configuring Credentials for Discovery

Discovery provides default Credential types to assign credentials and communicate with
external systems. We can use one of the following default credential types to add
credentials for communication with external systems.

Performing Quick Discovery for a Configuration Item.

Quick Discovery feature is used when we want to perform discovery on a single IP Address
without creating a Discovery Schedule.

● Navigate to ​Discovery > Discovery Schedules​ module.

 ● Click ​Quick discovery ​ in the header.
● A dialog box appears asking for an ​IP address​ and the name of the ​MID Server​ to use.
● Enter the target IP address for a discovery in the ​Target IP..
● Quick Discovery does not support IP network discovery. Make sure you enter ​a single IP
address​ only and not an entire network, such as 10.105.37.0/24.
● If a MID Server is assigned to the subnet containing the target IP address and currently in
an operational status ​(Up)​, the ​MID Server name appears automatically in the MID Server.
If multiple MID servers are found, the system selects one for you.
The value in the MID Server field can be overwritten if you want to select a different MID
Server.
● If no MID Server is defined for that network, select one from the list of available MID
Servers.
● Click ​OK​ to run discovery.
● The status record for that discovery appears. The Schedule column is empty because no
schedule is associated with this discovery.

Creating a Discovery schedule

Create a schedule record that defines what actions Discovery must take to scan the
devices and software in the network.

● Navigate to ​Discovery > Discovery Schedules​ and create a new record.

● Complete the Discovery Schedule form.
○ Name
○ Discover
○ MID Server
○ Active
 ○ Max Run Time
○ Run
○ Include Alive
○ Use SNMP Version
● Click ​Submit.

Inserting IP range for a Discovery schedule

Within each Discovery schedule are two related lists, Discovery IP Ranges and Discovery
Range Sets, where you can add Networks, Ranges or Lists of IP addresses to be used in
Discovery schedules. Populating the Discovery IP Range tab will direct Discovery to scan
all IPs in the specified range.

Create a quick IP range for a Discovery schedule

Quick ranges are used to define IP addresses to scan in a single comma-delimited string
without creating separate records.

● Click the ​Quick Ranges ​related link on the ​Discovery Schedule​ form.
● Enter the ​IP ranges​ and specific IP addresses to scan. Click ​Make Ranges.
● The Quick Range interface is for entering ​IP addresses only and cannot be used to edit IP
addresses that have already been submitted.
 ● The instance automatically displays the entries in the proper format.
● To make any changes to IP address ranges, select the ​IP address records​.

Create a Discovery range set for a Discovery schedule

Discovery range sets are common groups of IPs in a known location that can be called into
multiple schedules. Range sets provide for flexibility in both management and identification
of known networks for simplicity of administration. However, it's a best practice to utilize
range sets.

● Open a ​Discovery schedule.

● In the ​Discovery Range Sets​ related list, click ​New ​to add an new range set.
● On the Discovery schedule form, click the name of the range set under the Range
column in the ​Discovery Range Sets ​related list.
● On the Discovery Range Set form, add a ​Discovery behavior if necessary. You
can also activate or deactivate the range set for a schedule.
● Right-click the header, and then click Save.
Exclude IP addresses
For example, you might exclude a subnet containing devices restricted from interacting with
other devices or exclude a device with an intentionally unorthodox configuration that causes
an authentication issue each time it is discovered.
Perform below steps to exclude an IP address:

● In the ​Discovery Schedule form, click the link for the ​Type of IP address range that
contains the address to exclude.
● For example, to exclude 10.10.10.28, select the IP Network for 10.10.10.0/24, which is the
range of IP addresses that contains the target address​.
● The Discovery IP Range form appears. In the Discovery Range Item Excludes related list,
click New. There are 3 ways in which Exclude list can be created:
○ When Type is ‘IP Address Range’
○ When Type is ‘IP Address List’.
● Below example illustrates how to set exclude IP addresses list:
 ○ For example, select IP Address List to exclude a single IP address or
multiple IP addresses that are not sequential.

○ Right-click the header bar and select Save from the context menu.

○ The Discovery Range Item IP’s related list appears.

○ Click New in this list. An entry form for the IP addresses to exclude appears.

● Click New in this list. An entry form for the IP addresses to exclude appears.
Discover Now
● Navigate to​ Discovery -> Discovery Schedules.
● Select a particular schedule that needs to be executed.
● Ensure valid IP ranges/subnets have been configured.
● Click​ Discover Now.
● This will initiate discovery of the configured schedule immediately.

Discovery status record

By default, only 30 days of Discovery records are displayed in the status list at a time. This
is due to the reason that Discovery log retains information for of 30 days (2,592,000 in
seconds). This length of time can be modified.

The status record provides the following fields:

● Number
● Description
● Schedule
● State
● Source
● Completed

A Discovery Status record looks like this:

 In devices you will be able to see all the devices that have been discovered and those did
not get discovered will show some error information, related to that CI.

Discovery logs ​(mostly used by developers to troubleshoot discovery)

The Discovery Log displays all the activity for this Discovery, including such things as
classification failures, CMDB updates, and authentication failures.
From this list, click a link in the CMDB CI column to drill into the record for that CI or click
the link in the Created column to view an individual log record. Clicking an IP address link in
the Device column opens the Discovery Devices record. This is used to view the log
records for a particular device.

Discovery ECC Queue​ ​(mostly used by developers to troubleshoot discovery)

The External Communication Channel (ECC) Queue displays input and output messages
from and to MID Servers. The ECC Queue is the normal connection point between an
instance and other systems that integrate with it, most commonly a MID Server. Messages
are classified as Input (from a MID Server to the instance) or Output (from the instance to a
MID server).
Common error messages in Discovery
● Identified, ignored extra IP
This message can appear during the identification phase of Discovery if a targeted IP
address belongs to a device that is being discovered at the same time.
For example, a Windows server has two NIC cards with two IP addresses. Discovery
targets both IP addresses within the same Discovery schedule. This message is generated
to note that that second IP address is ignored because we don't want to update the same
CI twice within the same Discovery run.
This message is a warning and is expected. No action is needed.

● Authentication failures
The discovery process could not discover the CI because the discovery application could
not authenticate. To resolve, add the credentials of that machine in to the discovery
credentials table.

● Identified, not updating CI, now finished

No match on any of the CI Identifiers. Need to check the identifiers in the system and need
to create one if needed to identify the CI device.

● Connection failed to WMI service. Error: Permission denied

This message originates in WMI. Check that the MIS Server service is running with the
correct credentials and has access to the target device.