Krunal Mankar

Discovery
Discovery finds computers, servers, printers, a variety of IP-enabled devices, and the
applications that run on them. It can then update the CIs in your CMDB with the data it collects.

There are two types of discovery:

1. Horizontal discovery

Horizontal discovery is a technique that Discovery uses to scan your network, find computers
and devices, and then populate the CMDB with the CIs it finds. Horizontal discovery creates
direct relationships between CIs, such as a run-on relationship between an application CI and
the actual computer CI that it runs on. Horizontal discovery is not aware of business services and
does not create relationships between CIs based on the business service they are in.

2. Top-down discovery

Top-down discovery is a technique that Service Mapping uses to find and maps CIs that are part
of business services, such as an email service. For example, top-down discovery can map a
website business service by showing the relationships between an Apache Tomcat web server
service, a Windows server, and the MSSQL database that stores the data for the business service.

Typically, Service Mapping and Discovery work together to run horizontal discovery first to find
CIs, and then top-down discovery to establish the relationships between business services that
you need to know.

Probes, sensors, and patterns

Discovery uses these components to find CIs:

Probes and sensors

Probes and sensors are scripts that collect and process data on a host and then update the
CMDB. More specifically, probes explore or investigate CIs on your network, and sensors parse
the data returned from the probes. Several probes and sensors are provided by default, but you
can customize them to find different information, or you can create ones. You can also configure
several parameters to control the behaviours of a particular probe every time it is triggered.

Patterns

Patterns, like probes and sensors, are a series of operations that also collects data on a host,
process it, and update the CMDB. Patterns differ from probes and sensors in that they are written
in Neebula Discovery Language (NDL) rather than JavaScript, and they are called into action in
the later stages of the horizontal discovery process. Default patterns are provided, but you can
also customize or create patterns using the Pattern Designer.
 Krunal Mankar

Horizontal discovery phases

The phases of horizontal discovery are:

Discovery follows these phases:

Scanning

Discovery sends a probe called Shazzam to the network to see if commonly used ports are open
and if these ports can respond to queries. For example, if Shazzam finds a device that responds
on port 135, Discovery knows that it’s a Windows server.

Classification

If Discovery finds devices or computers, it sends additional probes to find the type of device or
the operating system on the device. For example, Discovery sends the WMI probe to a Windows
machine to detect the Windows 2012 operating system. Then Discovery uses records
called classifiers, which specify the trigger probe or probes that run during the next two phases.
If you’re using patterns, the classifier specifies a trigger probe that in turn launches a pattern.

Classify Probe:

- Classifies specifically what type of responds successfully to port scan

- Computers are classified by operating system
- Network devices are classified by functionality ( power, print, switch, route)
- Applications are classified based on the running process

Identification

Discovery tries to gather more information about the device and then tries to determine if a CI for
the device exists in the CMDB. Discovery then uses additional probes, sensors, and identifiers to
update existing CIs in the CMDB or create new ones. Identifiers, also known as identification
rules, specify the attributes that the probes look at when reconciling data with the CIs in the
CMDB. If you’re using patterns, Discovery uses the appropriate identification rule for the CI type
specified in the pattern.

Exploration

The identifier launches additional probes configured in the classifier. These probes are specially
designed as exploration probes to gather additional information about the device, like the
applications running on it, and additional attributes, such as memory, network cards, and
drivers. Discovery then creates relationships between applications and devices and between
applications. If you’re using patterns, the operations in the pattern perform the exploration of the
CI.
 Krunal Mankar

PORT Probes:

Port probes are used in Discovery by the Shazzam probe to detect protocol activity on open ports
on devices it encounters.

When a port probe encounters a protocol in use, the Shazzam sensor checks the port probe
record to determine which classification probe to launch. The common protocols WMI, SSH,
SNMP, and HTTP in the base system have priority numbers that control the order in which they are
launched.

The priority is as follows:

1 - WMI

2 - SSH

3 - SNMP

4 - HTTP

In the base system, the WMI probe is always launched first, and if it is successful on a device, no
other port probes are launched for that device. If the WMI probe is not successful, then the SSH
probe is launched to gather information on the device. If it is not successful, the SNMP probe is
launched. This method allows Discovery to classify a device correctly if the device is running
more than one protocol (for example, SSH, SNMP, and HTTP).

Classifiers
A classifier in ServiceNow Discovery is like a set of rules that helps identify what type of device or
application has been found on the network and determines where to store this information in the
database (CMDB). When device is classified, and target table is decided it then triggers the
probes and patterns to identify device.

How Does a Classifier Work?

1. Discovery: When ServiceNow scans your network, it finds various devices like
computers, servers, and network switches.

2. Classification: The classifier looks at the details of each device (like its operating system,
open ports, etc.) and figures out what type of device it is.

3. CI Table Assignment: Based on the type of device, the classifier decides which table in
the CMDB to put the information into.

Example 1: Windows Server

1. Discovery: ServiceNow finds a device on the network.

2. Classification: The classifier sees that the device is running Windows.

3. CI Table Assignment: The classifier determines this is a Windows server and stores the
information in the cmdb_ci_win_server table.

Example 2: Network Switch

1. Discovery: ServiceNow finds another device on the network.

 Krunal Mankar

2. Classification: The classifier identifies this device as a network switch by checking its
characteristics (like its IP address, the type of device, etc.).

3. CI Table Assignment: The classifier determines this is a network switch and stores the
information in the cmdb_ci_network_switch table.

Why is this Important?

By correctly identifying and categorizing devices, ServiceNow ensures that all the data about your
IT assets is organized and stored in the right place. This makes it easier to manage and keep track
of your IT environment.

CI Identifiers: When Discovery has determined the device's class, it launches an identity probe
that is configured to run one or more commands with a single authentication.

The identity probe in the base Discovery system can be configured to ask the device for
information such as its serial numbers, name, and network identification. The results of this scan
are processed by an identity sensor, which then passes the results to the identifier. The identifier
then attempts to find a matching device in the CMDB. If the identifier finds a matching CI, the
identifier either updates that CI or does nothing. If the identifier cannot find a matching CI, it
either creates a new CI or does nothing. If Discovery is configured to continue, the identifier
launches the exploration probes configured in the classification record to gather additional
information about the device. Exploration probes can be multiprobes or simple probes.

Note: When you use patterns for Discovery, the identity probe isn’t used. Discovery uses the
appropriate identifier rules based on the CI type that you’re trying to discover as specified in the
pattern operations. The operations in the pattern along with these identifier rules perform the
identification and exploration phases of discovery.
 Krunal Mankar

Discovery communication through MID Servers

A MID Server, which constantly queries the instance for probes to run, executes the instructions
in the probe or in the pattern that the probe specifies. The MID Server then returns the results to
the instance, where sensors process it. The MID Server does not retain any discovery information.

The MID Server starts all communications, using SOAP on HTTPS, which means that all
communications are secure, and all communications are initiated inside the enterprise's firewall.
No special firewall rules or VPNs are required.

Because Discovery is agentless, meaning that it does not require any permanent software to be
installed on any computer or device to be discovered, the MID Server uses several techniques to
probe devices without using agents. For example, the MID Server uses SSH to connect to a Unix
or Linux computer, and then it can run a standard command, as specified in the probe, to gather
information. Similarly, it uses the Simple Network Management Protocol (SNMP) to gather
information from a network switch or a printer.

Types of discovery

The types of horizontal discovery that the Discovery application can perform are explained in the
following table:

Type Description

Run this type of discovery to find the internal IP networks within your
Network
organization. If you already know the IP address ranges in your network, it
discovery
is not necessary to run network discovery.

Run this type of discovery to find the devices, computers, and applications
CI discovery on your network. This is essentially the standard type of discovery that you
run most often.

Cloud Run this type of discovery to find AWS and Azure resources in your
discovery organization's cloud.
 Krunal Mankar

Type Description

Run this type of discovery to find applications on host machines without

Serverless
the need to discover the host first. Serverless discovery relies on patterns
discovery
to explore CIs on a host.

IP service affinity

Table: ip_service_affinity_list

IP Service affinity saves the IP service (ssh, wmi) information that is used to successfully find a
device and associates it with the IP address of the device. Using this information, Discovery can
target the device in subsequent runs with the accurate protocol. Discovery records the IP Service
along with the IP address. Discovery can store the successful IP service information in the IP
Service Affinity table [ip_service_affinity].

For example: A network device has both an SSH port and an SNMP port open. By its agentless
design, Discovery tries SSH first. However, network devices should be discovered through
SNMP. Discovery tries the SSH probe and it fails. This triggers the SNMP probe, which succeeds.
With the association between the IP address and the IP service, subsequent discovery runs that
target this IP address use SNMP first, because that is the probe that succeeded.

IP Affinity/ Credentials affinity

Table: dscy_credentials_affinity

IP Affinity is a table which shows the relation between which credential was used to discover this
IP address. Whenever the IP address it discovered using any specific credential the IP affinity is
created automatically. IP affinity also shows which MID Server was used to discover this IP and
which credential was used.

IP Service is nothing but a relation between IP Service and Dameon’s. Like for example SNMP used
port 161 and which protocol is used like TCP or UDP.
 Krunal Mankar

Horizontal discovery process flow with probes and sensors

Kicking off Discovery

A user triggers horizontal discovery by configuring a discovery schedule or by launching an on-

demand discovery with Discover now or Quick Discovery. The schedule specifies one or more IP
addresses or range of IP addresses.

Scanning phase

1. Discovery first takes the Shazzam probe (and then port probes) and places it in a request
in the External Communication Channel (ECC) queue.

2. The MID Server checks the ECC queue, retrieves the discovery request, and runs the
probes against the host and discovers open ports.

3. The port probes scan common ports using several protocols, such as WMI, HTTP, SSH,
and SNMP.

4. If one or more ports respond, the Shazzam probe sends information about the port back
to the ECC queue through the MID Server.

5. Discovery checks the ECC queue to find out which ports responded, which identifies the
type of machine. For example, if Shazzam detects that the machine is listening on port
22, Discovery treats the machine as a UNIX or Linux machine.

Shazam Prob:

It scan for active devices

Ports are determined by Port Probes or by a specific behavior

Port probs are determined by ip servces

Multiple ports can be configured per port probe

Shazzam XML Payload shows:

-IP address

Port open/refused

Hostnames

Banners

Classification phase

1. The Discovery application determines which classification probe to send to the newly
discovered device by using information in the record of the port probe that successfully
responded.
 Krunal Mankar

2. Discovery puts the classification probe into the ECC queue.

3. The MID Server checks the ECC queue, retrieves the discovery request, and runs the
classification probe.

4. The classification probe retrieves additional information, such as which version of the
operating system is running on a machine. This information determines the class of the
CI that Discovery found. There is only one classification probe per discovered device.

5. The classification probe sends information back to the instance ECC queue through the
MID Server.

The Identification phases

1. Discovery determines which classifier to use based on the class of the CI and the criteria
specified in all CI classifier records. The classifier specifies which probes to use for the
next two phases.

2. Discovery puts the identification trigger probe for the CI classifier into the ECC queue. For
example, a Unix machine running HP-UX would require the HP-UX classifier, which
specifies that the Multi Probe-HP-UX Identity identification trigger probe. These probes
use identification rules to determine whether to insert or update a CI in the CMDB.

Note: The trigger probe could also be the Horizontal Pattern probe, which tells Discovery to follow
the operations in the specified pattern, rather than sending out additional probes. The operations
in the pattern cover both the identification and exploration phases. Discovery knows which
identification rules to use based on the CI type, and Discovery makes inserts or updates to the
CMDB based on these rules. Probes and sensors are not used.

3. The MID Server checks the ECC queue, retrieves the discovery request, and runs the
identification trigger probe.

4. The identification probe accumulates identification data for each device and sends that
data back to the instance via the MID Server.

5. Discovery uses sensors for the identifier probe to process the information.

6. Discovery performs the analysis on the CMDB using CI identifiers. Discovery can update
existing CIs in the CMDB or create new ones.

The Exploration phases

1. Discovery looks at the Triggers Probes related list in the classifier to find exploration
probes to run.

2. Discovery puts the exploration trigger probe into the ECC queue.

3. The MID Server checks the ECC queue, retrieves the discovery request, and runs the
exploration trigger probes.

4. The probes send data back to the instance via the MID Server and sensors make updates
to the CMDB, just as in the identification phase.
 Krunal Mankar

Horizontal discovery process flow with patterns

Horizontal discovery with patterns has four phases, just as horizontal discovery with probes does.
However, for the last two phases, Discovery triggers operations from a pattern, rather than
additional sets of probes.

Scanning phase

1. Discovery first takes the Shazzam probe (and then port probes) and places it in a request
in the External Communication Channel (ECC) queue.

2. The MID Server checks the ECC queue, retrieves the discovery request, and runs the
probes against the host and discovers open ports.

3. The port probes scan common ports using several protocols, such as WMI, HTTP, SSH,
and SNMP.

4. If one or more ports respond, the Shazzam probe sends information about the port back
to the ECC queue through the MID Server.

5. Discovery checks the ECC queue to find out which ports responded, which identifies the
type of machine. For example, if Shazzam detects that the machine is listening on port
22, Discovery treats the machine as a UNIX or Linux machine.

Classification phase

2. The Discovery application determines which classification probe to send to the newly
discovered device by using information in the record of the port probe that successfully
responded.

3. Discovery puts the classification probe into the ECC queue.

4. The MID Server checks the ECC queue, retrieves the discovery request, and runs the
classification probe.

5. The classification probe retrieves additional information, such as which version of the
operating system is running on a machine. This information determines the class of the
CI that Discovery found. There is only one classification probe per discovered device.

6. The classification probe sends information back to the instance ECC queue through the
MID Server.

The Identification and Exploration phases

Patterns unify the Identification and Exploration phases of discovery.

1. Discovery determines which classifier to use based on the class of the CI and the criteria
specified in all CI classifier records. The classifier specifies the Horizontal Pattern probe,
which in turn specifies which pattern to launch. The Horizontal pattern probe also
contains a sensor which does the actual work of updating the CMDB.

Note: Patterns need applicative credentials to find applications running on host machines. Make
sure you have applicative credentials configured along with the credentials required to access
the host machine itself.
 Krunal Mankar

2. The operations in the pattern specify the actions that Discovery needs to take for both the
identification and exploration phases. Discovery knows which identification rules to use
based on the CI type in the pattern, and Discovery makes inserts or updates to the CMDB
based on these rules. Only the Horizontal Discovery Sensor is used. Other probes and
sensors are not used.

3. Means in horizontal discovery using pattern only horizontal pattern probe and horizontal
discovery probe is used along with pattern in Identification and exploration phase. No
other probes or sensor are being used in identification and exploration phase.
 Krunal Mankar

Discovery Set Up

Plugin Required: Discovery (com.snc.discovery) plugin.

Discovery and Service Mapping Patterns application (sn_itom_pattern)

Role required: admin

MID server:

The management, instrumentation and Discovery server is alight weight java applications that
runs as windows service Unix daemon on server in local network.

MID Server Set UP

Install at least two MID Servers at first and assign them to different schedules and IP ranges to
help complete discoveries quicker

Install mid server at Client environment from there we can access various devices.

Access required:

a) RDP access with admin role.

b) Service Account on windows machine with “Log on as service” right.

c) MID server user with ‘Mid_User’ role.

Server Build:

MID Server Name: Discovery MID.

IP Address:

Hardware Specifications:

Note per IR documentation configure with

• CPU: 8

• RAM: 16 GB

• Hard Disk E:100 GB

• OS: Windows 2019 Standard

Software installed:

• Google Chrome

• Notepad++

• .NET 4.7 (3.5-4.7 required)

 Krunal Mankar

• PowerShell v5.1 (3-5 acceptable)

• Telnet client

• Java v11+

• Putty

1.1 Check access to SN from Mid Servers.

URL:https://dev.service-now.com

1.2 Download mid server.

a) In Virtual server open google chrome and open URL: https://dev.service-

now.com.

b) go to navigation ->MID server ->Downloads.

c) Download Windows 64-bit MSI file.

d) create mid server folder in local disk C.

e) Copy MID server MSI installer and paste it into the "Mid Server" folder.

1.3 Install mid Server.

a) Go to C:\Mid Server and double click Installer to Open installing wizard.

b) click Next.

c) Accept Terms in the Licence Agreement and Click Next.

d) Configure MID server Connection:-

We would require PROXY information (IF any)

i. Select Authentication Type Basic.

ii. Enter ServiceNow Instance URL: https://dev.service-now.com

iii. Enter ServiceNow Mid server user Username:

iv. Enter ServiceNow Mid server user Password:

e) Click "Test Connection” then click "Close" and go to "Next".

f) Configure the MID Server name “SVP” and Service Account parameters.

i. Enter MID Server Name:

ii. Enter Service Account Name.

iii. Enter Service Account Password.

 Krunal Mankar

g) Click Validate MID service setting then click “Close” and go to next.

h) Select destination Folder to install MID server.

To Change the path click change button and select C:\Mid Server

i) Click "OK" and Then "Next".

j) Review MID server Configuration.

k) select checkbox "Start MID server after Installation" and click "Next".

l) After Installing Click "Finish" Button to exit.

m) After finishing Mid server installation

i. Go to C:\Mid Server and locate Installer (Windows batch file) and Run
file as administrator.

ii. Put mid server User password and test the connection.

iii. When connection is validated click "Next".

iv. Review Configuration and click "Next".

v. Click "Start MID server" Button.

n) Once you start MID server, after Few second MID server visible on Instance validate the
MID server form related list.

Requirements:

• MID Server installed, configured from prior exercise, and successfully communicating with the
ServiceNow instance
• Devices should be up and running.
• No logical or physical firewalls can exist between the MID Server and the device that prevents
IP service communication over the ports.
 Krunal Mankar

Discovery schedule Form

Field Description

Name Enter a unique, descriptive name for your schedule.

Select one of the following scan types:

o Configuration items: Uses Discovery identifiers to match devices with CIs

in the CMDB and update the CMDB appropriately. Perform a simple
discovery by selecting a specific MID Server to scan for all protocols (SSH,
WMI, and SNMP). Or, perform advanced discoveries with discovery
behaviors. When you select a behavior, the MID Server field is not
available.

Note: An IPv6 via address list scan is allowed on Discovery schedule for Configuration
Items.

o IP addresses: Scans devices without the use of credentials. These scans

discover all the active IP addresses in the specified range and create device
history records, but do not update the CMDB. IP address scans also show
multiple IP addresses that are running on a single device. Identify devices
by class and by type, such as Windows computers and Cisco network gear.
The Max range size Shazzam probe property determines the maximum
number of IP addresses Shazzam scans. See Configure Shazzam probe for
details.
Discover
o Networks: Discovers IP networks (routers and switches). Results from this
search are used to populate the IP Network [cmdb_ci_ip_network] table
in Discovery > IP Networks with a list of IP addresses and network masks.
Network scans update routers and layer 3 switches in the CMDB.

o Service: Discovers services for the Service Mapping application.

See Schedule a top-down discovery by Service Mapping for instructions.

o Serverless: Finds CIs without needing to run discovery on a host, or CIs on

a proxy host that is already in the CMDB. See Serverless Discovery for more
information.

o Cloud application: Discovers only the cloud resources for the patterns that
you specify. See Exploring Cloud Discovery for instructions.

o Cloud resources: Discovers resources for one of the supported cloud

providers. This option only appears when you run Discovery on a cloud
service account. You cannot select it from a new Discovery schedule.

o Certificates. Discovers certificates based on URLs. Selecting this option

adds the Certificate Discovery Type field: URL Certificate Discovery.
 Krunal Mankar

Field Description

See Run Certificate Discovery via individual URL scans for more
information.

Select the method that Discovery uses to select a MID Server:

o Auto-Select MID Server: Allow Discovery to select the MID

Server automatically based on the Discovery IP Ranges you configure. To
find a matching MID Server, you must configure MID Servers to use:

▪ The Discovery application, or ALL applications. This setting

authorizes the MID Server access from Discovery.

▪ The IP Range that includes the ranges you configure on

the Discovery schedule.

Note: MID Server auto-select is not supported with IPv6.

o Specific MID Cluster: Use a preconfigured cluster of MID Servers. Select

the cluster. You are not required to specify one member of the cluster.
The MID Server cannot be part of multiple clusters, such as one that
supports load balancing and one that supports failover. You can add any
cluster regardless of the application that the MID Servers are assigned to.
When you select the cluster, the Discovery application is automatically
added when it does not exist for the MID Servers in the cluster.
MID o Specific MID Server: Use only one MID Server. If that MID Server is part of
Server selection a cluster, only that MID Server is used. The cluster is not used. You can add
method any MID Server regardless of the application it is assigned to.
The Discovery application is automatically added when it is not already
assigned for the MID Server you select. You can assign a specific MID
Server for all types of Discovery scans except Service.

o Use Behavior: Use a behavior when a single schedule requires the use of
multiple MID Servers to perform any of the following activities:

▪ Scans requiring multiple Windows credentials.

▪ A schedule that must execute two or more particular protocols

(SNMP, SSH, or WMI) using more than one MID Server.

▪ Load balancing for large discoveries where a single MID

Server would be inadequate.

▪ Scanning multiple domains.

Note: The Discovery schedule enforces domain separation. The MID Servers that are
available for selection are limited to the same domain of the user who is configuring the
schedule.

See MID Server selection sequence for Discovery schedules for additional information.
 Krunal Mankar

Field Description

Select the MID Server to use for this schedule. This field is available if MID Server selection
method is set to Specific MID Server, or if you discover IP addresses, networks, or web
MID Server services.

To verify that the MID Server you selected is up and validated, look at the MID Server
dashboard.

Select the MID Server cluster to use for this schedule. This field is available if MID Server
MID Server Cluster
selection method is set to Specific MID Cluster.

Select a behavior configured for the MID Servers in your network.

Behavior
This field is available only if MID Server selection method is set to Use Behavior.

Select the check box to enable this schedule. If you clear the check box, the schedule is
Active disabled, but you can still run a discovery manually from this form, using the configured
values.

Choose a location to assign to the CIs that the schedule discovers. If this field is blank, then
Location
no location is assigned.

Set a time limit for running this schedule. When the configured time elapses, the remaining
tasks for the discovery are canceled, even if the scan is not complete. Use this field to limit
Max run time
system load to a desirable time window. If no value is entered in this field, this schedule
runs until complete.

Determines the run schedule of the discovery. Configure the frequency in the Run field and
Run and related the other fields that appear to specify an exact time.
fields Note: The run time always uses the system time zone. If you add the optional Run as
tz field, it has no effect on the actual runtime.

Select this check box to create a log entry every time the state changes during a discovery,
such as a device going from Active to Classifying. View the discovery states from
Log state changes
the Discovery Devices related list on the Discovery Status form. The Completed
activity and Current activity fields display the states.

Enter the number of IP addresses that each Shazzam probe can scan. Dividing the IP
addresses into batches improves performance by allowing classification for each batch to
begin after the batch completes. rather than after all IP addresses have been scanned. The
probes run sequentially. For example, the value is set to 1000 and a discovery scans 10,000
Shazzam batch IP addresses using a single MID Server. It creates 10 Shazzam probes with each probe
size scanning 1000 IP addresses. By default, the batch size is 1000. A UI policy enforces a
minimum batch size of 256 because batch sizes below 256 IP addresses do not benefit from
clustering. The policy converts any value below 256 to a value of zero.

The value for this field cannot exceed the value defined in the maximum range size property
for the Shazzam probe.
 Krunal Mankar

Field Description

Select the check box to distribute Shazzam processing among multiple MID Servers in a
cluster and improve performance. This setting works with the Shazzam batch size. For
example, a schedule is created to scan 100,000 IP addresses, with 10 MID Servers assigned
Shazzam cluster
to do the work. Each MID Server is assigned to scan 10,000 IP addresses. If the Shazzam
support
batch size is set to 5,000 IP addresses per probe, the schedule runs two Shazzam probes
per MID Server (10,000 IP addresses/5,000 per batch). These probes are run in sequence
and not concurrently.

Use this field to designate the SNMP version to use for this discovery. The default value
Use SNMP Version
is ALL. You can change this to v1, v2c, or v3.

URL Certificate Define the number of URLs to discover per batch during Discovery. Leave the batch size as
Batch Size it is unless recommended to change.

Define IP addresses and address ranges to scan by entering IP addresses in multiple

Quick ranges formats (network, range, or list) in a single, comma-delimited string. For more information,
see Create a Quick IP range for a Discovery schedule.

Discover now Use this link to immediately start this Discovery.

Related lists

This related list defines the ranges of IP addresses to scan with this schedule. If you are
using a simple CI scan (no behaviors), use this related list to define the IP addresses to
IP Ranges discover.

Note: To improve security, limit the range of discovery targets to exclude unnecessary
networks and devices.

Discovery Range This related list defines each range set in a schedule to scan by one or more Shazzam
Sets probes.

Discovery Status This related list displays the results of current and past schedule runs.

This related list displays the URLs that are discovered using this schedule. You can add or
Certificate URLs
delete URLs from this list.
 Krunal Mankar

Discovery Status:

The Discovery Status contains the details of a Discovery that has been launched from a Discovery
Schedule. The Status displays high level information about the results of a Discovery, including
logs, probes, sensors, and the ECC queue

Discovery Log:
- Discovery info, discovery state, error massage
- Shows log for identification and exploration phase
Devices
- IP, Class, Device name, activity
- Issues and scan status\
ECC que
- Input / output queue, track command and result
- Shows log for scanning and classification phase

IP Address discovery is a credential less discovery.

MID Server selection sequence for Discovery schedules

The Discovery application follows this sequence to find a MID Server.

MID Server auto-selection

Discovery follows this sequence when you select Auto-Select MID Server for the MID Server
selection method on the Discovery Schedule form.

Note: MID Server auto-select is not supported with IPv6.

1. Discovery looks for a MID Server that also has an appropriate IP range configured.

2. If no MID Servers meet these criteria, it looks for a MID Server that has the ALL application
that also has an appropriate IP range configured.

3. If more than one MID Server meet the criteria, Discovery chooses the first MID Server with
the status of Up. If more than one MID Server is up, it randomly picks one.

4. If none are up, it uses the default MID Server specified for the Discovery application,
assuming it is up.

5. If no default MID Server is specified, it uses the default MID Server specified for
the ALL application, assuming it is up.
 Krunal Mankar

6. If no default MID Server is specified, Discovery cycles through the previous steps and
looks for MID Servers with the status of Paused or Upgrading.

Note: When a MID Server is paused or upgrading, it does not actually process commands until it
returns to the status of Up.

MID Server clusters

These steps are followed when you select Specific MID Cluster for the MID Server selection
method on the Discovery form, and the cluster is a load balancing cluster:

1. Discovery uses the first MID Server in the cluster that it finds with the status of Up.

2. If more than one MID Server is up, it randomly picks one. If it cannot find any MID Servers,
it looks for MID Servers in the cluster with the status of Paused or Upgrading.

These steps are followed when the cluster is a failover cluster:

1. Discovery uses the MID Server with the lowest Order value that also has the status of Up.

2. If no MID Servers are found, it looks for MID Servers in the cluster with the status
of Paused or Upgrading, choosing the one with the lowest Order value.

Note: Discovery ignores the default MID Server for it and ALL applications when selecting a MID
Server from the cluster.

Port scan (Shazzam) phase

During the port scan phase, Discovery collects all the target IP addresses. It splits them equally
between MID Servers matching the criteria (MID Servers are qualified to do the port scan). The
Shazzam batch size, which you configured on the Discovery schedule, determines the number of
IP addresses that each Shazzam probe can scan. This phase helps determine how much work
each MID Server does during the port scan phase.

For example, you have 16,000 IP addresses to scan among three qualified MID Servers, and you
use the default Shazzam batch size of 5000. Two of the MID Servers handle 5000 IP address scans
(one Shazzam probe each). The other MID Server handles 6000 IP address scans by launching
two Shazzam probes.

Note: Shazzam can only process IP lists containing a total of 5000 IP addresses (both IPv4 and
IPv6 addresses) if the list contains any IPv6 address. For schedules containing IP lists with IPv6
that go beyond this limit, Discovery gets cancelled with an error message.
 Krunal Mankar

Credentials for Discovery:

Credentials are used in classification phase of discovery

Simplifying Device Discovery: Common Credentials

Utilize identical username and password combinations for servers within specific groups. For
instance, all web servers could share the same credentials, such as adminuser:password123.
This approach streamlines management, enhances operational efficiency, and upholds security
protocols.

Simplifying Device Discovery: Service Accounts

Request the creation of dedicated service accounts with requisite permissions. Receive
corresponding credentials from the IT team. These credentials are then applied universally
across multiple devices for Discovery tasks, ensuring streamlined management, improved
efficiency, and maintained security standards

Behaviors:

Discovery behaviors determine the probes that Shazzam launches and from which MID Servers
these probes are launched.

The Behavior defines the protocol and MID Server used for this discovery. Behaviors are specific
to a schedule and do not have any global impact.

Scenario:

In this section, we have to discover the Windows Server running router simulation software. The
default Shazzam Probe tries all protocols to communicate with the target IP address based on a
classification priority. The protocol that responds with the lowest classification priority is used for
the classification phase of Discovery. By default, the WMI protocol is lower than SNMP. Hence
the device is being classified as a Windows device at this point

In this scenario, because there is router simulation software running on a Windows Server, it is
necessary for the initial port scan to use only SNMP via the configuration of a Behavior to discover
the router. A behavior is being configured in order for Shazzam to only use the SNMP protocol and
classify the device as a router

Note: WMI has a Classification priority of 1, therefore devices running WMI will be classified as
Windows, even if the device is running SNMP at the same time. This functionality or classification
priority can be altered. However, the configuration is global affecting all future discoveries.
 Krunal Mankar

Discovery Configuration Console:

The Configuration Console manages what kind of CIs and CI information is discovered. Specify
which devices and application types to ignore and filter the specific software to include or
exclude. Disabling the discovery of device data at the top level disables the related probe,
classifier, or pattern libraries for that CI. However, those elements are still available for general
use across the system

The Discovery configuration console is used to configure what Discovery data the system allows
in the CMDB. All the data gathered by Discovery might not be pertinent to your organization. The
Discovery configuration console allows you to choose which data is discovered and populated in
the CMDB
 Krunal Mankar

Troubleshooting:

Common issues (connectivity):

• Logical or physical firewall preventing connectivity (i.e, ports 22, 135, 161)
• Ip ranges are not defined correctly.
• Inaccurate behavior deployed for devices ( SSH only behavior used on a windows IP
address

Classification Phase ( Permissions)

• Inaccurate credentials preventing access to device (WMI,SSH , SNMP)

• Classifiers not accurately defined.

Ex: No classifiers meet the criteria or classifier is inactive

 Krunal Mankar

Troubleshooting for scanned phase:

Issue : No result returned from probe

No device exists or device not turned on for that IP

Device dose not respond to any of shazam probe port

Possible cause

File and printer sharing inbound rules are not enabled for ICMP-Windows Firewall with advance
Security.
 Krunal Mankar

Troubleshooting for Discovery CI classification:

In this section, you will review the classification records in more detail and view the classification
debug log.

1. In the filter, type sys_properties.list and hit enter to open the System Properties list.

2. From the System Properties list, click New.

3. Complete the form as shown.

• Name: glide.discovery.debug.classification

• Type: true false

• Value: true

4. Click Submit.

5. Navigate to Discovery > Discovery Schedules.

6. Execute My Windows Server Discovery.

7. Open the Discovery Status and under the ECC Queue, note the created time for the WMI:
Classify probe.

8. Navigate to System Logs > Utilities > Node Log File Browser.

9. Configure the form as shown.

 Krunal Mankar

10. Click Submit.

Note: A list of all the classifiers, in order, that were tried for your discovery are displayed, including
the attributes and values being tested in the classification criteria. Note the name value for the
Windows 2019 Server does contain 2019, therefore, your Windows Server is classified as a
Windows 2019 server as configured in the classification criteria. The log data displayed here can
be very useful if you need to build additional classification criteria or try to troubleshoot why a
device is not being classified as expected
 Krunal Mankar

Troubleshooting for Discovery CI Identification:

Cloud Dimensions has multiple network devices from the same manufacturer. They have a
requirement that each network device is represented as a CI in the CMDB

1. Navigate to the System Properties by entering sys_properties.list in the Filter navigator.

2. Click New to create a new System Property.
3. Populate the system property record as follows:
• Name: glide.discovery.ire_logs_in_discovery
• Value: True

Note: Setting the system property, glide.discovery.ire_logs_in_discovery will log output from the
IRE to the discovery log located in the Discovery Status record. Setting this property can have an
impact on system performance so it is recommended to only enable this while debugging
discovery.

4. Click Submit.

5. Rerun the Discovery Schedule Router Discovery with SNMP Only Behavior.
6. View the Status record details and click the Discovery Log tab.
7. Verify the Identifier: Hardware Rule, Rule 3 was a Match.

Note: When discovery ran, a match was found based on the attributes listed in the log from the
Hardware Identification Rule. Cloud Dimensions wants these Devices to create two distinct CIs.
 Krunal Mankar

8. From the Devices tab, click the CMDB CI link for jalaro2621 - 198.51.145.211 - v1*.
9. Click the Serial Numbers tab.

Note: The Serial Number and Serial Number Type attributes are an exact match when both
Devices are discovered. The Hardware Identification rule is therefore matching the data and
maintaining just one CI. The Serial Number is the same for both devices and therefore being
treated as a single CI.

10. Navigate to Discovery Definition > CI Identification > Identifiers.

11. Search for and open the Hardware Rule.

12. From the Identifier Entries related list, open the record with Criterion attributes equal to
serial_number,serial_number_type

Solution: Change the serial number for ci record so that identication rule will not trigger and new
ci records with serial number will be added to the table

Solution:
Adding a Custom Attribute and Modifying Identification Rules
Step 1: Add a Custom Attribute
1. Navigate to the Dictionary:
o Go to System Definition > Dictionary.
2. Create a New Custom Field:
o Click "New" to create a new dictionary entry.
o Table: Select cmdb_ci_network.
o Type: Choose String.
o Column label: Enter "Custom Unique Identifier".
o Column name: Auto-generated or enter u_custom_unique_identifier.
3. Save the Custom Field:
o Click "Submit".
Step 2: Populate the Custom Attribute for Special Devices
2. Open Network Devices List:
o Go to Configuration > Network Devices > All Network Devices.
3. Edit Special Devices:
o Open each device record with the same serial number.
 Krunal Mankar

o Populate Custom Unique Identifier with unique values (e.g., DeviceA and
DeviceB).
4. Save Changes:
o Click "Update".
Step 3: Modify Identification Rules
1. Navigate to Identification Rules:
o Go to Configuration > Discovery Definition > CI Identification.
2. Select CI Class:
o Choose the CI class (e.g., Network Gear).
3. Edit Identification Rule:
o Open the identification rule for the selected CI class.
4. Add New Identification Section:
o Click "New" to add a new rule section.
o Field: Select Custom Unique Identifier.
o Add other fields like Serial Number and Serial Number Type.
5. Set Order:
o Ensure the section with Custom Unique Identifier is evaluated first.
6. Save and Test:
o Click "Submit".
o Run a discovery scan to ensure correct identification.
By following these steps, you ensure that the special devices with the same serial number are
treated as unique CIs without affecting the standard identification process for other devices.
 Krunal Mankar

Process vs. Application

Process:
• What It Is: A process is a single running instance of a program or service on a computer.
• Characteristics:
o It's like one task or job that the computer is doing.
o Each process uses resources like CPU and memory.
o Processes have names and IDs (like a label and a number).
• Examples:
o notepad.exe when you open Notepad.
o chrome.exe when you open a Google Chrome browser.
o w3wp.exe for IIS (Internet Information Services) worker process.
o mongoose.exe for Mongoose Web Server process.
Application:
• What It Is: An application is a complete software package that performs specific
functions for the user. It can consist of multiple processes and other components like
files and settings.
• Characteristics:
o It's like a full program or suite of programs working together to provide a service.
o Includes various parts like executable files, configurations, and libraries.
o Manages and monitors all components as a whole.
• Examples:
o Microsoft Office (includes Word, Excel, etc.).
o Google Chrome (includes the main browser process and helper processes).
o A web application like an online banking system (includes the web server,
database server, etc.).
o
In ServiceNow Discovery
Process Discovery:
• Focuses on finding and identifying individual running processes on computers.
• Example: Discovering w3wp.exe (IIS process) and mongoose.exe (Mongoose Web Server
process).
Application Discovery:
• Focuses on finding and identifying entire applications, which can include multiple
processes and other related components.
• Example: Discovering the IIS web application (which includes multiple w3wp.exe
processes, configuration files, and web content) or the Mongoose Web Server application
(which includes mongoose.exe process, configuration files, and web pages).

Simple Scenario
IIS and Mongoose Web Server:
• Process:
o IIS: w3wp.exe is a process that handles web requests in IIS.
o Mongoose: mongoose.exe is a process that runs the Mongoose Web Server.
• Application:
o IIS Application: Might include multiple w3wp.exe processes, config files, and web
pages.
 Krunal Mankar

o Mongoose Web Server: Includes mongoose.exe process, configuration files, and

the web content served by Mongoose.
Key Points to Remember
• Processes are the individual tasks running on a computer.
• Applications are the complete packages that include multiple processes and other
components working together to perform a function.

java.exe process on the machine where the MID Server is installed.

 Krunal Mankar

Application Mapping

• Discovery finds applications to host dependencies base on the running process of a

computer CI.
• During Exploration phase the Application dependency probe is send out to classify the
application based on the process running on device. If application is successfully
classified, then it will show in dependency map of ci record
• Discovery finds the application-to-application dependency based on applications that
have process classifiers and have TCP communication between them.
• Application are classified in exploration phase
• Horizontal Discovery also used Netstat protocol to identify /the application to application
relationship.

Classifications Process for application:

- Locate the device : the device running the application must be classified
and available in CMDB
- Locate the running process
- Determine unique Parameters
- Create Process classifier: created process classifier using unique
parameter
- Execute Discovery
- Verify new application Display

Application Discovery in ServiceNow is a process that identifies and maps the relationships and
dependencies of applications running in your IT environment. This process is crucial for
understanding the infrastructure supporting your business services, enabling better
management, and troubleshooting.

Example: discovering a MID Server application running on a Windows machine.

Steps in Application Discovery

1. Identification of the Host
2. Discovery of Running Processes
3. Determine the unique parameter
4. Create process classifies
5. Mapping to CMDB

1. Identification of the Host

• Before discovering applications, Discovery must first identify the host (in this case, the
Windows machine) where the applications are running.
• A probe is sent to the target machine to gather basic information such as IP address,
operating system, hostname, and other hardware details.
• The collected data is classified to determine the type of device. For a Windows machine,
it might be classified as a Windows Server.
 Krunal Mankar

2. Discovery of Running Processes

• Once the host is identified, Discovery proceeds to identify the running processes on the
machine. This step involves:
• A probe collects information about all processes running on the Windows machine. The
data might include process names, IDs, CPU usage, memory usage, etc.

Example data collected might include:

{
"process_name": "java.exe",
"pid": 1234,
"cpu_usage": 10,
"memory_usage": 50000,
"command_line": "java -jar mid-server.jar"
},
{
"process_name": "notepad.exe",
"pid": 5678,
"cpu_usage": 1,
"memory_usage": 10000,
"command_line": "C:\\Windows\\System32\\notepad.exe"
},
{
"process_name": "chrome.exe",
"pid": 9101,
"cpu_usage": 20,
"memory_usage": 150000,
"command_line": "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe"
}

Determine the unique parameter:

• on windows server there might be number of application running but we want to discover
MID server applications only so we have to determine the unique parameter
• from example data, unique attributes of the MID Server process is command_line
containing mid-server.jar

Create process Classifier :

• Create a new classification entry or modify an existing one to specifically identify the MID
Server application.
• A classifier is set up in ServiceNow to identify specific applications.
• This classifier looks for unique characteristics that only the target application (like the
MID Server) has, such as specific words in the process details.
 Krunal Mankar

Process Handler: Prevent the creation of the duplicate application ci record by filtering out
parameter value

For example, A mid server running on windows server has unique process ID (PID) and this PID is
used to uniquely identify the mid server application, However if the mid server services restarted
the new process id given to the mid server process which makes it look like a second installation
of mid server but in reality it the only one application and it will create two mid server applications
ci record in ServiceNow

To prevent this process handers is used it looks for the unique value of discovered application in
the CMDB such as the installation path. And compared with process running and if the values are
same it considers as same application regardless of process ID is different.

Process Handler also can exclude the process from being classified.

Ex: below process handler preventing the any running on port 22 from being classified.

CI identifiers and process handlers are used to prevent duplicate application cis.
 Krunal Mankar

Asset and CI Relationships

For creation of asset record Model Category and Model field are required

Model Category:

Model categories defines the relationship between ci class and asset class

Determine the creation of asset and ci records

Model: Model are used as template for specific version or various configuration of an asset

A Model can be associate to multiple model category

Enforce CI Class verification:

Automatic creation of asset from ci can be override by Enforce CI Class verification:

Newly Created cis required verification through a ui action

 Krunal Mankar

Agent Client Collector for Visibility (ACC-V)

ACC-V installed on Windows, MAC and Linux system to collect host data

ACC has Multiple capabilities based on installed plugin

- Agent client collector framework(ACC-F)

- Agent Client Monitoring (ACC-M)
- Agent Client Collector for visibility (ACC-V)

Process:

ACC V applies checks and policies to schedule and collect host data which is triggered during
the following cases:

- Periodic scheduling: A policy-based approach where Discovery is

triggered on a periodic basis
- On ci delete when the computer or server record is deleted
- MID server cycle: When the mid server goes down and comes back up
- Target host cycle: When the target host goes down and comes back up
- Network Break: When there is break in network link to target

8433 (This is the default port for Agent Client Collector)

For detailed process:

https://www.servicenow.com/community/itom-articles/discovery-with-agent-client-collector-
step-by-step-configuration/ta-p/2324008

Check Definitions:

- Execute the osquery command on agent

- Osquery commands are used to gather specific attributes details from ci
such as serial numbers file system, running process
- Four check definitions are used by four ACC-V Policies
 Krunal Mankar

Policies:

- Four CI policies for ACC-V

- Define which ci Type to monitor
- Define interval-based scheduling
- Default interval is 86400 seconds which is 24 hours

Working of ACC-V on Window Device Discovery :

The Agent Client Collector is a lightweight agent installed on target devices (such as servers,
desktops, or laptops). It collects detailed data about the hardware, software, and configurations
of these devices and sends it back to ServiceNow.

1.Deployment of ACC listener

The ACC Listener is a server-side component in ServiceNow that receives data sent by the ACC
agents installed on target devices.
It listens for incoming data, processes it, and ensures that it is correctly ingested into the
ServiceNow instance.

2. Deployment of ACC Agent:

ACC is deployed on target devices in this example ACC agent is installed on a Windows server.
This can be done manually or through automated deployment tools.
Once installed, ACC runs as a background service, collecting data continuously or at scheduled
intervals.

3. Check Definitions:
These definitions specify what data to collect, such as system information, running processes,
installed applications, and more.

4. Policies
Policies in ACC define the behavior and scope of data collection, including which checks to
perform, when to perform them, and how often to collect the data.
Policies are applied to target devices to ensure that the appropriate Check Definitions are
executed based on the organization's requirements.
A policy is assigned to the Windows server. This policy includes various Check Definitions.

5. Data Collection:
Based on the policy, the ACC agent performs the specified checks on the Windows server.
For example, it collects CPU usage every 5 minutes and software inventory weekly.
The collected data is sent from the ACC agent to the ACC Listener on the ServiceNow instance.

6. Data Processing:
The ACC Listener receives and processes the data.
The data is then ingested into ServiceNow, updating the CMDB with the latest information about
the Windows server.
5. CMDB Update:
The CMDB is updated with detailed information about the Windows server’s hardware, software,
and performance metrics. Relationships and dependencies are also mapped, providing a
comprehensive view of the IT asset.
 Krunal Mankar

Horizontal Discovery Patterns:

What is Pattern?

Patterns are the series of operations that tells Discovery which Ci to find on network , what
credentials to use and what table to populate in the CMDB. Patterns perform the same functions
as probes like identifies a target CI and Explore a ci details, such as RAM,CPU,OS version etc.

Difference between Pattern and probs:

- Pattern runs during identification and exploration phases and probe runs
during all phases.
- Probes create many ECC queue record whereas pattern create only one
ECC queue record.
- Patterns have faster performance during Discovery than probes.

Types of Patterns

1. Infrastructure Patterns: used to identify hardware or host such as Server, Load Balancer

2. Application Patterns: used identify applications on host using the running process on host such
as IIS, Apache, MSSQL. It is used for both horizontal and top to down discovery.

3. Cloud Pattern: used to collect information about cloud resources in AWS and Azure
datacentres

Pattern Sections:

Identification sections: Used to identify a ci through a series of steps and is part of baseline
pattern record.

Extension: Used to extend the identification section, without changing the baseline pattern and
is saved as shared library.

Steps: Steps are the basis of the discovery . they determine how information is gathered, modify,
verified with in the sequence. Each Step must be successful during discovery or the pattern will
fail

Shared Libraries:

• Steps can be shaved in Shared Libraries and reused between patterns

• Shared patterns are saved in the Discovery pattern (sa_pattern) table.
• Can be modified from the pattern they reference

Debug Mode: It is used to test pattern steps and view the pattern result against the active system.
To Debug the Infrastructure pattern only IP addresses of device is required but for application
pattern both Ip address and Process id required.
 Krunal Mankar

Pattern Operations:
1) Set Parameter Value
- used to set the value of variable or field.
- Ideal for constant or static value
- Value is what will bne return.
- Name is the name of variable.
 Krunal Mankar

Pattern Operations

1. Set Parameter Value

- Used to set a value of a variable or field

- Ideal for constant or static values

- Value : is what will be returned

- Name: is the name of the variable

Variable names must matched the column name of a field, not the label, in order for it populate
in table

2. Parse Command Output

- used to extract information from the command output

- Define Parsing determines the strategy used to extract information such as Delimited text,
RegEx, etc.

- Delimiters and Positions are used to define what specific information will be captured from the
Output
 Krunal Mankar

3. Merge Table

- operation to merge content from two source table into a target table.

- Great final step if variable names match Ci attributes

- Target table should match CI type for final step.

4. Transform Table:

- Add one or more computed columns to an existing table and place the result in a target table.

- Use this operation to unify information from different sources

 Krunal Mankar

5. WMI query

- Get variable information from the target using OS tool.

- Break down the query with UI for field and condiotion.

 Krunal Mankar

6. SNMP Query

- Get variable information from the target

- Uses OID for SNMP query

- Populate Multiple variable into a pattern table.

7. Pattern Step Operations: Parse Variable

- use variable from query to populate pattern table.

- Multiple parsing Strategies.

- Drag and drop capabilities.

 Krunal Mankar

Note:

Parsing Strategies:

Regular Expression:
 Krunal Mankar

Pattern Payload Properties:

Mid.discovery.max_pattern_payload_siza

Important notes of Patterns:

• Whenever we make any changes the OOB functionality like identification section in
pattern we own that functionality and no new update from ServiceNow will be
applicable to that functionality.
• Key field on patterns are used to identify and reconcile the ci records . At least one field
pattern should discover else there will be duplication of the records.
• Values stored in variable in prior steps can be leveraged by subsequent steps
• MID servers store all the patterns locally in the NDL Directory.
 Krunal Mankar

Application Discovery Pattern

Application pattern Debug

Debug type:
Horizontal: Require host name /ip and the Application PID (unique identifier for a process
running on a host)
Top Down: requires an Entry Point Type and unique path such as a URL to locate the application.
 Krunal Mankar

Ways of finding Process ID:

1. From Windows host

2. From host CI after Running Discovery
3. From Log (Discovery status>Discovery log> Discovery pattern log)

An Entry point is how clients access an application service. Entry pints are stored as records in
the Endpoint [cmdb_ci_endpoint] tables. https, http and IP are the most commonly used entry
point types.

Every application uses a pre-defined port number that is used to make connections. HTTP uses
port 80 and HTTPS use port 443.
 Krunal Mankar

Process Classifier just enter the ci record for particular application in cmdb table and creates
the relationships with other cis. But if we require the more details from application ci like
versions install directory then we requires the patterns for that perticuler application
 Krunal Mankar

Discovery - How Location field is set for a CI | Why is the Location field empty on a CI? |
How to set location for CIs

The current implementation sets Location details for CIs using two methods

1. “Update location as needed” Business Rules

• It is the out of the box BR.
• If the CI has an Assignee (assigned to field), discovery can source the location from the
user's Location field post-update.
• e.g. If a user "test" whose location = "INDIA" is set as the CI's assigned to, the CI's
location will be set to INDIA.

2. Discovery Scheduled:

• When using a discovery schedule to discover the CI, Discovery will set the Location field
of the CI from the Location set on the discovery schedule. Add the Location field to the
form if it is missing from your view.

If the location was set by method #1, method #2 will not overwrite it and vice-versa.
NOTE: Exact CI location cannot be fetched by discovery using an Out of Box feature.
 Krunal Mankar

Credential less Application Discovery:

Credential-less Application Discovery attempts to identify an application service actively

listening on a specific port at a given IP address.

Service Mapping launches the Credential less Discovery Application pattern when all
credential-based port classification steps fail. The pattern executes an Nmap command on a
Windows MID Server with Nmap installed, that is configured to perform application/version
detection against a specific remote host IP address and port. If the port being scanned by Nmap
is open, the pattern executes the CredentialLessApplicationClassNameMapper MID Server
script include, which maps the service product, service name, and any extra information
supplied by Nmap to a supported ServiceNow application table. If the script can map the
returned product to an appropriate table derived from the base Application [cmdb_ci_appl]
table, the script passes this information to the pattern. The pattern passes the match to the
Discovery identifier for eventual CI creation or reconciliation. If the information returned by
Nmap does not match any derived table, then the instance uses the base Application
[cmdb_ci_appl] table to create the CI.

Credential Less Host Discovery:

Credential-less host discovery occurs when a scanned host is found to be alive, but not active,
or when all configured credential-based classification probes have failed.

How the host Discovery pattern is launched

If the Shazzam probe scans a host that is alive but not active, and if credential-based
classification probes fail, horizontal Discovery launches the Credentialless Discovery Network
Device pattern to gather host information. If the host being scanned does not have a CI defined,
Service Mapping launches the HorizontalDiscoveryProbe probe, which in turn launches the
Credentialless Discovery Network Device pattern. This pattern attempts to create a new CI if
one does not already exist for the scanned host or to update an existing CI in the Hardware
[cmdb_ci_hardware] table.

The Nmap (Network mapper) command

The Nmap command executed on the MID Server determines if the host is up. Using the IP
address and a list of ports passed to Nmap by the pattern, Nmap performs reverse DNS name
resolution to identify the host name associated with the IP address. If multiple host names are
configured, the first name returned by Nmap is used. If no host name is configured, then the IP
address of the remote host is used to create the host CI. The Npcap packet capture library,
included with the Nmap installation, identifies the host operating system family. If the scanned
host is located on the same subnet as the Windows MID Server host that executes Nmap, the
remote host's MAC address is returned.
 Krunal Mankar

CMDB Health KPIs and metrics

The overall CMDB health score consists of three Key Performance Indicators (KPIs) which are
completeness, correctness, and compliance, each further consisting of sub-metrics. Each
KPI and metric is associated with a scorecard that determines its contribution to the aggregated
health at the overall CMDB level, class, and CI level.

Correctness:

A KPI which is an aggregation of the following metrics

1. Duplicates:
Measures the percentage of duplicate CIs in the CMDB using identification rules. Only
independent CIs are evaluated for duplication. In a set of duplicate CIs, the count of
duplicate CIs is the total number of CIs in the set, minus one.

2. Orphan:
Measures the percentage of orphan CIs in the CMDB. A CI can become orphan if it was
unintentionally left in the CMDB when it is no longer needed. A CI is determined to be
orphan if:
• The CI satisfies the criteria in an orphan rule. This criteria checks for specific attributes
that a CI must have, and for CIs that have no relationships or that don't have specific
relationships.
• Data is missing for the CI in its respective table, or in one of its parents' table.

3. Staleness:
Measures the percentage of stale CIs in the CMDB. A CI is stale if it was not updated
within the Effective Duration time period that is specified in the staleness rule that
applies to the class.

Note: Discovery marks VMware vCenter CIs that no longer physically exist, as stale. By
default, this setting takes precedence over a CMDB Health staleness rule defined for the
CI. When drilling-down in the CMDB dashboard to Health Results, the Source for CIs
determined to be stale by Discovery, is CLOUD_DISCOVERY. Setting the
glide.cmdb.health.src.cmdb_health_audit_only system property to true, ensures that
the CMDB dashboard displays health results generated only by CMDB Health.

Completeness:

A KPI which is an aggregation of the following metrics, according to the completeness scorecard
weight settings.
1. Required
Measures the percentage of CIs in which fields that are defined as mandatory, are not
populated. Missing fields are tagged as incomplete noting that for this CI some
information is missing. Required fields are equivalent to the fields that are specified as
mandatory in the system dictionary.
2. Recommended
Measures the percentage of CIs in which fields that are set as recommended, are not
populated. Out-of-box, no recommended fields are specified.
 Krunal Mankar

Compliance

Based on the results of actual CMDB audit runs.

1. Audit
Audit compares actual values of specified fields, against expected values defined in
template and scripted audits. Based on the Last run date of audits, CMDB Health
identifies the set of the most recent complete audit run and uses those audit results. To
pass the CMDB Health audit test, a CI must be following all audits for that CI. Create a
compliance-type audit, for which the results are calculated into the CMDB Health
compliance KPI.

Relationships

Measures the health of CI relationships, consisting of the following metrics which are not
configurable:
1. Duplicate relationships:
Relationships that have identical parent and child CIs, identical relationship type, and
an identical port. Duplicate relationships are displayed per relationship type. In a set of
duplicate relationships, the duplicate relationship count is the total number of duplicate
relationships in the set, minus one. The detailed graphs for a duplicate set of
relationships display all the relationships in the set.
2. Orphan relationships
A relationship that is missing either a parent CI, a child CI, or both.
3. Stale relationships
A relationship in which the parent CI or the child CI is a stale CI.
A single relationship can fail more than one health test. For example, a duplicate
relationship can also be stale.
Also reports the following relationship-related summaries:

• Relations not compliant with suggested relations

• Relations not compliant with containment rules
• Relations not compliant with hosting rules
 Krunal Mankar

Networking Basics for Discovery

Common IP services and their ports

Services Port
FTP 21
SSH 22
telnet 23
DNS 53
HTTP 80
WMI 135
SNMP 161
HTTPS 443
PRINTERS 575
WIN RM 5985 for http
5986 for https
 Krunal Mankar

SUBNET Cheat Scheet