Discovery

Discovery
Data Collected by Discovery
PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information.
PDF generated at: Thu, 18 Dec 2014 18:02:42 PST
Introduction
Getting Started
Overview
Discovery uses conventional techniques and technology to extract information from computers and other devices. It
uses a wide variety of probes (simple commands or queries) to gather information, and matching sensors (small,
simple programs, usually in JavaScript that you can modify) to analyze that information and load it into the CMDB.
Discovery uses these probes and sensors to explore any given computer or device, starting first with basic probes and
then using more specific probes as it learns more.
Discovery finds out about the existence of any device connected to the network by using the Shazzam probe to
determine what TCP ports are open, and whether the device responds to SNMP queries. From this information,
Discovery infers what kind of device is at that IP address a Unix server, a Windows computer, network switch, and
so on.
For each type of device, Discovery uses different kinds of probes to extract more information about the computer or
device, and the software that's running on it:
Windows computers and servers: remote WMI queries, shell commands
Unix and Linux servers: shell command (via SSH protocol, version 2). Discovery supports Bourne Shell (sh) and
Bourne-again Shell (bash).
Storage: CIM/WBEM queries
Printers: SNMP queries
Network gear (switches, routers, etc.): SNMP queries
Web servers: HTTP header examination
Uninterruptible Power Supplies (UPS): SNMP queries
What Discovery Does with the Information

The information that Discovery gathers about devices can be used to update the Configuration Management
Database (CMDB) automatically. Discovery employs Identifiers to search the CMDB for Configuration Items (CI)
that match devices discovered in the network. These Identifiers can be configured to instruct Discovery to take
certain actions when device matches are made or not made. There are three possible result states that Discovery
recognizes:
When a discovered device is found to match an existing CI in the CMDB, then continue Discovery and update the
CI.
When a discovered device is not found to match an existing CI, then continue Discovery and create a new CI in
the CMDB.
Take no action in the CMDB, whether a match is made or not. Discovery stops after the identification process.
Getting Started
Discovery Architecture
ServiceNow is normally hosted in ServiceNow's data center, and it does not have the ability to access the enterprise's
network but Discovery needs access to do its job. Many enterprises have multiple networks, often separated by
slow WAN links or security barriers and Discovery needs access to all of them.
Discovery uses special server processes (called MID Servers), that are installed on each enterprise network that has
computers or devices to be discovered. Each MID server is a lightweight Java process that can run on a Linux, Unix,
or Windows server. A dedicated server is not required, as the MID server's resource consumption is quite low (and is
controllable). The MID server's job during Discovery is simply to execute probes and return the results back to the
ServiceNow instance for processing; it does not retain any information. In effect, a MID server is a remote extension
of the ServiceNow instance, on an enterprise network.
MID servers communicate with the ServiceNow instance they are associated with by a simple model: they query the
instance for probes to run, and they post the results of probes they've completed back to the instance. There, the data
collected by the probes is processed by sensors, which decide how to proceed. 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.
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 will use SSH to connect to a Unix or Linux computer, and then run a standard command
(such as uname or df) to gather information. Similarly, it will use the Simple Network Management Protocol
(SNMP) to gather information from a network switch or a printer.
For more details, see Discovery Agentless Architecture.
Discoverable Windows Operating Systems

Discovery can classify and discover Windows servers and workstations that use the following operating systems:
Windows NT Server
Windows 2000 Server
Windows 2003 Server
Windows 2008 Server
Windows 2012 Server (starting with the Dublin release)
Windows XP
Windows Vista
Windows 7
Discovery vs. Help the Help Desk

Help the Help Desk is a standard ServiceNow feature available through the self-service application (Self Service >
Help the Help Desk). It will gather information (much as Discovery does) about a single Windows computer by
running a script on that computer. Discovery does many things that Help the Help Desk can not do. Here's a
comparison of the two:
Getting Started
Capability
Discovery Help the Help Desk
Automatic discovery by schedule

Automatic discovery on user login
Manually initiated discovery
Windows workstations
Windows servers
Linux systems
Unix systems (Solaris, AIX, HP-UX, Mac (OSX))
Network devices (switches, routers, UPS, etc.)
Printers
Automatic discovery of computers and devices
Automatic discovery of relationships between processes running on servers
* Returns information about Windows server machines when Discovery is installed.
Discovery Made Easy

Overview
What is Discovery? The easiest way to sum up Discovery is to say that it's a set of conventional (and common)
techniques used to extract information from computers and other devices. The techniques used are nothing new and
have been around for years. In fact, some are over 10 years old. (e.g., SSH - Secure Shell on UNIX).
The Census Agent

Discovery is like the United States Census - the government headcount that sends census agents to your door to
gather information about your household - such as how many people live there and whether you have been to
college. The census agents report their findings back to the government, who puts all the data into a database. Thats
exactly what Discovery does, but instead of a census agent, we use an agent called a MID Server.
Before a census agent can survey a neighborhood, he needs to know where to go. So does the MID Server. However,
the MID Server doesn't quite understand a street address, but instead understands IP addresses. An IP address (for
example, 34.237.9.72) is the address to a computer on a network. The census agent can use your address to get to
your house just fine, but when he arrives he needs some kind of identification or badge so that you will talk to him.
In the Internet world, this identification is known as credentials. Access to computers is normally granted to you if
you have the correct credentials - a user name and password.
What have we learned so far? Before we can discover anything, we need:
A MID Server
IP addresses
Credentials
This is simple enough. After we configure Discovery, we need to start working. Nothing gets accomplished if the
census agent doesnt start knocking on some doors. The next step is to have our MID Server start knocking on doors.
The MID Server finds the devices it needs to question by using the IP addresses it was given.
Discovery Made Easy

When it visits a device, the MID Server attempts to question the device about what language it speaks. A census
agent would probably ask the person at the door what language they speak in their home. To achieve this, our MID
Server does a simple port scan. It scans a few commonly known ports to determine what kind of operating system
the device uses. For example, the MID Server checks to see if port 22 is listening.
What does this mean? When a device is online and communicating with other devices, it usually does this using a
protocol called TCP/IP (or just TCP for short). TCP uses ports to establish a connection and communicate. For
example, Web sites usually run on port 80. When you type in www.google.com, you're connecting to that address via
port 80. Using this example, if we scan a device's ports and determine that it is listening on port 80, we can assume
that it's running a Web server/Web site. We use this same approach to determine what kind of operating system the
device is using. Back to port 22 that's the port most UNIX or Linux machines use for their command line
administrator. So we know that if a device is listening on port 22, the odds are pretty good that it's a UNIX or Linux
machine. We use the same approach for Windows, which listens on port 135.
Once we've determined the operating system, we can talk the talk and communicate with the device using its own
native language.
For UNIX we use SSH (Secure Shell), and for Windows we use WMI
(Windows Management Instrumentation). For other devices like
Netgear (routers and switches) and printers, we use SNMP. So now we
know what kind of operating system the device has, and we know what
language to speak. Now we need to ask it some questions.
The census agent would probably ask questions like How many kids
do you have?" or "How much money do you make? The MID Server
needs to ask questions like What version of Windows are you
running?", "How much RAM do you have?", and "How fast are you?
The MID Server ask these questions with probes. When a MID Server
runs a probe, it's basically asking a question. Asking the question is only half of the work, however. The other half is
writing it down or translating it into terms that ServiceNow can understand. We do this by using sensors. The sensor
is the part of the process that analyzes and records the data. The probe's job is simply to ask the questions and pass
the information along to the sensor, which properly translates the response.
Probing the Neighborhood

Let's go a little more into the world of probes and sensors, since they are the foundation of the Discovery feature.
Probes are sent on their errands by the MID Server, and sensors live on the instance. In the census world, the sensor
would work out of the census office. The MID Server is out in the network (neighborhood) using probes (census
agents) to gather information. That information is returned to the instance where the sensor processes the data.
Sometimes, when the MID Server passes the information to the sensor, the sensor decides that it needs more
information and makes the MID Server run more probes. For example, if the MID Server tells the sensor the device
is running a Web server, then the sensor is going to tell the MID Server to go back to that IP address and run a probe
to ask the device what Websites it hosts.
The following diagram demonstrates the conversation between the MID Server and the sensor.
Discovery Made Easy
Hopefully, you have a basic understanding of Discovery by now. To recap, we'll go over the fundamentals of
Discovery, then run through a scenario that uses these fundamentals.
Discovery is the process of extracting information out of devices and recording it in a uniform way.
The Discovery process uses your ServiceNow instance and one or more MID Servers.
The MID Server is a light-weight (small and simple) agent that runs on a server in your network.
The MID Server needs ranges of IP Addresses and credentials (user names and passwords) before it can begin
discovering.
The MID Server gathers information (using probes) and passes it to the instance to be processed (using sensors).
No Secrets
The MID Server is very adept at ferreting out information, but it's up to you to give it the tools it needs to do the job.
Here's a simple scenario, stepped out to make it easy to follow. Your ServiceNow instance is running, and Discovery
is enabled. You also have a MID Server somewhere in your network that you think is communicating with your
instance. We'll do a Discovery on a single device.
MID Server Preparation

1. The first thing we do is to make sure the MID Server is started and connected to the instance.
For information about connecting MID Servers to an instance, see MID Server Configuration.
2. We must configure our Discovery IP address ranges to include the address of the single device.
In this case the device has an IP address of 10.10.10.5.
3. We must remember to specify credentials for the MID Server to use to log in to the device.
Now that we've configured all the basics, we're ready to kick off a Discovery on 10.10.10.5.
4. To enable Discovery manually, click the Discover Now link in a Discovery Schedule record.
Discovery Made Easy
Discovery Happens
Once Discovery has started, it's all up to the MID Server.
1. The instance prepares a probe for the MID Server with a range of IP addresses to test, and then delivers the probe
when the MID Server checks in for jobs to do.
2. The MID Server visits 10.10.10.5 (knocking on the device's door) and scans the ports.
3.
4.
5.
6.
7.
8.
The port scan sees that the machine is listening on port 22, which means that this must be a UNIX or Linux
machine.
The MID Server advises the instance of what it has discovered.
The sensor creates the Get Operating System probe and delivers it when the MID Server checks in for jobs again.
The MID server probes the Linux machine to determine its operating system.
When the machine replies Linux, the MID Server passes this information to the sensor.
Because this is a Linux machine, the sensor asks the MID Server to send a few more probes to get information
about the hard disk, the network adapters, and any processes that are running.
The MID Server runs each of those probes and sends the results back to the sensor, which translates the findings
for the instance.
Have We Met?
So now you have a list of devices that you found and a lot of information about those devices, but what can you do
with this information? Chances are, you already know about many of the devices that Discovery finds in your
network. Most of the computers, routers, printers, and so forth that you have in your Configuration Management
Database (CMDB) will show up every time you run Discovery. Then there are those devices that you don't know
about yet - devices recently added to the network perhaps - that are not in your CMDB. Well, it makes sense that you
should add those new devices to your database, and it also makes sense to update existing devices, particularly if
someone has installed new memory, new software, or added a disk drive. Discovery can do these things
automatically.
Discovery can launch probes that return identity data from the devices it finds. Discovery then feeds that information
into a handy tool called an Identifier that searches the CMDB for a matching device. If the Identifier determines that
ServiceNow already has a record of the device, the Identifier can tell Discovery to launch more probes and update
the existing record. If the Identifier cannot find a matching device in the database, it can tell Discovery to continue
exploring and then create a new record in the database. If you don't want these automatic updates for any reason, you
can tell the Identifier to stop Discovery and not change anything in the CMDB.
And that's all there is to it! We've learned how to Discover a device by using lightweight, remote probes, and we've
learned that we can use the information returned to update our Configuration Management Database automatically.
Discovery Agentless Architecture

Overview
This page describes the architecture for ServiceNow's Agentless Discovery. The two important parts we will cover
are Communications and Data Collection and Processing. Communication is how your ServiceNow instance talks
to the MID Servers and how the MID Servers talk to your devices. Data Collection and Processing is how we scan
your devices and process the information we have gathered.
Communications
This diagram demonstrates a typical Discovery setup for a hosted ServiceNow instance. The MID Server is installed
on the local internal network (intranet). All communications between the MID Server and the ServiceNow instance
is done via SOAP over HTTPS (Secure HTTP - grey lines). 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
(dashed lines).
The MID Server is deployed in the internal network, so it has access to connect directly to discoverable devices (red
lines). Typical protocols the MID Server uses to communicate with devices are:
UDP
SNMP (Routers / Switches / Printers)
TCP
SSH (Secure Shell, UNIX)
WMI (Windows Management Instrumentation)
Windows PowerShell
8
Note: Proper login credentials are required for accessing devices.
Data Collection and Processing (Probes and Sensors)
At ServiceNow, we refer to "Data Collection" as a Probe and "Data Processing" as a Sensor. Hence when you hear
the term "Probes and Sensors" you can think of "Data Collection and Processing". The purple lines represent the
MID Server probing for information. The MID Server then passes the results of each probe to the ServiceNow
instance via SOAP/HTTPS (grey lines). Sensors (red box) within the ServiceNow instance process the information
gathered and update the CMDB.
If a CI that Discovery found in a previous run does not respond, the CMDB data remains the same as the previously
run Discovery. For example, if a server or database is down, and there is no response to the probe on that port, the
port is ignored for that Discovery run.
Discovery Tasks
Setting up Discovery
Overview
Discovery can run on a regular, configurable schedule or can be launched manually. Whenever a Discovery runs, it
runs over a specified IP address range which tells the Discovery process which specific devices to investigate. To
retrieve useful information, Discovery needs credentials (usually a user name and password pair) for devices within
a particular range so that Discovery can connect to and run various probes on the devices it finds. Discovery
compares the devices it finds with configuration items (CI) in the CMDB and updates any matching devices. If
Discovery does not find a matching CI in the CMDB, it creates a new CI.
For details on how Discovery works, see Getting Started with Agentless Discovery.
To set up Discovery and configure it to update the CMDB accurately, perform the following tasks in the order in
which they appear.
1.
2.
3.
4.
5.
6.
7.
Meet Discovery prerequisites.

Enable the Discovery plugin.
Deploy one or more MID Servers.
Ensure MID Server has connectivity.
Add credentials.
Define and run Discovery schedules.
Validate results.
Meet Prerequisites
Grant Discovery role: Verify that users who are expected to configure and execute Discovery in your network
have the discovery_admin role. This role grants access to the tables in the Discovery application.
Select a MID Server host: Designate a computer to host the MID Server. See MID Server Requirements for
Discovery for a complete list of MID Server requirements.
Gather credentials: Gather the login credentials that the MID server must use to access the devices it is expected
to discover. See Discovery Credentials for instructions on providing Discovery with the proper credentials.
Select IP Address Ranges: Determine the IP addresses that Discovery must scan. In a very complex network, it
is good practice to group IP ranges into a Range Set, which is reusable for different schedules. Discovery will not
scan anything outside of these ranges.
Enable the Discovery Plugin

Discovery is available as a separate subscription from the rest of the ServiceNow platform. To purchase a Discovery
subscription, contact your ServiceNow account manager.
Deploy MID Servers

Install one or more MID Servers on physical or virtual servers that meet the minimum requirements and configure
them to communicate with the appropriate ServiceNow instance. A best practice is to install at least two MID
Servers at first and assign them to different schedules and IP ranges to help complete discoveries quicker. Dedicating
MID Servers to a particular task with Discovery Behaviors can also improve performance.
Ensure MID Server Connectivity

Open the instance and navigate to Discovery > MID Servers. If the new MID Servers are configured properly, they
will appear in the list of MID Servers. If a MID Server does not appear as a choice in the instance, perform the
following checks in the MID Server:
Ensure that the URL in the Configuration Parameters related list provided is correct.
If the MID Server is installed on Windows, make sure the ServiceNow MID Server service is configured properly
with the correct logon credentials and is running.
Check the MID Server log for errors.
UI: Navigate to Discovery > MID Servers > [MID Server] > Logs.
MID Server Host: Navigate to the agent\logs\agent0.log0 directory.
If Basic Authentication is enabled, a username and password must be provided.
The MID Server might not have outbound access on port 443 (SSL) or a proxy server might be preventing TCP
communication to the instance.
Make sure that no firewalls are blocking communication between the MID Server and the instance.
Add Credentials
Set the Discovery Credentials on the instance for all the devices in the network - Windows and UNIX computers,
printers, and network gear. Credentials for Windows devices (using the WMI protocol) are provided by the logon
configured for the MID Server service on the Windows server host. Credentials for UNIX, vCenter, and SNMP must
be configured on the instance. Discovery will automatically figure out which credentials work for a particular
computer or device.
Define and Run Discovery Schedules

The Discovery Schedule is the control point for running discoveries. The schedule controls when Discovery runs,
defines the MID Server to use, the type of Discovery that should run, and the IP addresses to query. Create as many
schedules as necessary, using different types of discoveries, and configure them to run at any time. Let Discovery
run on its configured schedule or manually execute Discovery at any time. These schedules can be set up in a variety
of ways, including a single schedule for the entire network or separate schedules for each location or VLAN.
If you do not know the IP address to scan in your network, run a Network Discovery first to discover the IP
networks. Once discovered, you can convert these networks into IP address range sets that you use in a Discovery
Schedule.
10
11
Note: For advanced discoveries, such as those requiring load balancing or scanning across multiple domains, use Discovery
Behaviors.
Validate Results
Initial Discoveries often reveal unexpected results, such as previously unknown devices and processes or failed
authentication. Results should also accurately identify known devices and update the CMDB appropriately. Become
familiar with the network that is being Discovered and the types of data returned for the different types of
discoveries. Use the Discovery Log and the ECC Queue to monitor the Discovery process as data is returned from
the probes. To view the actual payload of a probe, click the XML icon in a record in the ECC Queue.
Discovery Log
Use the Discovery Log form for a quick look at how the probes are
doing. To display the Discovery Log, navigate to Discovery >
Discovery Log.
Viewing a probe payload in XML
The Discovery Log provides the following information:
Sample discovery log
Column
Information
Created
Displays the timestamp for the probe launched. Click this link to view the record for the probe launched in this list.
Level
Displays the type of data returned by this probe. The possible levels are:
Debug
Error
Information
Warning
ECC queue
input
Displays the ECC queue name associated with the log message.
Message
Message describing the action taken on the information returned by the probe.
CI
The CI discovered. Click this link to display the record from the CMDB for this CI.
Source
Displays the probe name that generated the log message.
Device
Displays the IP address explored by the probe. Click this link to examine all the log entries for the action taken on this IP address
by this Discovery.
Discovery Source
The Source [sys_object_source] table stores information identifying the source of a Discovery (ServiceNow or
another product), the ID of that source, and the date/time of the last scan. To view this information, personalize a CI
form and add the Sources list. This table is populated automatically when the Discovery plugin is enabled.
Manually Changing the Discovery Source Name

To migrate your Discovery Source to ServiceNow:
1.
2.
3.
4.
Update the system property glide.discovery.source_name to have a value of ServiceNow.

Edit the dictionary entry for the Configuration Item [cmdb_ci] table.
Update the choice list for the discovery_source column to only have the value ServiceNow.
Open a list for the Configuration Item [cmdb_ci] table and filter on a discovery source field value you want to
change.
5. Use the Update All option to change the value to ServiceNow.
6. Open a list for the Source [sys_object_source] table and filter on a name field value you want to change.
7. Use the Update All option to change the value to ServiceNow.
Troubleshooting
Navigate to Discovery > Status and examine the status record for the current Discovery. From this record, use the
links to examine the following:
Discovery Log: this log shows Discovery issues such as:
Failed credentials
Inaccessible ports
Problems with Windows Firewall
Viruses or intrusion products running in the network
WMI Services not running
WMI drivers not installed
UNIX devices with ACLs running to restrict access
ECC Queue: examine the payloads of the individual probes and sensors to validate information returned against
what was expected. These results can help explain suspicious errors, such as why no software was detected
running on a network server.
To check returned data, run queries on the MID Server machine from products such as:
Scriptomatic (WMI)
PuTTY (SSH)
iReasoning (SNMP)
12
Common Procedures
Troubleshoot a Discovery using the procedures outlined in the following stages:
1.
2.
3.
4.
Port Scanning
Classification
Identification
Exploration
Enhancements
Eureka
Changes the Discovery source name to ServiceNow.
Calgary
Obsolete configuration parameter: The MID Server configuration parameter
mid.powershell.use_mssqlauth is obsolete and was removed from the platform. Microsoft SQL Server
discoveries use the PowerShell probe, which uses the MID Server's credentials. The PowerShell MSSQL probe
was also removed.
Schedule field visible: A previously hidden field called Starting is now available on the default Discovery
Schedule form. The run_start field enables an administrator to select the date and time that a one-time or
periodic discovery runs. This field appears when a user selects the Once or Periodic option in the Run field.
SNMP object identifier (OID): ServiceNow first attempts to classify an SNMP device using system OIDs. If
that fails, the platform tries to classify the device using the regular OIDs. In previous versions, SNMP
classification with system OIDs could cause an issue if a device was also matched through regular OIDs.
Process handlers: Process handlers prevent the creation of duplicate CIs by filtering out parameters known to
have inconsistent values before process classification occurs.
Gathering vCenter data without Discovery: A new workflow populates the CMDB with vCenter data without
having to install the Discovery plugin. This workflow requires a MID Server and runs the standard VMware
vCenter probe from a Related Link on the VMware vCenter Instance form. See Gathering vCenter Data without
Discovery for details.
New value for wmi_timeout probe parameter: All Windows probes now have a default timeout value of 5
minutes (configured with the wmi_timeout probe parameter), except for the Windows - Installed Software
probe, which is configured with a timeout value of 15 minutes.
Obsolete credential type: The MSSQL credential type was removed from the Credentials
[discovery_credentials] table.
User Name validation: A warning appears if the platform detects leading or trailing spaces in the User Name
field. These spaces prevent the VMware - vCenter probe from connecting to vCenter.
Configuration storage menu: The Configuration menu now contains a Storage section with direct access to
CIM storage tables. Previous access to these tables was through the CI record from a device link in a Discovery
Status record.
Access privileges for discovery_admin: The discovery_admin role was updated to grant access to all the tables
that a user needs to configure and run Discovery.
Storage forms: The HBA and Port related lists were removed from the Storage Pools, Storage Disks, and
Storage Volumes forms to eliminate confusion. These related lists did not have a direct relationship to the forms.
Hyper-V table structure: When you upgrade an instance, ServiceNow migrates virtualization data to a new table
schema and creates a backup table structure to protect existing data.
13
Previous version enhancements
Aspen Patch 3
The localhost MID Server, which was used as the default MID Server in Discovery Schedules, was removed from the platform. The localhost MID
Server originally was intended for demonstration purposes and was not intended to be a supported feature.
Aspen
Support for clustered process Discovery has been generalized to extend beyond Microsoft SQL Server.
14
15
MID Server
MID Server Plugin
Overview
The Management, Instrumentation, and Discovery (MID) Server is a Java application that runs as a Windows service
or UNIX daemon. The MID Server facilitates communication and movement of data between the ServiceNow
platform and external applications, data sources, and services.
For specific requirements for using the MID Server with Discovery, see MID Server Requirements for Discovery.
See the following pages for installation and configuration information:
MID Server Installation
MID Server Configuration
Functional Architecture
The MID Server is a Java process that oversees 2 main functional groups of sub-processes, namely Monitors and
Workers. A Monitor runs in a separate thread as a timer object and is configured to execute a task periodically,
returning its result to ServiceNow's ECC Queue (External Communication Channel Queue). A Worker is an
on-demand thread that executes a task when a corresponding ECC output queue record is read from ServiceNow
(The Queue Monitor reads the ECC output queue and triggers a Worker). For example, a Discovery probe is a
Worker.
Monitors
1.
2.
3.
4.
5.
Auto Upgrade
Heartbeat
Queue Monitor
Queue Sender
Synchronizers
Altiris
LanDesk
Microsoft SMS
JDBC
Workers
1.
2.
3.
4.
Command Line
JDBC
File
Probes
HTTP
WMI
SNMP
SSH
MID Server Plugin
JAR File Synchronization

An administrator can upload a JAR file to an instance and synchronize it to all MID Servers. The administrator can
then write custom probes that use the synchronized JAR file. To upload a JAR file to the instance:
1. Navigate to MID Server > JAR Files.
2. Click New.
3. Complete the following fields:
Name: A unique and descriptive name for identifying the file in the instance.
Version: A version number for the file, if one is available.
Source: Location of the JAR file for reference purposes. Source information is not used by the system.
Description: Short description of the JAR file and its purpose in the instance.
4. Click the paper clip icon in the banner and attach the JAR file to the record.
5. Click Submit.
6. Restart the MID Server service.
The platform makes the JAR file available to any MID Server configured to communicate with the instance.
System Requirements
ServiceNow has tested the MID Server in the following environments:
Windows Server 2003, 2008, and 2012. All Windows Server 2008 and 2012 editions are supported. Virtual
machines and 64-bit systems are supported.
Linux: Virtual machines and 64-bit systems are supported. On 64-bit Linux systems, you must install the 32-bit
GNU C library [1] (glibc). The installation command for CentOS is: yum install glibc.i686
The minimum suggested configuration is:
4GB of available RAM per application

2+GHZ CPU (Multi-core preferred)
500MB of disk space per application deployed
Can ride-along with other services (dependent on server utilization and resource availability)
16
MID Server Plugin
17
Applications
The MID Server is used by the following applications:
Discovery
Orchestration
Import Sets
Altiris
Microsoft SMS / SCCM
Avocent LANDesk
HP OpenView Operations
Microsoft System Center Operations Manager (SCOM)
Borland Starteam Integration
Microsoft MIIS
Reports
The following global reports are available for MID Server analytics (starting with the Eureka release).
MID: Avg Max Memory Percent Use Last 30 Days
MID Host: Avg CPU Use Percent Per Last 30 Days
Enhancements
Fuji
The following records can no longer be modified or deleted:
Table
Public Page [sys_public]
Record
InstanceInfo
Scripted Web Service [sys_web_service]
InstanceInfo
GetMIDInfo
MIDAssignedPackages
MIDFieldForFileProvider
MIDFileSyncSnapshot
MIDServerCheck
MIDServerFileProvider
Eureka
MID Server upgrades support an HTTPS connection over port 443.
Provides a new SSH client with improved connectivity.
Provides new reports for MID Server analytics.
Dublin
Administrators can install a 64-bit MID Server on a 64-bit host system.
Script File synchronization stores all MID Server scripts in the ServiceNow instance to simplify distribution and
security. It is no longer necessary to manually unblock MID Server scripts on the host machine.
Several new business rules ensure that changing a MID Server's name in the configuration parameter also changes
the name in MID Server record. See Available Parameters.
MID Server Plugin

The first MID server to successfully connect with the ServiceNow instance automatically becomes the default
MID Server.
Calgary
Configuration parameter for SSH command delay: The MID Server configuration parameter
mid.ssh.initial_delay_ms enables an administrator to configure the amount of time (in milliseconds)
that an SSH probe must wait to run a command after connecting to a target device.
Configuration parameter for credentials: The MID Server configuration parameter
mid.powershell.local_mid_service_credential_fallback enables the MID Server to use the
login credentials of its service to access a device if all other credentials fail. This parameter replaces the parameter
mid.powershell.use_mssqlauth. This parameter defaults to true.
Access for the discovery_admin role: Users with the discovery_admin role can now access the MID Server
application and all its modules from the application navigator. In previous versions, this role had some access to
MID Server tables, but no access through the user interface.
Configuration parameter for MSSQL credentials with PowerShell: The MID Server configuration parameter
mid.powershell.use_mssqlauth was removed from the platform. MSSQL discoveries with PowerShell
now use either the user account running the MID Server or an Active Discovery credential.
Configuration parameter for fallback credentials: The MID Server configuration parameter
mid.powershell.local_mid_service_credential_fallback was added to allow the MID Server
to use the login credentials of its service to access a device if all other credentials fail.
Configuration parameter for 64-bit Windows hosts: The parameter mid.powershell.path can only
discover 64-bit applications running on Windows hosts if the MID Server is also running on a 64-bit Windows
host.
wrapper.conf configuration file: The wrapper.conf configuration file is not available for user configuration
in Calgary and is replaced for that purpose by the wrapper-override.conf file.
Requirements: Support for certain operating systems has changed in Calgary. The installation command for Linux
CentOS is provided in the documentation.
References
[1] http:/ / www. gnu. org/ s/ libc/
18
MID Server Requirements for Discovery

Overview
The ServiceNow MID Server is used for enterprise application and service monitoring, integration, Orchestration,
and Discovery. The requirements in this page are specifically for the use of MID Servers with the ServiceNow
Discovery and Orchestration products.
System Requirements
ServiceNow has tested the MID Server in the following environments:
Windows Server 2003, 2008, and 2012. All Windows Server 2008 and 2012 editions are supported. Virtual
machines and 64-bit systems are supported.
Linux: Virtual machines and 64-bit systems are supported. On 64-bit Linux systems, you must install the 32-bit
GNU C library [1] (glibc). The installation command for CentOS is: yum install glibc.i686
The minimum suggested configuration is:
4GB of available RAM per application

2+GHZ CPU (Multi-core preferred)
500MB of disk space per application deployed
Can ride-along with other services (dependent on server utilization and resource availability)
External Connectivity Requirements

The MidServer communicates securely on port 443 to the instance and requires no inbound connections. In some
cases, it might be necessary to allow this communication through the firewall if the MID Server fails to register on
the instance. To determine if the application or a network security restriction is to blame for connection failure,
attempt to telnet to the instance on port 443 from the server that is hosting the MID Server application. If this
connection fails, then the problem could be a web proxy (since 443 is a https connecton) or a Firewall rule
preventing external TCP connections from that host. Contact network security personnel for the proxy information to
add to the config.xml file, or request that the Firewall be configured to allow access using one of the following
syntaxes:
<source IP> to <any>
<source IP> to <ServiceNow> any established
<source IP> to <instance_name.service-now.com> 443
Additionally, ensure the MID server can connect to install.service-now.com to download and install updates.
Internal Requirements
The three methods used for discovering various devices on a network are SSH, WMI and SNMP. SSH is used for
accessing UNIX-like machines. Discovery logs into a machine with SSH and runs commands within an encrypted
session to gather system information. Orchestration logs in to UNIX and Linux machines using SSH to perform
Workflow activities. WMI is used by Discovery for Windows based machines and is used for querying the remote
WMI protocol on targets for gathering of Windows information. Orchestration uses PowerShell to run activities on
Windows machines. And lastly, SNMP v1/v2 is used on various network devices (Routers, Switches, Printers) by
Discovery and Orchestration. Detailed information is listed below about these methods.
19
SSH - UNIX
For UNIX-like machines, Discovery and Orchestration use SSH protocol, version 2 [1] to access target machines.
SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices.
SSH communicates on port 22 within an encrypted datastream and requires a login to access the targets using two
available methods of authentication: a user name and password combination and a user name and shared private key.
Specify SSH authentication information and type in the Credentials module. If multiple credentials are entered, the
platform tries one after the other until a successful connection is established or all are ultimately denied. To provide
for application relationships a limited number of SUDO commands must be available to be run. Additional details to
these requirements can be found in UNIX/Linux commands requiring root privileges for Discovery and
Orchestration.
WMI - Windows
For Windows machines, Discovery uses the Windows Management Instrumentation (WMI) [2] interface to query
devices. Due to Microsoft security restrictions for WMI, the MID Server application executing the WMI queries
must run as a domain user with local (target) administrator privileges. When Discovery detects activity on port 135,
it launches a WMI query. The response from the Windows device is sent over a Distributed Component Object
Model (DCOM) port configured for WMI on Windows machines. This can be any port [3]. Ensure that the MID
Server application host machine has access to the targets on all ports due to the unique nature of the WMI
requirements.
Windows PowerShell
PowerShell [4] is built on the Windows .NET Framework and is designed to control and automate the administration
of Windows machines and applications. Orchestration uses PowerShell to run Workflow activities on Windows
machines. PowerShell must be installed on any MID Server that executes these activities. MID Servers using
PowerShell must be installed on a supported Windows operating system. ServiceNow supports PowerShell 2.0.
Orchestration activities for PowerShell require a credentials Type of Windows.
SNMP - Network
For network devices, Discovery uses a SNMP scan [5] to get device specific MIBs and OIDs. SNMP is a common
protocol used on most routers, switches, printers, load balancers and various other network enabled devices. Use a
"community string" (password) for authentication when scanning a device via SNMP. Many devices have an
out-of-box community string of public which Discovery (by default) uses when querying a target. Define additional
community strings in the Credentials module which are tried in succession, along with public, until a successful
query returns. In addition to the credentials, the platform also requires the ability to make port 161 SNMP requests
from the MID Server to the target. If Access Control Lists (ACLs) are in place to control the IP addresses that can
make these queries, ensure that the IP address of the MID Server is in the ACL. ServiceNow Discovery supports
SNMP versions 1 and 2c [6].
The out-of-box Orchestration activity SNMP Query returns the OID of a device and requires SNMP credentials.
20
21
WBEM
Web-Based Enterprise Management (WBEM [7]) defines a particular implementation of the Common
Information Model (CIM [8]): , including protocols for discovering and accessing each CIM implementation.
WBEM requires either of two ports, 5989 or 5988 and uses the HTTP transport protocol. WBEM supports SSL
encryption and uses CIM user name/password credentials. ServiceNow Discovery launches a WBEM port probe to
detect activity on the target ports and to append gathered data to a classification probe that explores CIM Servers.
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
http:/ / en. wikipedia. org/ wiki/ Secure_Shell

http:/ / en. wikipedia. org/ wiki/ Windows_Management_Instrumentation
http:/ / support. microsoft. com/ kb/ 832017
http:/ / support. microsoft. com/ kb/ 968929
http:/ / en. wikipedia. org/ wiki/ SNMP
http:/ / www. paessler. com/ manuals/ prtg_traffic_grapher/ snmpversion12cand3
http:/ / en. wikipedia. org/ wiki/ Web-Based_Enterprise_Management
http:/ / en. wikipedia. org/ wiki/ Common_Information_Model_(computing)

Overview
The Monitoring, Integration, and Discovery (MID) Server is a Java server that facilitates communication and
movement of data between the ServiceNow platform and external applications, data sources, and services.
Video Tutorials
How to Set Up a MID Server
How to Set Up Multiple MID Servers on the Same Host Computer
Satisfying Connection Prerequisites

You must install a MID Server on a local network resource and configure it to communicate with the machines it
will probe. The local network resource must have these network privileges:
Firewall access: Configure any firewalls between the MID Server and the target devices to allow a connection. If
your network uses a DMZ [1], and if your network security protocols limit port access from within the network to
the DMZ, you might have to deploy a MID Server to a machine within the DMZ to probe the devices there.
Network access: Configure target devices to allow the MID Server probe to connect. If network security prevents
you from configuring new machines that can connect to the targets, install the MID Server on an existing machine
with connection privileges.
Network account: Install the MID Server with the proper account, either local or domain administrator.
Additionally, for the MID Server to access your ServiceNow instance, satisfy these prerequisites:
Network access to the ServiceNow instance: Configure the network that the MID Server uses to allow traffic
over TCP port 443.
A MID user: Create a ServiceNow user record for the MID Server to use. This user record must have the
mid_server role.
22
Downloading MID Server Files

Enabling Discovery, Orchestration, or any integration that requires the use of the MID Server, automatically
activates the MID Server plugin. After activation, the MID Server application menu appears in the application
navigator.
To download and install a MID Server, navigate to Mid Server >
Downloads on your instance. Select and download the MID Server for
the appropriate operating system. If the download does not begin
immediately, try the download at a later time as the system may be
busy.
MID Server application menu
Installing a MID Server on Linux

MID Server Downloads module
You can install a MID server on a 32-bit or 64-bit Linux computer. If

you are using a 64-bit operating system with a version of ServiceNow
prior to Dublin, see Installing a 32-bit MID Server on 64-bit Linux.
1. Run mkdir -p /servicenow/<mid server name> to create the installation directory.

2. Extract the downloaded MID Server archive file, mid.<os>.zip into the /servicenow/<mid server name>
directory.
The resulting directory structure is /service-now/<mid server name>/agent.
3. Open the cd /service-now/<mid server name>/agent directory, and edit the config.xml file as follows:
Find the element <parameter name="url" value="
UNIQ-nowiki-0-e01f7ba94fecc571-QINU //YOUR_INSTANCE.service-now.com" /> and
change the value to the URL of your instance.
If basic authentication is enabled, as it is by default, enter the MID user credentials in the
mid.instance.username and mid.instance.password parameters.
Enter connection information for any proxy server used and remove the comment tags from the proxy
configuration information.
4. Execute the shell script start.sh.
5. In the instance identified in the config.xml file, navigate to MID Server > Servers. If Discovery is installed,
navigate to Discovery > MID Servers.
All MID Servers connected to this instance are listed.
6. Make sure that the Status is Up for the MID Server you just installed.
Installing a 32-bit MID Server on 64-bit Linux

A 64-bit MID Server is available with the Dublin release. For releases prior to Dublin, you can install a 32-bit MID
Server on a 64-bit Linux operating system by installing 32-bit libraries. To install the required libraries, run the
command for your Linux operating system version.
Ubuntu: sudo apt-get install ia32-libs ia32-libs-multiarch libgphoto2-2
Redhat: sudo yum y install glibc.i686
After installing the required libraries, install the MID server.
Uninstalling
A MID Server running on Linux operates as a single process. You can end this process to accommodate such tasks
as redeploying the MID Server to another host machine or changing the unique name of a MID Server when
deploying multiple MID Servers.
1. Stop the MID Server process by executing the shell script stop.sh.
2. Verify that the MID Server is running by executing the shell script bin/mid.sh status.
3. After the MID Server stops, delete the files in the agent directory.
Installing a MID Server on Windows

Use the following procedures to install one or more MID Servers on a single machine.
1. Log in to the host machine where you want to install the MID Server.
2. Create a directory for the MID Server on the top level of the drive, with a distinctive name, such as
ServiceNow\MID Server1.
3. Move the MID Server archive file into the new directory.
4. Right-click the archive and select Extract All.
5. Navigate to the \agent directory that was created when the file was extracted.
6. Edit the config.xml file with a text editor such as WordPad:
If basic authentication is enabled, as it is by default, enter the user credentials in the
Find the element <parameter name="name" value="YOUR_MIDSERVER_NAME_GOES_HERE"
/> and change the value to define the name of your MID Server.
NOTE: If this MID Server is installed on a system that contains other MID Servers, edit the wrapper.conf file
as described in the procedure for installing multiple MID Servers.
23
Installing the MID Server as a Windows Service

To run a MID Server as a Windows service in Windows XP, Windows 2000 Server, or Windows Server 2003:
1. Open the agent directory in the directory you created for the MID Server installation files. For example, the path
might be C:\ServiceNow\MID Server1\agent.
2. Double-click the start.bat file to install the Windows service.
To run a MID Server as a Windows service in Windows Vista, Windows 2008 Server, or Windows 7:
1. Click the Start button.
2. In the search box, type command prompt or cmd.exe.
3. In the results list, right-click Command Prompt or cmd.exe, and then click Run as administrator.
This enables the MID Server to be installed with administrative rights under any Windows User Account
Control (UAC) setting.
4. In the command prompt, navigate to \agent in the directory you created for the MID Server files. For example,
the path might be C:\ServiceNow\MID Server1\agent.
5. Run start.bat.
Configuring MID Server Service Credentials

1.
2.
3.
4.
5.
6.
7.
Open the Windows Services console.

Double-click the ServiceNow <MID Server name> service for each MID Server.
Select the Log On tab.
Set Log on as privileges with Domain User or Local Admin credentials.
In the General tab, set Startup type to Automatic.
Click OK.
Restart the ServiceNow <MID Server name> service, and make sure that ServiceNow\<MID Server
name>\agent\logs\agent0.log does not have error messages. If the MID Server does not start, see the ServiceNow
knowledge article Review the agent log for MID Server errors (article KB0535148).
8. On the instance this MID Server is connected to, navigate to MID Server > Servers. If Discovery is installed,
9. Make sure that the Status of the MID Server you just installed is Up.
Uninstalling
The MID Server runs as a stand-alone service. It can be removed easily to accommodate such tasks as redeploying
the MID Server to another host machine or changing the unique name of a MID Server when deploying multiple
MID Servers.
1.
2.
3.
4.
Stop the running MID Server service.

Open a command window (Start > Run > cmd).
Go to the \agent\bin directory in the MID Server installation directory.
Double-click the uninstall.bat file.
24
Installing Multiple MID Servers on a Single System

You can install multiple MID Servers on a single host or on a virtual machine using either Linux or Windows.
Installing multiple MID Servers may involve other setup steps depending on your network configuration. See
Deploying Multiple MID Servers for other considerations. For instances using a version prior to Calgary, see the
previous version information.
Use the configuration file wrapper-override.conf to enter all configuration information. Do not edit the wrapper.conf
file, which contains the default configuration for the MID Server. Any future ServiceNow upgrades overwrite the
contents of the wrapper.conf file, but do not modify the wrapper-override.conf file.
1. Log in to the host system or virtual machine where you want to install multiple MID Servers.
2. Create a directory for each MID Server on the top level of the drive.
Make sure you create a unique and descriptive name for each MID Server, such as MIDServer_SMS_Int or
MIDServer_Disc1.
3. Extract the downloaded MID Server archive file into each MID Server directory.
When this is complete, there should be the a directory path that resembles the following for each MID Server:
\ServiceNow\<MID Server name>\agent.
4. Using a text editor such as WordPad, edit the config.xml file in each MID Server \agent directory, as follows:
change the value to define the name of your MID Server.
If basic authentication is enabled, as it is by default behavior, enter the user credentials in the
5. For each MID Server, edit the \agent\conf\wrapper-override.conf file with a text editor such as WordPad .
wrapper.name [2]: [Required] This name identifies the MID Server process and must be unique. The default
value is snc_mid.
wrapper.displayname [3]: [Required for Windows] This name is displayed to the user in the Windows
Services console. For example, you might enter ServiceNow DevMID01. The default value is ServiceNow
MID Server.
wrapper.java.command [4]: [Optional] This property defines the path to the java bin directory, either relative
to the agent directory or absolute. The default value is jre/bin/java.
wrapper.java.initmemory [5]: [Optional] This property defines the initial Java heap size [6] in MB. The
default value is 10.
wrapper.java.maxmemory [7]: [Optional] This value defines the maximum Java heap size in MB. The default
is 512.
Note: These values cannot be edited while the MID Server is running.
25
Confirming Connectivity
1. Restart each ServiceNow MID Server or MID Server service and make sure that \ServiceNow\<MID Server
name>\agent\logs\agent0.log does not have error messages.
2. In each instance these MID Servers are connected to, navigate to MID Server > Servers. If Discovery is
installed, navigate to Discovery > MID Servers.
3. Make sure that the Status is Up for the MID Servers you just installed.
Versions Prior to the Calgary Release

MID Servers in versions prior to Calgary
Log in to the host machine or virtual machine where you want to install multiple MID Servers.
Create a directory for each MID Server on the top level of the drive.
Make sure you create a unique and descriptive name for each MID Server, such as MIDServer_SMS_Int or
MIDServer_Disc1.
Extract the downloaded MID Server zip file into each MID Server directory.
When this is complete, you should have the a directory that resembles the following for each MID Server:
\ServiceNow\<MID Server name>\agent.
Using a text editor such as WordPad, edit the config.xml file in each MID Server agent directory, as follows:
If basic authentication is enabled, as it is by default, enter the user credentials in the
Enter connection information for any proxy server used. Be sure to remove the comment tags from the proxy
Edit the wrapper.conf file for each MID Server with a text editor such as WordPad. By default, this file is located
here:
\ServiceNow\<MID Server name>\agent\conf
wrapper.console.title=<MID Server name>: This is the title to use when running the MID Server as a
console.
wrapper.ntservice.name=<MID Server name>: This is the internal Windows name for the service and is
not displayed. This name must be unique. For example, example: snc_agent2.
wrapper.ntservice.displayname=<MID Server name>: This is the name that is displayed to the user in the
Windows Services console. For example, you might enter ServiceNow MID Server1.
wrapper.ntservice.description=<New Custom Description>: This is the optional long description of the
service that appears in the Services console.
NOTE: These values cannot be edited in this file after you create the service. Make sure you name and
describe the services correctly before continuing to the next step.
Install the MID Server as a Windows service:
a. For Windows XP, Windows 2000 Server, or Windows Server 2003:
26

1. Open the \agent folder in the directory you created for the MID Server installation files. For example,
the path might be C:\ServiceNow\MID Server1\agent.
2. Double-click the start.bat file to install the Windows service.
b. For Vista, Windows 2008 Server, or Windows 7:
1. Click the Start button.
2. In the search box, enter command prompt or cmd.exe.
3. In the results list, right-click Command Prompt or cmd.exe, and then click Run as administrator.
This enables the MID Server to be installed with administrative rights under any Windows User
Account Control (UAC) setting.
4. In the command prompt, navigate to agent in the directory you created for the MID Server files. For
example, the path might be C:\ServiceNow\MID Server1\agent.
5. Run start.bat.
Edit each MID Server's credentials.
a. Open the Windows Services console.
b. Double-click the ServiceNow <MID Server name> service for each MID Server.
c. In the properties dialog box, select the Log On tab.
d. Set Log on as privileges with Domain User or Local Admin credentials.
e. In the General tab, set Startup type to Automatic.
f. Click OK.
Restart each ServiceNow MID Server service and make sure that \ServiceNow\<MID Server
name>\agent\logs\agent0.log does not have error messages.
In each instance these MID Servers are connected to, navigate to MID Server >Servers. If Discovery is installed,
Make sure that the Status is Up for the MID Servers you just installed.
Upgrading and Testing

The MID Server is upgraded automatically when you upgrade the instance. The system that hosts the MID Server
must be able to access one of these URLs to automatically upgrade (starting with the Eureka release):
HTTPS: https://install.service-now.com on the default HTTPS port (443)
HTTP: http://install.service-now.com on the default HTTPS port (80)
The MID Server automatically tests connectivity through a public scripted web service.
Note: In versions prior to Eureka, the MID Server upgrade URL was only available on the default HTTP port (80).
27
28
Upgrade Error Messages

The MID Server can display the following upgrade error messages.
Message
Description
Unable to refresh packages
The MID Server displays this as a generic error when the error is not handled by a defined error
message.
Failed to query instance for MID Server

buildstamp
Instance is offline or there is a major version mismatch between the MID Server and the instance.
Not a valid package buildstamp
InstanceInfo returned an assigned buildstamp that was not in the correct format, such as a version
mismatch.
Using Basic Authentication

You can enforce basic authentication on each request. Basic authentication requires each SOAP request to contain an
Authorization header as specified in the Basic Authentication [8] protocol.
To set basic authentication for SOAP messages:
1. Navigate to System Properties > Web Services.
2. Select the check box for Require basic authorization for incoming SOAP requests.
3. Click Save.
Supplying basic authentication information, regardless of whether it is required, has an added advantage. The web
service invocation creates or updates data using the supplied credentials. As an example, when you create an incident
record, the journal fields have the user id of the basic authenticated user instead of the default Guest user. This
behavior allows you to identify data added by a specific MID Server.
To provide basic authentication credentials for a MID Server, navigate to C:\Program Files\ServiceNow\<MID
Server name>\agent and edit the config.xml file, as follows:
Find the element <parameter name="mid.instance.username" value=""/> and enter your
instance's administrator user name as the value. For example, you might enter <parameter
name="mid.instance.username" value="admin"/>.
Find the element <parameter name="mid.instance.password" value=""/> and enter the
configured password for this instance as the value. For example, you might enter <parameter
name="mid.instance.password" value="abc123"/>.
Note: The setting for enforcing strict security controls how ServiceNow uses the credentials you provide for the MID Server. When
the setting is enabled, you must provide a user ID with access to the tables the MID Server is trying to access. When the setting is
disabled, any valid user ID allows the MID Server to access to all tables.
Monitoring Your MID Server

A properly functioning MID Server on Windows should be running the following:
A snc_agent service, or custom agent names if there are multiple installations of the MID Server on a Windows
host
A java.exe process
A wrapper.exe process
If the MID Server process is the only Java process running on the host, monitor the memory used by java.exe and
alert on less than the maximum configured memory defined in ~\agent\conf\wrapper-override.conf.
Review the following logs for warning, critical, and severe errors:
~\agent\logs\agent0.log.0
~\agent\logs\wrapper.txt
Verify that the Windows host has no issues on these standard health metrics:
CPU
Memory
Disk utilization
NT Event log
syslog monitoring
References
[1]
[2]
[3]
[4]
[5]
[6]
http:/ / en. wikipedia. org/ wiki/ DMZ_(computing)

http:/ / wrapper. tanukisoftware. com/ doc/ english/ prop-name. html
http:/ / wrapper. tanukisoftware. com/ doc/ english/ prop-displayname. html
http:/ / wrapper. tanukisoftware. com/ doc/ english/ prop-java-command. html
http:/ / wrapper. tanukisoftware. com/ doc/ english/ prop-java-initmemory. html
http:/ / publib. boulder. ibm. com/ infocenter/ javasdk/ tools/ index. jsp?topic=%2Fcom. ibm. java. doc.
igaa%2F_1vg00014884d287-11c3fb28dae-7ff6_1001. html
[7] http:/ / wrapper. tanukisoftware. com/ doc/ english/ prop-java-maxmemory. html
[8] http:/ / www. w3. org/ Protocols/ HTTP/ 1. 0/ draft-ietf-http-spec. html#BasicAA
29
Deploying Multiple MID Servers

Overview
Depending upon how you use the MID Server (for an external integration, Discovery, or Orchestration) and the load
placed on it, you might find it necessary to deploy multiple MID Servers in your network. You can install each MID
Server on a separate machine or install multiple MID Servers on a single machine (including virtual machines). For
instructions on installing the MID Server on multiple machines, see MID Server Installation.
Integrations
Factors determining the number of MID Servers your network will require to support external applications that
integrate with ServiceNow include the following:
The security constraints in your network
The amount of traffic between ServiceNow and the integrations
The reliability of the MID Server machines.
Security
Security policies in your network (firewalls between network segments, for example) might make direct
communication impossible between your instance and an integration's data source (JDBC, LDAP, etc.). To retrieve
data for the instance, you can install a MID Server that has access to both the data source and the instance.
Load balancing
In some cases, a single MID Server can handle all the transactions that occur between an instance and an external
integration. However, in a high volume environment, it might be necessary to deploy multiple MID Servers as load
balancers for certain transactions. For example, JDBC data transfers can tie up the resources of a MID Server,
making it unable to respond to other requests. The following operations between an integration might require
separate MID Servers in a busy network:
File exports
Running scripts
JDBC data sources
Reading files
High availability model

Avoid installing MID Servers for critical integrations on a machine that might experience any type of planned outage
or an outage caused by overloaded processes. If necessary for reliability, consider deploying these types of MID
Servers to dedicated machines for high reliability.
Warning: Do not integrate with an external application on a MID Server provisioned for ServiceNow Discovery or
Orchestration.
30
Discovery
When determining if you need multiple MID Servers to discover the configuration items in your network efficiently,
the following factors must be considered:
WAN deployment: When determining where to deploy MID Servers in a WAN, consider the bandwidth
available between your local area networks. In most cases, the best practice is to install a MID Server on each
LAN to probe devices locally, rather than deploying MID Servers that must probe devices across slow WAN
connections. An alternative to this type of deployment is to install MID Servers that probe other LANs via VPN
connections that take advantage of fast Internet connections. If the bandwidth of your WAN connections is
comparable to that of your Internet connection, then there is no performance impact in running MID Server
probes across WAN connections.
DMZ: Your network policy might require you to install one or more MID Servers in your DMZ to probe the
devices there. This is common in networks that tightly regulate the ports that are opened on the inside firewall.
High capacity: Deploy multiple MID Servers where capacity is an issue, as when Discovery has to gather
information about thousands of configuration items quickly.
Security: If your security policy controls access to network devices (e.g. switches and routers) with an access
control lists (ACL), it might be necessary to install one or more MID Servers on a machine in the network that is
already on the ACL.
Probe types: If you are conducting probes of different operating systems, your network policy might require a
separate MID Server for each type of probe (e.g., one MID server for Windows WMI probes and another for SSH
probes on UNIX)
Orchestration
When determining if multiple MID Servers are necessary to execute Orchestration activities, consider the following
factors:
WAN deployment: When determining where to deploy MID Servers in a WAN, consider the bandwidth
available between your local area networks. In most cases, the best practice is to install a MID Server on each
LAN to probe devices locally, rather than deploying MID Servers that must probe devices across slow WAN
connections. An alternative to this type of deployment is to install MID Servers that probe other LANs via VPN
connections that take advantage of fast Internet connections. If the bandwidth of the WAN connections is
comparable to that of the Internet connection, then there is no performance impact in running MID Server probes
across WAN connections.
DMZ: Network policy might require the installation of one or more MID Servers in the DMZ to probe the
devices there. This is common in networks that tightly regulate the ports that are opened on the inside firewall.
Security: If a security policy controls access to computers with an access control list (ACL), it might be necessary
to install one or more MID Servers on a machine in the network that is already on the ACL.
Probe types: If Orchestration launches probes for different operating systems, network policy might require a
separate MID Server for each type of probe (e.g., one MID server for Windows PowerShell and another for SSH
probes on UNIX).
31
32

Overview
Administrators must configure a MID Server to ensure that it has access to sufficient system resources, probes the
proper data sources, and communicates with the instance as expected. You must complete all the steps in MID
Server Installation before attempting any of the configuration steps explained here.
Note: Using special characters in an XML configuration file requires you to encode them.
Available MID Server Setting Types

You can configure the following setting types on a MID Server. The setting type determines what components are
affected by the MID Server setting. Choose a MID Server setting type that matches the scope you want the setting to
affect.
Type of setting
MID Server Property
Components affected
Overrides
Either:
MID Server properties override MID Server parameters
The behavior of all MID Servers

The behavior of a particular MID Server
MID Server parameter The behavior of a particular MID Server
None
Setting MID Server Properties

Use a MID Server property to control either the behavior of all MID Servers or a particular MID Server. MID Server
properties override MID Server parameters.
1. Navigate to MID Server > Properties.
2. Click New.
3. Fill in the fields, as appropriate (see table).
Field
Description
Name
Enter the property name. See the Name(s) column in Required Parameters or Optional Configuration parameters for a list of parameter
and property names.
Value
Enter the value you want the property to have.
MID
Server
Leave this field blank to set a MID Server property that affects all MID Servers. To set a MID Server property for a particular MID
Server, select the MID Server.
33
Setting MID Server Parameters

Use a MID Server parameter to control the behavior of a particular MID Server. Set MID Server configuration
parameters in either of the following places:
From the Configuration Parameters related list in the MID Server record.
From the config.xml file in the \agent directory of your MID Server installation.
Note: Changes to parameters only take effect when the MID Server is started (or restarted).
Setting Parameters from the ServiceNow Instance

You can view and manage MID Server configuration from the ServiceNow instance.
1. Navigate to the list of MID Servers using one of the following paths:
MID Server > Servers
Discovery > MID Servers
Orchestration > MID Servers (starting with Dublin)
Runbook Automation > MID Servers (versions prior to Dublin)
2. From the list of MID Servers, select a MID Server to configure.
The Configuration Parameters related list shows all the parameters currently in the MID Server's
configuration file. If there are any passwords, they are displayed in asterisks for security reasons.
3. To add parameters, click New, and then complete the form.

After the form is submitted, the configuration file for that MID Server is modified to include the new
parameter. Changes to existing parameters are reflected in the MID Server configuration file as well. Changes
made to the MID Server configuration file do not take place immediately, but rather the next time the MID
Server is restarted. The MID Server form has a related link for restarting the MID Server.
Note: ServiceNow prevents you from saving changes, such as modifying or deleting parameters, that would cause the MID Server to
lose communications with the instance. For example, you cannot change the url parameter. Any changes to these protected properties
must be made directly in the config.xml file for that MID Server.
Setting Parameters from the config.xml File

MID Server configuration is controlled by an XML file called config.xml. This file is located in the \agent directory,
immediately under the directory where the MID Server is installed. Edit this file directly to make any configuration
changes to protected parameters. Many configuration changes, such as those that do not disrupt communication
between the MID Server and the ServiceNow instance, may also be made from the instance.
The structure of the config.xml file is simply an outer parameters tag and a series of inner parameter tags. Each
parameter tag has name and value attributes.
To change the value of a parameter, edit the value attribute.
To add a parameter, add another parameter tag with its name and value.
To delete a parameter, delete the entire parameter tag.
The order of the parameters within the file is not important. Notice the green comment sections in the sample. Use
these elements to add useful comments to the configuration file.
Note: When configuring the MID Server for use with a proxy server, be sure to remove the comment tags around the proxy sections
that you configure.
Note: The sample file here is from FireFox. Conventional text editors, such as Notepad, Wordpad, or TextEdit, do not display colors
and variable fonts.
34
35
Required Configuration
All MID Servers require the following configuration settings.
Setting up MID Server User Credentials

Each MID Server must have a set of ServiceNow user credentials with the mid_server role. This role ensures that the
MID Server can communicate with the instance. See MID Server User Security for more information.
Required Parameters
The following parameters are required for all MID Servers.
Note: Using special characters in an XML configuration file requires you to encode them.
Label
Instance
URL
Names
url
Description
Specifies the URL to the associated ServiceNow instance. Normally the URL is similar to
https://instance.service-now.com, where you replace instance with the instance name. If you host your
own ServiceNow instance, use the URL set by your organization.
MID
Server ID
mid_sys_id
Records the MID Server record's unique identifier. This parameter should be empty when you initially
configure a MID Server. Do not change the value.
MID
Server
name
name
mid.instance.username or
glide.glidesoap.username
mid.instance.password or
glide.glidesoap.password
Type: string
Default value: YOUR_MIDSERVER_NAME_GOES_HERE
If the ServiceNow instance has authentication enabled, as it is by default, set this parameter to define
the user name the MID Server should use to log in to the instance. This user should have the mid_server
role on the ServiceNow instance in order to access necessary tables and fields.
Instance
password
Type: string
Default value: automatically set (GUID)
Use this parameter to supply a name that is meaningful for you. If you do not supply this parameter, the
MID Server uses the default value. A set of business rules synchronizes the name in the configuration
file with the name in the MID Server record (starting with the Dublin release). The business rules
ensure that changing the name in one location also changes the name in the other location.
Instance
user name
Type: string
Default value: none
Type: string
Default value: none
If your ServiceNow instance has authentication enabled, as it is by default, set this parameter to define
the password the MID Server should use to log in to the instance.
Type: string
Default value: none
Optional Configuration
The following configuration settings are optional. While a MID Server should start with the default settings, you
may want to change the default values to improve performance or follow your organization's business practices.
Setting MID Server Memory Size

In the base ServiceNow system, the MID Server memory is set to 512MB, which can be configured in the
\agent\conf\wrapper.conf file in the MID Server installation directory. This setting might not be appropriate for the
way your organization uses the MID Server. If you want the MID Server to work harder, allocate more resources to
it. Or perhaps the MID Server is located in a small branch office with very few devices, and runs in an environment
where memory allocation is shared between a print server, mail server, or web proxy server. In this situation, the
MID Server memory allocation might have to be reduced.
To edit the memory allocation:
1. Navigate to \ServiceNow\<MID Server name>\agent\conf and open the wrapper-override.conf file in a text
editor.
For more information about this file, see Installing Multiple MID Servers on a Single System.
2. Locate the following lines in the file:
# OPTIONAL: Maximum Java Heap Size (in MB)
# wrapper.java.maxmemory=512
3.
4.
5.
6.
Edit the memory allocation.

Remove the comment tag (#) from the memory allocation parameter.
Save the file.
Restart the MID Server service.
Setting MID Server Thread Use

By default, the MID Server uses a maximum of 25 threads. If the MID Server is running on a host containing many
other programs that must compete for CPU time, fewer threads than the default of 25 might be necessary. You can
set the MID Server to use as few as 5 threads without issues. If the MID Server needs more speed, and the host is
powerful enough or lightly loaded with other programs, raise the thread setting. The thread limit depends on the
hardware and the operating system of the host. You might have to experiment to find the optimal value for your
situation. The following general observations may be useful:
Most MID Server tasks require file handles to do their job.
Windows: On the Windows operating system, file handles are available in a fixed quantity. If you configure
too many MID Server threads on a Windows host, the MID Server can consume all the file handles before
approaching maximum CPU usage. This situation appears as an Out of file handles error in the MID Server
log and indicates that the MID Server is trying to use too many threads.
Unix and Linux: UNIX and Linux hosts have a much different scheme for allocating file handles. Generally,
you can increase MID Server thread use on these operating systems until the CPU of the host is overloaded.
See your OS documentation for monitoring CPU usage.
Each thread on the MID Server requires some memory. Exactly how much memory varies considerably from task
to task and depends on the equipment being discovered. To increase the number of threads, you might have to
increase the amount of memory that Java uses. If you configure insufficient memory, an Out of memory error
appears in the MID Server log.
To edit the maximum number of threads allowed for the MID Server:
36

1. Open the \agent\config.xml file using any text editor.
2. Locate the following lines:

<parameter name="threads.max" value="25"/>
3. Edit the value. Keep in mind the cautions described above.
4. Save the record.
Enabling Script File Synchronization for Windows Enhanced Security

Windows Internet Explorer enhanced security blocks downloaded files that it determines are potentially dangerous.
Without script file synchronization, Internet Explorer blocks files downloaded for use by the MID Server, forcing
ServiceNow administrators to unblock each file manually. File synchronization creates the files on the MID Server
rather than downloading them, which does not trigger security blocking. Also, file synchronization between script
records on the instance and the MID Server protects any customer updates in those records from being overwritten
during a ServiceNow upgrade.
Script file synchronization is available starting with the Dublin release. If you are using an older version, see the
previous version information.
How File Synchronization Works

Script files synchronized with the MID Server are stored on the ServiceNow instance in the MID Server Script File
[ecc_agent_script_file] table (MID Server > Script Files). When the MID Server first connects to the instance,
ServiceNow creates a directory called \scripts in the MID Server root. The instance then creates a parent directory in
the path \scripts\<parent name> using definitions from the ecc_agent_script_file table. Finally, the instance creates
the script files themselves inside the parent directory using the records from the ecc_agent_script_file table.
The record for the parent directory looks like this:
The instance creates each script file in the parent directory on the MID Server using the record Name from the
ecc_agent_script_file table as the file name and the Script field payload as the file contents. A script file record
looks like this:
37
38
Unblocking PowerShell Scripts Prior to the Dublin Release

Click the plus for previous version information
Enhanced security on the Windows operating systems can block PowerShell from working with Discovery and Orchestration. If PowerShell does
not run with Discovery or Orchestration, unblock the MID Server archive:
MID Server archive: mid.<build date>.<operating system>.<system bit>.zip
If you do not unblock the archive, unblock each individual file:
Credentials.psm1
LaunchProc.psm1
MSSqlAuth.ps1 (Removed in the Calgary release)
MSSqlWinAuth.ps1 (Removed in the Calgary release)
PSScript.ps1
WMIFetch.psm1
XmlUtil.psm1
Perform this procedure on each MID Server machine:

1.
2.
3.
4.
Navigate to the MID Server archive file.

Right-click the first file in the list and select Properties from the menu.
In the Properties dialog box, click Unblock.
Repeat the procedure for each of the remaining files, if necessary.
39
MID Server Properties

Use the following properties to control the behavior of all probes on a MID Server or all probes on all MID Servers.
See Setting MID Server Properties.
Label
Names
Max length of a
payload that a
MID Server will
return
Description
mid.discovery.max_payload_size Specifies the maximum string length of Discovery probe results that the MID Server will
send to the instance. The MID Server verifies the size of the Discovery probe results before
sending them to the instance. If the Discovery probe results exceed the limit, the MID Server
discards them and returns a warning message. This applies only to probes where the Used by
Discovery field is true. Set the value to any negative number to disable the payload limit
and allow Discovery payloads of any size to be sent to the instance. For example, -1. This
parameter is available starting with the Eureka release.
Max length of an
ECCQ payload
XML that a MID
Server will send
to the instance
mid.eccq.max_payload_size
Type: integer (bytes)

Default value: 5000000
Specifies the maximum string length of a payload that the MID Server will send to the
instance. The MID Server verifies the size of the payload before sending it to the instance. If
the payload size exceeds the limit, the MID Server saves a copy of the payload to the
filesystem on the MID Server host, and returns an error message that contains the location of
the file.
Type: integer (bytes)

Default value: 20000000
CIM Parameters
This parameters determine how a MID Server conducts CIM Discovery.
Label
Interval to wait between
requests to the same CIMOM
(ms)
Names
mid.cim.request.interval
Description
Specifies the number of milliseconds to wait between requests to the same
Common Information Model Object Manager (CIMOM). This parameter is
available starting with the Eureka release.
The maximum amount of

simultaneous connections
allowed per CIMOM
Type: integer (milliseconds)

Default value: 0
mid.cim.host.connection.limit Specifies the maximum number of simultaneous connections to each Common

Information Model Object Manager (CIMOM). A value of zero disables
simultaneous connections. This parameter is available starting with the Eureka
release.
Connection Parameters
Type: integer (number of connections)

Default value: 0
Label
40
Names
The maximum
amount of
standard
messages to
queue in memory
for processing
mid.max.messages
Instance date
format
instance.date.format
Description
Specifies the maximum number of messages to hold in memory for processing. The default
value is computed from the threads.max parameter.
Specifies the format the instance uses for dates and times. The primary impact of setting this
parameter is to allow the MID Server to correctly refresh its start and stop times on the MID
Server record in ServiceNow. The format of this date/time string is identical to that used by
[1]
the Java SimpleDateFormat class, documented here
in the section titled Date and Time
Patterns.
MID Server
immediate
response enable
glide.mid.fast.responses
Type: true | false

Default value: false
Enables a JMX server on the MID Server, which exposes some management information to
JMX consoles. Implementing JMX requires additional configuration of the Java runtime
environment. Setting this parameter to true is only recommended for those with detailed
knowledge of the Java security architecture and a specific need for JMX.
MID Server max

transmission
queue size
Type: string (Date format)

Default value: yyyy-MM-dd HH:mm:ss
Instructs the MID Server to try sending messages to the instance as soon as they are ready.
Normally the MID Server sends message to the ServiceNow instance serially (that is, one
message at a time). Since many probes can be run in parallel, there can be multiple messages
simultaneously transmitted to the instance. Setting this parameter to true may decrease the
time between a probe's completion and its response arriving at the instance. However, the
multiple simultaneous messages consume resources, decreasing the overall instance
responsiveness. If there are communications problems, this parameter's value can also cause a
logjam on the MID Server, as threads normally used for running probes may become
consumed for sending messages. Generally, leave this parameter out of your configuration.
Setting it to true is meaningful only under very special circumstances.
MID Server JMX mid.jmx.enabled

enable
Type: integer
Default value: [10 * threads.max]
Type: true | false

glide.mid.max.sender.queue.size Places an upper limit on how large the queue is allowed to get. The MID Server starts
deleting queued messages if this limit is exceeded. When the MID Server generates messages
to the ServiceNow instance faster than it can send them, it queues them temporarily on the
file system of the MID Server's host. This queue is normally quite small, and is completely
emptied as soon as the MID Server processing slows for a short period. However, this queue
can grow in size when there are communication problems between the MID Server and the
instance, and especially if there is an integration running on the MID Server, .
The parameter is of the form {number}{multiplier}, where {number} is any positive decimal
number including non-integers, and the optional multiplier is any spelling of bytes, kilobytes,
megabytes, gigabytes, or terabytes (only the first character is tested, and the test is
case-insensitive). The default multiplier is bytes. White space is liberally tolerated. The
following strings all represent valid parameters: "1000000000", "0.5m", "5 GB", "7.67gigas",
"145.69392 meg", and "1.1 terra".
Type: string
Default value: 0.5g
MID Server
maximum
number of probe
threads
41
threads.max
Controls the number of execution threads (simultaneous work) that probes may use. This
parameter provides direct control over what CPU resources the MID Server consumes on the
computer that hosts it. To decrease the MID Server's CPU consumption, lower the number of
threads. To make the MID Server work faster, increase the number of threads. See Setting
MID Server Thread Use.
MID Server poll

time
mid.poll.time
Type: integer (threads)

Default value: 25
Sets the MID Server polling interval (in seconds).
Type: integer (seconds)

Default value: 15
Credentials Parameters
Label
Names
Description
Credentials provider mid.credentials.provider Specifies the Java class name of the credentials provider.
Type: string
Default value: com.service_now.mid.creds.standard.StandardCredentialsProvider
Debug Parameters
Label
Debug logging
enable
Names
Description
debug.logging
Specifies whether to enable logging of MID Server events and messages (both sent and received). Normally this
parameter is only used by developers, but it is occasionally useful when troubleshooting a problem. Be aware
that setting this parameter to true causes intensive logging on the MID Server, potentially using considerable
disk space.
Debug mode
enable
debug
Type: true | false

Specifies whether to enable debug logging on the MID Server. Normally this parameter is only used by
developers, but it is occasionally useful when troubleshooting a problem. Be aware that setting this parameter to
true causes intensive logging on the MID Server, potentially using considerable disk space.
Type: true | false

Enables debug
logging for CIM
/ WBEM / SLP /
SMI-S
mid.cim.debug Specifies whether to enable debug logging for CIM, WBEM, SLP, or SMI-S.
Enable debug
logging for
ServiceNow
SSH Client
mid.ssh.debug Enables SSH debug information in the log file. The parameter usage depends on whether the ServiceNow SSH
client is enabled (starting with the Eureka release).
Type: true | false

When the ServiceNow SSH client is enabled, the parameter functions as follows:
Type: string
42
The following string values are valid for the ServiceNow SSH client:
true: Enables SSH debug information in the log file.

false: Disables SSH debug information in the log file.
<IP Addresses>: Specify which IP ranges to enable SSH debug information in the log file. You can
enter IP addresses in the following formats:
[2]
An IP range defined by a slash and the number of bits in the subnetwork . For example, the string
10.10.10.0/24 scans 24 bits of IP addresses from spe10.10.10.0 to 10.10.10.254.
An IP range defined by a dash. For example, the string 10.10.11.0-10.10.11.165 scans the
IP addresses from 10.10.11.0 to 10.10.11.165.
A comma-separated list of specific IP addresses. For example the string
10.10.11.200,10.10.11.235 scans the IP addresses 10.10.11.200 and 10.10.11.235.
deferred: Logs SSH debug information in memory unless an error or warning occurs. If an error or
warning occurs, the platform publishes the debug information to the log file. This ensures that only the
part of the log file pertaining to the error or warning is recorded. If no error or warning is detected, the
platform deletes the unused log data from memory when the session closes. Each session stores up to
1000 log messages. If the session exceeds 1000 log messages, the deferred log discards the oldest log
message to make room for the newest log message.
When the ServiceNow SSH client is disabled, the parameter enables or disables SSH debug information in the
log file:
Type: true | false

DNS Parameters
Label
Names
DNS scanning regulator interval (ms) mid.dns_scan.regulator.internval_ms
Description
Specifies the interval between DNS scans in milliseconds.
Type: integer
Default value: 10
DNS scanning regulator packets per

interval
mid.dns_scan.regulator.packets_per_internval Specifies the number of regulator packets per DNS scan.
DNS scanning default name servers
mid.dns_scan.default_name_servers
Specifies the host names or IP addresses of the default name

servers.
DNS scanning additional name

servers
mid.dns_scan.additional_name_servers
mid.dns_scan.load_balancing_enable
Type: string
Default value: none
Specifies the host names or IP addresses of any additional

name servers.
DNS scanning load balancing enable
Type: integer
Default value: 1
Type: string
Default value: none
Specifies whether to enable load balancing of name servers.
Type: true | false

43
ECC Queue Parameters

Label
Names
Description
The amount of
mid.eccq.monitor.window Specifies the time period to look behind on the ECC Queue in seconds. The default value is 30
time to
minutes.
look-behind on the
Type: integer
ECCQ when
Default value: 1800 seconds
querying for more
work (s)
MID Server ECC
query interval
query_backoff
Allows the interval at which the MID Server queries the ECC Queue to lengthen if the MID Server
is idle. By default, the MID Server queries the ECC Queue for work every 15 seconds. In a system
that employs a large number of MID Servers, these queries can produce unnecessary traffic during
periods of light MID Server activity. When the query_backoff parameter is set to true, the
query interval slowly lengthens for an idle MID Server. Eventually, the interval slows to one query
every four minutes and holds at that rate until the MID Server has a job to do. When the MID
Server starts work again, the query interval for that MID Server immediately increases to once
every 15 seconds and continues at that rate until the demand on the MID Server backs off again.
Type: true | false

Logging Parameters
Label
Names
Disable
monitor
checking
disable_monitors
Query
logging
enable
mid.show.queries
Description
Specifies whether to disable the MID Server from actively checking for monitors on the instance.
Instructs the MID Server whether to log details about every query it makes to the ServiceNow instance.
Typically this parameter is only used by developers, but it is occasionally useful when troubleshooting a
problem. Be aware that setting this parameter to true causes intensive logging on the MID Server,
potentially using considerable disk space.
Remote
logging
disable
Type: true | false

disable.remote.logging Prevents the MID Server from logging any information to the MID Server log on the ServiceNow instance.
Relatively little information is logged on the instance in any case, but setting this parameter to true
eliminates all logging to the instance.
Status
sending
disable
Type: true | false

disable.status
Type: true | false

Prevents the MID Server from sending a status report to the ServiceNow instance every 10 minutes.
Type: true | false

44
Proxy Server Parameters

Use these parameters to configure how your MID Server communicates through a proxy server to access the
ServiceNow instance.
Label
Names
Instance proxy mid.instance.use_proxy or

enable
mid.proxy.use_proxy
Description
If your MID Server must go through a web proxy to access the ServiceNow instance, set this
parameter to true to instruct the MID Server to use the proxy. You must also set the proxy
server's host and port, and perhaps the user name and password as well.
Instance proxy mid.proxy.host

host
Type: true | false

parameter to define the proxy's host.
Instance proxy mid.proxy.password

password
If your MID Server must go through a web proxy to access the ServiceNow instance, and your
proxy requires a password, set this parameter to define that password.
Instance proxy mid.proxy.port

port
Type: string
Default value: none
Type: string
Default value: none
parameter to define the proxy's port.
Instance proxy mid.proxy.username

user name
Type: integer (0-65535)

Default value: 80
If the MID Server must go through a web proxy to access the ServiceNow instance, and the
proxy requires a user name, set this parameter to define that user name.
Type: string
Default value: none
Shazzam Parameters
Label
Port probe
packet
interval
Names
mid.shazzam.regulator.interval_ms
Description
Sets the interval, in milliseconds, in which Shazzam can launch packets. This
parameter works with the
mid.shazzam.regulator.packets_per_interval parameter to set the
number of packets allowed in this interval. By default, Shazzam launches one packet
each millisecond.
Type: integer
Default value: 1
Port probe
mid.shazzam.regulator.packets_per_interval Sets the number of packets that Shazzam can launch in the configured time interval.
packets
This parameter works with the mid.shazzam.regulator.interval_ms
launched per
parameter, which sets that interval. By default, Shazzam launches one packet each
regulator
millisecond.
interval
Type: integer
Default value: 1
Shazzam
chunk size
mid.shazzam.chunk_size
Specifies the maximum number of IP addresses that Shazzam scans in parallel. This
parameter primarily controls outbound port consumption.
Type: integer
Default value: 100
45
SNMP Discovery Parameters

Label
Names
Enable automatic inclusion of SNMP public

community string
Description
mid.snmp.enable_auto_public Specifies whether to enable the SNMP public community

[3]
string .
Timeout to wait for a response for each OID request

(ms)
mid.snmp.request.timeout
Specifies the timeout value for each SNMP OID

request. The default is 1.5 seconds.
Inactivity timeout for an established session - after the

first response is received (ms)
mid.snmp.session.timeout
Type: true | false

Default value: true
[4]
Type: integer
Default value: 1500 milliseconds
Specifies the timeout value for existing SNMP

connections. The default is 0.5 seconds.
Type: integer
Default value: 500 milliseconds
SSH Discovery Parameters

Label
MID Server
connection cache
Names
mid.connection_cache
Description
Specifies whether to cache connections. Set to false' to disable connection caching.
This parameter applies to SSH connections only.
Decide if the PATH

environment variable
should be set for SSH
commands
mid.ssh.set_path
Process commands
against localhost via
SSH rather than
console
mid.ssh.local
MID Server SSH

connection per host
mid.ssh_connections_per_host
Type: true | false

Default value: true
Specifies whether to set the PATH environment variable for SSH commands.
Type: true | false

Default value: true
Specifies whether to execute commands for the MID Server host machine
(localhost) via SSH rather than from a console. This allows long-running commands
to execute properly. This parameter applies to the legacy SSH client only.
Type: true | false

Controls the number of concurrent probes the MID Server can run against a given
host. Lowering the number of concurrent connections can slow Discovery.
Type: integer
Default value:
Enable (or disable)

sudo to preserve
environment (-E) for
SSH
7 for the ServiceNow client

3 for the legacy SSH client
mid.ssh.sudo_preserve_environment Specifies whether to use sudo [5] to preserve the environment for SSH.
Type: true | false

Set the PATH

environment paths for
SSH commands
mid.ssh.path_override
46
Overrides the default paths set before executing a command. Enter one or more
override paths delimited by a colon (:). The default path is /usr/sbin: /usr/bin: /bin:
/sbin.
The ServiceNow SSH client accepts the following prefixes in front of the
path_overide value.
Enable ServiceNow
SSH Client
mid.ssh.use_snc
append: Appends the override path to the end of the hosts path. This is the
default behavior.
replace: Replaces the host path with the path_overide value.
prepend: Appends the override path to the front of the host path.
Type: string (a colon-separated list of directories)

Default value: None
Enables the ServiceNow SSH client. The ServiceNow SSH client is active by default
on new instances starting with the Eureka release. Customers upgrading to Eureka or
a later release can manually switch to the ServiceNow SSH client with this
parameter. Enabling the ServiceNow SSH client disables the legacy SSH client. This
Type: true | false

The maximum number mid.ssh.max_retries

of times to retry an
SSH operation after a
timeout
Specifies the maximum amount of times to retry an SSH operation after a time-out.
The system sleeps two seconds between each connection attempt. By default, the
MID Server retries once only. Set the parameter to 0 to disable retries.
Sets a different
remove file command
to replace the default
'/bin/rm -f'
Sets a different SSH remove file command.
mid.ssh.alt_rm
Delay sending any

mid.ssh.initial_delay_ms
SSH commands to a
server after connecting
mid.ssh.suppress_history
mid.ssh.socket_timeout
mid.ssh.channel_timeout
Type: true | false

Specifies the timeout value for the SSH socket to prevent issues created by a socket
timeout. Some devices, such as systems with embedded controllers like UPSs and
PDUs, that have SSH enabled require more time to respond to an authentication
request. The default value of 1 minute ensures such requests do not timeout
prematurely.
Timeout in ms for
SSH channel activity

Default value: 0
Suppresses the generation of the SSH history file. This parameter applies to the
legacy SSH client only.
Timeout in ms for
SSH socket read
Type: string
Default value: none
Delays sending any SSH probe commands to a server after connecting to the target
for the time specified, in milliseconds. This parameter is available starting with the
Calgary release. This parameter applies to the legacy SSH client only.
Suppress history file

generation for SSH
Type: integer
Default value: 1

Default value: 60000 (1 minute)
Specifies the amount of time that the MID Server waits for activity on the SSH
socket before closing the connection. If there has been no activity on the SSH socket
for the specified timeout value, the MID Server closes the connection. Some
devices, such as systems with embedded controllers like UPSs and PDUs, that have
SSH enabled may require more time to respond to an authentication request. This

Default value: 120000 (2 minutes)
Timeout in ms for
SSH socket read
47
mid.ssh.session_timeout
Specifies the amount of time that a cached session remains in memory after last use.
Excessively small values tend to decrease performance. This parameter applies to
the ServiceNow SSH client only.
Timeout for SSH

command execution
(ms)
mid.ssh.command_timeout_ms

The timeout duration, in milliseconds, for the execution of an SSH command.

[6]
Use keyboard
mid.ssh.use_keyboard_interactive
interactive
authentication for SSH
Uses the keyboard interactive authentication mode

is activated.
Min size of DH group

in bits
Specifies the minimum group length in bits used for generating a "shared secret" key
[7]
in Diffie-Hillman key exchange . The larger the key the more secure the SSH
connection is but at the cost of performance. This parameter is available starting
with the Eureka release.
mid.ssh.dh_group_length_min
Max size of DH group

in bits
mid.ssh.dh_group_length_max
in SSH daemons on which it
Type: true | false

Type: integer (bits)

Default value: 1024
Specifies the maximum group length in bits used for generating a "shared secret"
[7]
key in Diffie-Hillman key exchange . The larger the key the more secure the SSH
connection is but at the cost of performance. This parameter is available starting
with the Eureka release.
Type: integer (bits)

Default value: 2048
Default Paths for SSH Commands

By default, the MID Server is configured to search for SSH commands in the following paths and the logged-on
user's default paths:
/usr/sbin
/usr/bin
/bin
/sbin
Upgrade Parameters
Label
Names
Fixed MID
Server version
mid.pinned.version
MID Server
auto-upgrade
enable
auto_upgrade
Description
Name of the version to which this MID Server is pinned.
Type: string
Default value: build timestamp
If true or absent, enables the MID Server to periodically check whether it should
upgrade. If false, the MID Server remains on the same version, which is
generally neither safe or useful.
Type: true | false

Default value: true
Upgrade branch
48
glide.mid.autoupgrade.branch or
mid.upgrade.branch
Defines a branch (a directory on the distribution server) the MID Server should
download its upgrades from. This might be set if you had a special MID Server
version for some reason. Consult with ServiceNow before adding this parameter
to your configuration.
Upgrade proxy
enable
mid.upgrade.use_proxy
If your MID Server must go through a web proxy to access the upgrade URL, set
this parameter to true to instruct the MID Server to use the proxy. You must also
set the proxy server's host and port. If the instance proxy user name and
password are set, they are used for the upgrade proxy as well.
Upgrade proxy
host
glide.mid.autoupgrade.proxy_host or
glide.glidesoap.proxy_host
glide.mid.autoupgrade.proxy_port or
glide.glidesoap.proxy_port
glide.mid.autoupgrade.proxy_user
glide.mid.autoupgrade.proxy_password
glide.mid.autoupgrade.host
Type: string (URL)

Default value: none
If your MID Server must go through a web proxy to access the upgrade URL,
define the proxy's password here.
Upgrade URL
Type: integer (0-65535)

Default value: 80
define the proxy's user name here.
Upgrade proxy
password
Type: string (URL)

Default value: none
define the proxy's port here. You must restart the instance after changing this
property to apply the change in versions prior to Calgary Patch 6.
Upgrade proxy
user
Type: true | false

define the proxy's host here. You must restart the instance after changing this
property to apply the change in versions prior to Calgary Patch 6.
Upgrade proxy
port
Type: string (path)

Default value: none
Type: string
Default value: none
Controls where the MID Server downloads its upgrades from. Normally, you
should not set this parameter.
Type: string (URL)

Default value: [8]
Windows Discovery Parameters

Label
Enable or Disable
the enforcement
of UTF-8 for
command output
Names
mid.powershell.enforce_utf8
Description
Enable this parameter to force commands on a target Windows system
to return UTF-8 encoded output. Disabling it allows the target system
to use its default encoding. This parameter is only valid when
PowerShell is enabled. Setting this value to false may result in
incorrect values in the CMDB when non-ASCII characters are returned
by a probe.
Type: true | false

Default value: true
Enable
PowerShell for
Discovery
mid.use_powershell
49
Specifies whether to enable PowerShell for Discovery. The MID
Server requires PowerShell version 2 to operate. If the MID Server
cannot find the correct version of PowerShell, it uses WMIRunner
instead.
Type: true | false

Enable/Disable
mid.powershell.local_mid_service_credential_fallback Specifies the login credentials the MID Server uses if all other
automatically
credentials fail. This parameter is available starting with the Calgary
falling back to the
release.
MID Server
Type: true | false
service user
Default value: true
credential if all
other credentials
fail
Timeout for
Windows probes
mid.windows.probe_timeout
Specifies the timeout value for the Windows probe, in seconds. The
default value is 5 minutes.
MSSQL
credentials for
PowerShell
mid.powershell.use_mssqlauth
Type: integer
Default value: 300 seconds
Determines whether PowerShell should use Integrated Windows

[9]
Authentication , also known as Windows Integrated Security, or
SQL authentication when attempting to log into the MSSQL instance.
PowerShell uses Windows Integrated Security by default.
Note: This parameter is obsolete starting with the
Calgary release and has been removed from the
platform. Microsoft SQL Server discoveries use the
PowerShell probe, which uses the MID Server's
credentials. The Calgary upgrade removes any MSSQL
credentials from the Credentials
Powershell use
credentials table
mid.powershell.use_credentials
Specifies whether PowerShell Discovery should use the Windows

credentials from the credentials table. To use PowerShell Discovery on
a single domain, set this parameter to false, and then restart the MID
Server. In this case, the MID Server runs the probes with the
credentials of the user for the MID Server process.
Path to
Powershell
executable
mid.powershell.path
Type: true | false

Type: true | false

Default value: true
Enables an administrator to point to a specific PowerShell on a MID

Server in cases where more than one PowerShell is installed. Supply
the path to the directory containing the PowerShell executable, for
example, C:\mypowershell or C:\mypowershell\. ServiceNow
automatically appends the string powershell.exe to the path.
This parameter might be necessary when both 32-bit and 64-bit
PowerShells are active on the same MID Server, and it becomes
necessary to launch the correct PowerShell for the context. Note that
64-bit Windows employs file system redirection and the MID Server
runs as a 32-bit application. If the path is in %WinDir%\System32,
Windows automatically redirects to %WinDir%\SysWOW64. To avoid
redirection, specify the path as %WinDir%\Sysnative. An example
would be to specify
C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\ instead of
C:\WINDOWS\system32\WindowsPowerShell\v1.0\.
50
Note: On a 64-bit version of Windows Server 2003 or

[10]
Windows XP, a Microsoft hotfix
may be required
to enable this capability.
To discover applications running on a 64-bit Windows machine in the
Calgary release, the MID Server must be running on a 64-bit Windows
host machine. For MID Servers installed on 32-bit hosts to discover
64-bit Windows applications, you must add the
mid.powershell.path parameter to the MID Server and define
the C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\ path.
Timeout for all

Windows probes
on a MID Server
windows_probe_timeout
Type: string (path)

Default value: none
Sets the timeout interval for all Windows probes on a specific MID
Server. This value is overridden by the values configured for
individual probes with the wmi_timeout probe parameter.
Type: integer
Default value: none
References
[1] http:/ / java. sun. com/ j2se/ 1. 4. 2/ docs/ api/ java/ text/ SimpleDateFormat. html
[2] http:/ / en. wikipedia. org/ wiki/ Subnetwork
[3] http:/ / en. wikipedia. org/ wiki/ Simple_Network_Management_Protocol#Security_implications
[4] http:/ / en. wikipedia. org/ wiki/ Object_identifier
[5] http:/ / en. wikipedia. org/ wiki/ Sudo
[6] http:/ / en. wikipedia. org/ wiki/ Secure_Shell#Architecture
[7] http:/ / en. wikipedia. org/ wiki/ Diffie%E2%80%93Hellman_key_exchange
[8] http:/ / install. service-now. com/ glide/ distribution/ builds/ mid/
[9] http:/ / msdn. microsoft. com/ en-us/ library/ aa292114(VS. 71). aspx
[10] http:/ / support. microsoft. com/ kb/ 942589
MID Server Clusters
51
MID Server Clusters

Overview
MID Server clusters enable multiple MID Servers with the appropriate capabilities to be grouped together for load
balancing and fail-over protection. A MID Server can be added to both a load balancing cluster and a fail-over
cluster for more flexibility. MID Server clusters are available for Discovery, Orchestration, and use with products
integrating with ServiceNow.
MID Server Cluster Event

The following event is triggered when the platform cannot find a MID Server with the appropriate capabilities to
replace a MID Server in a fail-over cluster. Use this event to create an email to notify appropriate users that the
cluster has failed.
Event
Table
Description
Business Rule
mid_server.cluster.down MID Server Cluster [ecc_agent_cluster] A MID server cluster has failed MID Server Cluster Management
How Clusters Work

MID Servers in clusters must be able to connect to the all the devices with which they are expected to communicate.
Make sure all the MID Servers are added to any Access Control List (ACL) in use. MID Server clusters are managed
by a business rule called MID Server Cluster Management, which checks to see if the MID Server assigned to a
job in the ECC Queue belongs to a cluster.
Load Balancing
If the cluster business rule determines that a MID Server is part of a load balancing cluster, the application using the
MID Server automatically balances the work between the MID Servers in that cluster. It is best practice to put MID
Servers with the same capabilities in a load balancing cluster.
Fail-Over Protection
MID Servers in a fail-over cluster each have a configured order that the platform uses to determine which MID
Server to use next in case of failure. MID Servers in a fail-over cluster work independently and do not load balance
with other MID Servers in that cluster (although they might also be members of load balancing clusters). When a
MID Server fails, the MID Server Cluster Management business rule selects the highest available MID Server in
the order to take over the work. The selected MID Server checks the ECC Queue and starts with jobs that are either
Processing or Ready. It is best practice to configure a fail-over MID Server with at least the same capabilities as the
MID Server it is intended to relieve.
MID Server Clusters
Combining Clusters
A MID Server can be a added to both types of clusters at the same time. This diagram shows a scenario in which a
MID Server from a load balancing cluster (MID Server D) is also present in a failover cluster.
If MID Server D fails, MID Server E in the failover cluster is available to the load balancing cluster to perform the
tasks previously assigned to MID Server D.
Configuring a Cluster
1.
2.
3.
4.
5.
6.
Navigate to MID Server > Clusters.

Click New.
Name the cluster and select the cluster type: Failover or Load Balance.
Right click in the header bar and select Save from the context menu.
Click Edit in the Includes MID Servers Related List.
Select appropriate MID Servers for this cluster from the slushbucket.
Note: All MID Servers in a cluster must have capabilities defined. Ensure that each MID Server has the
appropriate capabilities for the job. A MID Server in a failover cluster must have the same capabilities (or
expanded capabilities) as the MID Server it is expected to replace.
52
Controlling the MID Server Version
Controlling the MID Server Version

Overview
ServiceNow MID Servers are configured to check the instance for the correct MID Server version once every hour.
If the version has changed since the last check-in, the MID Server upgrades or downgrades itself accordingly. An
administrator might want to edit the MID Server version to enable a new feature or get a fix for a defect. There are
two properties that control how and when the MID Server can change its version:
mid_buildstamp
mid.version.override
Note: Downgrades are only possible within the same release family. For example, you can downgrade from Dublin Patch 3 to
Dublin Patch 2, but not from Dublin to Calgary.
mid_buildstamp
The mid.buildstamp property identifies the MID Server version with an identifier based on the date of the build.
This property uses a date and time format of yyyy-mm-dd-hhmm.
The MID Server checks for version information hourly. If no override version is configured, the MID Server looks at
the mid_buildstamp property for the version to use. This property resets itself to the default version (the version that
matches your instance version) when the instance is restarted or upgraded, so any user changes are lost at that time.
mid.version.override
Use this property to set an override condition for the current MID Server version. When the MID Server checks the
version each hour, it looks at the mid.version.override property first. If this property is empty, the MID Server will
get its version information from the mid_buildstamp property. If an override version is configured, the MID Server
uses this value and ignores the version information in the mid_buildstamp property. This override value remains
when the instance is restarted and is passed to the MID Server at check in. However, the version in the
mid.version.override property is deleted during an upgrade, allowing the MID Server to reset itself to the version in
the mid_buildstamp property.
Create the property and then set the value.
1. In the Navigation pane filter, type sys_properties.list.
2.
3.
4.
5.
The list of system properties appears.

Click New.
Type mid.version.override in the Name field.
Enter a description, such as, Set an override value for the current MID Server version.
Enter a version for the MID Server to use that is different from the version ServiceNow has selected in the
mid_buildstamp property.
The date and time format is yyyy-mm-dd-hhmm.

6. Click Submit.
53
MID Server Heartbeat
MID Server Heartbeat

Overview
The ServiceNow platform checks the MID Server for a response every 5 minutes, using a synthetic transaction
monitoring system. When the MID Server changes status ( from Up Down or from Down Up), a system event
is triggered which can be used for script actions or to send notifications.
Checking for a Heartbeat

ServiceNow instances send a synthetic transaction via the Heartbeat probe to every MID server every 5 minutes.
The Heartbeat probe functions exactly as a normal probe does and is sent by writing an output record to the ECC
queue. A MID Server retrieves the record when it queries the ECC queue for work. The MID Server processes the
probe just as it would any other probe and responds back to the instance. If the instance does not detect a response
from a MID Server, the instance marks that MID Server as Down. If the MID Server responds, the instance
considers the MID Server to be Up.
System Events
When a MID Server transitions from one state to another, one of these events is triggered:
mid_server.up: The MID Server goes from a status of Down to a status of Up.
mid_server.down: The MID Server goes from a status of Up to a status of Down.
Scheduled Job
To change the trigger interval for the Heartbeat probe, navigate to System Scheduler > Scheduled Jobs > Scheduled
Jobs. Open the MID Server Monitor record and edit the interval.
54
MID Server User Security
MID Server User Security

Overview
The strict SOAP security feature, enabled by default for any instance that uses basic authentication, protects all
tables with Access Control Lists (ACL). The tables that the ServiceNow MID Server must access are protected by
these ACLs and are unavailable to the MID Server unless the MID Server user has specific roles.
The mid_server Role

The mid_server role allows the MID Server to access protected tables when strict SOAP security is in place. Add
this role to the MID Server user for any instance on which basic authentication is enabled. The system adds the
necessary SOAP roles automatically with the mid_server role.
55
56
Probes and Sensors

Shazzam Probe
Overview
When you run Discovery, the Shazzam probe finds your active network devices by scanning specified ports on
specified IP address ranges.
Configuring the Shazzam Probe

Properties
The default property values are correct for most discoveries.
To configure properties for the Shazzam probe, navigate to Discovery Definitions > Properties, and edit the
following properties (see table).
Property
Max range
size
Description
Default
The maximum number of IPs to scan in a single Shazzam probe. If a range has more IPs than are specified here, the probe 100000
is skipped and a warning is logged.
Parameters
You control the behavior of individual Shazzam probes using basic and advanced parameters.
1. Navigate to Discovery Definition > Probes.
2. Select Shazzam.
3. Add or edit parameters in the Probe Parameters related list.
Basic Parameters
These parameters are defined in the config.xml file on the MID Server, but you can edit the values in the Shazzam
probe record as well. Changes to specific parameters that could disconnect you from the MID Server are prohibited
in the probe record and can only be made in the configuration file.
Shazzam Probe
57
Parameter
shazzam_chunk_size
Description
The maximum number of IP addresses Shazzam will scan in parallel. This parameter primarily controls
outbound port consumption.
Default
Value
100
regulator_max_packets Sets the number of packets that Shazzam can launch in the time interval specified by the
regulator_period_ms parameter.
regulator_period_ms
Sets the interval, in milliseconds, in which Shazzam can launch packets.
Advanced Parameters
These parameters are available for fine tuning the Shazzam probe. These values are defined in the probe record only.
Parameter
Description
Default
Value
report_inactive
When true, reports device that are alive but inactive. For example, a device has no ports open but true
refuses at least one port connection request.
report_dead
When true, reports devices with dead IP addresses. For example, a device that has all ports
closed.
false
GenericTCP_waitForConnectMS Sets the number of milliseconds the GenericTCP scanner waits for a connection.
1000
BannerTCP_waitForConnectMS
Sets the number of milliseconds the BannerTCP scanner waits for a connection and banner.
1500
HTTP_waitForConnectMS
Sets the number of milliseconds the HTTP scanner waits for a connection.
500
HTTP_waitForResponseMS
Sets the number of milliseconds the HTTP scanner waits for a response.
500
NBT_waitForResponseMS
Sets the number of milliseconds the NBT scanner waits for a response.
500
NBT_alternativePort
Defines an alternative port number for the NBT scanner.
N/A
SNMP_taps
Sets the number of taps (requests) the SNMP scanner attempts.
SNMP_tapIntervalMS
Sets the number of milliseconds the SNMP scanner waits between taps.
1000
SNMP_waitForResponseMS
Sets the number of milliseconds the SNMP scanner waits for a response after the last tap.
1000
SNMP_alternativePort
Defines the alternative port number for the SNMP scanner.
N/A
DNS_waitForResponseMS
Sets the number of milliseconds the DNS scanner waits for a response.
1000
DNS_alternativePort
Sets an alternative port number for the DNS scanner.
N/A
debug
Enables debug logging if set to true.
false
scanner_log
Enables scanner logging if set to true. This logging information appears in the Shazzam probe
response.
false
Port Probes
58
Port Probes
Overview
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 SSH, WMI, and SNMP in the out-of-box
system have priority numbers that control the order in which they are launched. 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 gathers information on the device. The SNMP probe is always the last to scan, after
the other port probes have failed. This method allows Discovery to classify a device correctly if the device is running
more than one protocol (e.g. SSH and SNMP).
Port Probe Form

To access the Port Probe form, navigate to Discovery Definition > Port Probes. An out-of-box port probe record
looks like this:
The Port Probe form provides the following fields:

Field
Input Value
Name
Simple name for the port probe that reflects its function (e.g. snmp).
Description
Definition of the acronym for the protocol. (e.g. ssh is Secure Shell Login).
Scanner
Shazzam techniques for exploring a port. Some of these are protocol specific, and others are generic. For example, a WMI port
probe will use a Scanner value of Generic TCP, and the snmp port probe uses a value of SNMP.
Conditional
Runs this port probe if any one of the non-conditional probes return an open port. The conditional port probes in the out-of-box
system attempt to resolve the names of Windows devices and DNS names. These ports probes take additional resources and are
not used unless activity is detected on open ports.
CIs
Indicates whether this port probe is enabled or disabled for discovering "Configuration Items".
IPs
Indicates whether this port probe is enabled or disabled for discovering "IP addresses".
Active
Indicates whether this port probe is enabled or disabled.
Triggered by
services
Indicates which services define the port usage. Use this setting to define non-standard port usage and pair the port number with
the protocol.
Triggers probe
Indicates which probe is triggered by the results of this port probe. This is the name of the appropriate classify probe.
Port Probes
59
Use
classification
Names the appropriate classification table, based on the protocol being explored.
Classification
priority
Establishes the priority in which this port probes must be run. If the first port probe fails, then the next probe runs on the device,
and so forth, until the correct data is returned. This allows for the proper classification of a device that has two running protocols,
such as SSH and SNMP. The default priorities for the Discovery protocols are:
1 - WMI
2 - SSH
3 - SNMP.
CIM Probe
Overview
The CIM probe uses WBEM protocols to query a particular CIM server, the CIM Object Manager, for a set of data
objects and properties.
Parameters
The following parameters may be passed to the CIM probe:
Parameter
Description
Default Value
source
[Required] The initial host to connect to.
None
port
The port to connect to. If empty, the value is determined by the "schema" parameter: http = 5988, https =
5989.
5988 or 5989
schema
[Required] The schema to use: '"http"' or '"https"'.
http
namespace
[Required] The CIM namespace. May be overridden by a query.
None
queries
[Required] A semicolon-delimited list of CIM probe queries to process and return results for.
None
retries
The number of times to retry a query if it fails due to network connectivity issues.
connection_timeout The number of milliseconds the probe has to connect to a server.
5000
socket_timeout
5000
The number of milliseconds the probe has to read data.
Query Language
The CIM Intermediate Query Language (CimIQL) uses keys, filters, and dot-walking to traverse the CIM schema.
Parameter Expansion
The CIM query language supports standard SNC preprocessed probe parameter expansion. Place variables in queries
by encapsulating their names like this:
${foobar}.CIM_RunningOS[0].Name
CIM_ComputerSystem.${barfoo}
The text ${foobar} is replaced with the contents of the foobar probe parameter passed to the CIM probe;
likewise for barfoo.
Database Catalogs
60
Database Catalogs
Overview
In ServiceNow, the Database Catalog lists all the catalog objects, or databases, discovered for an instance of a
database. For example, the ServiceNow catalog view of a single instance of Microsoft SQL Server might contain
several dozen catalogs, each of which contains SQL Server tables. In the base platform, ServiceNow enables
administrators to populate catalog views of common database products such as Oracle, MySQL, and SQL Server,
and provides a Discovery probe and sensor for creating Microsoft SQL Server catalog views and for updating those
catalogs in the CMDB.
Note: Different database manufacturers use the term catalog differently. For example, MySQL uses database to mean catalog.
Viewing Database Catalogs

To view a database catalog, navigate to Configuration > Database Catalogs and select a database.
A list of all the catalogs in the database appears.
An example of a database catalog is the Microsoft SQL Server catalog on the sandb01 server, which is populated in
the CMDB automatically by a default probe called Windows - Get SQL Information. Click the link in the
Database Instance column to view the CI for the selected SQL Server database. The list of catalogs for that
database is included in the MSFT SQL Catalogs related list.
Database Catalogs
Generating Catalogs
Database catalogs can be imported into ServiceNow from a third-party discovery tool, entered into the platform
manually, or discovered by ServiceNow Discovery. The Windows - Get SQL Information probe is configured to
populate the MSSQL Database Catalog in the CMDB. To generate catalog data for other databases with Discovery,
create probes and sensors for those databases. See Discovery Probes and Sensors for instructions. To use Discovery
to generate database catalogs, install the Discovery Plugin.
61
Custom Probe - Text File

Overview
This custom Discovery probe will help you if you need to read a text file from a Windows computer and populate a
CI in the CMDB with the values from the file. In this example the user wanted to read files created by BGinfo.
Note: When you have completed the probe and sensor, place the probe in the appropriate Windows classifier at Discovery
Definition > CI Classification > Windows.
Creating a New Probe

1. Navigate to Discovery Definition > Probes, and then click New.
3.
4.
5.
6.
Name: Unique and descriptive name for the probe

Probe type: Select Probe.
Description: Describe the function of this probe.
Used by Discovery: Select this check box
ECC queue topic: This is name of the probe the MID server is to run. In this example, we use WMIRunner.
ECC queue name: In this example, we use the descriptive name WMI: BGInfo files.
Right-click in the header bar and select Save from the context menu.
Select the Probe Parameters tab in the Probe form, and then click New.
Enter WMI_GetFiles.js as the Name of this parameter.
Copy the script below into the Script field and edit as needed.
7. Click Submit.
The completed probe form looks like this:
62
//
// Use ServiceNow WMIAPI to gather stats
//
var CMD_RETRIES = 3;
var scanner = getScanner();
if (scanner) {
var output = "";
for(var i = 0; i < CMD_RETRIES; i++) {
output = scanner.winExec("%SystemRoot%\\system32\\cmd.exe /C type
\\\"C:\\Information Systems\\BgInfo\\*.txt\\\"");
if (output)
break;
}
scanner.appendToRoot("output", output);
}
Creating a Sensor
1. Navigate to Discovery Definition > Probes, and then click New.
Name: Use the same name as the matching probe. In this example, we use Windows - Get BGInfo files.
Reacts to probe: The name of the probe created in the previous procedure: Windows - Get BGInfo files
Sensor type: Select the type of sensor to create - in this example Sensor.
Description: Describes the function of this sensor.
Script: Copy the script below into the Script field and edit as needed.
Sensor type: Determines how the answer from the probe is processed - in this example Javascript.
3. Click Submit.
//
// Sensor Script text
63

//
new DiscoverySensor({ data: {}, process: function(result) {

this.parseOutput(result.output);
this.update(this.data);
},
parseOutput: function(output) {
var currentFile;
var files = {};
if (output.startsWith("<wmi")) {
var bgout = new XMLHelper(output).toObject();
if (!bgout)
return;
output = bgout.output;
}
var lines = output.split(/\n/);
for(var i = 0; i < lines.length; i++) {
var line = lines[i];
if (line.startsWith("C:\\Information Systems\\BgInfo\\")) {
currentFile = line.substr(30);
files[currentFile] = "";
} else if (currentFile) {
var newLine = line.trim();
if (newLine)
files[currentFile] += (files[currentFile]?
"\n" : "") + newLine;
}
}
this.data['u_jack_id'] = files['JackID.txt'];
this.data['warranty_expiration'] = files['Warranty.txt'];
this.data['po_number'] = files['Ponum.txt'];},
type: "DiscoverySensor"
});
The completed form looks like this:
64
65
66
Device Classification
Device Classifications
Overview
After Discovery detects active devices in your network using a port scan (Shazzam probe), Discovery attempts to
classify the devices so that it can gather additional information. Discovery launches classify probes that query
devices to find out such things as operating system and version information. For information, see Data Collected by
Discovery.
The following classify probes are included with the platform:
UNIX - Classify: SSH commands for all UNIX operating systems. ServiceNow supports SSH protocol, version 2
only.
SNMP - Classify: SNMP commands for all network devices, such as printers, routers, or UPS.
Windows - Classify: WMI commands for all Windows machines
How Device Classification Works

When Discovery is initiated, the Shazzam probe is launched to detect open ports on devices in the network. The data
returned is used by the Shazzam sensor to identify certain characteristics about these devices based on the activity
known to exist on these ports. For example, UNIX-based operating systems communicate with the SSH protocol
over port 22, and Windows communicates with the WMI protocol over port 135 or higher. Discovery makes certain
assumptions about the devices, applications, and processes running on these ports and launches the appropriate
classify probes to find out more. Classify sensors process the data returned from the probes and compare it with
configured criteria for each class of device. At this point, classification varies, depending upon the type of scan
selected and the version of ServiceNow being used.
Process classification occurs during the exploration phase of Discovery, after device classification. For more
information, see Process Classifications.

The out-of-box Discovery system provides separate classifiers for the following Windows server versions:
Windows NT Server
Windows 2000 Server
Windows 2003 Server
Windows 2008 Server
Windows 2012 Server (Starting with the Dublin release)
Windows Cluster VIP
The Windows classifier supports the following Windows workstation operating systems:
Windows XP
Windows Vista
Windows 7
Windows 8 (Starting with the Dublin release)
Classification
Device classification occurs only when a Discovery Schedule is configured to discover Configuration items. This
scan type enables Discovery Identifiers and is the only scan that can be used to update the CMDB.
When Discovery has determined the device's class, it launches an identity probe - a multiprobe - that is configured to
run one or more commands with a single authentication. The identity probe in the out-of-box system can be
configured to ask the device for information such as its serial numbers (there can be more than one), 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.
This diagram shows the processing flow for classifying and probing devices with Identifiers configured.
IP Scan Mode
The IP Scan mode enables credential-less Discovery, which attempts to identify devices and software based on just
the open ports and banners it finds. If the classification criteria are met for a device in the IP Scan mode, Discovery
automatically updates the CI in the CMDB. After a device is properly classified, Discovery launches the exploration
probes configured for that class of device and begins gathering detailed information about the CI. For example, in
the default ServiceNow system, the Linux classification triggers eleven exploration probes that return information
such as disk size, memory, and the number of current connections. The data from these probes returns at different
times and is stored in the ECC Queue until processing is complete.
This diagram shows the processing flow for classifying and probing devices with Discovery IP Scan (no Identifiers):
67
The Classification Form

Select Discovery Definition > CI Classification in the navigation pane and select the desired classification.
ServiceNow includes classifications in the base platform that discover most common operating systems, network
devices, and processes. ServiceNow provides the following fields for creating new device classifications or edit
existing ones.
Field
Input Value
Name
Name of the configuration item (CI)
Active
Enable or disable this classification.
Order
Configure the order (sequence) in which the platform run this classifier,
Table
Select the a table for this classification. For example, if this record classifies a Windows server, select the Windows Server
[cmdb_ci_win_server] table.
Match Criteria Select which criteria must match to classify this device - Any of the parameters or All of the parameters.
On
classification
script
This script runs if classification criteria are met. Use this script to perform any special tasks after a device is classified. It is
possible to use the g_probe_parameters hashmap from within a classification script to set probe parameters for any configured,
triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all triggered probes.
(JS), g_probe_parameters['node_port'] = 16001; //

Classification
Criteria
These criteria are formed from specific parameters and the values that they must contain to match devices that Discovery finds in
the network with CIs in the CMDB. For a detailed discussion of these parameters, see Discovery Classification Parameters.
Triggers
probes
These are the exploration probes that Discovery launches to gather detailed information about a CI that it has classified in the
network.
A completed CI classification form with exploration probes defined is shown here. For instruction on creating
probes, see Discovery Probes and Sensors. The probes defined here are launched when the device is properly
classified, unless Discovery is configured to stop after classification.
68
69
Classification Criteria
The classification criteria for a device classification includes a parameter, an operator, and a value. The available
parameters are those returned by Discovery classify probes for each class of device found. The values configured for
these parameters are the values that Discovery is looking for to establish a device's class. For available parameters
for each default classification, see Discovery Classification Parameters. In this example from the base ServiceNow
platform, the device to be classified has a name value that starts with Windows 2003.
The On classification script field can be used to further customize the application record being created. The
following objects are exposed for this purpose.
Parameter Description
isNode
Indicates if this instance is a node.
type
Returns the classification windows.
isVIP
Indicates if this CI is a virtual machine, with a virtual IP address.
ip_address
Returns the IP address of the device being discovered.
name
Name of the Windows version, such as Windows 2003 Standard.
Reclassifying a Windows Workstation Machine as a Server

By default, Discovery automatically classifies computers using certain Windows operating systems as workstations.
(See Discoverable Windows Operating Systems for details.) However, some organizations might want specific
computers in their network that are acting as servers to be classified by their function and not their operating system.
Use the following variables, preceded by cidata., to construct a reclassification condition. For example, to reclassify
based on a machine's IP address, use cidata.ip_address.
name
dsn_domain
os_domain
ip_address
serial_number
The following procedure reclassifies any Windows workstation operating system (Windows Vista, XP, or Windows
7) that is acting as a server.
1. Navigate to Discovery Definition > CI Classification > Windows.
2. Create a new classification record, such as Windows XP Server.
3. Select Windows Server [cmdb_ci_win_server] as the table.
4. Right-click in the header bar and select Save from the context menu.
The Classification Criteria and Triggers Probes Related Lists appear.
5. Configure the following Classification Criteria:
Name: Select a variable to use as the classification criteria from the list above. For example, to reclassify a
machine by name, enter cidata.name. This works for servers that have a uniform naming convention, such as
SRV001, SRV002, etc., regardless of operating system.
Operator: Select an operator for the classification condition. In networks containing servers named with a
specific convention, you might select starts with or contains.
Value: Enter the value for the condition. In our example of a network with a server naming convention, this
value would be the root of that convention, such as SRV.
This condition will classify all computers as servers if their machine name is SRVXXX.
6. Select the Triggers Probe Related List and add the appropriate probes.
a. Copy the list of probes from another Windows server classification, including the Condition scripts.
b. Ensure that the Windows - Identity probe has a phase of Identification (the default is Exploration).
The completed form looks like this:
70
71
Debugging Classifications
To log debugging information about classifications, add the following system property. The resulting log entries list
the name of each classifier that runs, along with all the names and values that are available to the criteria in the
classifier.
System Property
Description
glide.discovery.debug.classification Enables debugging information for process classification.
Type: true | false

Default Value: false
Location: Add to the System Properties [sys_properties] table
Enhancements
Dublin
Offers discovery support for new Windows Operating Systems.
Process Classifications
72
Overview
Process classification in Discovery tracks services, such as database servers, running on computer CIs in your
instance. Discovery classifies processes during the exploration phase, after identifying devices in the Computer
[cmdb_ci_computer] table and its extensions. Like device classification, process classification has its own
classification criteria and also has the ability to launch probes. Unlike device classification, process classification
creates child configuration items (CI) with Runs on::Runs relationships. By default, Discovery includes
classifications for most common processes.
For information on how Discovery creates and maintains dependent relationships between CIs, including processes,
see Application Dependency Mapping.
When Process Classification Runs

Process classification is unique to computer CIs from the Computer [cmdb_ci_computer] table and its extensions.
When Discovery identifies a computer CI, it triggers an active processes probe to explore the computer CI further.
Discovery compares the results of the active processes probe to the process classification conditions to determine if
there is a match.
Workflow for computer CIs
Process Classification Workflow

Discovery compares the data from the active processes probe to the
classification criteria. If a process matches the classification criteria,
Discovery determines whether to run the process handler script. The
process handler script modifies the parameter data to help Discovery
identify whether the process represents an existing or new application
CI. Every time Discovery adds or updates an application CI, it also
determines the application dependency mapping of the application CI
to other CIs in the CMDB.
Process Classification workflow
If a process does not match any existing classification criteria, Discovery checks if the process is communicating
with other processes (Dublin). If the process communicates with other processes, Discovery automatically generates
both a new process classification and application CI from the process name and the list of the other processes it
communicates with. After Discovery is complete, review these automatically generated records to determine whether
you want to define a new application class for this process.
This feature has been significantly revised for the Dublin release. If you are using an older release, see previous
version information.
Workflow Prior to the Dublin Release

View process classification workflow on versions prior to the Dublin release
Pre-Dublin Process Classification workflow

Prior to Dublin, Discovery would not check whether a process communicated with other processes. If a process failed to match to an existing
classification criteria, Discovery ignored classifying the process. Discovery administrators had to define all classification criteria prior to Discovery
in order to create an application CI from process data.
Creating a Process Classification

A process classification allows Discovery to create a particular CI type from information gathered during the
identification and exploration phases. When a process matches the classification criteria, Discovery uses the process
classification record to create a CI. You can also have Discovery update existing CIs or ignore certain processes by
creating a process handler. This feature has been significantly revised for the Dublin release. If you are using an
older release, see previous version information.
1.
2.
3.
4.
5.
6.
Navigate to Discovery Definition > CI Classification > Process.

Click New.
Enter the classification fields (see table).
Right-click the header bar and click Save.
Enter items from related lists.
Click Update.
ServiceNow provides the following fields for classifications.
73
74
Field
Input Value
Table
Select the table where this classification generates CI records. This table must be an extension of the Computer
[cmdb_ci_computer] table such as Applications [cmdb_ci_appl].
Relation type
Select the CI relationship type for this classification. The relationship field is only available for Process and Scan Application
classifications. Discovery process classifications typically use one of these relationship types:
Runs on::Runs: Defines the relationship of an application to the host on which it runs. This relationship is expressed from the
perspective of the host and the application. For example: My database application runs on server001::server001 runs my
database application.
Depends on::Used by: Defines the relationship of an application that communicates with another application. This relationship
is expressed from the perspective of each application. For example: The Tomcat application depends on the MySQL database::
The MySQL database is used by Tomcat.
Virtualized by::Virtualizes: Defines the relationship of a virtual machine to its host. This relationship is expressed from the
perspective of the virtual machine and of the host. For example: server001 is virtualized by ServerESX::Server ESX virtualizes
server001.
Active
Select this option to enable the process classification record. Only active process classifications can create application CI records.
Order
Enter the order in which Discovery should run this process classification when there are multiple classifications available for a
table. Discovery runs process classifications from the lowest to highest order.
Test with
Lists the host CI where an automatically generated process classification conditions were met. Use this field to test changes to the
process classification to ensure that the updated classification behaves as expected (Dublin release).
Condition
Use the condition builder to create the match and classification criteria for the process classification. This field replaces both the
Match criteria field and Classification Criteria related list. The upgrade process converts all existing classification criteria into
conditions (Dublin release).
On
classification
script
Enter a script to run when the condition and classification criteria are met. Use this script to perform any special tasks after a device
is classified. It is possible to use the g_probe_parameters hashmap from within a classification script to set probe
parameters for any configured, triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all
triggered probes.
g_probe_parameters['node_port'] = 16001;
See Available Script Objects for additional script options.
Triggers
probes
Select the exploration probes you want Discovery to launch. These probes gather detailed information about a classified CI.
Discovery will not launch these probes if it is configured to stop after classification. See Probes for more information.
Applications
Use this related list to view the application CIs that match this process classification (Dublin release).
Test Results
Use this related list to view the how Discovery classifies processes on the Test with host and build better classification conditions
(Dublin release).
Parameters
Use this related list to view the parameters associated with this process and build better classification conditions (Dublin release).
Versions
Use this related list to view previous versions of the process classification record (Dublin release).
Available Script Objects

An On classification script can call the following script objects to
further customize an application record.
current: points to a JavaScript object with its [property:value] pair
to update the application record. (It is not an actual GlideRecord
object of the application.)
Process Classification record
g_sensor: points to the running process sensor class. This object

contains a deviceGR object, which points to the computer CI
record on which the process resides.
g_classification: points to the process classifier record itself.

name: points to the process name.
command: points to the process command.
parameters: points to the process parameters.
g_probe_parameters: a JavaScript object that will allow parameter passing to the triggered probes.
Changing the Default Application Name

By default, ServiceNow names applications in this format:
<name of the process classifer>@<the name of the computer CI where the process resides>;
For example, for a MySQL server running on a computer called machineA, ServiceNow names the application,
mysql@machineA.
You can use the On classification script field to change the default application name to match your business needs.
For example, the following script changes the default application name to include a suffix after the process classifier:
var computerName = g_sensor.deviceGR.name;
var processClassiferName = g_classification.name;
current.name = processClassiferName + "999" + "@" + computerName;
In this example, the name of the application record becomes mysql999@machineA.
Another common technique is to set the application name based on the name, command, and parameter variables.
For example, an Eclipse process might have the following values in these variables:
name => "eclipse"
command => "/glide/eclipse/Eclipse.app/Contents/MacOS/eclipse"
parameter => "-psn_0_1884620"
If an Eclipse application runs on a computer called machineA, ServiceNow names the application,
eclipse@machineA. The following script appends the parameter value as part of the application name.
var computerName = g_sensor.deviceGR.name;
var processClassiferName = g_classification.name;
current.name = processClassiferName + parameters + "@" + computerName;
In this example, the name of the application record becomes eclipse-psn_0_1884620@machineA.
Passing Values to Probes

Sometimes it is useful to pass values to the triggered probes in the process classification. You can do this by creating
a custom script that defines a name/value pair for the g_probe_parameters object. For example:
g_probe_parameters['processCommand'] = command;
In this example, when a classification record triggers a probe, the script passes the probe a parameter called
processCommand with the value of the command variable.
75
76
Classification Prior to the Dublin Release

This feature has been significantly revised for the Dublin release. If you are using an older release, see previous
version information.
View process classification on versions prior to the Dublin release
Process classification in previous releases required:
Defining the match criteria.
Defining the classification criteria.
(Optional) Defining the on classification script.
To create a process classification:
1.
2.
3.
4.
5.
Navigate to Discovery Definition > CI Classification > Process.

Enter the classification fields (see table).
Right-click the header bar and click Save.
Enter items from related lists.
Click Update.
Process Classification Fields

ServiceNow provides the following fields for classifications on releases prior to Dublin.
Field
Input Value
Table
Select the table where this classification generates CI records. This table must be an extension of the Computer
[cmdb_ci_computer] table such as Applications [cmdb_ci_appl].
Relation type
Select the CI relationship type for this classification. The relationship field is only available for Process and Scan Application
classifications. Discovery process classifications typically use one of these relationship types:
Runs on::Runs: Defines the relationship of an application to the host on which it runs. This relationship is expressed from the
perspective of the host and the application. For example: My database application runs on server001::server001 runs my
database application.
Depends on::Used by: Defines the relationship of an application that communicates with another application. This
relationship is expressed from the perspective of each application. For example: The Tomcat application depends on the
MySQL database:: The MySQL database is used by Tomcat.
Virtualized by::Virtualizes: Defines the relationship of a virtual machine to its host. This relationship is expressed from the
perspective of the virtual machine and of the host. For example: server001 is virtualized by ServerESX::Server ESX virtualizes
server001.
Match criteria
Select how many criteria must match to classify this device: Any of the parameters or All of the parameters.
On
classification
script
Enter a script to run when the classification criteria are met. Use this script to perform any special tasks after a device is classified.
It is possible to use the g_probe_parameters hashmap from within a classification script to set probe parameters for any
configured, triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all triggered probes.
g_probe_parameters['node_port'] = 16001;
Triggers
probes
Select the exploration probes you want Discovery to launch. These probes gather detailed information about a classified CI.
Discovery will not launch these probes if it is configured to stop after classification. See Probes for more information.
Classification
Criteria
Select the parameters and values that cause Discovery to match devices with CIs in the CMDB. See Classification Criteria for
information on building classification criteria.
77
Classification Criteria
Process Classification record prior to Dublin

release
All classification criteria include a parameter, an operator, and a value.

The available parameters depend on what the Discovery classify
probes return for each class of device found. Set the classification
criteria to define what Discovery looks for when establishing a
process's class. For example, this classification criteria illustrates
classifying a command containing sqlservr.exe as a Microsoft SQL
Server CI.
Example Discovery Classification Criteria
Note: See Discovery Classification Parameters for a list of available parameters for each default classification.
Automatically Generated Process Classifications

Discovery automatically creates a classification record for processes that connect to or listen on a TCP port. Each
automatically generated classification follows these conventions:
Name: indicates:
whether the process was automatically discovered with the Pending: prefix.
whether the process is listening on or connecting to a TCP port.
the TCP port the process listens on or connects to.
Table: is Pending Application.
Relationship Type: is either Runs on::Runs or Depends on::Used by.
Condition: indicates the name, command, and key parameters of the process.
Test With: lists the host where the process was found.
Requirements
Discovery must have access to the following applications to
automatically generate classifications for processes.
Automatic Process Classification record
78
OS
Application Required
Windows WMI
Linux
lsof
Mac
Solaris
AIX
Reviewing Automatic Process Classifications

Discovery administrators can review the automatic process classification to determine if it is a process they want
include as an application CI.
1. Navigate to Discovery Definition > CI Classification > Pending Process.
2. Select the automatically generated process classification you want to view. For example, the process listening on
port 32300.
3. Select the Applications tab to see what other applications and devices the process communicates with.
4. The Running process field may provide enough information to classify it. For example, in this case the process
name java makes a good application match, but the Windows version of the process wrapper.exe may or
may not be a Java application.
5. If necessary, select the Parameters tab to get additional
information about the process.
6. Determine if you want to:
Applications of automatic process classifications
Convert the automatic classification into a standard process

classification.
Ignore future instances of this process.
Converting an Automatic Process Classification to a Standard Process

Classification
Discovery administrators may want to convert an automatically generated process classification into a standard
process classification so that future discovery runs will automatically recognize the process as an application CI.
1. From the process classification form, select the Table where you want to store this application CI.
1. If the application table does not already exist, you can create it by clicking the Create, use application
instance table related link.
2. In the confirmation dialog, enter the table suffix name to append to the application table.
3. Enter the table label you want to use. The new table will have the name <My Label>
[cmdb_ci_appl_<my_table_name>].
79
2. If necessary, add additional conditions and classification criteria.
See Creating a Process Classification for additional options.
For example, we want to restrict our classification to process
where the running process is java.
Create application table
Ignoring an Automatic Process Classification in

Future Discoveries
If the automatic process classification does not represent an application
CI that you want future discoveries to recognize, you can set the
process to ignored.
Adding conditions and criteria to the process

classification
1. From the process classification form, click the Create "No

classify" process handler.
2. From the confirmation dialog, click Yes.
3. The process handler has the same conditions as the automatically

generated process classification.
Process Handlers
Discovery process handlers prevent the creation of duplicate CIs by
filtering out parameters known to have inconsistent values before
process classification occurs. For example, the Process Handler [discovery_proc_handler] table includes a
Websphere record. This record filters out a specific parameter that changes each time a WebSphere server restarts.
Process handlers are available starting with the Calgary release.
Process Handler to ignore process classification
To create a new the process handler:

1. Navigate to Discovery Definition > CI Classification > Process
Handlers.
2. Click New.
Sample process handler for WebSphere
3. Complete the fields on the Process Handler form (see table).

4. Click Submit.
80
Field
Description
Name
Enter a unique name for the process handler record.
Active
Select the check box to run the process handler.
Classify
Select the check box to enable classification of any Running Process [cmdb_running_process] record that matches this Process
Handler's conditions. Clear the checkbox to disable classification of any Running Process [cmdb_running_process] record that matches
this Process Handler's conditions (Dublin release).
Condition Select the conditions that trigger the process handler to run the script. In most cases, this condition contains either specific executable
names or the presence of certain parameters.
Script
Enter the JavaScript you want to run on the current record in the Running Process [cmdb_running_process] table when the Condition is
met. The current variable is a reference to a Running Process GlideRecord. The script should examine current.parameters
for certain values, perform string replacement to manipulate these values, and save the result to current.key_parameters.
ServiceNow uses the key_parameters field, together with the process name, to determine whether the process is unique on a specific
machine. See Available Script Objects for additional options.
Debugging Classifications
To log debugging information about classifications, add the following system property. The resulting log entries list
the name of each classifier that runs, along with all the names and values that are available to the criteria in the
classifier.
System Property
Description
glide.discovery.debug.classification Enables debugging information for process classification.
Type: true | false

Default Value: false
Enhancements
Dublin
Discovery automatically creates new process classifications for unclassified processes that listen on or connect to
a TCP port. Discovery admins can review these unrecognized processes to determine whether to create CIs from
them.
Process classification uses a condition builder instead of match criteria and classification criteria.
The process classification form has new related lists to view information about associated running processes and
application CIs.
Process Handlers have a new field to enable or disable classification of running processes that match the process
handler's conditions.
Calgary
Process Handlers allow Discovery to review parameter values to determine if a process represents a new or
existing application CI.
Discovery Classification Parameters

Overview
Each type of Discovery classify probe (Windows, UNIX, SNMP, etc.) returns a unique set of parameters that
contains classification information. Any of the supported parameters can be used as configurable criteria for
classifying devices that Discovery finds. The tables in this page define the available parameters for each
classification.
Discovery also provides a way to classify devices it finds when no credentials are available. Discovery for IP
addresses makes certain assumptions about devices and the applications running on those devices from the ports that
it finds open. Classification parameters for this type of Discovery are generated differently from scans in which
credentials are available. See Forming Parameters for IP Address Scanning for details.
Creating Classification Criteria

To add criteria to a Classification record, navigate to Discovery Definition > Classification > <type> and click
New in the Classification Criteria related list. Type in the appropriate parameter, select an operator, and enter a
value to use for this classification. This form provides the usual operators, including these that may not be familiar:
regex matches: Use this operator to create a regular expression [1] to conduct a complicated search on a string.
in IPs: Find a single IP address in an IP address range, network or list. Possible formats are: 10.10.10.0 10.10.10.255; 10.10.10.0/24; or 10.10.10.0, 10.10.10.1, 10.10.10.2.
The Discovery classify probe returns values for these parameters from the devices it finds and compares them with
the values configured for this classification. The classify sensor then decides if the classification criteria for a device
have been met. If the criteria match, the sensor looks at the classification record to determine what probes must be
launched.
The following record is for a Windows Server 2003 in the Windows classification. To add an additional
classification criteria (parameter) to the list, click New and define the new parameter in the Classification Criterial
form (inset). Click Submit to add the parameter to the list.
81
82
UNIX Parameters
The UNIX parameters define the characteristics of several types of computers, such as Linux, Solaris, and HP-UX,
communicating with SSH protocol, version 2.
output
The raw output of the classifier probe (uname -a).
type
Returns the classification UNIX.
IP address
name
Name of the operating system for this UNIX CI. For example, Linux or HP-UX.
Windows Parameters
Windows parameters identify Windows computers communicating with the WMI protocol.
83
isNode
Indicates if this instance is a node.
type
Returns the classification windows.
isVIP
Indicates if this CI is a virtual machine, with a virtual IP address.
ip_address
name
Name of the Windows version, such as Windows 2003 Standard.
SNMP Parameters
The SNMP parameters can define the characteristics of several types of devices, such as routers, switches, and
printers.
Parameter
Description
powering
A value of true indicates that this device is an uninterruptible power supply (UPS).
hosting
A value of true indicates that this device can host programs. Hosts are general purpose computers such as servers.
netware
A value of true indicates that this device is running the Netware operating system.
routing
A value of true indicates that this device has network routing capabilities.
ip_address
Returns the IP address through which the device is being discovered. A device can have multiple IP addresses.
sysdescr
Required descriptive field on any SNMP device that can contain useful classification data, such as the operating system
and its version.
vlans
A value of true indicates that this device can host a virtual local area network.
hint_router
A value of true indicates that Discovery has determined that this device is a router. This field only applies to devices
that can be used as both a router and a switch.
block_router_exploration If this parameter is true, Discovery will not launch exploration probes for routers it detects. This parameter is used for
network Discovery only.
switching
A value of true indicates that this device has network switching capabilities.
mfr_apc
A value of true indicates that this device is an uninterruptible power supply (UPS) manufactured by American Power
Conversion (APC).
printing
A value of true indicates that this device has printing capabilities.
block_switch_exploration If this parameter is true, Discovery will not launch exploration probes for switches it detects. This parameter is used for
network Discovery only.
Process Parameters
Process parameters identify processes such as those used by LDAP, Apache Server, and JBoss Server.
parameter
The parameters used to run the process.
command
The command used to run the process.
output
The complete output of the current line of the process probe.
type
Indicates the process type (e.g. unix or windows).
PID
The process ID generated by the operating system of a device to identify a running process. Generally, this parameter is not a practical
classification criteria, because the value does not remain static, except in the case of processes running on an appliance that is never
restarted.
name
Name of the process being discovered. In some cases, this parameter is not reliable, since several process might be given the same
name. In Windows, for example several processes return scvhost.exe for this parameter.
Classification for IP Address Scanning

Classification is available for the IP Addresses Discovery type and returns information about CIs (Scan CI) and
applications running on CIs (Scan Application). No credentials are required to scan for Windows or UNIX devices
with this type of scan, but community string credentials are required for SNMP devices. By determining which ports
are open on the devices that it scans, IP address classification can discover such things as the type of device
(computer, UPS, etc.), operating system, running applications, and version numbers.
Note: IP address classification attempts to classify devices when no credentials are available; however, Discovery will use
credentials when they are available, even when IP address classification is configured.
To use IP address classification, follow these steps:

1. Determine what ports to use for classification. Run a scan program such as Nmap on specific IP addresses to
decide which ports reveal the desired information about a device or application.
The scan can reveal several pieces of data that are useful for configuring classification parameters. An Nmap
scan displays port numbers, their state (open or closed), their service names, and any version information it
can find. From the port information returned in the example below, we can construct criteria to classify UNIX
servers (port 22), MySQL (port 3306), and Apache Tomcat (port 16000).
84
2. Add an IP Service and port probe.

The out-of-box ServiceNow system supplies probes for some of the most common ports, but additional port
probes will be needed for effective IP address scanning.
a. Navigate to Discovery Definition > IP Services and click New.
b. Create a new IP Service record using the port number and service from the Nmap scan. In this example, we
associate the mysql service with port 3306 and add the CI (sanops02) on which the service runs to the
Available on Related List.
c. To use Basic Discovery, navigate to Discovery Definition > Functionality Definition and select the record
for All.
d. Add the new port probes to the list. This tells Discovery which port probes to run for IP address scans.
85
e. Save the record and navigate to Discovery Definition > Port Probes and click New.
f. Create a port probe using the new IP Service you just defined.
3. Create a new classification and add the parameter for IP address scanning.
In this example, we have created an application classifier that will discover Apache Tomcat, based on the port
information we received from the Nmap scan. See the following section for details about forming parameters
for IP address scans.
Forming Parameters for IP Address Scanning

The syntax for creating parameters is derived from the fields returned by the Shazzam probe when conducting a
Discovery for IP addresses. Parameters for CIs and applications are formed in the same way. The Shazzam probe
creates an XML file containing the following fields:
name
port
portprobe
protocol
result
service
86
Note: Optional fields that can be used to form parameters appear as child tags beneath the default fields. Example of these are the
sysDescr and banner_text fields.
Parameters are expressed in the form of <portprobe.service.field>. The value for field can come from any of the
fields or child tags in the XML file. For example, the following parameters classify a device as a UNIX server and
detect an installation of MySQL:
ssh.ssh.result
mysql.mysql.result
These parameters were derived from the values in the following XML file generated by a Shazzam probe conducting
an IP Scan. The result field returned a value of open for ports 22 and 3306 on the target device. The service field
indicates the services that normally communicate over those ports.
The sysDescr field can provide additional information about devices, depending upon the manufacturer. This XML
file from the Shazzam probe reveals the following about port 161 on the device at IP 10.10.11.149:
In the classification criteria, we can construct the following parameter with sysDescr that returns an Apple AirPort
wireless router.
snmp.snmp.sysDescr > contains > Apple AirPort
87
References
[1] http:/ / www. zytrax. com/ tech/ web/ regex. htm
88
89
Setting Up and Running Discovery

Discovery Identifiers
Overview
When Discovery finds a device in your network, it makes an effort to determine if the device already exists in the
CMDB. When Discovery is configured to use Identifiers, it launches special identity probes that accumulate
identification data for each device and feed that data into the Identifiers, which determine the action that Discovery
must take for each device. Identifiers accurately determine the identity of the device and prevent the creation of
duplicate CIs.
Enabling Identifiers
Identifiers are used for all Discovery Schedules that are set up to discover Configuration items. Discoveries of this
type compare devices found in the network with CIs in the CMDB and update the CMDB, when appropriate. The
Configuration item scan is the only type of Discovery that touches the CMDB.
1. Select Configuration items as the type of Discovery to run in the Discovery Schedule.
This setting tells Discovery to launch the appropriate identity probes after classification has determined the
class and operating system of the device.
2. Configure the Identity probes and probe sequence

3. Configure Identifiers and result states.
4. Run Discovery.
90
Creating Custom Identifiers and Identity Probes

Note: This functionality requires a knowledge of Javascript.
The default ServiceNow Identity probes and Identifiers are configured to work together to identify discovered
devices in most networks. You are encouraged to use these records whenever possible. If you need different data to
identify devices, create your own probe/sensor pairs and matching Identifiers to suit your particular situation. DO
NOT modify, disable, or delete existing ServiceNow records. If you do so, they cannot be upgraded or recovered.
The best practice is to use the existing records as templates for your own elements, and then replace the ServiceNow
probes, sensors, and Identifiers with your custom elements in all modules where they are used (Classification
records, probe and sensor records, and Identifiers).
How Identifiers Work

When Discovery has determined the device's class, it launches an identity probe - a multiprobe - that is configured to
run one or more commands with a single authentication. The identity probe in the out-of-box system can be
configured to ask the device for information such as its serial numbers (there can be more than one), 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.
This diagram shows the processing flow for classifying and probing devices with Identifiers configured.
91
Configuring Identity Probes

Identity probes are multiprobes. Multiprobes contain one or more simple probes configured to extract specific
information from manageable devices. Identity probes return such information as device serial numbers (there can be
several per device), the computer name, and network identification (MAC address). For example, the Linux - Identity
multiprobe provided in the system, contains two simple SSH probes configured to return hardware and network
information about the device. After the probe has discovered this information, it passes the data to a multisensor
configured to process identity information.
To configure identity probes:
1.
2.
3.
4.
Navigate to Discovery Definition > Probes.

Select Multiprobe in the Probe Type field.
In the Includes Probes Related List, click Edit to select simple probes to include in this multiprobe.
Click New to create a new simple probe.
Note: A multiprobe cannot contain another multiprobe.
Identity Probes Included with ServiceNow

The following identity multiprobes are included with the out-of-box ServiceNow system. The corresponding
multisensors have the same names.
92
Multiprobe
Includes these probes
AIX - Identify
AIX - Network: Determines network interfaces, IPs, and MACs

AIX - Serial Number: Retrieves the AIX serial number
CIM - SMI-S - Identity CIM - SMI-S - Computer System: Retrieves a CIM Computer System using SMI-S.
HP-UX - Identify
HP-UX - Hardware Serial Number: Retrieves HP-UX serial number

HP-UX - Network: Retrieves HP-UX networking information
Linux - Identify
Linux - Hardware Information: Gets DMI (BIOS) information

Linux - Network: Gets network information
Mac OS X - Identify
Mac OS X - Network: Gathers network information from Macintosh machines

Mac OS X - CPU/Memory: Gathers CPU/memory information from Macintosh machines
SNMP - Identify
SNMP - Identity Info: Identifies a printer CI.
Solaris - Identify
Solaris - Network: Gets network information about Solaris devices
Windows - Identify
Windows - Network: Probes a Windows machine for network information

Windows - OS/Hardware Information: Probes a Windows machine for WMI information
Configuring Identity Sensors

You must have a properly configured multisensor for each identity probe in your system. These multisensors pass
the data returned by the identity probes to the Discovery Identifiers. The Identifiers then search the CMDB for
matching CIs. When the identity of a device is resolved, the Identifiers pass the result state for the device to the
multisensors, which react accordingly, either by launching exploration probes or stopping Discovery for that device.
See Processing Flow for Discovery Identifiers for details on the interaction between multisensors and the Identifier.
To configure a multisensor, navigate to Discovery Definition > Sensors and select an existing identity multisensor
from the list. To avoid confusion, the multisensors provided in ServiceNow have the same names as their matching
multiprobes. The Responds to Probes Related List shows the simple probes which pass their data to this
multisensor. These are the same simple probes that appear in the Includes Probes list in the matching multiprobe
record. Click on the Script link for each probe in the list to see the script that the multisensor runs to process the data
from the probe.
Device Classification
When a classification probe runs, it returns the device class and operating system (if the device is a computer).
Computer
Printer
Netgear
UPS
When you enable Identifiers, Discovery Classification determines what identity probe to launch. For example, if the
device class returned is Computer, and the operating system is Linux, then the classification record launches the
pre-configured Linux - Identity multiprobe. The out-of-box ServiceNow system has identity probes configured for
each classification, in addition to exploration probes, that can be launched after the results are evaluated.
To view all probes triggered by a classification, navigate to Discovery Definition > Classification. Computers are
listed by operating system. Non-computer classes use SNMP probes. The identity probe is listed in the Triggers
Probes Related List and is launched only when Identifiers are enabled. You can use the probes provided or click
Edit to select different probes. Click New to create a custom probe.
93
Configuring Identifiers
When enabled, Identifiers collect information gathered by identity probes and use that data to search for matching
CIs in the CMDB. Using the scripting power of the Identifier, you can control the order in which the identification
criteria is parsed for comparison with the CMDB, and you can configure how Discovery should handle each matched
or unmatched device. You create identifiers for each identity probe command that you run in your network. For
example, if you query devices for network names, device serial numbers, and MAC addresses, then you must create
matching identifiers that define how each piece of data should be evaluated.
Processing Flow for Discovery Identifiers

Identity probes and sensors are used to determine if the devices you discover in your network already exist in your
CMDB. Multisensors used for this purpose must be configured to pass identification data to Identifiers. The
Identifiers then determine how to proceed for each device discovered, based on the result states.
The Identifiers pass the result state for a discovered device back to the identity sensors, which respond appropriately,
either by launching additional exploratory probes to continue discovering the device or by taking no further action on
the device.
94
Identifier Form
To create an Identifier record, navigate to Discovery Definition > CI Identification > Identifiers and click New. The
Identifier form provides the following unique fields:
Field
Input Value
Applies
to
Select the ServiceNow table of the device class for this Identifier. For example, if the class is Printer, then the table is cmdb_ci_printer.
Order
Configure the order in which the identification criteria are evaluated. An example might be serial number - 910, network name - 920, and
computer name - 930.
Script
Create the conditions that determine what Discovery should do when the results are returned from a search of the CMDB for this
Identifier. For example, you might want to stop Discovery if two or more CIs in the CMDB match this Identifier. Or you might want to
evaluate additional Identifiers even after a match has been established with this Identifier. Use the scripting methods described below to
tell Discovery how to respond.
The completed Discovery Identifier form looks like this:
95
96
Result States
The following table shows how the possible Discovery Identifier result states are used to decide the outcome of an
identity probe:
Continue Discovery
Create CI
Exactly one device

matched in CMDB
Yes
No
Device not matched

in CMDB
Yes - if the device has matchable information available, such Yes - if the device has matchable information available, such
as IP address, MAC address, or class, and if there are no
as IP address, MAC address, or class, and if there are no
multiple matches.
multiple matches.
Multiple devices
matched in CMDB
No
No
97
Evaluation Order For Custom Identifiers

If you create new Identifiers, make sure you assign them a different Order value than that of the out-of-box
Identifiers. Discovery runs the Identifiers in sequence from low order numbers to high. You can create identifiers to
run before or after the out-of-box Identifiers, or mixed in with the out-of-box Identifiers. To prevent any Identifier
from running, disable it by changing the Active flag to false.
Base System Identifiers

The following Identifiers are included in the ServiceNow base system.
Identifier
Description
Details
Serial Number
Table & Class
Name
Identify CIs in the CMDB

based on serial number(s)
in the serial number table
and sys_class_name.
This identifier matches the discovered serial number against the serial_number in the Serial
Number [cmdb_serial_number] table. If the discovered serial number matches a CI in the
cmdb_serial_number table and the class name, the CI is declared identified. Note that in the base
system, Discovery populates the cmdb_serial_number table. Therefore, this identifier is important
for Discovery to use to find the CIs it has discovered in the past (assuming these were valid serial
numbers). For more information, see Serial Number Types.
Serial Number
& Class Name

based on the
serial_number field and
matching sys_class_name.
This identifier matches the discovered serial numbers against the serial number field in the base CI
record. If a discovered serial number and class type (sys_class_name) matches a CI, that CI is
declared identified. The matching class name requirement means that Discovery will not identify
CIs that are not in the same class. For example, a computer and a printer have the same serial
number, but since their class names differ, Discovery does not identify them as the same CI.
Typically, imported data has the serial number field completed, but no matching value in the
cmdb_serial_number table. This identifier solves the issue of Discovery finding imported data in the
CMDB.
Name & Class

Name

based on name field and
matching sys_class_name.
This identifier matches the discovered name against the name field in the base CI record. If a
discovered name and class type (sys_class_name) matches a CI, then that CI is declared identified.
The matching class name requirement means that Discovery will not identify CIs that are not in the
same class. For example, a computer and a printer have the same name, but since their class name
differs, Discovery will not identify them as the same CI.
Network

based on IPs and MAC
Address(es) in the network
adapter table.
This identifier matches the discovered network adapters against those in the Network Adapter
[cmdb_ci_network_adapter] table, using the IP address and MAC address. If all the discovered
network adapters match a CI in the network adapter table, then the CI is declared identified.
98
Network &
Class Name

based on the mac_address
field and the ip_address
field and matching
sys_class_name.
This identifier matches the discovered IP address and MAC address of the base CI against those in
the base CI record. If a discovered IP address, MAC address and class type (sys_class_name)
matches a CI, then that CI is declared identified. The matching class name requirement means that
Discovery will not identify CIs that are not in the same class.
MAC Address
& Class Name

field and matching
sys_class_name.
This identifier matches the discovered MAC address of the base CI against those in the base CI
record. If a discovered MAC address and class type (sys_class_name) matches a CI, then that CI is
CIs that are not in the same class.
IP Address &
Class Name

based on the ip_address
field and the matching
sys_class_name.
This identifier matches the discovered IP address of the base CI against those in the base CI record.
If a discovered IP address and class type (sys_class_name) matches a CI, then that CI is declared
identified. The matching class name requirement means that Discovery will not identify CIs that are
not in the same class.
MACAddress

based on MAC Address(es)
in the network adapter
table.
record. If a discovered MAC address and class type (sys_class_name) matches a CI, then that CI is
CIs that are not in the same class.
Generic Serial
Number

based on serial_number
field.
This identifier matches the discovered serial number against the serial number field in the base CI
record. If a discovered serial number matches a CI, then that CI is declared identified. Note here that
the matching class name is NOT a requirement, which means that Discovery will identify CIs even
if they are not in the same class. For example, a computer and a printer have the same serial
number, but even though their class name differs, Discovery will still identify them as the same CI.
Generic
Network

field and the ip_address
field.
This identifier matches the discovered IP address and MAC address of the base CI against those in
the base CI record. If a discovered IP address and MAC address matches a CI, then that CI is
declared identified. The matching class name is NOT a requirement, which means that Discovery
will identify CIs that are not in the same class.
Generic Name

based on name field.
This identifier matches the discovered name against the name field in the base CI record. If a
discovered name matches a CI, then that CI is declared identified. The matching class name is NOT
a requirement, which means that Discovery will identify CIs that are not in the same class.
Generic MAC
Address

based on MAC address
field.
record. If a discovered MAC address matches a CI, then that CI is declared identified. The matching
class name is NOT a requirement, which means that Discovery will identify CIs that are not in the
same class.
Generic IP
Address

based on IP address field.
This identifier matches the discovered IP address of the base CI against those in the base CI record.
If a discovered IP address matches a CI, then that CI is declared identified. The matching class
name is NOT a requirement, which means that Discovery will identify CIs that are not in the same
class.
Serial Number Types

Serial number types in the Serial Number [cmdb_serial_number] table vary depending on the CI, as described in the
following examples.
Linux
In the result of dmidecode | cat, the value on the left side is what Discovery looks for. The value on the right side is
how it is stored in the Serial Number [cmbd_serial_number] table.
Serial Number : system_serial_number
UUID : uuid_serial
Serial Number : baseboard_serial
Serial Number : chassis_serial
Windows
For Win32 WMI classes, the value on the left is the name by which it is stored in the Serial Number
[cmdb_serial_number] table. The value on the right is the WMI value.
('system' : Win32_ComputerSystemProduct.IdentifyingNumber);
('uuid' : Win32_ComputerSystemProduct.UUID);
('chassis' : Win32_SystemEnclosure.SerialNumber);
('bios' : Win32_BIOS.SerialNumber);
('baseboard' : Win32_BaseBoard.SerialNumber);
SNMP
For SNMP, the mapping below is based on the code. Physical types of serial numbers are from all instances of
iso.org.dod.internet.mgmt.mib-2.entityMIB.
'cisco_stack' :
'iso.org.dod.internet.private.enterprises.cisco.workgroup.ciscoStackMIB.chassisGrp.chassisSerialNumberString'
'cisco_chassis' :
'iso.org.dod.internet.private.enterprises.cisco.temporary.chassis.chassisId'
'foundry' :
'iso.org.dod.internet.private.enterprises.foundry.products.switch.snChassis.snChasGen.snChasSerNum'
'apc_pdu' :
'iso.org.dod.internet.private.enterprises.apc.products.hardware.masterswitch.sPDUIdent.sPDUIdentSerialNumber'
'printer' :
'iso.org.dod.internet.mgmt.mib-2.printmib.prtGeneral.prtGeneralEntry'
'standard' :
'iso.org.dod.internet.private.enterprises.apc.products.hardware.ups.upsIdent.upsAdvIdent.upsAdvIdentSerialNumber'
99
Credentials
100
Credentials
Overview
Credentials, such as user names and passwords, or certificates, are required to gain access to a computer or network
device for ServiceNow Discovery or to perform work on a computer using Orchestration. The platform stores these
credentials in an encrypted field on the Credentials table, and once they are entered, they cannot be viewed.
Credential tagging allows workflow creators to assign individual credentials to any activity in an Orchestration
workflow or assign different credentials to each occurrence of the same activity type in an Orchestration workflow.
Credential tagging also works with credential affinities.
Credential Affinity
It is not necessary to associate credentials with a device within Discovery. When Discovery or Orchestration first
attempts to access a device, they try all available credentials until they find the correct ones. After identifying the
credentials for a device, Discovery and Orchestration create an affinity between the credentials and the device using
the Credential Affinity [dscy_credentials_affinity] table. All subsequent discoveries or Orchestration activities
attempt to match the credentials in this table with a device for which an affinity exists. If credentials for a device
change, Discovery and Orchestration try all available credentials again until they create a new affinity.
Note: If Orchestration and Discovery are installed, and credential tagging is enabled, multiple affinities can exist. In this case, the
platform looks up credentials for each affinity and inserts the credential for the affinity with the lowest order into the probe.
Encryption/Decryption
Credentials are encrypted automatically with a fixed instance key when they are submitted or updated in the
Credentials [discovery_credentials] table. When credentials are requested by the MID Server, the platform decrypts
the credentials using the following process:
1.
2.
3.
4.
5.
The credentials are decrypted on the instance with the fixed key.
The credentials are re-encrypted on the instance with the fixed Web Service key.
The credentials are encrypted on the instance with SSL.
The credentials are decrypted on the MID Server with SSL.
The credentials are decrypted on the MID Server with the fixed Web Service key.
Credentials
101
Note: The platform does not have separate encryption keys for multi-tenant instances.
Discovery and Orchestration Credentials

The MID Server must have the proper credentials for the devices it expects to find. Windows MID Servers use the
login credentials of the MID Server service on the host machine to discover Windows devices in the network. This
login is configured when the MID Server is installed and must have domain or local administrator privileges. For
Linux and UNIX machines and network devices, the MID Server uses the SSH and SNMP credentials configured in
the ServiceNow instance in Discovery > Credentials.
MID Servers used by Orchestration must have access to the necessary credentials to execute commands on
computers in the network as specified by the Workflow activities. Orchestration can use the same SSH and SNMP
credentials as Discovery, but has two additional credentials designed for specific Workflow activities: Windows (for
PowerShell) and VMware.
UNIX and Linux Credentials

Discovery and Orchestration explore UNIX and Linux devices by using commands executed over Secure Shell (SSH
[1]
), so they need SSH credentials. The user can be any user. Both applications must run commands on UNIX and
Linux systems with root privileges. There are two general approaches to accomplishing this:
Give root credentials. These are obviously the most powerful credentials, but may not be desirable from a
security perspective. If Discovery or Orchestration have the root credentials to any UNIX or Linux system, no
further configuration is required.
Give other credentials for Discovery or Orchestration, but grant the user in those credentials the right to execute
certain commands with root privileges, using sudo [1]. This is a secure way to grant limited privileges. Discovery
or Orchestration use sudo on any probe that has the must_sudo parameter set to true (it defaults to false).
However, each system must be configured to allow sudo to work. This is done by editing the /etc/sudoers file
using the visudo command.
Access Requirements for Non-Root Credentials

If you do not provide Discovery with root access credentials, you must provide credentials with the following access
requirements.
Application
File or Directory
Access Required
Apache
httpd.conf
Read
JBoss
jboss-service.xml
Read
JBoss home directory
Read
web.xml
Read
MySQL
my.cnf
Read
Oracle
oratab
Read
Associated (s)pfiles
Read
Oracle Listener lsnrctl

listener.ora
Execute
Read
Credentials
102
Tomcat
Unix
catalina.jar
Read
server.xml
Read
web.xml
Read
/etc/*release
Read
/etc/bashrc
Read
/etc/profile
Read
/proc/cpuinfo
Read
/proc/vmware/sched/ncpus Read
WebSphere
/var/log/dmesg
Read
APD directory
Read
cell.xml
Read
server.xml
Read
serverindex.xml
Read
Configuring Sudo Commands to Grant Root Privileges

Each command for which Discovery or Orchestration requires root privileges is described below, along with how to
configure the /etc/sudoers file to allow them. These examples assume that the user name in the credentials is Disco.
Substitute the actual user name and ensure that the paths for the commands match the path on the systems.
Note: Sudo commands do not work with private key credentials, because there is no password to supply to the sudo command. A
solution is to add the NOPASSWD option to the sudo configuration. For example, you might enter: disco ALL=(root)
NOPASSWD:/usr/sbin/dmidecode,/usr/sbin/lsof,/sbin/ifconfig.
UNIX/Linux Commands Requiring root Privileges for Discovery and Orchestration

Command
Platform(s)
Purpose
/etc/sudoers line example
dmidecode
All Linux
Gathers several pieces of information

about the hardware, including the serial
number embedded within the
motherboard.
Disco ALL=(root) /sbin/dmidecode
lsof
All Linux and

Mac versions
Determines the relationship between

Disco ALL=(root) /sbin/lsof
processes and the connections being made
to the system.
Used By
Discovery
Discovery
vmware-cmd ESX
Gathers vmware instances information.
Disco ALL=(root) /usr/bin/vmware-cmd Discovery
adb
HP-UX
Gathers CPU speed and memory.
Disco ALL=(root) /usr/bin/adb
Discovery
chpasswd
All Linux and

UNIX versions
Changes user passwords.
Disco ALL=(root) /etc/chpasswd
Orchestration
chage
All Linux and

UNIX versions
Changes the number of days between

password changes and the date of the last
password change.
Disco ALL=(root) /etc/chage
Orchestration
oratab
All Unix
versions
Grants read access to the oratab file for

locating the Oracle Home and pfile.
N/A
Discovery
Credentials
/usr/ucb/ps
103
Solaris
Lists running process. As an alternative to

running with root access, add a
proc_owner role.
Disco ALL=(root) /usr/ucb/ps
Discovery
Windows Credentials
Discovery uses Windows credentials to explore Windows computers by:
Running remote WMI queries from WMI probes.
Running Powershell scripts from Powershell probes.
Accessing Windows administrative shares [2].
Orchestration uses Windows credentials to run workflow activities on Windows computers, which are typically
Powershell commands.
Requirements
Discovery and Orchestration have the following requirements for Windows credentials.
Install a MID Server on a Windows host as a service.
Add Windows credentials to one of these locations:
Credentials [discovery_credentials] table
MID Server service account
To have the MID Server use credentials from the Credentials table:
1. Add individual Windows credentials to the Credentials [discovery_credentials] table. See Credentials Form.
Verify each credential meets the permission requirements.
Verify each username meets the name format requirements.
Verify each credential meets the Windows domain requirements.
2. Configure the MID Server to use Powershell by setting the mid.use_powershell parameter to true. See
MID Server Configuration.
3. [Optional] By default, Discovery automatically uses the MID Server service account credentials if all credentials
in the Credentials table fail. If you do not want to use the MID Server service credentials as a fall back, set the
mid.powershell.local_mid_service_credential_fallback parameter to false. See MID Server
Configuration.
To have the MID Server use credentials from the MID Server service account:
1. Set the MID Server service account to a user who meets the permission requirements.
2. Verify the username meets the name format requirements.
3. Verify the credentials meet domain requirements.
Credentials
104
Permission Requirements
In order to provide sufficient permissions, Windows credentials must be one of the following:
A domain administrator
A domain user with local administrator access on the target Windows hosts
A user who meets the requirements of Discovery Windows Probes and Permissions (Discovery only)
A user who meets the requirements of the Orchestration activity to be run (Orchestration only)
Supported User Name Formats

Discovery and Orchestration support Windows domain credentials in both User Principal Name and Down-Level
Logon Name user name formats [3]. For example, Domain\UserName or UserName@example.domain.com. You
can provide Windows workgroup credentials in the following format: WORKGROUP\UserName.
Windows Domain Requirements

Additional actions are required to enable Windows credentials to function across multiple Windows domains.
Condition
Additional actions required
MID Server host on the same Windows domain as the Windows host
None
MID Server host on a different Windows domain than the Windows host
Install Powershell on each target Windows host

Enable the MID Server parameter to use Powershell
MID Server host on a different Windows domain than the Microsoft SQL Server host See Microsoft SQL Servers
SNMP Credentials
Discovery explores many kinds of devices (switches, routers, printers, etc.) using the SNMP protocol. Credentials
for SNMP do not include a user name, just a password (the community string). The default read-only community
string for many SNMP devices is public, and Discovery will try that automatically. Enter the appropriate SNMP
credentials if they differ from the public community string.
The default Orchestration activity SNMP Query returns the OID of a device and requires SNMP credentials.
VMware Credentials
Discovery can explore VMware's vCenter running on a Windows machine. When Discovery detects the vCenter
process, Discovery automatically launches the VMware - vCenter probe. This probe logs into the vCenter instance
with the credentials provided and uses the vCenter API to return information about ESX machines, virtual machines,
and resource pools. Ensure that the credential Type selected is VMware.
Orchestration requires vCenter credentials for any work that it performs on vCenter, such as cloning a virtual
machine.
Note: Do not use VMware type credentials for Orchestration activities that perform work on the individual virtual machines cloned
by vCenter (for example, restarting a Linux VM). For these activities, the credential Type depends on the operating system of the
virtual machine (either SSH or Windows).
Credentials
105
CIM Credentials
Discovery can explore storage systems based on the Common Information Model (CIM) and can query a CIM server
(also referred to as a CIMOM - Common Information Model Object Manager) for information about VMware ESX
servers and the virtual machine hosts they serve. See CIM Discovery for information about the probes involved.
NetApp Storage Devices

NetApp storage devices require additional configuration in order for Discovery to explore them.
1. Install the SMI-S agent [4] on the storage device host. See the Data ONTAP SMI-S Agent 4.1 Installation &
Configuration guide [5] for instructions and requirements. Note: Both the SMI-S agent and its associated
documentation require a valid NetApp login.
2. Create a user account and password for the SMI-S agent.
3. Create a credential record for the SMI-S agent credentials. Set the credential type to CIM.
Note: The SMI-S agent currently supports all versions of ONTAP up to 8.x for any storage device running in 7-ONTAP.
Clustered-ONTAP is not currently supported. NetApp plans to add support for Clustered-ONTAP in a future release.
Credential Order
When Orchestration attempts to run a command on an SSH server (such as a Linux or UNIX machine), or when
Discovery attempts to query an SNMP device (such as a printer, router, or UPS), the application tries the credentials
in the Credentials table randomly, until it finds one that works. Credentials can be assigned an order value in the
Credentials Form, which forces Discovery and Orchestration to try all the credentials at their disposal in a certain
sequence. Ordering credentials is useful in the following situations:
The credentials table contains many credentials, with some used more frequently than others. For example, if the
table contains 150 SSH credentials, and 5 of those are used to log into 90% of the devices, it is good practice to
configure those five with low order numbers, which places them at the top of the execution list. Discovery and
Orchestration will work faster if they try these common credentials first. After the first successful connection, the
system knows which credentials to use the next time for each device.
The system has aggressive login security. For example, if the Solaris database servers in the network only allow
three failed login attempts before they lock out the MID Server, configure the database credentials with a low
order value.
Creating Custom Credential Types

ServiceNow supports several credential types by default, such as SSH or SNMP. To use credentials of a different
type, create a custom credential type. Custom credential types are available starting with the Dublin release.
1.
2.
3.
4.
5.
6.
Navigate to Orchestration > Credentials.

Click New.
Right-click the Type field.
Select Show Choice List.
Click New.
Create a new Choice record with these values:
Table: discovery_credentials
Element: type
Credentials
106
Value: the parameter used by the script include getCredentials method

7. Click Submit.
A custom credential type requires a MID Server script include (MID Server > Script Include) to process the new
credential type. This script include must extend the AProbe class and specify a run function that:
Creates an iterator of all credentials that specify a particular Value
Evaluates each credential as appropriate. This code varies depending on the login requirements your credential
must satisfy.
For example, this script include creates the iterator credentials containing all credentials with a Value of
customtype. This example does not show the JavaScript code to evaluate each credential.
var CustomCredTypeTestProb = Class.create();
CustomCredTypeTestProb.prototype = Object.extendsObject(AProbe, {
initialize : function(probe) {
this.probe = probe;
},
run : function() {
// Use the Value specified by the credential type choice for the string
parameter of the getCredentials method.
var credentials = this.getCredentials("customtype");
while (credentials.hasNext()) {
var credential = credentials.next(); // Iterate
through each credential.
try {
ms.log('Attempting to log in with user: ' +
credential.getUsername());
// Try each credential.
// This code varies based on your login requirements.
// If successful, add the credential to the credential

affinity table.
// Credentials added to this table are preferentially
used for later login attempts.
credentials.worked(this.getParameter("probe"));
} catch (ex) {
throw ex;
}
}
},
Credentials
107
type: "CustomCredTypeTestProb",
});
Other Considerations
Sometimes computers or devices have additional security measures configured, and these measures may interfere
with the MID Server's ability to run commands or queries on those systems. For example, a Linux server might be
configured to allow only certain IP address to connect to it via SSH. Similarly, a network router might be configured
to allow only certain IP address to query SNMP on it. To allow access in such cases, use one of the following
methods:
Update the configuration of those computers or devices to allow the desired MID Server to run commands or
query them. For example, a network router may be configured to only allow the network management systems to
query SNMP on it. In that case, add the MID Server as though it were another network management system.
Install a MID Server on a computer that already has access to the computers or network devices with such
restrictions. For example, to use Discovery within a DMZ (where communication from outside the DMZ will be
severely restricted), install a MID Server on a computer that is already in the DMZ.
Credentials Form
The Discovery Credentials form provides the following fields:
Field
Input Value
Name
Unique and descriptive name for this credential. For example, you might call it SSH Atlanta.
Type
Select between SSH, SNMP, and VMware credentials.
SSH: Credentials for all Linux and UNIX devices.

SSH Private Key: Certificate-based identification for Linux and UNIX devices.
SNMP: This credential is a community string. If you select this, ServiceNow automatically uses public first and then a community
string.
Windows: Credentials required for Windows machines accessed by Orchestration activities. These credentials are used for running
PowerShell commands on Windows machines.
VMware: Credentials required by probes that access or run commands on vCenter. For more information, see Discovery for
VMware vCenter and VMware Workflow Activities.
CIM: The credentials used to access CIM servers.
MSSQL: [Obsolete] Credentials used for discovering Microsoft SQL instances when using SQL authentication with PowerShell.
Enable SQL authentication by setting the mid.powershell.use_mssqlauth parameter to true in the MID Server config.xml file. In
versions at Calgary or later this credential type and the mid.powershell.use_mssqlauth parameter are obsolete and were removed
from the platform. MSSQL discoveries with PowerShell in Calgary use the credentials of the MID Server. All MSSQL credentials
are removed from the instance when the Calgary upgrade is applied.
User name Enter a user name for this type of credential. If a domain account is used to execute Powershell commands in Discovery, the user name
must include the domain. Avoid leading or trailing spaces in user names. These spaces can prevent the VMware - vCenter probe from
connecting to vCenter. A warning appears if the platform detects leading or trailing spaces in the user name.
Password
Enter the password to use. For SNMP type credentials, enter the community string here. For SSH Private Key type credentials, enter
the sudo password if one is required for the user name (starting with the Dublin release).
Order
The order (sequence) in which the platform tries this credential as it attempts to log onto devices. The smaller the number, the higher in
the list this credential appears. Establish credential order when using large numbers of credentials or when security locks out users
after three failed login attempts. If all the credentials have the same order number (or none), Discovery or Orchestration tries the
credentials in a random order.
SSH
Type a secure SSH passphrase. This field is available only for SSH Private Key credentials.
passphrase
Credentials
SSH
Private
Key
108
Enter a secure, private key that can be used instead of a password for SSH logins. This field is available only for SSH Private Key
credentials. The private key must be entered in the proper format to ensure it is correctly encrypted. The private key must start with the
string -----BEGIN.
Here is an example of a correctly formatted private key
-----BEGIN RSA PRIVATE KEY----MIIEogIBAAKCAQEAsEK65scPssPSobpDFMpR+Btv3MS4Q7NP8ERaStRZsh3IWz+x...
...7hrxV2dbSug60FahyupGWBGtPnXm5PaE2X5WPLuUj94ue48i1Fs=
-----END RSA PRIVATE KEY----The ServiceNow platform supports private keys in the PEM format generated by the OpenSSH ssh-keygen utility. To convert PPK
keys that were generated by PuTTY:
Open your private key in PuTTYGen.

Export it in OpenSSH format from the menu Conversions > Export OpenSSH key.
Save the new OpenSSH key.
MID
servers
Select one or more MID Servers from the list of available MID Servers. The credentials configured in this record are available to the
MID Servers in this list. This field is available only when you select Specific MID servers from the Applies to field.
Applies to
Select whether to apply these credentials to All MID servers in your network, or to one or more Specific MID servers. Specify the
MID Servers that should use these credentials in the MID servers field.
Active
Enable or disable these credentials for use.
A completed credentials form for an SSH credential could look like this, but local configurations can vary:
Enhancements
Dublin
SSH Private Key credentials can also include a password if one is required for sudo commands. See Credentials
Form.
You can create custom credential types using JavaScript.
Calgary
Obsolete configuration parameter: The MID Server configuration parameter
mid.powershell.use_mssqlauth is obsolete and was removed from the platform. Microsoft SQL Server
discoveries use the PowerShell probe, which uses the MID Server's credentials. The PowerShell MSSQL probe
was also removed.
Obsolete credential type: The MSSQL credential type was removed from the Credentials
User Name validation: A warning appears if the platform detects leading or trailing spaces in the User Name
field. These spaces prevent the VMware - vCenter probe from connecting to vCenter.
Credentials
References
[1]
[2]
[3]
[4]
[5]
http:/ / www. sudo. ws/ sudo/ sudo. html

http:/ / en. wikipedia. org/ wiki/ Administrative_share
http:/ / msdn. microsoft. com/ en-us/ library/ windows/ desktop/ aa380525(v=vs. 85). aspx
http:/ / support. netapp. com/ NOW/ download/ software/ smis/ Windows/ 4. 1/ download. shtml
https:/ / library. netapp. com/ ecm/ ecm_get_file/ ECMP1140913
Discovery Schedules
Overview
A discovery schedule is the starting point for all discovery activities. The schedule determines what is going to be
discovered, the day and time when it will be discovered, and the MID Servers that will perform the discovery.
Use the Discovery Schedule module to:
Configure device identification by IP address or other identifiers.
Determine if credentials will be used in device probes.
Name the MID Server to use for a particular type of discovery.

Create or disable a schedule that controls when the discovery runs in your network.
Configure the use of multiple Shazzam probes for load balancing (available starting with the Eureka release).
Configure the use of multiple MID Servers for load balancing.
Run a discovery manually.
Prerequisites
Before you begin with Discovery, configure the following:
MID Servers: Install and configure one or more MID Servers.
Credentials: Provide the MID Servers with the login credentials they need to query the devices in the network.
Schedules: Create a schedule record that defines what actions Discovery must take to scan the devices and
software in the network.
Classifications: Make sure the device and process classifications provided in the base platform are sufficient.
Create new classifications as needed for the devices, processes, and applications in the network.
Discovery Schedule Form

To create a Discovery schedule:
1.
2.
3.
4.
Navigate to Discovery > Discovery Schedules.

Click New.
Complete the Discovery Schedule form (See table).
Click Submit.
109
Discovery Schedules
110
Discovery schedule starting with the Calgary release
Field
Description
Name
Enter a unique, descriptive name for your schedule.
Discover
Select one of the following scan types:
Behavior
Configuration items: Configuration item scans use discovery identifiers to match devices with CIs in the CMDB and update the
CMDB appropriately. You can perform a simple discovery by selecting a specific MID Server to scan for all protocols (SSH,
WMI, and SNMP), or perform more advanced discoveries with discovery behaviors. When you select a behavior, the MID
Server field is not available.
IP addresses: IP address scans discover 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. Devices are identified by class and in some cases 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 Configuring the Shazzam Probe.
Networks: Network scans discover 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.
Select a behavior configured for the MID Servers in your network. When you select a behavior, the MID Server field is no longer
visible. Use a behavior when a single schedule requires the use of multiple MID Servers to perform any of the following:
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.
This field is available only if Discover is set to Configuration items.

MID Server Select the MID Server to use for this schedule. This field is available if Discover is set to Configuration items or Networks. If you
select a MID Server, you cannot select a behavior for the schedule.
Location
Choose a location to assign to the CIs that are discovered by this schedule. If this field is blank, then no location is assigned.
Max Run
Time
Set a time limit for running this schedule. When the configured time elapses, the remaining tasks for the discovery are cancelled, even
if the scan is not complete. Use this field to limit system load to a desirable time window. If no value is entered in this field, this
schedule runs until complete.
Active
Select the check box to enable this schedule. If you clear the check box, the schedule is disabled, but you can still run a discovery
manually from this form, using the configured values.
Run
Select whether the discovery runs on a periodic schedule. If you select Once or Periodic, the form displays the Starting field for
selecting the date and time to run the discovery (Calgary release). If you select Once in versions prior to Calgary, Discovery runs one
time after an update to the record.
Day
Select the day of the week or month when Discovery runs in a weekly or monthly schedule. This field is available only if Run is set
to Weekly or Monthly.
Time
Select the time of day this schedule should run. All times are local and use a 24-hour clock.
Repeat
Interval
Select the number of days between scheduled discovery runs. This field is available only if Run is set to Periodically.
Discovery Schedules
Starting
Select a date and time to run the discovery once or periodically. This field is available only if Run is set to Once or Periodically.
This field is visible by default starting with the Calgary release.
Include
alive
Select this check box to include alive devices, which are devices that have at least one port that responds to the scan, but no open
ports. Discovery knows that there is a device there, but has no information about it. If this check box is cleared, Discovery returns all
active devices, which are devices that have at least one open port.
Log state
changes
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 the Discovery Devices related list on the Discovery Status form. The Completed
activity and Current activity fields display the states.
Shazzam
batch size
Enter the number of IP addresses that each Shazzam probe will 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, if this value is set to 1000 and a discovery must scan 10,000 IP addresses using a single MID
Server, it creates 10 Shazzam probes with each probe scanning 1000 IP addresses. By default, the batch size is 5000. 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 maximum range size property for the Shazzam probe.
This field is available starting with the Eureka release.
Shazzam
cluster
support
Select the check box to distribute Shazzam processing among multiple MID Servers in a cluster to improve performance. For
example, if 10 probes are running and there are 10 MID Servers in the cluster, each probe runs on a different MID Server.
Quick
ranges
Define IP addresses and address ranges to scan by entering IP addresses in multiple formats (network, range, or list) in a single,
comma-delimited string. For more information, see Quick Ranges.
Discovery
IP Ranges
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 discover.
Discovery
Range Sets
This related list defines each range set in a schedule to be scanned by one or more Shazzam probes.
Discovery
Status
This related list displays the results of current and past Discovery schedule runs.
This field is available starting with the Eureka release.
Configuring IP Addresses
Use one or more of these methods in any combination to define the network or network segment for Discovery to
query:
IP address list
IP address range
IP network
Quick Ranges
Discover Now
Note: If you do not know the IP addresses in the network, run network discovery first to determine the IP networks. Then, convert the
IP networks into IP address range sets.
111
Discovery Schedules
IP Address List
Use IP address lists to add individual addresses for Discovery to query. These addresses should not be included in
any existing IP range or IP network. You can enter the IP address of the device or a host name (DNS name). If you
enter a host name, it must be resolvable from the ServiceNow instance.
IP Address Range
You can define arbitrary ranges of IP addresses for Discovery to query. This is a good way to include selected
segments of a network or subnet, but Discovery has no way of knowing if the IP range includes addresses for private
networks [1] or broadcast addresses [2], and so must ping all the addresses in the range. If the network and broadcast
addresses are included, then the results are inaccurate. For this reason, discoveries configured to detect IP networks
are generally more accurate than those configured for IP address ranges. ServiceNow recommends that any IP
address range only includes IP addresses reserved for manageable devices on the public network.
IP Network
An IP network includes the range of available IP addresses in that network, including the network address (the
lowest address in the range) and the broadcast address (the highest address in the range). An example of a class C
network range is 192.168.0.0 to 192.168.0.255. In the Range Set form, this network can be entered with either of the
following notations:
192.168.0.0/24
192.168.0.1/255.255.255.0
This notation indicates that Discovery is scanning an IP network, and Discovery does not scan the highest and lowest
numbers in the range. This prevents significant errors from being introduced into the Discovery data by the broadcast
address, which returns all the devices in the network, and the network address, which can add an arbitrary number of
redundant devices. This built-in control makes IP networks the best method of defining which IP address ranges to
query.
Quick Ranges
Quick ranges allow administrators to define IP addresses to scan in a single comma-delimited string without creating
separate records. You can enter IP addresses in one of the following formats:
An IP range defined by a slash and the number of bits in the subnetwork [2]. For example, the string
10.10.10.0/24 scans 24 bits of IP addresses from 10.10.10.0 to 10.10.10.254.
An IP range defined by a dash. For example, the string 10.10.11.0-10.10.11.165 scans the IP addresses
from 10.10.11.0 to 10.10.11.165.
A comma-separated list of specific IP addresses. For example the string 10.10.11.200,10.10.11.235
scans the IP addresses 10.10.11.200 and 10.10.11.235.
To create quick ranges:
1. Click the Quick Ranges related link on the Discovery Schedule form.
2. Enter the IP networks, IP ranges, and specific IP addresses to scan.
3. Click Make Ranges.
Note: The Quick Range interface is for entering IP addresses only and cannot be used to edit IP addresses that have already been
submitted.
112
Discovery Schedules
The instance automatically displays the entries in the proper format. To make any changes to IP address ranges,
select the IP address records.
Discover Now
Discover Now allows you to manually run a Discovery schedule. Manually running a schedule record does not affect
the schedule. It continues to run as configured, despite manual execution.
1. Navigate to Discovery > Discovery Schedules.
2. Select the schedule you want to manually run.
3. From Related links, click Discover now.
Excluding IP Addresses
Administrators can exclude specific IP addresses in a range or network from a Discovery Schedule. 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.
To exclude an IP address:
1. 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.
113
Discovery Schedules
The Discovery IP Range form appears.
2. In the Discovery Range Item Excludes related list, click New.

3. In the Discovery Range Item Exclude form, select a Type for the excluded IPs. For example, select IP Address
List to exclude a single IP address or multiple IP addresses that are not sequential.
4. Right-click the header bar and select Save from the context menu.
The Discovery Range Item IPs related list appears.
114
Discovery Schedules
5. Click New in this list.

An entry form for the IP addresses to exclude appears.
6. Enter a single IP address to exclude or multiple addresses separated by commas, and then click Submit.
The excluded IP address appears in the Discovery Range Item IPs related list for that IP address Type.
7. Click Update to save the excluded address and return to the Discovery Schedule.
115
Discovery Schedules
Enhancements
Eureka
Supports clustering of Shazzam probes across multiple MID Servers for improved performance.
Calgary
A new field Starting allows administrators to specify the start date for periodic and one-time discoveries. See
Discovery Schedule Form for more information.
References
[1] http:/ / en. wikipedia. org/ wiki/ Private_network
[2] http:/ / en. wikipedia. org/ wiki/ Broadcast_address
Network Discovery
Note: If you already know the IP address ranges in your network, it is not necessary to run Network Discovery. This procedure is
intended for organizations that do not have complete knowledge of the IP addresses available for Discovery in their networks.
Overview
Network Discovery discovers the internal IP networks within your organization. Discovery uses the information it
gathers to update routers and Layer 3 switches in the CMDB. Network Discovery is performed by a single MID
Server that begins its scan on a configurable list of starting (or seed) routers. Typically, the starting routers are the
default routers used by all the MID Server host machines in the network, but can be any designated routers. The
MID Server uses the router tables on the starting routers to discover other routers in the network. The MID Server
then spreads out through the network, using router tables it finds to discover other routers, and so on, until all the
routers and switches have been explored.
After running Network Discovery, convert the IP networks it finds into IP address Range Sets that you use in
Discovery Schedules to discover configuration items (CI).
Running Network Discovery

Configure Network Discovery in a Discovery Schedule.
1. Navigate to Discovery > Discovery Schedules.
2. Click New and select Networks from the list in the Discover field.
3. Select a MID Server.
This field is mandatory.
4. Complete the form, including the schedule.
5. Right-click in the header bar and select Save from the pop-up menu.
The Related Links and Related Lists appear.
6. Click Network Discovery Private IPs in Related Links to view the list of default private IP networks in the
Discovery IP Ranges Related List.
116
Network Discovery
The default IP networks in this list are available to every Network Discovery you conduct and are sufficient
for most discoveries.
7. If your organization has additional private IP addresses, click New to add them.
8. Add starting routers to the schedule in the Discovery Range Sets list.
a. Click the Network Discovery Auto Starting Routers link to populate the list with the starting router for
each MID Server in your network.
b. Click Edit to add or delete routers from the list.
9. Run Discovery manually, or through the scheduler.
Converting IP Networks into Discovery Range Sets

After you conduct the Network Discovery, you must convert the IP networks that were found to range sets for use in
discovering other devices.
1. Navigate to Discovery > IP Networks.
2. Click New to add an IP network.
The IP Networks form appears.
3. Ensure that the following field values are provided:
State: Ready
Discover: true
Router: Select a router from the list. This field must not be empty.
117
Network Discovery
118
If your IP Networks were created through Network Discovery, then these fields will be populated
automatically in the IP Networks Related List. However, if you entered the IP Networks manually, and you
want to convert your IP Networks into range sets through the UI Action, you must edit these field accordingly.
4. Click Update to return to the list.

5. Click the Create Range Sets Related Link.
This converts all the IP networks in the list to range sets.
The Discovery Status page appears, displaying the progress of the conversion. Depending upon the number of
IP networks you have, you will see the Started and Completed count increment until all the networks are
converted.
Network Discovery Properties

The following properties control how Network Discovery works. The default values are correct for most discoveries.
Navigate to Discovery Definitions > Properties to edit the properties.
Property
Description
Default
BGP Router
Exploration
Disable
Controls whether Network Discovery exploration of routers running the BGP protocol is
Yes
disabled. Normally such exploration IS disabled because of the huge size of BGP routing
tables, and because generally such routers are only operating at the edge of large networks
where further network discovery would be irrelevant. The only time this value should be set
to "no" is in the unlikely case that your organization uses BGP routers as edge routers
between relatively small networks (such as between buildings on a single campus).
Network Discovery
119
Maximum
Netmask Size
for
Discoverable
Networks (bits)
The maximum number of bits in a regular netmask for networks that will be discovered by
Network Discovery. By "regular netmask" we mean a netmask that can be expressed in
binary as a string of ones followed by a string of zeroes (255.255.255.0 is regular,
255.255.255.64 is irregular). Regular networks are commonly expressed like this:
10.0.0.0/24, which means a network address of 10.0.0.0 with a netmask of 255.255.255.0.
Larger bit numbers mean networks with smaller numbers of addresses in them. For
example, the network 10.128.0.128/30 has four addresses in it: one network address
(10.128.0.128), one broadcast address (10.128.0.131), and two usable addresses
(10.128.0.129 and 10.128.0.130). Small networks like this are commonly configured in
network gear to provide loopback addresses or networks used strictly by point-to-point
connections. Since these sorts of networks generally don't need to be discovered by
Network Discovery, it would be useful to filter them out. By setting this property to a value
of 1 through 32, you can limit the sizes of regular networks that are discovered. Setting it to
any other value will cause all networks to be discovered. Irregular networks are always
discovered. The default value is 28, which means that regular networks with 8 or fewer
addresses will not be discovered.
28
Network
Router
Selection
Method
This property controls the method used to decide (during Network Discovery) which router
should be selected as the router to be associated with a given IP Network. The possible
values are: "First Router" (the first router that discovers the network is associated), "Last
Router" (the last router that discovers the network is associated), "Most Networks" (the
router with the most attached networks is associated), and "Least Networks" (the router
with the least attached networks is associated).
Most Networks
Physical
A comma-separated list of interface types that will be considered "physical" for the
6,117,9,71,209
Interface Types purposes of network discovery. In other words, if a router (or device capable of routing) has
an interface of this type, the networks connected to that interface will be considered locally
connected to that device. The default interface types include Ethernet, 802.11, and Token
Ring types. Interface type numbers are defined in the SNMP MIB-2, specifically in OID
1.3.6.1.2.1.2.2.1.3.
Switch
List of interface types (comma-separated) that will be considered Interface type numbers
Interface Types are defined in the SNMP MIB-2, specifically in OID 1.3.6.1.2.1.2.2.1.3. Devices with any
interface types that do not appear in this list will be classified as routers (if they have
routing capability). A complete list of the interface type numbers may be found on the
IANA web site, in the section "ifType definitions".
7,8,9,26,53,62,69,71,78,115,117,209
Stale Network
Discovery
Threshold
(Days)
The number of days before which discovered information about network gear is considered -1
"stale". While performing network discovery, if a router (or other device capable of routing)
has not been discovered, or if the discovered information is stale, then network discovery
will launch probes to freshen the information. Otherwise, it will reuse the information that
has already been discovered. If this number is negative, then any previously discovered
information is always considered stale, and network discovery will always launch probes to
freshen the information.
Network
Discovery
Debugging
Enables extensive logging (for debugging purposes) of all Network Discovery activities on
the instance. Normally this is only set to "yes" by developers.
Yes
Discovery Status
120
Discovery Status
Overview
The Discovery Status interface (Discovery > Status) displays all the details of a Discovery. Each record in the Status
list represents the execution of a Discovery by a schedule and displays such high level information as the date of the
Discovery, the mode, the number of probe messages sent to devices, and the number of sensor records that were
processed. From this record, you can drill down into the following data:
Probe and sensor records, including the instructions given to the probes and the information returned
The relationships between the probes and sensors
All log entries for the Discovery
Specific information about devices discovered
Use this data to troubleshoot the behavior of individual probes and sensors or even run those elements separately.
Use the status controls to enter probe/sensor threads at any point for a specific Discovery, and then follow the
process in either direction.
Discovery Status Record

By default, only 30 days of Discovery records are displayed in the status list at a time. The status record provides the
following fields:
Field
Input Value
Number
Discovery record ID generated by your ServiceNow instance.
Description
How this Discovery was run. Typically, the description is Scheduled, but if you ran Discovery manually from a Schedule, the
record would show Discover Now in the Description field. If the scan was performed by the Help the Help Desk application, this
description is Help the help desk.
Schedule
The name of the Discovery schedule.
State
Indicates the state of this Discovery (Active, Completed, etc.)
Started
The number of probe messages sent to devices from the MID Server.
Completed
The number of sensor records that were processed. This number must match the number of probes launched.
From Schedule
Discover
Shows the Discovery type. The possible types are: Configuration items, IP addresses, or Networks.
Max Run
Time
Displays the maximum amount of time Discovery was permitted to run on this schedule.
Include alive
Indicates that this Discovery includes devices on which one port responded to the scan, but no ports are open. Such a device is
considered to be alive. If this check box is not selected, only active devices with one or more open ports that Discovery can query
are displayed.
Log state
changes
Indicates that state changes were logged during this Discovery. Discovery states can be seen in the Last and Current fields in the
Discovery Devices list in this form.
A Discovery Status record looks like this:
Discovery Status
Discovery Timelines
A Discovery Timeline generates a graphical display of the Discovery Status records for a Discovery, including
information about each probe and sensor running.
Use Discovery Timelines to display the following:
The flow of probes and sensors through a Discovery
The duration of each probe and sensor that ran during a Discovery and the proportion of time required for queuing
and processing
Tooltips containing additional data about a probe or sensor
Records from the ECC Queue
121
Discovery Status
122
Discovery Log
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. To view the log records
for a particular device, click the IP adddress link in the Device column. This action opens the Discovery Devices
record.
Log Information
The Discovery Log provides the following information:
Field
Input Value
Created
Timestamp of the Discovery activity. Each timestamp defines the approximate time of the activity. Several Discovery events may occur
in random order within a second.
Level
Classifies the activity into one of the following levels for general sorting:
Error
Information
Warning
Message
Informative message detailing the outcome of the activity or the Discovery progress. Look here for the result of a classify probe or for
authentication failure.
Source
Names the particular activity, such as the Shazzam probe or a UNIX classify probe.
CMDB
CI
Names a device for which a matching CI was found in the CMDB. Click this link to drill down into the CI record for the device.
Sensor
Names the sensor that processed the results of a specific probe that was run. This field also indicates if the probe was a MultiProbe.
Click this link to view the sensor record, including the package that was processed.
Device
Lists the IP address of the CI discovered. All devices identified by IP address appear in the log, even if they refused all invitations to
communicate. Any port activity from a device places it into the log, even if all subsequent efforts to identify it fail. Click the IP address
of the device to view the events associated with discovering that device.
Discovery Status
Filtering the Log

Sort the log by different values to create your view of Discovery activities. Use the breadcrumbs above the header
bar to return to a previous view. To filter the list quickly by a specific target value, right-click in any column and
select Show Matching or Filter Out. For example, show only the Warning level activities, and then select the
specific type of failure to display from the Message field, such as SSH Authentication or connection failure.
Devices
Select the Devices Related List to view a summary for all the devices scanned. During a Discovery, the list tracks
current and completed activity and displays an incremental scan counter. When Discovery is finished for a device,
the final disposition is displayed in the Completed activity column. Successful Discoveries that result in updated or
created CIs are highlighted in green. To view the log entries for errors (such as connection failure) on a specific
device, click the Details link in the Issues column.
Click on the IP address of a device in this list for details about that device. The log results for that device are
displayed in the list at the bottom of the form.
123
Discovery Status
124
If there were issues, or if Discovery failed to complete, click the Details link to view the log records for the issue.
The failure of any probe is considered an issue, even if the device was eventually classified properly and updated in
the CMDB.
The following information is displayed in this form:

Field
Input Value
Source
The IP address of the device discovered.
Completed
activity
Indicates the outcome of Discovery for this device or the last completed activity for a Discovery in progress, such as Identified
CI. Successful outcomes are indicated in green.
Current activity
The current scanning activity for this device for a Discovery in progress, such as Updating CI.
CMDB CI
The name of this device as it appears in the CMDB.
Started
The number of device-specific probes run. This number does not include the universal probes, Shazzam and Ping, that run
initially.
Completed
The number of sensor records created from the device-specific probes that were run.
Scan status
Shows the final scan count of a completed Discovery or an incremental scan counter for a Discovery in progress (e.g. Scan 17 of
19).
Issues
Displays the number of issues encountered during Discovery of this device. Select the Discovery Log Related List to view these
issues.
Fields which can be added by personalizing the form:
DNS Names
Displays DNS names for each discovered device.
Discovery Status
IP Address Scan Data

When Discovery scans for IP addresses only (without credentials or identifiers), no updates are made to the CMDB.
All IP addresses discovered appear on this list, including multiple IPs on the same device. The results of IP address
scans include slightly different information than the results of a CI scan. Since there is no CMDB activity associated
with the IP address scan, the Completed activity column displays only the classification status.
Possible statuses are:
Classified
Unclassified
Alive, not classified
For Classified devices, Discovery might identify the type of device in the Current activity column. For example,
Network Gear might be classified as Cisco Network Gear, and a Computer might be classified as a Windows
Computer.
ECC Queue
The External Communication Channel (ECC) Queue lets you see all probe and sensor records for a particular device
for a particular Discovery. You can drill down in the ECC Queue from the beginning to the end of the Discovery, or
drop into the sequence of probes and sensors at any point. To open the ECC Queue, open a Discovery Status record,
and then select ECC Queue from the Related Links. You can sort the list by the timestamp or select any probe or
sensor record that interests you. You can see what activity launched the probe or answered the sensor's commands
and track the processing order for a Discovery in either direction. To determine whether a record is for a probe or a
sensor, look at the value in the Queue column. Sensor records are in the input queue, and probe records are in the
output queue.
This view of the ECC Queue is the best way to see the Shazzam and Ping probes without extensive drilling. Ping
probes can be chunked up to reduce the delay in returning results. The chunking of Ping probes is controlled by a
property in Discovery Definition > Properties called Max ping chunk size. This property is described as the
maximum number of IPs that will be pinged in one "chunk" of work. If a Discovery range has more than this number
of IPs in it, it will be automatically broken up into chunks no larger than this parameter's value.
125
Discovery Status
126
Probe and Sensor Activity

The ECC Queue provides you with a connected flow of probe and sensor activity. The position of records in the list
is dependent on your sorting criteria and might not represent the processing order of the Discovery. Activity is
recorded (Created date) when the probe is launched or the sensor records the response in the instance. On a busy
system, sensor input might be queued in the instance and delayed from being recorded. Sensors can launch multiple
probes that require different intervals to respond. A probe record displays the instructions it was given when it was
launched, and the sensor record shows the probe instructions and the results of the probe. All this information is
checked into the instance.
To track the processing sequence, use the following methods:
To track the flow of probes and sensors deeper into the Discovery (toward completion), drill down using the
Queue Related List at the bottom of the ECC Queue record. This list displays the next activity in the Discovery,
by either a probe or a sensor. If the Queue list is empty, then that branch of the Discovery is complete. Multiple
entries means that the sensor in the current record launched multiple probes.
To track backwards toward the beginning of the Discovery, drill down using the Related Field icon in the
Response to field. This action opens the ECC Queue record for the activity that spawned the current probe or
sensor record.
ECC Queue Fields

An ECC Queue record provides the following fields:
Field
Input Value
Agent
The name of the MID Server that initiated the probe.
Topic
Type of probe or sensor that was active (SSH, WMI, or SNMP).
Name
Identifying name of the probe or sensor. For SSH probes, this is the probe's message. For all others, the name is an identifying string
generated by the instance.
Source
The IP address of the Discovered device. The Shazzam and Ping probes do not have a source IP associated with them. These probes are
not directed toward a single device, but exist to scan all devices in the specified network range.
Response
to
Displays the name of the probe or sensor in the Discovery sequence whose activity triggered this probe or sensor. A single sensor can
launch several probes, but a sensor can only respond to a single probe.
Queue
Designates whether the record is for a probe or a sensor. Sensors are in the input queue, and probes are in the output queue.
State
Shows where the probe or sensor is in the process of completing its task (e.g. processed or processing)
Processed
Times that this probe or sensor's task was finished.
Created
Time that this probe or sensor was launched/activated.
Sequence
Internal ID for the execution sequence for this probe or sensor.
Payload
Contents of the probe's instructions or the response that the sensor reports to the instance. Click the XML button to display the code in
an XML view.
An ECC Queue record for Discovery looks like this:
Discovery Status
Viewing CMDB Records

As you drill down through the probes and sensors that are part of a Discovery, you can view the CMDB record for
the device (CI) that was probed, using either of the following methods:
Right-click a probe or sensor in the ECC Queue record list and select Go to CMDB item.
In a ECC Queue record, click the Go to CMDB item Related Link.
Troubleshooting
If you are suspicious of the results of a Discovery (credential failure, for example), you can run individual probes
directly. To run a probe from the ECC Queue list, right-click the probe and select Run Again from the pop-up menu.
To run a probe directly from an ECC Queue record, click the Run Again UI action in Related Links.
127
Discovery Timelines
Discovery Timelines
Overview
A Discovery Timeline generates a graphical display of the Discovery Status records for a Discovery, including
information about each probe and sensor running.
Use Discovery Timelines to display the following:
The flow of probes and sensors through a Discovery
The duration of each probe and sensor that ran during a Discovery and the proportion of time required for queuing
and processing
Tooltips containing additional data about a probe or sensor
Records from the ECC Queue
Using Timelines
View timelines for an entire Discovery or for individual devices in a Discovery. In the out-of-box system, the
maximum size Discovery that can be displayed in a timeline is 300 entries in the ECC Queue (150 probes and 150
sensors). To display larger discoveries, change the default setting in the glide.discovery.timeline.max.entries
property.
Probe and sensor timelines are available automatically when Discovery starts. Partial timelines for any device or for
the entire Discovery can be viewed during the scanning process. View the progress of the Discovery by refreshing
the browser.
1. Navigate to Discovery > Status.
2. Select a Discovery from the record list.
3. Click the Show Discovery Timeline Related Link.
128
Discovery Timelines
The timeline for the entire Discovery appears, unless the size threshold is exceeded. If the timeline is too large
to display, an error message appears.
4. Clear the warning, and then select the Devices Related List.
5. Click the IP address of a device.
6. In the Device record, click the Show Discovery Timeline Related Link.
The Discovery timeline for that device appears.
7. Use the pink slider at the bottom of the timeline to change the perspective.
a. Move the slider from right to left to view all the tasks on a long timeline.
b. Adjust the end points of the slider to change the magnification.
A narrow slider zooms in on the spans and provides a more detailed view of complex timelines. A wide
slider pulls the view out and makes more of the timeline visible on the screen.
8. Use the selector range at the top of the screen to adjust the visible time frame. To limit the timeline to the length
of the Discovery, click Max.
The time scale adjusts automatically to the length of the Discovery. The available time scale range is from one
day to 1 year.
129
Discovery Timelines
Tooltips
Discovery timelines display probe and sensor performance data and CI information in tooltips. Hover the cursor over
a span to view this data. Probes are displayed by black spans. The queue time for a probe is shown as a silver bar
within the span, and the processing time is represented by the remaining space. Sensor spans are red, and the queue
time is shown as a green bar. Selected spans of any type display in yellow.
ECC Queue
Double-click on a span to open the ECC Queue record for that probe or sensor.
130
Resource Throttling
131
Resource Throttling
Overview
Discovery sensor processing is database intensive and can create performance issues on ServiceNow instances. For
example, Discovery could increase response times for activities in the user interface. To mitigate the impact
Discovery can have on performance, ServiceNow provides a mechanism that throttles (decreases) the speed at which
Discovery processes sensors. This control is a simple meter that creates an interval between Discovery sensor
processing jobs so that no two sensors are processed simultaneously. A throttled Discovery reduces performance
issues in the user interface, but takes longer to complete.
The throttling feature requires the Discovery Throttling plugin and is available starting with the Calgary release.
Activating the Plugin

To activate the Discovery Throttling plugin, make a request to ServiceNow Technical Support using the Request
Plugin Activation module from HI [1]. You must already be a Discovery subscriber to receive this plugin.
Required Role
To implement Discovery resource throttling, a user must have the discovery_admin role.
Tables
The following tables manage throttling data.
Table
Description
Discovery Sensor Throttling Configuration

[discovery_sensor_throttling_config]
Stores the application configuration. This table only has a single row.
Discovery Sensor Throttling Timestamp

[discovery_sensor_throttling_timestamp]
Stores the latest time a throttled sensor process is scheduled to run. This table
is not meant to be edited manually.
Throttling Mechanism
When Discovery throttling is enabled, a before business rule called Discovery - Sensor Throttler runs on the
Schedule Item [sys_trigger] table and applies the throttling level interval from the configuration form to Discovery
sensor processing. The business rule sets a time for each process to run which is at least the length of the throttling
level interval after the latest Discovery sensor has run.
The
configuration
form
automatically
sets
a
system
property
called
glide.discovery.throttling.enabled to tell the business rule whether or not to apply the throttling
level interval to a specific sensor processor.
Warning: Do not manually edit this property. Use the configuration form to enable throttling. Manually changing this property
can disable throttling.
Resource Throttling
Setup
Discovery throttling can be enabled or disabled while Discovery is running, with the following effects:
If you enable throttling during a discovery, there is no effect on the currently running discovery. The throttling
occurs on the next and all subsequent discoveries.
If you disable throttling during a discovery, new sensor jobs start immediately. Sensor jobs created when
throttling was enabled are processed on their original schedule.
To enable throttling:
1. Navigate to Discovery Definition > Performance > Sensor Throttling.
The Discovery Sensor Throttling Configuration record is set to Off by default. This is the only record in the
table.
2. Edit the following fields in the form:
Throttling Mode: Enable or disable throttling.
Off: Throttling is not applied to Discovery.
On: All Discovery sensors are subject to throttling at all times.
Scheduled: Schedules the time period in which throttling is applied to Discovery. Scheduled start and end
times are intended to occur on a single day (from 00:00:00 to 23:59:59). The following scheduling fields
appear only when this mode is selected.
Scheduled Start Time: The time of day to begin throttling.
Scheduled End Time: The time of day to stop throttling.
Weekdays Only: Only throttle Discovery Monday through Friday.
Throttling Level: Select the sensor processing interval.
Low: An interval of 333 ms that processes an average of 3 sensors per minute.
Medium: An interval of 500 ms that processes an average of 2 sensors per minute.
High: An interval of 1000 ms that processes an average of 1 sensor per minute.
3. Click Update.
Scheduler Snapshot
To view a count of scheduled jobs in the Schedule Item [sys_trigger] table, click the View schedule status related
link. The snapshot contains the following information:
Scheduled Job State Distribution: lists all the scheduled jobs in the instance and the number that are for
Discovery sensors. These jobs are categorized by their state: Running, Queued, or Ready.
Discovery Ready Job Distribution: lists the number of Discovery sensor jobs that are ready to run at the current
time and in the future. Each row lists a 30-minute interval. The table shows as many rows as needed to include all
scheduled Discovery sensor jobs. However, the list stops at the first row that has no scheduled sensor jobs.
132
Resource Throttling
Throttling Message
When you manually activate Discovery on an instance with throttling enabled, a message appears above the
Discovery Status list showing the schedule name and indicating that throttling is active.
References
[1] https:/ / hi. service-now. com/ nav_to. do?uri=com. glideapp. servicecatalog_cat_item_view.
do?sysparm_id=891f088e465667e234a3cb52ffa1d299
133
External Credential Storage

Overview
A ServiceNow instance can store credentials used by Discovery and Orchestration on an external credential
repository rather than directly in a ServiceNow credentials record. The instance maintains a unique identifier for
each credential, the credential type (such as SSH, SNMP, or Windows), and any credential affinities. The MID
Server obtains the credential identifier from the instance, and then uses a customer-provided JAR file to resolve the
identifier from the repository into a usable credential.
Enhancements
Calgary
The external credential storage feature is available for use with Orchestration in the Calgary release. Discovery is not
required.
Installed Components
The following components are installed with the External Credential Storage plugin.
Business Rule
The External Credential Storage business rule performs the following tasks when an administrator makes any
change to the external credential storage property:
Changes the view for the Credentials record list and form to the External Storage view. This view enables users to
to see the Credential ID column in the list.
Instructs the MID Server to refresh its credentials cache in preparation for a change in the way credentials are
obtained.
System Property
A property called Enable External Credential Storage enables or disables the External Credential Storage plugin
after it is activated. The property is located in Discovery Definition > Properties and Orchestration > MID
Server Properties, and is enabled when you activate the plugin.
Automatic Deactivation
If you disable external credential storage with the system property, the system automatically sets all the external
credentials to inactive in the instance. If you re-enable the feature with this property, the system does not reset the
external credential records to active. You must reactivate each credential record manually.
134
Configuration Tasks
To configure your instance to obtain credentials from a remote repository, complete these tasks in order. These
procedures assume that you already have an external repository configured with the credentials you want to protect.
The credential identifier configured in the ServiceNow instance must be mapped to the actual credential in the
repository through the JAR file.
Task 1: Activate the External Credential Storage plugin.

Task 2: Create the JAR file to use for resolving credentials on a remote repository with an identifier.
Task 3: Import the JAR file into the ServiceNow instance.
Task 4: Configure the credential identifier in the instance
Task 1: Activate the Plugin

To activate the External Credential Storage plugin, make a request to ServiceNow Technical Support using the
Request Plugin Activation module from HI [1].
Task 2: Create the JAR File

Create a JAR file that contains the implementation needed to resolve a credential identifier sent from the MID Server
into actual credentials from the repository. Make sure to include all the credential elements that the instance expects,
such as the private key.
View the sample Java class to use as a template
package com.snc.discovery;
import java.util.HashMap;
import java.util.Map;
/**
* Implements a credential resolver. Given a credential identifier and
other metadata,
* this resolver will return an actual credential. This credential may
be obtained by
* any means whatsoever.
*
* Note that the fully qualified name of this class must be exactly:
*
com.snc.discovery.CredentialResolver
*
* This class must have a no-arguments constructor, and this must be
the only
* constructor. The MID server will instantiate this class when
needed, and call its
* single public method to resolve a credential. The MID server will
NOT call a single
* instance of this class from multiple threads. The MID server MAY
call a single instance
* of this class multiple times from the same thread.
*
135
136
* @author Tom Dilatush tom.dilatush@service-now.com

* @author Eugene Lockett eugene.lockett@service-now.com
*/
public class CredentialResolver {
// These are the permissible names of arguments passed INTO the
resolve() method.
// the string identifier as configured on the ServiceNow
instance...
public static final String ARG_ID
= "id";
// a dotted-form string IPv4 address (like "10.22.231.12") of the
target system...
public static final String ARG_IP
= "ip";
// the string type (ssh, snmp, etc.) of credential as configured
on the instance...
// Argument will be one of:
//
"ssh_password","ssh_private_key","snmp","vmware","windows","mssql","cim"
public static final String ARG_TYPE = "type";
// the string MID server making the request, as configured on the
instance...
public static final String ARG_MID = "mid";
// These are the permissible names of values returned FROM the

resolve() method.
// the string user name for the credential, if needed...
public static final String VAL_USER = "user";
// the string password for the credential, if needed...
public static final String VAL_PSWD = "pswd";
// the string private key for the credential, if needed...
public static final String VAL_PKEY = "pkey";
// the string pass phrase for the credential if needed:
public static final String VAL_PASSPHRASE = "passphrase";
public CredentialResolver() {
// Do whatever is needed to instantiate this class.
could be nothing at all,
This

// or it could be something much more elaborate, including
reading configuration
// files from disk, making connections to a credentials
repository, etc.
}
/**
* Resolve a credential.
*/
public Map resolve(Map args) {
// First grab the arguments from the map
String credentialId = (String) args.get(ARG_ID);
String credentialType = (String) args.get(ARG_TYPE);
String thisMidServerName = (String) args.get(ARG_MID);
String targetIp = (String) args.get(ARG_IP);
// Variables for returning to the MID server
String user, password, passphrase, privateKey;
// Check the requested type and make the appropriate calls to
the credential repository:
// Possible type values are "ssh_password, ssh_private_key,
snmp, windows, vmware, mssql, cim and etc"
if(credentialType == "ssh_private_key") {
// TODO: make call to to credential repository to
grab user, passphrase and privateKey
}
else {
// TODO: make call to credential repository to grab
user and password
}
// Finally, the resolved credential is returned in a
HashMap...
Map result = new HashMap();
result.put(VAL_USER, user);
result.put(VAL_PSWD, password);
result.put(VAL_PASSPHRASE, passphrase);
result.put(VAL_PKEY, privateKey);
return result;
}
/**
* Return the API version supported by this class.
*/
public String getVersion() {
return "1.0";
137
138
}
}
Task 3: Import the JAR File

After creating the JAR file, import it into the instance, where it becomes accessible to the MID Server.
1. Navigate to MID Server > JAR Files.
2. Click New.
Name: A unique and descriptive name for identifying the file in the instance.
Version: A version number for the file, if one is available.
Source: Location of the JAR file for reference purposes. Source information is not used by the system.
Description: Short description of the JAR file and its purpose in the instance.
4. Click the paper clip icon in the banner and attach the JAR file to the record.
5. Click Submit.
The platform makes the JAR file available to any MID Server configured to communicate with the instance.
Task 4: Configure the Credential Identifier

The form appears in the External Storage view and contains fields only visible when the external credentials property
is enabled.
1.
2.
3.
4.
Navigate to Discovery > Credentials or Orchestration > Credentials.

Click New.
Complete the form using the field definitions from the Credentials form.
Select the External Storage check box.
The User name and Password fields disappear, and the Credential ID field appears.
5. In Credential ID, enter the unique key configured for these credentials in the external repository.
This is the ID passed to the Java class in the parameter map:
public static final String ARG_ID
= "id";

The MID Server uses this identifier to resolve the actual credentials on the repository.
6. Click Submit.
Logging
If the repository encounters an error while attempting to resolve a credentials request, the MID Server posts log
messages with the following prefix:
Problem with client's CredentialResolver:
139
140
Application Profile Discovery

Overview
Application Profile Discovery (APD) enables Discovery to identify custom applications or applications that contain
multiple processes and determine their dependencies by using pre-populated data. The information that Discovery
uses to do this appears in an XML file, created by an administrator, and installed in your environment. The
administrator saves this environment file to a location on a managed system (host, node, server, platform, or other
device that is present in the CMDB) where probes launched by the MID Server are configured to look for it.
Discovery uses the data in this file to establish the relationships between the application and the business services it
supports. In addition to the environment file, the administrator creates a version file containing general information
about the application and the version that Discovery uses to describe the application. See Application Profile
Discovery Example for the complete setup procedure. For instructions on customizing the type of information that
APD can provide to Discovery, see Application Profile Discovery Customization.
The diagram shows a hypothetical relationship between the SAP application and another application created by a
common business service. APD is able to discover both SAP and the dependencies created by the shared business
service by using information contained in an environment file called sap.xml installed on the managed system.
Version information is contained in the sap_version.xml file which is installed in a different location on the
same managed system or proxy server.
141
Requirements
Enable Application Profile Discovery: To enable APD, navigate to Discovery Definition > Properties and
select Yes in the Application Profile Discovery property.
Select a MID Server
Calgary: Application Profile Discovery now supports the use of MID Servers configured for PowerShell to
discover Windows machines.
Included with Application Profile Discovery

Name
Description
Table
Application Classification
[discovery_classy_appl]
Stores the results of application discoveries. Access application CIs in this table by navigating to
Discovery Definition > CI Classification > Application.
Category
DiscoveryAPDVersionSensor
Processes the APD version file
DiscoveryAPDSensor
Parses the application files
DiscoveryAPDEnvSensor
Processes the APD environment file
Normalizing Business Service Names

The name of a business service used in an Application Profile Discovery environment or version file might not be an
exact match for an existing business service name in the ServiceNow CMDB. For example, the creator of the
environment file might define a business service as Management tools, but in the CMDB, that business service
appears as Management tool (singular). This can occur if the administrators who manage profile Discovery and the
CMDB fail to standardize the names. Discovery assumes that these are two separate business services and creates
separate records, one for each version of the name. To eliminate duplication, normalize all business service names
after running a new Application Profile Discovery.
Environment File
The XML file that contains the application environment information must be created by a system administrator who
understands the relationships of the specified application. Ideally, this file is prepared when an application is
configured on a managed system. The environment file provides information relevant to the organization and to the
application. See the example to understand how Discovery displays data from environment files in configuration
item (CI) records.
Environment File Template

Use the following XML template for your environment file.
<?xml version="1.0" encoding="UTF-8"?>
<apd>
<config version="1.0" application="(optional) application-name" type="environment" system=" (optional, if not local system) managed system name">
<environment>
<label> environment-name </label>
<description> environment description </description>
142
<ownership> (optional) environment ownership information </ownership>

<business_service> (optional) business service name </business_service>
<application_version_path path="path to version file including filename "/>
<subservices>
<subservices_provided>
<subservice> label </subservice>
</subservices_provided>
<subservices_consumed>
</subservices_consumed>
</subservices>
</environment>
</config>
</apd>
Environment File Configuration

Provide the following information in the environment configuration file:
Attributes
Tags
Detail
Requirement
Description
Attributes
version
Mandatory
Version of this application.
application
Optional. Discovery uses the

application name from the version
file to populate the CMDB.
Name of this application.
system
Mandatory if this environment

configuration file is installed on a
proxy server (the managed system
cannot store custom files or is
accessible to the MID Server).
The system name represents the managed systems name, unique to a given system,
to which this environment configuration file belongs.
<label>
Mandatory
This label has information important to the organization, such as Production,

UAT, QA, or Development. The label and description appear only in the
Environment related list in the application record. You must personalize the form
to add the Environment related list.
<description>
Optional
This is a short description of the application.
<ownership>
Optional
If ownership is not specified here, then it must be configured in the version file.
This value is typically a group-level ownership label that may be mapped to an
existing group in the Group [sys_user_group] table. This value appears in the
Support group field in the ServiceNow Environment record for this application.
To access the record, personalize the form to add the Environment related list to the
application record, and then drill down into the environment listed.
<business service>
Optional
The name of the business service that this application presents to the rest of an
organization. This business service has a Depends on::Used by relationship with
the application.
Tags
143
<application version
path>
Mandatory
This is the path to the version file for this application. Never place the version file
in the same directory as the environment file.
Optional
These values can be used to describe the individual services provided to other
applications apart from this one. Configure sub-services provided in the
environment configuration file if they are different in each environment. Configure
them in the version configuration file if sub-services are hardwired into the
application. Sub-service configuration information can be used by the MID Server
to connect this application environment with other applications or application
environments.
<subservices_consumed> Optional
These values describe the individual services that this application consumes from
others. Configure sub-services consumed in the environment configuration file if
they are different in each environment. Configure them in the version configuration
file if sub-services are hardwired into the application. Sub-service configuration
information can be used by the MID Server to connect this application environment
with other applications or application environments.
Locating Environment Configuration Files

Environment files are stored on and collected directly from systems that support a general purpose file system. The
MID Server searches for environment files on every machine it discovers, using the location preferences described in
this section. To provide flexibility in different environments, an administrator has several options for installing
environment files in a file system. The MID Server checks specific locations on the managed systems it discovers in
a particular order. When the MID Server finds a base environment file, the MID Server quits searching on that
device.
Note: Never place the version file in the same directory as the environment file. Discovery treats all files found in that location as
environment files and cannot parse the version file correctly.
UNIX
Place the environment files in one of the following locations. Discovery searches for the file in the order shown.
1. Environment variable: Put the environment configuration file in a path such as /usr/local/APD and set
the variable, $APDCONF, to describe the location of the file. How this environment variable is maintained is left
to the administrators of the local environment.
2. Discovery property: Navigate to Discovery Definition > Properties and set the file path in the Application
Profile Discovery location for UNIX based systems property
(glide.discovery.application_discovery.unix_location). The default path is /etc/opt/APD/.
Windows
Place the environment configuration file in one of the following locations on a Windows OS version that supports a
local machine registry.
1. Registry key: Before the MID Server retrieves a file from a managed Windows system, it checks the
HKEY_LOCAL_MACHINE (HKLM) hive, in the key HKLM\SOFTWARE\APD\APD\CONFIGPATH for a
REG_EXPAND_SZ or REG_SZ type registry value. The key value can require expansion for terms such as
%CommonAppDataFolder%. See Microsofts CSIDL [1] documentation for further details.
2. Discovery property: Navigate to Discovery Definition > Properties and set the file path in the Application
discovery location for Windows systems property
(glide.discovery.application_discovery.windows_location). The sample path is
%ALLUSERSPROFILE%\Application Data\APD, in which %ALLUSERSPROFILE% is the environment variable
for any Windows system. This variable points to different paths on different versions of Windows. For example,
on Windows 7, %ALLUSERSPROFILE% opens C:\ProgramData, and on Windows XP, it opens C:\Documents
and Settings\All Users.
Proxy Locations
Some managed systems, such as network routers, switches, and network load balancers, do not support locally stored
files or general purpose file systems that could store APD configuration files. In this case, you can name the target
managed system in an environment configuration file installed on a separate proxy server. Make sure to put the
configuration XML file in one of the approved locations on the proxy machine. The MID Server searches for this file
on every machine it discovers. When it finds an XML file in one of the expected locations, it identifies the correct
managed system by parsing the value for <managed system name> in the following line:
<config version=1.0 application=(optional) application-name type=environment system= (optional, if not local system) managed system name>
Version File
The XML file containing version information about the application is typically prepared as part of the software
packaging and release process and is identical across all managed systems using that version of the software. An
application on any given managed system can be fully described by one or more version files and one or more
environment files. Never place the version file in the same directory as the environment file. You can install the
version file in any other location on the managed system or proxy server that is visible to the MID Server. The MID
Server locates the version information related to an application by following a path defined within the environment
file. Install one copy of the version file per installed software version on a managed system. See the example of this
feature to understand how Discovery displays data from version files in configuration item (CI) records.
144
145
Version File Template

Use the following XML template for the version file.
<?xml version="1.0" encoding="UTF-8"?>
<apd>
<config version="1.0" application="application-name" type="version">
<version>
<label>version-name-label</label>
<description>version description</description>
<ownership>software package ownership information</ownership>
<subservices>
</subservices_provided>
<subservices_consumed>
</subservices_consumed>
</subservices>
</version>
</config>
</apd>
Version File Configuration

The version configuration file contains the following information:
Application details
Application Details
Detail
Requirement
Description
Attributes
version
Mandatory
The version must be unique to the installed version of an application. This label displays the
application version or other distinguishing name.
application
Mandatory. Discovery
uses the application
name from the version
file to populate the
CMDB.
Name of this application.
<label>
Optional
This label has information important to the organization, such as Production, UAT, QA, or
Development. The label and description appear only in the Environment related list in the
application record. You must personalize the form to add the Environment related list.
<description>
Optional
This is a short description of the application.
Tags
146
<ownership>
Mandatory
This value is typically a group-level ownership label that may be mapped to an existing group
in the Group [sys_user_group] table. This value names the owner who is responsible for this
software package or installation. If no value is specified in the environment file, then this
value is used to record ownership of the environment as well. A group owner selected from
the Group [sys_user_group] table appears in the Support group field in the ServiceNow
Environment record. To see this record, personalize the Application form to display the
Environment related list, and then drill into the environment listed.
Optional
These values describe the individual services provided by this version of the software. Use
this value to define additional services provided by a new version of an existing application
already configured by an environment file. Discovery creates the relationships defined in the
environment file first and then adds any sub-services listed in the version file.
<subservices_consumed> Optional
These values describe the individual services this application consumes from other
applications. Use this value to define additional services consumed by a new version of an
existing application already configured by an environment file. Discovery creates the
relationships defined in the environment file first and then adds any sub-service relationships
listed in the version file.
Enhancements
Calgary
The following enhancements have been added as of the Calgary release:
PowerShell support: Application Profile Discovery supports the use of MID Servers configured for PowerShell
to discover applications on Windows machines.
References
[1] http:/ / msdn. microsoft. com/ en-us/ library/ windows/ desktop/ bb762494(v=vs. 85). aspx
Example
147
Example
Overview
This page contains these examples of Application Profile Discovery (APD):
Linux environments
Windows environments
Proxy servers
APD in Linux Environments

The RCD Corporation wants to discover details of their custom human resources application called ResourceNow
and create relationships to other processes in their CMDB. As the IT lead, you decide to use Application Profile
Discovery (APD) to supply Discovery with information about the application for all the systems on which it is
installed.
To use APD to discover the ResourceNow application, you must complete the following tasks:
Task 1: Create the APD Directories

Task 2: Enable APD and Set the Environment File Location
Taks 3: Create the Environment File
Task 4: Create the Version File
Task 5: Classify the Application
Task 6: Run Discovery
Task 1: Create the APD Directories

You must create at least two directories on a host machine: one for the environment file and another for the version
file. The two file types cannot be stored in the same directory. However, you can store multiple files of the
appropriate type in each directory. Ensure that the MID Server has permission to read the files in these directory. For
this example, create a directory called /APD at the top level of the host machine and another directory at the same
level called /APD_version.
Task 2: Enable APD and Set the Environment File Location

1. Navigate to Discovery Definition > Properties.
2. In the Application Profile Discovery field , select Yes. (This field maps to the
glide.discovery.application_profile_discovery property.)
3. Use the appropriate Application Profile Discovery location field (for UNIX or Windows) to name the path to
the /APD directory you just created for the ResourceNow environment file.
In this example, the file system is UNIX based, so define the /APD path in the Application discovery location
for
UNIX
based
systems
property.
(This
field
maps
to
the
glide.discovery.application_discovery.unix_location property.)
Example
4. Click Save.
Task 3: Create the Environment File

1. In an XML editor, open the environment file template and complete it for the ResourceNow application using the
following values:
Version: Enter 2.0.

Application: Name the application ResourceNow.
Label: Configure Development as the name for this environment.
Description: Enter Development environment for this example.
Ownership: Add the name of an existing group from the Group [sys_user_group] table that is responsible for
managing this environment. For this example, add Software.
Version path: Enter the path and the name of the version you will create in the next task. For this example,
enter /APD_version/ResourceNow_version.xml, where ResourceNow_version.xml is the name of the version
file.
Sub-services provided: Name this sub-service Benefits.
Sub-services consumed: Name this sub-service Management tool.
2. Give the environment file a logical name, such as the name of the application (ResourceNow.xml) and save it to
the /APD directory.
148
Example
149
Task 4: Create the Version File

Note: Do not save the version file in the same directory as the environment file. Discovery cannot process version data found in the
environment directory.
1. In an XML editor, open the version file template and complete it for the ResourceNow application using the
following values:
Version: Enter the version number for this application. For this example, enter 2.0.
Application: Use the application name that should appear in the CMDB. In this example, the application is
called ResourceNow.
Type: Leave the default as version.
Label: Enter a descriptive name. For this example, enter ResourceNow 2.0.
Description: Describe the purpose of the application briefly. For this example, enter Human Resources
management application.
Ownership: Add the name of an existing group from the Group [sys_user_group] table responsible for
managing this application. For this example, enter Enterprise Applications.
2. Give this file the same name as entered in the environment file as the version target.
In this example, use ResourceNow_version.xml.
3. Save the file in the /APD_version directory created in Task 1.
Task 5: Classify the Application

For Discovery to classify the custom application, you must create a classification record in the CMDB.
1. Navigate to Discovery Definition > CI Classification > Application and click New.
2. Complete the Application Classification record, using the following values:
Name: Enter the application name that should appear in the CMDB. For this example, enter ResourceNow.
Table: Select Application [cmdb_ci_appl] from the list of tables.
Relation type: Select the relationship of the application to the host on which it runs. For this example, select
Runs on::Runs. For additional information regarding relationships, see Defining CI Relationships.
3. Right-click in the header bar and select Save from the context menu.
4. Go to the Classification Criteria related list, click New.
Example
5. In the Classification Criteria record, enter name in the Name field.
6. Click Submit.
7. In the Classification Criteria related list, edit the list directly and save the following values:
Operator: Select contains.
Value: Enter ResourceNow.
8. Click Update.

When Discovery runs, the MID Server checks for environment files in the directory specified in the location
property (/APD/ in this example). The MID Server parses the ResourceNow.xml environment file and finds the path
to the ResourceNow_version.xml file. The contents of both files are used to construct the relationships of the
application to its configured business services and to the computer on which it runs. You can see these relationships
in the following records:
CI record for the computer host
Application CI record
BSM map
150
Example
Computer CI
The CI Relations Formatter in the host computer CI record displays the relationships of all the business services
(including shared services) that run on the machine.
Application CI
The application CI record is populated with version and environment information and displays the business services
connected to that application in the CI Relations Formatter.
151
Example
152
To view the environment details from an application CI record:

1. Personalize the form to display the Environment related list.
2. Click Development in the related list to see the environment details.

The value in the Support group field is the ownership value from the ResourceNow.xml environment file.
Business Service Management Map

To see a graphical representation of the relationship between this application, its business services, and the computer
on which it runs, open the CI record for the computer host. Then, click the Business Service Management (BSM)
map icon
in the header bar of the CI Relations Formatter. The map shows all the business services and
applications associated with the computer host, as well as the installed hardware.
APD in Windows Environments

This example uses a property for Windows systems to set the path location for the environment file. The default path
is %ALLUSERSPROFILE%\Application Data\APD, where %ALLUSERSPROFILE% is the environment variable
for any Windows system. This variable points to different paths on different versions of Windows. For example, on
Windows 7, %ALLUSERSPROFILE% opens C:\ProgramData, and on Windows 2003 server it opens C:\Documents
and Settings\All Users.
To create the APD folder on a Windows 2003 server:
1. Open Windows Explorer and enter %ALLUSERSPROFILE% in the address bar, then press Enter.
Example
153
The complete path defined by that variable appears in the address bar.
2. Create an APD folder in the All Users folder for the environment file .
3. In ServiceNow, navigate to Discovery Definition > Properties.
4. Locate the Application discovery location for Windows based systems property
(glide.discovery.application_discovery.windows_location).
5. Using the environment variable, enter the entire path in the Windows file location property, including the APD
folder you just created .
In this example, enter %ALLUSERSPROFILE%\APD, which resolves to C:\Documents and Settings\All
Users\APD on Windows 2003.
6. Click Save.
7. Continue the procedure from Task 3 on this page and copy the completed environment file from that task into the
APD folder you created.
APD with Proxy Servers

Some devices that you want to discover might be inaccessible to the MID Server. Examples of this are mainframe
computers, a server whose credentials are not in the Credentials [discovery_credentials] table, and a switch that does
not have a file system for storing XML files. For such devices, create an environment file that identifies the
inaccessible device, and then put that file on a proxy server where the file is visible to the MID Server. Place the
version file on the same proxy server, but in a different directory than the environment file. The MID Server locates
the environment file in one of the expected locations on the proxy server and reads the path to the version file. The
MID Server includes the environment and version data in the sensor package, without exploring the hidden system.
To create APD files for an SAP application on a server (any OS) for which no credentials are available:
1. Navigate to Discovery Definition > Properties and find the property for the proxy server's operating system.
In this example, use the Application discovery location for UNIX based systems property
(glide.discovery.application_discovery.unix_location) for a Linux proxy server. This
example uses the default path of /etc/opt/apd/, although it could use any path.
Example
2. On the Linux proxy server, create an APD folder in the default UNIX path: /etc/opt/apd/.
Note: By default, Discovery looks for the environment file in this location on all UNIX machines.
3. Use the template to create an SAP environment file for a Solaris server that does not have Discovery credentials.
system: The namer of the inaccessible computer on which the SAP application is running. For this example,
sol13.lab2 is the name of the Solaris computer with no credentials for Discovery.
application_version_path: Specify the path to the SAP version file on the proxy server. For this example,
enter /etc/opt/apd_version/sap_version.xml. The version file must be on the same computer as the environment
file but in different directories.
4. Save the environment file to the /etc/opt/apd/ directory.

5. Create the version file directory using the path specified in the environment file.
For this example, create a directory called apd_version on the same level as the apd directory. Remember that
the version file cannot be in the same directory as the environment file.
6. Use the template to create a version file called sap_version.xml and save it to the /etc/opt/apd_version directory.
7. Continue the process at Task 5 on this page.
154
Customization
Customization
Overview
Application Profile Discovery (APD) enables administrators to define processes and dependencies for applications
that Discovery cannot explore. The base system provides the configuration to discover the relationships of business
services to an application and can be extended to return other data about the application. This example demonstrates
how to add additional data to the environment and version files and display that data in the application record.
For a task-based procedure on setting up and configuring APD to use default parameters, see the Application Profile
Discovery Example page.
Setup Tasks
This customization procedure assumes you have performed the following prerequisite tasks:
Enabled Application Profile Discovery on your instance.
Created environment and version files for your application.
Placed the environment file in a location where the MID Server is configured to search for it.
Task 1: Customize the Environment File

This example adds a value to the environment file that populates the comments field of the ResourceNow
application record.
1. Open the existing environment file in an XML editor.
2. Add a new XML tag within the <environment> tags, at the end of the last subservices section.
The tag name is arbitrary. This example uses <custom>, but the tag could also be named <notes>.
155
Customization
3. Create a nested tag inside the custom tag that names the field in the Application [cmdb_ci_appl] table you want to
populate.
This tag name is also arbitrary, but should be descriptive of the field selected. This example uses
<comments>.
4. Add a value to this tag that appears in the Discovery record for this application.
This example provides information about how this application is used in the company.
5. Save the environment file.
Task 2: Customize the Version File

This example adds a value to the version file that populates the asset_tag field of the ResourceNow application
record.
1. Open the existing version file in an XML editor.
2. Add a new XML tag within the <version> tags, at the end of the default subservices tags.
The tag name is arbitrary but must not contain any spaces. This example uses <custom>, but this tag could
also be named <tagNumber>.
3. Create a nested tag inside the custom tag that names the field in the Application [cmdb_ci_appl] table you want to
populate.
This tag name must match the name of a field in the Application [cmdb_ci_appl] table. This example uses
<asset_tag>.
4. Add a value for this tag.
This value appears in the appropriate field in the application record.
5. Save the version file.
156
Customization
Task 3: Update the Classification Script

1. Navigate to Discovery Definition > CI Classification > Application and open the Application Classification
record for your application.
2. In the On classification script field, configure the classifier to return the data from the environment and version
files.
3. This example uses the following script:
var appdata = ciData.getData();
appdata.<asset_tag> = versionResult.config.version.custom.<asset_tag>;
appdata.<comments> = envResult.config.environment.custom.<comments>;
5. This script uses the appdata parameter to identify the field tags in each file. The remainder of the statement
shows the position in each XML file in which the data appears.
6.
Task 4: Personalize the Application Form

To display the information that Discovery returns from APD in this example, you must personalize the Application
form to display the necessary fields.
1. Navigate to Configuration > Applications.
2. Select the application from the list.
For this example, select ResourceNow.
3. Right-click the header bar of the Application record and select Personalize > Form Layout from the context
menu.
4. Add the Asset tag and Comments fields.
5. Save the changes.
157
Customization

Run Discovery to add the custom Application Profile Discovery data to the CMDB. The values you specified in the
XML files appear in fields on the Application record.
158
159
Extended Capabilities
DiscoverNow
Overview
DiscoverNow allows an administrator to run a CI Configuration discovery on a single IP address without requiring a
schedule. The platform automatically selects the correct MID Server to use for the discovery if one is associated with
the IP address selected. If no MID Server is configured for the network in which that address appears, the
administrator selects a MID Server. This feature enables an administrator to discover new devices in the network as
soon as they are connected to the network, rather than waiting for a regularly scheduled discovery. DiscoverNow is
available with the Calgary release.
Setup
To configure the system to automatically determine which MID Server to use, set up the IP range capabilities for
each MID Server in your system. Refer to Configuring a MID Server for an IP Address Range for instructions.
Using DiscoverNow
You can run DiscoverNow from a Discovery Schedule form or from a script.
Run DiscoverNow from the Schedule Form

1. Navigate to Discovery > Discovery Schedules module.
2. Click Quick discovery in the header.
A dialog box appears asking for an IP address and the name of the MID Server to use.
3. Enter the target IP address for a discovery in the Target IP field.
Note: DiscoverNow does not currently 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 field. 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.
4. If no MID Server is defined for that network, select one from the list of available MID Servers.
DiscoverNow
5. 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.
Run DiscoverNow from a Script

You can run DiscoverNow from a script, such as a background job, a business rule, or web services.
Use the following script:
var d = new Discovery();
var statusID = d.discoveryFromIP(TARGET_IP, TARGET_MIDSERVER);
The discoveryFromIP method takes two arguments, IP and MID Server. The IP argument is mandatory, but
the the MID Server argument is optional. To choose the MID Server, supply either the sys_id or name of the MID
Server as the argument. If you do not name a MID Server, the system attempts to find a valid one automatically. A
valid MID Server has a status of Up and is capable of discovering the given IP address. If the system finds a valid
MID Server and runs a discovery, the discoveryFromIP method returns the sys_id of the discovery status
record. If no MID Server is capable of discovering this IP address, the method returns the value undefined.
If you manually specify the TARGET_MIDSERVER, the system validates the given value and ensures that the MID
Server table contains the specified MID Server record. If the validation passes, the discoveryFromIP method
returns the sys_id of the discovery status record. If the validation fails, the method return the value undefined.
160
PowerShell
161
PowerShell
Overview
PowerShell [4] is built on the Windows .NET Framework and is designed to control and automate the administration
of Windows machines and applications. ServiceNow Discovery supports the use of PowerShell to discover Windows
computers. MID Servers using PowerShell must be installed on a supported Windows operating system.
ServiceNow supports PowerShell 2.0.
Note: PowerShell is the preferred method for running Discovery over multiple Windows domains, because it allows a single MID
Server to authenticate on machines on different domains using credentials stored on the instance.
Enhancements
Calgary
The following enhancements are part of the Calgary release.
A new parameter mid.powershell.local_mid_service_credential_fallback specifies the
login credentials the MID Server uses if all other credentials fail. This parameter replaces the parameter
mid.powershell.use_mssqlauth. See MID Server Parameters.
The parameter mid.powershell.path can only discover 64-bit applications running on Windows hosts if
the MID Server is also running on a 64-bit Windows host. See MID Server Parameters.
The parameter mid.powershell.use_mssqlauth is obsolete and was removed from the platform.
Microsoft SQL Server discoveries use the PowerShell probe, which uses the MID Server's credentials. The
PowerShell MSSQL probe was also removed. See MID Server Parameters.
Installed with PowerShell for Discovery

The following elements were added to support PowerShell discoveries:
MID Server Parameters

The following parameters are optional.
Note: After changing the setting for any parameter, be sure to restart the MID Server service.
PowerShell
162
Description
PowerShell
credentials
Name(s)
mid.powershell.use_credentials
Details
Determines the credentials to use for Discovery with PowerShell. A setting
of true directs the MID Server to run probes with the Windows credentials
from the credentials table. To run probes with the credentials of the user for
the MID Server service, set this parameter to false.
Enable
mid.use_powershell
PowerShell
for Discovery
Enables PowerShell for Discovery. You must and restart the MID Server
after setting the parameter to true. If PowerShell is not installed or is not at
version 2.0, Discovery reverts to WMIRunner.
PowerShell
executable
path
mid.powershell.path
Type: true | false

Default value: true
Type: true | false

Enables an administrator to point to a specific PowerShell on a MID Server

in cases where more than one PowerShell is installed. Supply the path to
the folder containing the PowerShell executable (for example,
C:\mypowershell or C:\mypowershell\). ServiceNow automatically appends
the string powershell.exe to the path. This parameter might be necessary
when both a 32-bit and 64-bit PowerShells are active on the same MID
Server, and it becomes necessary to launch the correct PowerShell for the
context. Note that 64-bit Windows employs file system redirection and the
MID server runs as a 32-bit application. If trying to specify a path in
%WinDir%\System32, Windows will automatically redirect to
%WinDir%\SysWOW64. To avoid redirection, specify the path as
%WinDir%\Sysnative. An example would be instead of
C:\WINDOWS\system32\WindowsPowerShell\v1.0\, specify
C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\.
Note: On a 64-bit version of Windows Server 2003 or

[10]
Windows XP, a Microsoft hotfix
may be required to
enable this capability.
To discover applications running on a 64-bit Windows machine in the
Calgary release, the MID Server must be running on a 64-bit Windows host
machine.
MID Server
credentials
mid.powershell.local_mid_service_credential_fallback Specifies the login credentials the MID Server uses if all other credentials
fail. This parameter is available with the Calgary release.
Enable or
Disable the
enforcement
of UTF-8 for
command
output
Type: string (path)

Default value: none
mid.powershell.enforce_utf8
Type: true | false

Default value: true
Enable this parameter to force commands on a target Windows system to

return UTF-8 encoded output. Disabling it allows the target system to use
its default encoding. This parameter is only valid when PowerShell is
enabled. Setting this value to false may result in incorrect values in the
CMDB when non-ASCII characters are returned by a probe.
Type: true | false

Default value: true
PowerShell
163
MID Server Script Includes

The following script includes were added for PowerShell discoveries. These scripts run on the MID Server to
generate the scripts that Discovery uses for WMIRunner and PowerShell.
Script Include
Description
GenerateWMIScriptJS
Generates a Javascript script for the WMIRunner probe.
GenerateWMIScriptPS1 Generates a PowerShell script for PowerShell Discovery.
Probe and Sensor

When a Windows machine is classified with PowerShell, and an MSSQL instance is detected, a probe called
Windows - MSSQL is launched. The probe returns the SQL database catalogs and version to a matching sensor.
Probe Parameter
A probe parameter called WMI_ActiveConnections.ps1 contains a script that runs netstat.exe on a target machine
for connection information (such as process IDs, ports, IP addresses) when PowerShell is enabled.
Credentials
Discovery uses Windows PowerShell credentials from the ServiceNow Credentials table or the domain administrator
credentials of the MID Server service. If Discovery cannot find PowerShell credentials in the Credentials table (of
the type Windows), it uses the login credentials of the MID Server service (starting with the Calgary Release).
Setting Up a MID Server to Use PowerShell

Discovery can be run with a mix of MID Servers using PowerShell and WMIRunner.
1. Download [1] PowerShell and install it on each MID Server configured to discover Windows computers.
2. Enable PowerShell for Discovery by setting the mid.use_powershell MID Server parameter to true on all the
MID Server machines using PowerShell.
See the instructions for configuring MID Server parameters.
3. Determine which credentials PowerShell should use.
To discover Windows computers using credentials from the credentials table, set the
mid.powershell.use_credentials parameter to true. This is the default behavior when PowerShell is enabled.
To force Discovery to use the credentials of the MID Server service user, set the
mid.powershell.use_credentials parameter to false on the MID Server. The MID Server service must have
domain admin credentials to have access to the Windows machines in the domain.
References
[1] http:/ / technet. microsoft. com/ en-us/ scriptcenter/ dd772288
VMware vCenter
164
VMware vCenter
Overview
These options are available for getting VMware vCenter data:
ServiceNow Discovery can run the VMWare - vCenter probe when it identifies a VMware vCenter process
running on a Windows machine.
ServiceNow Orchestration can run the VMWare - vCenter probe from a workflow.
See VMware Component Relationships for a description of the VMware architecture and component relationships.
Discovery Configuration and Process Flow

Discovery of vCenter CIs requires at least two credentials: the Windows credential for the host on which the vCenter
server runs and the VMware credential for the vCenter server. When Discovery runs, a classifier called vCenter
classifies the process running on a Windows machine and launches the VMware - vCenter probe. This probe logs
into the vCenter instance with the credentials provided and uses the vCenter API to return information about ESX
machines, virtual machines, and resource pools. If using a domain account to access vCenter, specify the domain
with the user name in the credential record in one of the supported formats such as Domain\UserName.
Note: Make sure to select a credential Type of VMware.
Orchestration Configuration and Workflow

Administrators can configure configure instances with Orchestration to run a workflow called Discover vCenter to
populate the CMDB with vCenter data without having to activate the Discovery plugin. This workflow is particularly
useful for an administrator who has just installed vCenter and wants to begin using it for cloud provisioning, but has
not purchased Discovery. This workflow is available starting with the Calgary release.
The workflow resolves the DNS name and populates the CMDB by running the standard VMware - vCenter probe
(installed by default). You must have a properly configured MID Server connected to the ServiceNow instance to
use this feature.
You can discover a vCenter instance using one of these methods available on the VMware vCenter Instance form:
Discover vCenter Details: This related link is available to users with the vmware_operator role.
Scheduled discoveries: Users with the cloud_admin role can create and edit scheduled discoveries from this
related list. Users with the vmware_operator role can view scheduled discoveries.
Note: For more information about these roles and capabilities, see Cloud Provisioning Security.
To discover a single vCenter instance:

1. Navigate to VMware > Configuration > vCenter Instances.
2. Select the vCenter instance you want to discover.
3. Under Related Links, click Discover vCenter Details.
VMware vCenter
The list of vCenter instances appears. ServiceNow sends you an email confirmation when the scan is
complete.
To create a scheduled discovery:

1.
2.
3.
4.
Navigate to VMware > Configuration > vCenter Instances.

Select the vCenter instance you want to discover.
Click New in the Scheduled discoveries related list.
Enter a unique and descriptive name for this schedule.
5. Select the day and time to run this discovery, using the field descriptions from the Discovery Schedules form as a
reference.
6. [Optional] Select the Conditional check box to script a condition that defines a custom run time.
7. Click Submit.
165
VMware vCenter
166
The Discovery vCenter workflow runs in silent mode for this type of discovery and does not send
notifications.
8. Click Execute Now to run this discovery immediately.
vCenter Data Collected

Discovery and Orchestration collect the following data for VMware vCenter servers.
Tables and Fields

Field Label
Table Name
Column Name
Source
API version
VMware vCenter Instance [cmdb_ci_vcenter]
api_version
VMWare - vCenter probe
Full name
fullname
Instance UUID
instance_uuid
URL
url
Effective CPU
VMware vCenter Cluster [cmdb_ci_vcenter_cluster]
effectivecpu
Effective memory
effectivememory VMWare - vCenter probe
Number of effective hosts
effectivehosts
Number of hosts
numhosts
Total CPU
totalcpu
Total memory
totalmemory
Top level folder for hosts
VMware vCenter Datacenter [cmdb_ci_vcenter_datacenter]
host_morid
Top level folder for VMs
folder_morid
Accessible
VMware vCenter Datastore [cmdb_ci_vcenter_datastore]
accessible
Capacity (GB)
capacity
Free space (GB)
freespace
Type
type
VMware vCenter
167
URL
url
Full path
VMware vCenter Folder [cmdb_ci_vcenter_folder]
fullpath
Accessible
VMware vCenter Network [cmdb_ci_vcenter_network]
accessible
Managed object reference ID VMware vCenter Object [cmdb_ci_vcenter_object]
morid
vCenter Instance UUID
VMware vCenter Object [cmdb_ci_vcenter_object]
vcenter_uuid
vCenter Reference
vcenter_ref
Managed object reference ID VMware vCenter Server Object [cmdb_ci_vcenter_server_obj] morid
Folder
vCenter Folder Type [vmware_vcenter_folder_type_m2m]
folder
Type
type
Relationships
Discovery automatically creates relationships for vCenter components using data from a key class. Subsequent
Discoveries use the same key class to automatically validate and remove relationships that are no longer valid.
Parent Class
Relationship Type
Child Class
Relationship Key
Class
VMware Virtual Machine Instance

[cmdb_ci_vmware_instance]
Registered on::Has registered
ESX Server [cmdb_ci_esx_server]
Child

Connected by::Connects
VMware vCenter Network

[cmdb_ci_vcenter_network]
Parent

Provided by::Provides
Parent
VMware vCenter Datastore

[cmdb_ci_vcenter_datastore]
Provides storage for::Stored

on

Parent

Used by::Uses
Child
VMware vCenter Cluster

[cmdb_ci_vcenter_cluster]
Members::Member of
Child
ESX Resource Pool

[cmdb_ci_esx_resource_pool]
Defines resources for::Get

resources from

Parent
ESX Resource Pool


resources from
Parent
VMware vCenter Folder

[cmdb_ci_vcenter_folder]
Contains::Contained by

Parent


Parent

Virtual Machine Template

[cmdb_ci_vmware_template]
Parent


Parent
VMware vCenter Datacenter

[cmdb_ci_vcenter_datacenter]

Parent


Parent
VMware vCenter
168

Parent


Parent


Parent
Enhancements
Eureka
Automatically validates and updates relationships for vCenter CIs. This process also removes stale relationships.
In addition to the new logic to remove stale relationships, code existed in previous versions to perform the
following tasks:
Remove records in the cmdb_ci_vmware_instance table that are no longer associated to a record in the
cmdb_ci_esx_server table, including the corresponding Registered on::Has registered relationship.
Remove records in the cmdb_ci_computer table that are no longer associated to a record in the
cmdb_ci_esx_server table with a Virtualized by::Virtualizes relationship.
Remove duplicate records in the cmdb_ci_vcenter table that have the same instance_uuid or ip_address fields
as the CI that is currently being discovered.
Calgary
An Orchestration workflow Discover vCenter can populate the CMDB with vCenter data without having to
install the Discovery plugin. See Orchestration Configuration and Workflow.
Hyper-V
Hyper-V
Overview
Microsoft Hyper-V is a virtualization application that is included with the Windows Server 2008 operating system. A
physical machine running Hyper-V is divided into partitions (virtual machines), including a parent partition running
Windows Server 2008 and child partitions running supported guests. The parent partition manages the virtual
machines with the Hyper-V Manager application. On Windows Server 2008 this is done through the Microsoft
Management Console (MMC) service. On Windows 7, use the Remote Server Admin tools.
Hyper-V supports the following functionality:
Failover clustering: Failover is managed with Failover Cluster Manager.
Live migration: Virtual machines can be moved between failover cluster nodes without bringing down the virtual
machine.
ServiceNow Discovery can explore the Microsoft Hyper-V platform running on Windows Server 2008 and return the
following information:
The Hyper-V server running on the host computer
All virtual instances running on the Hyper-V server

Attributes of each instance running on the Hyper-V server
Virtual networks
Resource pools
See Hyper-V Component Relationships for a description of the Hyper-V architecture and component relationships.
Hyper-V discovery is available with the Calgary release.
Required Roles
Users with the itil and asset roles can access Hyper-V configuration item (CI) records. To run discovery on Hyper-V
servers, users must have the discovery_admin role.
Credential Requirements
A Hyper-V discovery requires one of the following credentials:
Domain administrator: Discovery can authenticate on Hyper-V without additional credentials.
Enable PowerShell and provide Windows credentials for the Hyper-V server host: Enable PowerShell for
the MID Server used to discover Hyper-V servers and instances. See MID Server Parameters for instructions on
enabling PowerShell.
Hyper-V Discovery Components

Hyper-V discovery uses the following components to classify and explore virtual machines:
169
Hyper-V
170
Name
Description
Component
Classifier
Hyper-V Server
Classifies stand-alone Hyper-V servers only (servers not running on Windows 2008).
Probe
Hyper-V - VMs
Exploration probe that extracts the list of virtual machines and their attributes from the Hyper-V server. This
probe determines if Hyper-V is on or off on a Windows Server 2008 machine. This result is used to identify
standalone Hyper-V installations.
Probe
Hyper-V
Exploration probe that queries the Hyper-V server for virtual networks.
Virtual Networks
Probe
Hyper-V Clusters
Exploration probe that queries the Hyper-V server for clusters.
Hyper-V Data Collected by Discovery

When Discovery detects the Hyper-V process running on a host machine, it launches exploration probes that return
the typical Windows server data and the following data on the Hyper-V instances.
Virtual Instances
Label
Field Name
Data Description
On
Off
Suspended
Changing
Stuck
Stored in Table
State
state
cmdb_ci_vm_instance
CPUs
cpus
Count
cmdb_ci_vm_instance
Memory
memory
Quantity in MB
cmdb_ci_vm_instance
Network adapters
nics
Count
cmdb_ci_vm_instance
Disks
disks
Count *
cmdb_ci_vm_instance
Disks size
disks_size
Capacity in GB *
cmdb_ci_vm_instance
Virtual Base Board Serial Number baseboard_serial Virtual serial number
cmdb_ci_hyper_v_instance
BIOS Serial Number
bios_serial
Virtual serial number
Chassis Serial Number
chassis_serial
Virtual serial number
BIOS GUID
bios_guid
Globally unique identifier (GUID) cmdb_ci_hyper_v_instance
* Discovery can only return this information if the virtual machine is running.
Hyper-V
171
Virtual Networks
Label
Field Name
Data Description
Stored in Table
Name
name
Name of the virtual network
ID
object_id
Globally unique identifier (GUID) cmdb_ci_vm_object
cmdb_ci
Resource Pools
Label
Field Name
Data Description
Stored in Table
ID
object_id
Globally unique identifier (GUID)
cmdb_ci_vm_object
Capacity
capacity
Maximum amount of the appropriate allocation unit
cmdb_ci_hyper_v_resource_pool
Allocation units allocation_units Units of measurement used (for example, MB or GB)

Resource type
resource_type
cmdb_ci_hyper_v_resource_pool
Type of resource discovered (for example, memory, or hard drive space) cmdb_ci_hyper_v_resource_pool
Clusters
Label
Windows
Cluster
Field Name
win_cluster
Data Description
Reference field displaying the Windows Cluster on which the

Hyper-V cluster resides.
Stored in Table
Reference Table
cmdb_ci_hyper_v_cluster cmdb_ci_win_cluster
Data Migration
When you upgrade an instance to the Calgary release, ServiceNow migrates your virtualization data to a new table
schema and creates a backup table structure to protect existing data. In versions prior to Calgary, records in the
existing Virtual Machine Instance [cmdb_ci_vm_instance] table contain data for VMware virtual machines.
Upgrading to Calgary migrates these records to a new table called VMware Virtual Machine Instance
[cmdb_ci_vmware_instance]. The Virtual Machine Instance [cmdb_ci_vm_instance] table becomes the base class
used for all virtualization platforms: VMware, Amazon EC2, and Hyper-V.
Backup Tables
The upgrade creates the following temporary tables to back up the existing virtual machine instances and associated
references:
temp_backup_cmdb_rel_ci
temp_backup_dictionary
temp_backup_vm_instance
temp_backup_vm_reference
Hyper-V
172
Upgrade Tasks
After creating the backup tables, the upgrade performs the following tasks:
1.
2.
3.
4.
5.
6.
7.
Copies records from the cmdb_ci_vm_instance table to the appropriate temp_backup_vm_instance table.
Backs up affected relationships, references, and dictionary references to the appropriate temp_backup tables.
Deletes the cmdb_ci_vm_instance table.
Creates new cmdb_ci_vmware_instance and cmdb_ci_vm_instance tables.
Copies and maps records from the temp_backup_vm_instance table into the cmdb_ci_vmware_instance table.
Restores relationships and references
Creates a clean-up job in Scheduled Jobs (Schedule Item [sys_trigger] table) called VMware Data Migration
Clean-up that deletes the backup files at a scheduled time three months in the future.
Tips for Cloning Hyper-V Virtual Machines

When importing (cloning) Hyper-V virtual machines, make sure each virtual machine has a unique ID. Discovery
identifies virtual machines with duplicate IDs as the same machine.
1. Export the virtual machine from the Hyper-V server.
2. Import the virtual machine into a different server, making one of the these choices:
Move or restore the virtual machine: This selection clones the image, using the same ID, and moves it to
another server. The original image remains on the Hyper-V server.
Copy the virtual machine: This selection copies the virtual machine, using a different ID, and moves it from
the Hyper-V server. This is the best selection and does not require any further action before you run Discovery.
3. If you import the Hyper-V clone using the Move or restore selection, be sure to delete the original image from
the Hyper-V server.
When Discovery encounters two virtual machines with the same equivalent serial numbers, it creates only one
configuration item (CI).
CIM Discovery
CIM Discovery
Overview
CIM probes can explore any device based on the Common Information Model (CIM) by querying a CIM server, also
referred to as a CIMOM - Common Information Model Object Manager. By default, Discovery uses CIM probes to
explore storage systems as well as to get the serial numbers of ESX servers.
Architecture
The following components are part of CIM:
Common Information Model (CIM): CIM [8] allows multiple parties to exchange information about managed
elements. CIM represents these managed elements and the management information, while providing the
mechanism to actively control and manage the elements.
Storage Management Initiative Specification (SMI-S): SMI-S [1] is a standard of use that describes methods for
storage discovery on the vendor's side. ServiceNow uses SMI-S to determine how to discover CIM. SMI-S is
based on the Common Information Model (CIM) and the Web-Based Enterprise Management (WBEM)
standards, which define management functionality via HTTP. The main objective of SMI-S is to enable
management of dissimilar storage products. ServiceNow supports SMI-S version 1.5 or higher.
Web-Based Enterprise Management (WBEM): WBEM [7] defines a particular implementation of CIM,
including protocols for discovering and accessing each CIM implementation.
Service Location Protocol (SLP): SLP [2] is an ad hoc protocol for retrieving and associating configuration
information about CIM servers, such as default paths, capabilities, and the exact interop namespace [3].
ServiceNow Discovery retrieves the interop namespace of a CIM server via SLP and passes that information to
the CIM Classify probe. SLP, referred to here as the SLP server, uses service agents (SA) to gather and
disseminate information about a CIM server on a subnet. A subnet can have multiple service agents.
173
CIM Discovery
How CIM Discovery Works

1. The Shazzam probe launches the wbem port probe as part of network discovery.
2. The wbem port probe detects activity on target ports SLP 427, CIM 5989 and 5988, and then examines the
Service Registry Queries related list, at Discovery Definition > Port Probes, for the SLP query. The base
system provides this query is provided to detect the service:wbem service type, which indicates the presence of
an SLP server.
3. The Shazzam probe launches a scanner for the WBEM service type. The scanner retrieves:
The attributes of the service from the SLP server.
The interop namespaces [3] of CIM servers in the network.
4. The scanner appends the namespace values it finds to the port probe results.
5. The wbem port probe appends the SLP data it carries to the CIM Classify probe.
6. The CIM Classify probe uses that information to explore the CIM servers.
174
CIM Discovery
wbem Port Probe

The wbem probe stores the data it retrieves in the CIM Classification [discovery_classy_cim] table. The wbem port
probe is defined in Discovery Definition > Port Probes.
SLP Query
The SLP query detects the wbem service (service:wbem) on an SLP server and gathers the attributes of the service.
To access the SLP query:

1. Navigate to Discovery Definition > Port Probes'.
2. Select the wbem port probe record.
3. From the Service Registry Queries related list, select the SLP Query.
175
CIM Discovery
CIM Classify Probe

The wbem port probe appends the SLP data it carries to the CIM Classify probe before launching it. The CIM
Classify probe extracts VMware ESX serial numbers and connector relationships between the SAN and NAS
components from CIM Servers in the network.
To access the CIM Classify probe:

2. Select the CIM - Classify probe.
176
CIM Discovery
177
Enhancements
Eureka
Provides more efficient querying of SMI-S compliant storage devices using CimIQL queries.
References
[1] http:/ / www. snia. org/ tech_activities/ standards/ curr_standards/ smi
[2] http:/ / en. wikipedia. org/ wiki/ Service_Location_Protocol
[3] http:/ / sfdoccentral. symantec. com/ ccstor/ 5. 1. 1/ win_unix/ html/ cc_hscg/ apas01. htm
SQL Server Clusters

Overview
Discovery identifies Microsoft SQL Server instances that are part of a cluster in the CMDB by the cluster name
rather than as individual configuration items (CI). In previous versions, the CI record for the node (server) on which
the SQL Server instance was running displayed the classified process name of each SQL Server instance with a
relationship of Runs::Runs on. In the current version, an SQL Server instance is not listed as a related item in the CI
record for the server that hosts the instance if the instance is part of an SQL Server cluster. Only stand-alone SQL
Server instances (instances not joined to a cluster) appear as related items in CI records with the Runs::Runs on
relationship. For more information on CI relationships, see Defining CI Relationships.
Relationship of an SQL Server instance to a node
SQL Server Clusters
Viewing Relationships
By default, a CI record for a server (node) hosting an SQL Server instance that is part of a cluster does not display
the instance or the cluster as related items. To see the cluster information on a CI record, personalize the form and
add the Cluster Nodes related list. This list displays the name of the node and the parent cluster.
Click the cluster in the related list to drill into the CI record for that cluster. Individual SQL Server instances running
on that cluster are listed in the Related Items hierarchy. The names in the list contain the instance name prepended
to the cluster name with the @ symbol. In this example, DISCO is the instance name, and cluster2003 is the name
of the SQL Server cluster.
178
SQL Server Clusters
The CI record for an individual SQL Server instance uses the combined instance/cluster name and displays the
relationship hierarchy to the configured number of levels, including the application that uses the instance and the
cluster on which the application runs.
179
SQL Server Clusters
180
In the CI for an application that Depends on an SQL Server instance, the Related Items hierarchy also displays all
downstream relationships, including the instance on which the application depends, the cluster on which the instance
runs, and the server on which the application runs.
Defining Clusterable Processes

To define a Windows process as clusterable:
1. Open the desired process classifier (Discovery Definition > CI Classification > Process).
2. Add the Parameters related list (if not visible).
3. Click New in the Parameters related list and add a new parameter, using the following values:
Name: Unique name of your choosing.
Type: Enter Cluster.
Value: Enter the following statement.
resourceType: "Resource Type",
isMatch: function(process, resource) {
//javascript function that returns true if a resource matches the
classified process
}
Parameter
Description
resourceType Resource type the platform should look for in the cluster's Windows Cluster Resources related list.
isMatch
Determines if the cluster resource that is found, based on the type, is a match for the classified process being examined.
SQL Server Clusters
181
182
Discovery Behavior
Discovery Behavior
Overview
A Discovery Behavior determines what probes Shazzam launches and from which MID Servers these probes are
launched. Unlike a scan in which a single MID Server that performs all protocol scans on a designated IP address
range, network, or list, a behavior can assign different tasks to multiple MID Servers on the same IP address segment
or on different network segments. Behaviors are available in Discovery Schedules for discoveries in which
configuration items (CI) are updated in the CMDB.
Behaviors can be used in the following scenarios:
Load balancing: A behavior enables load balancing in systems that use multiple MID Servers deployed across
one or more domains.
Multiple protocols in multiple domains: Configure one MID Server to scan for all protocols on one domain and
another MID Server to perform a WMI scan on a second domain.
Access Control Lists (ACL): Discovery can scan SNMP devices protected by an ACL if the MID Server host
machine is granted access by that ACL. Use a behavior to configure a MID Server to scan devices protected by an
ACL.
Devices running two protocols: Some devices might have two protocols running at the same time. Examples of
this are the SSH and SNMP protocols running concurrently on one device (most common). A behavior can
control which of the two protocols is explored for certain devices. The behavior then prevents the other protocol
from being explored.
Creating a Behavior
To create a behavior, navigate to Discovery Definition > Behavior and click 'New. The Behavior form provides the
following unique fields:
Field
Input Value
Name
Type a unique name that describes the use for this behavior, such as Two Domains or Load Balance.
Discovery
Functionality
Select the MID Servers to use for this behavior, the desired execution phase, and the pre-configured functionality for each
MID Server (protocols to scan).
The completed Discovery Behavior form looks like this:
Discovery Behavior
183
Discovery Functionality
Discovery Functionality defines what each MID Server in this behavior must do, specifically which protocols to
detect. This form provides the following unique fields:
Field
Input Value
Phase
A phase is an arbitrary integer used to group one or more functionalities together. All the functionalities within a phase are
executed together, and all phases are executed in numerical order. All functionalities in a behavior can have the same phase. The
Shazzam probe runs once for each phase in a behavior, which makes fewer phases desirable. Run multiple phases for behaviors
only when devices in the network are running multiple protocols (e.g. SSH and SNMP). In this example, set one phase for the SSH
scan and another phase for the SNMP scan.
Functionality
Select a pre-configured functionality that defines the protocol or list of protocols that each MID Server will scan. Access the
Functionality Definition records through the Functionality link in the Discovery Behavior form or by navigating to Discovery
Definitions > Functionality Definition.
MID Servers
Select one or more MID Servers to perform this functionality for the following Discovery types:
IP Scan
CI Scan
Discovery automatically balances the load when multiple MID Servers are selected.
Functionality
Criteria
Define criteria here for Windows MID Servers. See the following section for details.
Functionality Criteria
Functionality Criteria are required for Windows MID Servers only, and only when the behavior controls Discovery
across multiple domains. When the instance launches the Shazzam probe for a Discovery in which a behavior
defines multiple MID Servers to scan multiple domains, the Functionality Criteria determine which MID Server will
process the results of the probe.
The form provides the following unique fields:
Field Input Value
Name The name in the criteria is the variable that passes the following information:
mid_server: MID Server that processes the results from the Shazzam probe.
win_domain: Windows domain of the target device.
Value Enter the actual name of the MID Server (mid_server) or domain (win_domain) to pass to Discovery for this criteria. This field can also
have a value of mid_domain, which defines the Windows domain of the MID Server that is processing the Shazzam results.
The completed criteria form looks like this:
Discovery Behavior - Load Balancing

Overview
ServiceNow behaviors enable load balancing when multiple MID Servers are configured to scan the same protocol.
For example, an organization has fifty remote locations, varying in size from 10 devices to several hundred devices.
All the satellite offices are part of the same Windows domain, which is administered from a central location. There
are three MID Servers installed at this central location: two to scan all the Windows devices and one to scan the
remaining devices. Because some of the remote offices are in different time zones, different schedules must be
created to run Discovery at off-peak hours in each time zone. The same behavior can be used for each schedule, and
the behavior will load-balance the two Windows MID Servers automatically.
Step 1: Create the Behavior Record

Create a new Discovery Behavior record, and name it something descriptive, such as LoadBalanced. Right-click
in the header bar and select Save from the pop-up menu. This action saves the record and creates the Discovery
Functionality Related List in the form.
Step 2: Define the Windows Functionality

1. Click New in the the Discovery Functionality Related List.
2. Create a new record using the fields described here.
3. Right-click in the header bar and select Save from the pop-up menu.
Field
Input Value
Phase
Type a phase number of 1 in this field.
Functionality Select Windows only (WMI) from the list. This functionality defines the protocol that will be scanned. Because we selected to scan
WMI, we must select Windows MID Servers for this functionality.
MID Servers
We select the two MID Servers that we want to share the load for the WMI probes. By entering multiple MID Servers in this field,
we tell Discovery to balance the load between these servers automatically. If we were to create separate functionality for each server,
load balancing would not occur.
Active
Make sure this check box is selected to enable this behavior.
Match
criteria
Leave the default criteria of Any.
184
Step 3: Create Functionality Criteria

All Windows functionality requires criteria to identify the Windows domain and define any special behavior for the
MID Servers named. To create Functionality Criteria, click New in the Related List and enter the following values:
Field
Input Value
Name
We enter win_domain to name the Windows domain that Discovery will scan with the MID Servers we have defined.
Operator Select equals as the operator in this criteria.

Value
This is the name of the Windows domain that these MID Servers will scan for devices.
Active
Be sure to enable the criteria by selecting this check box (true).
The completed criteria appear in the Discovery Functionality form for the Windows MID Servers.
Step 4: Define the Functionality for the Remaining Scans

Create a second record to scan for all the remaining protocols (SSH, SNMP, etc), using the following settings:
Field
Input Value
Phase
Type a phase number of 1 in this field. This phase will be executed at the same time as the WMI scans and with the same Shazzam
probe. We use the same phase number for efficiency and because we know that none of the devices in the target IP ranges are
running multiple protocols (e.g. SSH and SNMP). If any devices were running multiple protocols, we would want to specify a
second or even a third phase to discover the correct protocol first for each device.
Functionality Select All except windows (no WMI) from the list. This functionality causes the MID Server to scan all remaining protocols after
Discovery has run the WMI scans.
MID Servers Name the MID Server that will scan for all other devices. If we want to use automatic load balancing, we can add an additional MID
Server to this field.
The completed Discovery Behavior form looks like this. It is not necessary to create Functionality Criteria for this
MID Server.
185
Step 5: Create the Schedules

Create a Discovery Schedule record for each different time zone, and name the behavior we just created. See
Discovery Schedules for details.
1. Navigate to Discovery > Discovery Schedules and click New in the record list.
2. Select a Discover type of Configuration items.
This action displays the Behavior field.
3. Click the magnifier icon and select the behavior to use.
4.
5.
6.
7.
In our example, we select LoadBalanced.

Select the appropriate time to run Discovery for this location.
Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this location.
Save the record.
Create additional schedules for each time zone or region in the network and select the same behavior.
186
Discovery Behavior - Multiple Domains

Overview
ServiceNow Behaviors enable the efficient Discovery of SSH and SNMP devices and WMI devices running on
multiple Windows domains, using multiple MID Servers. For example, an organization has two Windows domains
in its network and a variety of UNIX computers and SNMP devices. The challenge is to discover all the devices
efficiently, without duplicating effort. Each domain contains a Windows MID Server which is used to scan the IP
addresses from the two domains specified in the Discovery Schedule, as well as the SSH and SNMP devices. We
need a Behavior that divides the work appropriately to avoid scanning anything twice. In this example, we assume
that both domains are in the same geographical location, and that a single schedule is sufficient.
Note: The preferred method for running Discovery over multiple Windows domains is to use PowerShell, which allows a single MID
Server to authenticate on machines on different domains using credentials stored on the instance.
Step 1: Enable NetBios

Enable WINS/NetBIOS/port 137 on the MID Server machine so it can authenticate on other machines in the
domain.

Create a new Discovery Behavior record and give it a descriptive name. Right-click in the header bar and select Save
from the pop-up menu. This action saves the record and creates the Discovery Functionality Related List in the
form.
To complete this behavior (as shown here) we must create functionalities. For the functionalities that scan for the
WMI protocol, we must define criteria that specify the Windows domain being scanned and the MID Server
responsible.
187
Step 3: Define the Functionalities

We will create three functionalities for this Behavior: one MID Server to scan Domain A for Windows devices only;
a second functionality for the same MID Server to scan for all SSH and SNMP devices; and a third functionality that
names a second MID Server to scan Domain B for Windows devices. The rationale for this is as follows:
A Windows MID Server can only discover Windows machines on the Windows domain to which it is joined.
This is entirely due to the way Windows authentication works. For this reason, we need a WMI functionality for
each domain.
A Windows MID Server, provided with the correct credentials, can discover SSH and SNMP devices anywhere;
however, we cannot combine WMI, SSH, and SNMP functionalities across Windows domains. This is because
the functionality criteria for the WMI scans locks in the Discovery to one specific domain. For this reason, SSH
and SNMP discoveries require a separate functionality.
We want to scan each machine only once.
Click New in the the Discovery Functionality Related List to add functionalities.
Functionality 1: WMI Scanning on Domain A

We configure a MID Server to scan for the WMI protocol on Domain A. WMI scans authenticate on Windows
machines using the domain credentials of the Windows MID Server machine. Windows MID Servers cannot scan for
the WMI protocol outside their own domains.
Create the first functionality using the following values:
Field
Input Value
Phase
Type a phase number of 1 in this field. All functionalities in this example use the same phase number, which launches a single
Shazzam probe for all the functionalities in that phase. A single phase, when feasible, is the most efficient use of the Shazzam probe.
Functionality Select Windows, DNS, and WINS from the list. This functionality defines the WMI protocol that will be scanned and resolves the
domain. Because we selected to scan for WMI, we must select a Windows MID Server for this functionality.
MID Servers
We select a Windows MID Server from Domain A - in this case sandb01-358.
Active
Match
criteria
Change the criteria to All.
Create Functionality Criteria

All Windows functionality requires criteria to identify the domain and the MID Server. In our example, we will
create two criteria for this functionality. To create Functionality Criteria, click New in the Related List and enter the
following values for the MID Server doing the WMI scanning on Domain A:
188
Field
Input Value
Name
Create the following criteria:
Enter mid_server to name the MID Server that will execute the WMI scans on Domain A.
Enter win_domain to name the Windows domain that Discovery will scan with the MID Server defined.

Value
For the mid_server value, enter the name of the MID Server that will scan Domain A for Windows devices.
For the win_domain value, enter the name of Domain A that this MID Server will scan for Windows devices.
Active
The completed criteria appear in the Discovery Functionality form for this behavior.
Functionality 2: SSH and SNMP

In our network, we want to scan for UNIX computers and netgear, but we don't want to classify these devices twice.
One of our MID Servers will be configured to classify SSH and SNMP using a different functionality than it does for
WMI scans. We do not need to create criteria for non-WMI functionality.
Create the second functionality using the following values:
Field
Input Value
Phase
Functionality Select All except Windows (no WMI) from the list. This functionality will scan SSH and SNMP protocols only.
MID Servers
We select the MID Server from Domain A - in this case sandb01-358.
Active
Match
criteria
Leave the default criteria of Any. Criteria are not used for non-WMI functionalities.
189
Functionality 3: WMI Scanning on Domain B

All that remains is to create a functionality for the WMI scans on Domain B. Because of the Windows authentication
mechanism, we must configure a Windows MID Server to scan Domain B that is a member of that domain.
Create the third functionality using the following values:
Field
Input Value
Phase
Functionality Select Windows, DNS, and WINS from the list. This functionality defines the WMI protocol that will be scanned and resolves the
domain. Because we selected to scan for WMI, we must select a Windows MID Server for this functionality.
MID Servers
We select a Windows MID Server from Domain B - in this case disco-win2003.
Active
Match
criteria

All Windows functionality requires criteria to identify the Windows domain and the MID Server. In our example,
we will create two criteria for this functionality. To create Functionality Criteria, click New in the Related List and
enter the following values for the MID Server doing the WMI scanning on Domain B:
Field
Input Value
Name
Enter mid_server to name the MID Server that will execute the WMI scans on Domain B.

Value
For the mid_server value, enter the name of the MID Server that will scan Domain B for Windows devices.
For the win_domain value, enter the name of Domain B that this MID Server will scan for Windows devices.
Active
The completed criteria appear in the Discovery Functionality form for this behavior.
190
Step 4: Create the Schedule

Create a Discovery Schedule record and name the behavior we just created. See Discovery Schedules for details.
2. Select a Discover mode of Configuration items.
4.
5.
6.
7.
In our example, we select Southwest-SNMP.

Select the appropriate time to run Discovery for this location.
Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this location.
Save the record.
Create an additional schedule if more than one time zone is involved.
191
Discovery Behavior - Access Control Lists (ACL)

Overview
A specific type of Access Control List (ACL) on an SNMP device can prevent Discovery from identifying that
device. This list defines host machines by IP addresses that are permitted to run agents on SNMP devices. In this
example, we want to classify, identify, and update all the devices in an IP range, including the SNMP devices
protected by an ACL. To do this, we must install a MID Server with access to the protected SNMP devices and then
create a Behavior that allows us to scan for all protocols without missing any devices or doing any extra work.
Note: See the instructions for earlier versions of ServiceNow, in Legacy:Discovery Behavior for ACLs
Step 1: Install a MID Server on a Host Permitted by the ACL

To scan the SNMP devices in a network protected by an ACL, a MID Server must be installed on a host machine
specified by IP address in the ACL as having access to the SNMP devices. Because this MID Server is scanning
SNMP devices only, it can be installed on any supported operating system. The other MID Server, configured to
discover WMI and SSH, can be installed on any Windows host that has visibility to the specified IP ranges. Install
additional MID Servers if you intend to configure either functionality to load balance.

Create a new Discovery Behavior record, and name it something descriptive, such as Southwest-SNMP. Right-click
in the header bar and select Save from the pop-up menu. This action saves the record and creates the Discovery
Functionality Related List in the form.
To complete this behavior (as shown below) we must create functionalities using the MID Servers we installed for
that purpose. For the functionality that scans for the WMI protocol, we must define criteria that specify the Windows
domain and MID Server being used. Because this Discovery is being performed on one Windows domain, we can
configure a functionality for WMI and SSH (All except SNMP) using the same MID Server.
192
Step 3: Define the Functionalities

For this behavior, we create two functionalities, one for SNMP on the MID Server installed on the host specified in
the ACL and another for WMI and SSH on a second MID Server.
Click New in the the Discovery Functionality Related List to add functionalities.
Functionality 1: SNMP Protocol

We configure the MID Server installed on the privileged host machine to scan for the SNMP protocol only.
Create the first functionality using the following values:
Field
Input Value
Phase
Type a phase number of 1 in this field. Both functionalities in this example use the same phase number, which launches a single
Functionality Select SNMP only from the list. This functionality defines the protocol that will be scanned.
MID Servers
We select a MID Server (sansol02_Solaris) installed on a Solaris host that is granted access to the SNMP devices by the ACL. You
can select multiple MID Servers if you want Discovery to load balance this functionality automatically.
Active
Match
criteria
Leave the default criteria of Any. Criteria are not used for SNMP functionalities.
Functionality 2: WMI and SSH Protocols

In the second functionality, Discovery will scan our domain for WMI and SSH protocols. Because WMI is one of the
protocols, the MID Server for this functionality must be installed on a Windows machine and must have criteria.
Create the second functionality using the following values:
Field
Input Value
Phase
Shazzam probe for all protocol scans. A single phase, when feasible, is the most efficient use of the Shazzam probe.
Functionality Select All except SNMP from the list. This functionality defines the protocols for which scanning will occur. Because WMI is one
of the protocols selected, we must use a Windows MID Server for this functionality.
MID Servers
We select a Windows MID Server from our domain. In this case we select disco-win2003. You can select multiple MID Servers if
you want Discovery to load balance this functionality automatically.
Active
Match
criteria
193

Functionalities that scan for WMI require criteria to identify the domain and the MID Server. In our example, we
will create two criterias for this functionality. To create Functionality Criteria, click New in the Related List and
enter the following values for the MID Server doing the WMI scanning on our domain:
Field
Input Value
Name
Enter mid_server to name the MID Server that will execute the WMI scans.

Value
For the mid_server value, enter the name of the MID Server that will scan our domain for Windows devices.
For the win_domain value, enter the name of our Windows domain.
Active
The completed criteria appear as follows in the Discovery Functionality form for this behavior.
Step 4: Create the Schedule

Create a Discovery Schedule record and name the behavior we just created. See Discovery Schedules for details.
2. Select a Discover mode of Configuration items.
In our example, we select Southwest-SNMP.
4. Select the appropriate time to run Discovery for this location.
5. Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this domain.
6. Save the record.
194
195
196
FAQ
Discovery FAQ
General Topics
What technologies are used for Discovery?
Discovery is deployed in an agentless framework and uses Internet Protocols to probe the network.
SNMP - machine specific information

SSH - Linux and UNIX logins for in depth scans
WMI - Windows discovery
Powershell - Windows discovery
DNS/WINS IP Resolution
VMware API - VMware/ESX discovery
What are credentials, and what kind do you need?

Credentials are generally a user/password used to authorize use of a system. For discovery purposes, the following
types of credentials are required:
user / password or preshared key - for UNIX and Linux systems
domain authorization - authorizing WMI for Windows systems
community strings - for SNMP
What will be created with no credentials, no login, no SNMP?

Nothing can be created without these elements. However, if Discovery finds an IP address that is partially
responsive, Discovery logs the device for additional exploration.
What will you find in UNIX Discovery?

Very detailed and deep information about the OS, the hardware, network, disk, and application configurations. See
Data Collected by Discovery for details.
What detail will you get with Windows WMI?

Very detailed and deep information about the OS, the hardware, network, disk, and application configurations.
Discovery FAQ
Can you discover multi-core processors on UNIX and Windows?

Yes, we detect the number of cores for UNIX, Linux, Windows environments.
Can you discover Web / Application Servers without specific credentials?

Yes. We can discover the presence of a Web Server through a running process classifier. The Web Server will be
identified by vendor and make (Apache, Tomcat, BEA WebLogic, IBM Websphere, JBoss, Microsoft IIS, etc.) and
the database connections used.
What will you discover about Web Servers with specific credentials?
The applications installed and the database connections used.
Can you identify patches and packages?

Yes. Packages and patches are identified for Solaris, Linux, and Windows.
How does application mapping work?

By finding the relationships between different running processes, such as Web Servers, application servers, and
databases. In a typical scenario, Discovery determines that an application starting at an Apache HTTP server may
contact one or more application servers that are running particular J2EE applications that connect to one or more
databases.
The output of the mapping is a dependency map of the discovered pieces which is easily viewed graphically using
our Business Service Visualizer.
Can you import Discovery data?

Yes. For example, you may want to import a list of IP addresses in host file format to start the discovery process on a
set of known machines. The system is very agile at importing, exporting, and synchronizing (federating) data.
Does your Discovery run agentless or require an agent on every machine?

Agentless is the simple answer.
Do you discover Solaris Zones?

Yes. Using standard Sun Utility Tools for Management of Solaris Containers.
Do you discover Virtual Machines?

Yes. Using management instrumentation provided by VMware, including the vCenter API on Windows hosts.
197
Discovery FAQ
Which commands are used by Discovery on UNIX and Linux?

In general, we use simple commands like ps, df, sh, uname, etc. All the commands can be seen in the Probes section
of the Discovery application.
Which WMI queries are performed?

The WMI queries are in the database through the Probe Parameter for the WMIProbe. Many parameters are obtained
from the Win32_ComputerSystem object, among others.
What access level do you need to run discovery on Linux / UNIX?

For most items, non-root. For application dependency mapping, sudo, or limited root privilege.
What kind of built-in reporting capabilities do you provide?

The system has an easy to use, yet powerful and comprehensive reporting package. The reporting is very interactive,
with drill downs, grouping, sorting, filtering, and aggregation all under the end users control.
We supply a number of reports to help get insight to the discovered CMDB.
How can you see the file path that Windows uses to uninstall software?
Discovery detects and displays the paths that Windows uses to uninstall software with the Add or Remove
Programs utility. To see uninstallation paths, open a Windows Server configuration item (CI) record. All available
paths are shown in the Uninstall string column in the Software Installed Related List.
Software License Management / Compliance

How can you help with license management for application servers such as Websphere and
WebLogic?
Discovery will tell you how many instances of the application servers are running, what applications are installed
(PKGAdd, RPM or MSI installer).
How can you help with license management for databases such as Oracle, SQL Server,
Sybase, others?
Discovery can show the databases / table spaces installed and track the IP address that connect to the database engine
to try and help with CAL type licensing. See Software License Management for details on software licensing.
Can Discovery help with license management of Microsoft desktop applications?

Yes. After discovering installed software (Operating System and applications) entries are recorded in the CMDB and
also the Microsoft License section of the product's Asset Management application.
The licensing also includes special identifications required by vendors (OEM versus Retail for Microsoft), counting
for Symantec and Adobe, etc.
198
Discovery FAQ
MID Server (Monitoring, Integration, Discovery)

What is this MID Server?
It is a small Java process that runs the probes for the discovery.
Do you provide an appliance or do I need my own hardware for the MID server?
You use your standard hardware (including virtual machines). There is no need to introduce a foreign appliance with
it's requisite security / backup / DR issues.
How does Discovery scale in an environment with tens or even hundreds of thousands of
devices?
Multiple MID servers deployed in different network segments and/or geographically will provide virtually unlimited
scalability. MID servers are capable of handling multiple thousands of devices each.
What OS does the MID server require?

UNIX, Linux, or Windows.
What are the resource requirements (network and CPU) during the discovery?
Resource consumption is remarkably low, see MID Server Requirements for details.
How are the MID servers administered?

All administration (with the exception of the installation) is handled centrally from your instance. Configuration of
IP ranges, credentials, schedules for discovery are all in a web-based UI.
Security
How are the credentials secured?
They are stored in the database using 3DES encryption.
How are the credentials transported to the MID server?

Using HTTPS (SSL) to transport all data encrypted. Once at the MID server, the standard encryption capabilities of
SSH and WMI are used.
Firewall, TCP Planning Information

What ports are used for Discovery on UNIX and Linux?
Connection is made using the standard SSH port 22.
What port numbers are used in Windows Discovery?

Discovery detects activity on port 135 on Windows machines, and then launches a WMI query. The response from
the Windows device is sent over a Distributed Component Object Model (DCOM) port configured for WMI on
Windows machines. This can be any port.
199
Discovery FAQ
Customization and Integration

Can we customize the Discovery commands, and on what level can we customize them?
Yes. The entire set of Discovery commands is centrally administered in the database and can freely be altered, added
to, or removed.
Can the Data Model (database definition) be extended?

Yes. Fields, tables, and relationship descriptions can all be customized. There are no limitations.
Can you integrate with other CMDB technologies such as Atrium or AssetCenter?
Yes. This is something we do very well. Through web services, bi-directional integration can be created. We also
have standard integrations to many other popular systems such as HP OpenView, HP / Mercury MAM, IBM Tivoli,
Microsoft SMS, LanDesk, Oracle Financials, Altiris.
Is it possible to have specific Discovery configurations for a group of computers?

Yes.
Can we specify which ports are scanned / probed?

Yes. The PortProbe definition permits a parameter "ports" to limit scope. As an example, you could specify ports =
22,80,135.
Can we use an alternate SSH tool?

Yes. It is possible to write probes in languages such as PERL, JavaScript, or BASH that use any tool you choose.
Can Discovery commands be run independently (without sensor reaction)?

Only in Orchestration. Define a Probe with either no Sensor or a special sensor that does not schedule further Probes.
Is it possible to automate the discovery tasks with 3rd party tools?

Yes. There are two possibilities:
Use web services to schedule IP ranges to be discovered.
Use special Probes and Sensors (written in PERL and JavaScript for example).
200
201
Reference
Discovery Bandwidth
Functionality described here requires the Discovery plugin.
Overview
The graph is in Bytes per second. It had a capture filter of (MIDservicenow01 or MIDservicenow02).
The Black line is the traffic to the Bluecoat, i.e ServiceNow.
The Red line represents New York.
The Green line represents L.A.
The traffic appears to be as follows - idle scanning for a site: typically not more than 320Kb/second (about 20 to
40KB/sec max), spiking very briefly to 1.6Mb/sec.
Bluecoat traffic for these servers looks to be 480Kb/sec.
Discovery Resource Utilization
Discovery Resource Utilization

Windows
Typical Windows transactions will generate on the average of 1.5 to 5 Mb of traffic for each client successfully
discovered. This number is dependant on the computer being discovered with Desktops being on the low end to
fully loaded servers providing multiple applications and services to other hosts on the other.
UNIX - SSH
Typical SSH network traffic sizes are around 6k (kilobytes) plus commands being executed
Initial TCP connection handshake (~300 bytes)

SSH initialization, key exchange and authentication (~5k)
SSH commands/output from commands (Data is compressed)
SSH/TCP connection teardown (~300 bytes)
For example, If executing dmidecode and it's output is 12k of data, the total network transfer would be ~18k.
Lets run through a scenario. Host is RedHat Linux ES3 with a 2.4.21-53.EL kernel. SSH commands used for
Discovery:
/bin/uname (80 bytes)

/proc/meminfo (780 bytes)
/proc/cpuinfo (420 bytes)
/bin/ps (8k)
/usr/sbin/dmidecode (12k)
/sbin/ifconfig (860 bytes)
/usr/sbin/lsof (18k)
Command Output total: 40k
SSH Communication total: 42k (7 commands * 6k traffic size)
Total: 82k
To get the base information from a Linux host, it uses about 82k of traffic per Discovery of the host.
Sample Bandwidth Graph

This graph shows the bandwidth consumption of a typical Discovery by operating system.
202
Application Dependency Mapping
203

Overview
Application dependency mapping (ADM) creates relationships between interdependent applications. ADM
identifies:
Which devices are communicating with one another.
Which TCP ports they are communicating on.
Which processes are running on these devices.
For example, if a web server application uses a database server application, the web server "depends on" the
database. The web server also "runs on" the host or server cluster. You can use the data from running processes to
determine which devices to drill into to see more application-specific configuration data.
Requirements
Your instance must meet the following requirements to use application dependency mapping.
ADM system properties are enabled
ADM probes are configured
Process classifications are configured
Windows 2000 Server Requirements

The Windows - Active Connections probe associates running processes on Windows machines with the ports on
which they communicate, using the netstat [1] command. Windows 2000 Server and Windows workstations, in their
default configuration, cannot associate process IDs with ports using the netstat command. This prevents Discovery
from providing application mapping on these machines. To enable a Windows 2000 Server or workstation to support
process-to-port connections in the ServiceNow system, apply this Microsoft hotfix [2]. This hotfix enables these
Windows machines to support the -o parameter of the netstat command, which enables Discovery to associate
processes with TCP/IP connections.
System Properties
Property
Description
glide.discovery.application_mapping Enables or disables the ADM feature.
glide.discovery.auto_adm
Type: string
Default value: true
Automatically creates process classifiers for application dependency mapping. When Discovery detects
processes that are communicating over the network, "Pending Process" classifiers are automatically
generated.
Type: string
204
Probes and Sensors

ADM uses the following probes and sensors to explore applications and determine their relationships.
ADM Probes
ADM uses the following probes (starting with the Dublin release).
Name
AIX ADM
Probe
Type
Multiprobe
Description
Queries for information about active (running) AIX processes and active connections - the
information required to perform application dependency mapping.
Includes Probes
HP-UX ADM
Solaris ADM
Unix ADM
Multiprobe
Multiprobe
Multiprobe
Queries for information about active (running) HP-UX processes and active connections - the
information required to perform application dependency mapping. This probe requires that lsof
be installed and the Unix - Active Connections probe be activated, which is inactive by default.
Queries for information about active (running) Solaris processes and active connections - the
information required to perform application dependency mapping. This probe requires that lsof
be installed.
Queries for information about active (running) Unix processes and active connections - the
Windows ADM
Multiprobe
Queries for information about active (running) Windows processes and active connections - the
Versions prior to Dublin

ADM uses the following probes for Calgary and earlier releases.
Name
Probe Type Description
Unix - Active Connections
Probe
Retrieve active connections infomation
Unix - Active Processes
Probe
Get active (running) processes
Windows - Active Connections Probe
Retrieve active connections infomation
Windows - Active Processes
Get active (running) processes
Probe
ADM Sensors
ADM uses the following sensors (starting with the Dublin release).
AIX - Active
Connections
AIX - Active
Processes
Unix - Active
Connections
HP-UX - Active
Processes
Unix - Active
Connections
Solaris - Active
Processes
Unix - Active
Connections
Unix - Active
Processes
Windows - Active
Connections
Windows - Active
Processes
Name
AIX - ADM
Sensor
Type
Javascript
205
Description
Responds to Probes
Updates the running processes and active connections, and runs application dependency
mapping.
HP-UX ADM
Javascript
Updates the running HP-UX processes and active connections, and runs application
dependency mapping. This sensor requires that lsof be installed.
Solaris ADM
Javascript
Updates the running Solaris processes and active connections, and runs application
dependency mapping. This sensor requires that lsof be installed.
Unix - ADM
Javascript
Updates the running Unix processes and active connections, and runs application
dependency mapping.
Windows ADM
Javascript
Updates the running Windows processes and active connections, and runs application
dependency mapping.
Unix - Active
Connections
AIX - Active
Processes
Unix - Active
Connections
HP-UX - Active
Processes
Unix - Active
Connections
Solaris - Active
Processes
Unix - Active
Connections
Unix - Active
Processes
Windows - Active
Connections
Windows - Active
Processes
Versions prior to Dublin

ADM uses separate sensors running asynchronously to each other. Since ADM
requires information from both sensors, ADM runs twice, once after each sensor
runs (Calgary and earlier releases).
Name
Sensor Type Description
Unix - Active Connections
Javascript
Determine process connections
Unix - Active Processes
Javascript
Determine running processes
Windows - Active Connections Javascript
Process active connections
Windows - Active Processes
Process running processes
Javascript
Application Relationships
Discovery maps application data automatically into upstream and downstream relationships, using the following
types:
Runs on::Runs
Depends on::Used by
Hosted on::Hosts
Virtualized by::Virtualizes
IP Connection::IP Connection
Note: For information on how Discovery classifies processes and establishes relationship types, see Process Classifications.
Accessing Dependency Maps

1. Navigate to Configuration and select a CI class (such as Servers, Database Servers, or Database Instances).
2. Select a specific CI from the list.
3. In the CI record, click the map icon in the Related Items header bar.
4. In the dependency map that appears, right-click on the arrow connectors between CIs to display the relationship
type.
Upstream and Downstream Relationships

In upstream and downstream relationships anything that happens downstream can have an adverse affect on
upstream configuration items. In our example relationship, if the virtual server sannnm-01 crashes, the database
instances and the web server upstream are adversely affected. Likewise, if the web server fails, the web site hosted
on it goes down. The CI record for the virtualized Windows server sannnm-01 with its upstream and downstream
relationships is shown below. The downstream relationships show that this server is virtualized by VMware running
on a Windows server named sandb01. Our upstream relationships show a MySQL instance, a SQL instance, and a
web server running on sannnm-01. Farther upstream, a web site is hosted on the web server.
206
Deleting CIs
When you delete a CI from the CMDB, ServiceNow also deletes all relationships with that CI. The cascade delete
feature that deleted upstream CIs was removed from the system starting with the Calgary release.
Cascade Delete in Versions Prior to Calgary

When CIs are deleted from the CMDB, upstream CIs with relationship types of Hosted on and Runs on are also
deleted. This cascade delete feature is intended to remove applications from the CMDB that have a one-to-one
relationship with the adjacent downstream CI. In our example, VMware runs on the sandb01 server in a one-to-one
relationship and is deleted when the host machine is deleted. However, the sannnm-01 server is virtualized on the
VMware CI in a potential one-to-many relationship and is not deleted when sandb01 is deleted.
If the virtual server sannnm-01 is deleted, then so are the upstream CIs that have a one-to-one relationship with the
server. In our example, the MySQL instance, the web server and the SQL instance are all deleted, as is the web site
hosted by the web server.
207
Application Dependencies
This screenshot shows the application dependencies between three different JBoss application servers and the local
Apache web site. In this example, the three JBoss application servers on three different physical machines have a
TCP connection to the local Apache application on www.online1.com. Additionally, there are 5 Apache web servers
using the local JBoss application.
Adding CI Relationships
Discovery automatically maps the dependencies between CIs that it finds in the network and assigns the appropriate
type to each relationship. ServiceNow configuration enables administrators to add dependencies manually and to
define the appropriate relationship type between new configuration items based on lists of suggested relationships.
The best practice when adding application dependencies to a configuration item is to avoid the use of the Runs
on/Runs and Hosted on/Hosts types. When a configuration item is deleted, any upstream CIs with a relationship
type of Runs on or Hosted on is deleted as well. In some cases, manually added CIs might have other important
dependencies that are adversely affected by the cascade deletion triggered by these two relationship types.
To add a dependency:
1. In a CI record, click the + icon in the Related Items toolbar.
2. Select the appropriate relationship type from the list at the top of the page.
208
3. Create and run an appropriate filter to make the CI visible in the list of available CIs.
4. Move the CI from the list of available CIs to the dependent list.
5. Click Apply to.
Example
An example of the importance of selecting the proper relationship type is when the Business Service dependency,
PeopleSoft CRM, is added to the sannnm-01 virtual server in the following diagram. If PeopleSoft CRM is added
with a relationship type of Depends on, it is protected from the cascade delete triggered by the deletion of the
Windows server sannnm-01. This is important because PeopleSoft CRM has dependencies to other servers and must
not be deleted.
209
210
Automatically Classified Applications

If the glide.discovery.auto_adm system property is enabled, Discovery automatically creates a classification record
for processes that connect to or listen on a TCP port. In addition, the application dependency map displays the
relationships between the communicating process and other CIs. Discovery administrators can view automatically
classified processes from:
The related item list of a CI that has a relationship to the automatically classified process
The classification definitions available from the Pending Process module.
Automatically classified applications are available starting with the Dublin release.
Viewing Automatically Created Processes from the CI Related List

The application dependency map lists processes that it finds communicating with other devices or processes as
automatically discovered applications. These applications have a Runs - Pending Applications relationship in the
CI's application dependency map.
1. Navigate to Configuration and select the CI type you want to view. For example, Servers > Linux.
2. Select the CI whose relationships you want to view.
The Related Items section displays the relationships the CI has to other CIs.
3. Look for the relationship Runs - Pending Applications. For example, this Linux Server has several unclassified
processes that run on it.
4. Click the application dependency map icon.
Each automatically-generated
conventions:
process
follows
these
naming
The name starts with the Process prefix.

The name indicates whether the process is listening on or
connecting to a TCP port.
The name indicates the TCP port the process listens on or connects
to.
Processes with a Runs - Pending Applications
relationship
The name includes the name of the host running the process ater the
at (@) symbol.
211
Pending Process Classifiers

Pending process classifiers identify interdependent processes, based on TCP connections, that are not classified by
the system-provided process classifiers, such as database or web servers, or even proprietary applications. They can
be refined as needed to properly identify the same processes in future discoveries, or be used to simply ignore those
processes altogether.
Pending Process Classifier
Pending process classifiers are initially

denoted by a name starting with
"Pending:" and use the underlying
running process name, command, and
parameters as matching conditions. A
running process matching the given
conditions also creates a record in the
Pending
Application
[cmdb_ci_appl_pending] table and
uses the Runs on::Runs relationship to
associate it with the appropriate
computer CI. They can be refined as
needed and used to classify desired
processes or to define processes that
should simply be ignored.
Pending process classifiers are available starting with the Dublin release.
Converting a Pending Process Classifier Into a Conventional Process

Classifier
If a process should have its own conventional classifier, a few updates may be useful for properly creating discovery
data. First, determine if the given process or application is represented by an existing CI table. If such a table does
exist, it can simply be selected for the Table field in the process classifier. If a suitable table does not exist, a new
one can first be created (see Creating a Table Using the Application Instance Table below). Additionally, the
classifier name can be changed to give it meaning specific to the given process or application, and the condition
(especially Name, Command, and Key parameters) can be refined to provide better matching characteristics. For
more information, see Process Classifications.
Creating a "No classify" Process Handler

A "No classify" process handler prevents future discoveries from classifying matching processes, and also prevents
creation of new Pending Process Classifiers and Pending Applications for that process. It does this by creating a new
Process Handler with the Classify field set to false, using the same conditions as the given Process Classifier. To
create a "No classify" process handler:
1. Under Related Links, click Create "No classify" process handler.
2. Click Yes in the Confirm pop-up box.
212
Creating a Table Using

the Application Instance
Table
Create "No classify" process handler
A new application instance table, with

a classifier name suitable to the
process or application, can be created
by extending the Application instance
table [cmdb_ci_appl] if a suitable table
does not exist. The new table is used
both for the classifier and any related
applications. To create a table using the application instance table:

1. Under Related Links, click Create, use application instance table.
2. In the Name field, enter a name for the table, where the name you provide will be appended to u_cmdb_ci_appl_
to form the table name. You can provide up to 15 letters and underscores.
3. In the Label field, enter a label for the new table.
4. Click Yes in the Confirm pop-up box.
Deleting Application
Instances
Deleting application instances deletes
all application records that reference
the given classifier. The classifier is
also deleted. To delete the application
instance:
1. Under Related Links, click Delete
application instance.
2. Click Yes in the Confirm popup
box.
Create new table using the Application Instance table
Creating Pending
Processes Classifiers for
Local Connections
Delete instances created by the classifier
By default, Discovery does not create

pending process classifier records for
processes that communicate with one
another on the same host (starting with
Eureka release). For example, if
Discovery finds process A connecting
213
to a port on the local host and another process B listening on the same port of the same local host, these two
processes are considered a local connection.
To have Discovery create pending process classifiers for local connections:
1. Navigate to Discovery > Properties.
2. For Map local connections for pending process classifier, select Yes.
3. Click Save.
Discovery property to map local connections
Note: This property only affects pending process classifiers. Discovery always applies existing process classifications if their
triggering conditions are met.
Enhancements
Eureka
Allows Discovery administrators the option to create pending process classifiers for processes communicating on
the same host.
Dublin
Creates pending process classifiers for processes found connecting to and listening on communications ports.
Uses new probes and sensors to explore applications and determine their relationships.
Displays relationships for automatically classified applications in the application dependency map.
References
[1] http:/ / technet. microsoft. com/ en-us/ library/ bb490947. aspx
[2] http:/ / support. microsoft. com/ hotfix/ KBHotfix. aspx?kbnum=907980& kbln=en-us
VMware Component Relationships

Overview
ServiceNow supports the use of virtual machines generated by the VMware application, installed on Windows,
Linux, or ESX Servers. The ServiceNow Discovery product can extract information from VMware configuration
items (CI), including their relationships. Discovery is configured to work with the Orchestration VMware Support
Plugin, which enables the automatic cloning of virtual machines by an ESX Server managed by vCenter. For
information about data collected by Discovery on vCenter, see Discovery for VMware vCenter.
VMware Architecture
ServiceNow supports two basic types of VMware deployment using the VMware application:
VMware installed on an ESX Server, managed by vCenter.
VMware installed on a Windows or Linux host machine, not managed by vCenter.
ServiceNow Discovery can extract information from all the components in a VMware system, including vCenter.
Discovery creates records in the CMDB for vCenter, the host machine and all the virtual machines running on that
server. Discovery finds the stored templates and maps all the relationships between components. In networks that use
Orchestration to create and manage virtual servers, Discovery populates records automatically and detects changes in
the network. Without Discovery, all the records for Orchestration VMware Support must be created and updated
manually, including the relationships between VMware components.
vCenter Cloning
The vCenter management console can control multiple ESX Server machines, each of which is capable of hosting
multiple virtual servers cloned from stored templates. The relationships between VMware components for this type
of installation are shown in the following diagram:
214
Relationships
The components in a system managed by vCenter have the following relationships:
VCenter: Manages one or more ESX Servers
ESX Server:
Managed by vCenter
Gets resources from the Resource Pool
Has registered VMware instances
Virtualizes virtual machines.
Resource Pool: Defines resources for the ESX Server. See Resource Pools for more information.
VM Instances (including images and templates):
Registers on the ESX Server
Instantiates individual virtual machines.
Virtual machines:
Instantiated by VM instances (images and templates)
Virtualized by ESX Server
Establishing Relationships Using Discovery

ServiceNow Discovery identifies appropriate relationships for new virtual machines or updates the relationships for
previously discovered virtual machines.
1. The UNIX classify probe identifies the ESX Server.
2. Discovery assumes that the VMware application is running on the ESX Server and creates/updates the application
CI in the CMDB.
3. Discovery launches an SSH Probe that discovers all images on the ESX Server, including the unique IDs (UID).
4. Discovery then compares the master list of UIDs retrieved from the ESX Server with the UIDs of previously
discovered virtual machines in the CMDB and looks for a match.
5. If a match is found, Discovery updates the many-to-many relationship between the VMware components.
215
VMware Running on a Host Machine

In the basic VMware system, the VMware application runs on a Windows or Linux host machine. This system can
clone instances from templates, but cannot be automated. The relationships between VMware components for this
type of installation are shown in the following diagram:
Relationships
The components in a VMware system installed on a Windows or Linux host have the following relationships:
Windows or Linux Server: Runs the VMware application
VMware application:
Runs on a Windows or Linux host machine
Has registered VM instances
Virtualizes virtual machines.
VM Instances (including images and templates):
Registers on the VMware application
Instantiates individual virtual machines.
Virtual machines:
Instantiated by VM instances
Virtualized by VMware application
Establishing Relationships Using Discovery

ServiceNow Discovery identifies appropriate relationships for new virtual machines or updates the relationships for
previously discovered virtual machines.
1. The UNIX classify probe (or Windows classify probe) determines the operating system of the host machine.
2. Discovery finds the VMware application running on the host machine and creates/updates the application CI in
the CMDB.
3. Discovery launches an SSH Probe that discovers all images on the host machine, including the unique IDs (UID).
4. Discovery then compares the master list of UIDs from the host machine with the UIDs of previously discovered
virtual machines in the CMDB and looks for a match.
5. If a match is found, Discovery updates the many-to-many relationship between the VMware components.
216
Hyper-V Component Relationships
217

Overview
ServiceNow Discovery can extract information from all the components in a Microsoft Hyper-V system. Discovery
creates records in the CMDB for the host machine, the parent partition running Windows Server 2008, and all the
virtual machines running on the Hyper-V server. Discovery finds the stored templates and maps all the relationships
between components.
See Discovery for Hyper-V for a list of ServiceNow requirements for discovering Hyper-V and the data collected.
Hyper-V discovery is available with the Calgary release.
Hyper-V Architecture
ServiceNow stores Hyper-V configuration items (CI) in these tables:
Table
Purpose
Hyper-V Server [cmdb_ci_hyper_v_server]
Contains data about the physical machine running the Hyper-V server. This table has a
reference relationship with the existing Windows Server [cmdb_ci_win_server] table.
Hyper-V Virtual Machine Instance

[cmdb_ci_hyper_v_instance]
Contains data about Hyper-V instances.
Hyper-V Virtual Network

[cmdb_ci_hyper_v_network]
Contains data about Hyper-V networks.
Hyper-V Cluster [cmdb_ci_hyper_v_cluster]
Contains data about Hyper-V clusters. This table has a reference relationship with the existing
Windows Cluster [cmdb_ci_win_cluster] table.
Hyper-V Resource Pool

[cmdb_ci_hyper_v_resource_pool]
Contains data about Hyper-V resource pools.
Hyper-V Resource Pool Component

[cmdb_ci_hyper_v_rpool_comp]
Contains groups of Hyper-V resource pools.
Hyper-V Object [cmdb_ci_hyper_v_object]
Base class for all Hyper-V objects.
ServiceNow modifies these tables for use with multiple virtualization products:
Table
Purpose
Virtualization Server
[cmdb_ci_virtualization_server]
Contains data on all discovered virtualization servers.
Virtual Machine Instance

[cmdb_ci_vm_instance]
Contains data on all discovered virtual machine instances.
Virtual Machine Object [cmdb_ci_vm_object]
Contains data about various objects associated with a Hyper-V server, such as partitions,
networks, resource pools, and clusters.
218
Relationships Discovered in Hyper-V

Discovery detects the following relationships when it discovers a Hyper-V server:
Parent table
Relationship
Child table

Instantiates::Instantiated by
Computer [cmdb_ci_computer]

Provided By::Provides
Hyper-V Network

Connected by::Connects to
Hyper-V Network
Hyper-V Cluster [cmdb_ci_hyper_v_cluster]
Members::Members of
Hyper-V Resource Pool [cmdb_ci_hyper_v_resource_pool] Defines resources for::Gets resources

from
219
Computers, Clusters, and Virtual Machines

Windows
Discovery can classify and discover Windows servers and workstations that use the following operating systems:
Windows NT Server
Windows 2000 Server
Windows 2003 Server
Windows 2008 Server
Windows 2012 Server
Windows XP
Windows Vista
Windows 7
Windows 8
You may need to set Windows permissions on the systems you want to discover.
Tables and Fields

Discovery stores information about Windows servers and workstations in the following tables and fields.
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_computer
os
wmi
OS version
cmdb_ci_computer
os_version
wmi
OS service pack
cmdb_ci_computer
os_service_pack
wmi
Name
cmdb_ci_win_server
name
DNS, NBT
Hostname
cmdb_ci_win_server
host_name
DNS, NBT
DNS domain
cmdb_ci_win_server
dns_domain
DNS
OS domain
cmdb_ci_computer
os_domain
NBT
Assigned to
cmdb_ci_win_server
assigned_to
wmi
Department
cmdb_ci_win_server
department
Internal (User)
Short description
cmdb_ci_win_server
short_description
wmi
Manufacturer
cmdb_ci_win_server
manufacturer
wmi
Serial number
cmdb_ci_win_server
serial_number
wmi
CPU name
cmdb_ci_computer
cpu_name
wmi
CPU manufacturer
cmdb_ci_computer
cpu_manufacturer
wmi
CPU speed (MHz)
cmdb_ci_computer
cpu_speed
wmi
CPU count *
cmdb_ci_computer
cpu_count
wmi
CPU core count *
cmdb_ci_computer
cpu_core_count
wmi
Windows
220
CPU core thread * (Calgary release) cmdb_ci_computer
cpu_core_thread
wmi
Model ID
cmdb_ci
model_id
wmi
RAM (MB)
cmdb_ci_computer
ram
wmi
Disk space (GB)
cmdb_ci_computer
disk_space
wmi
Type
cmdb_ci_disk
type
wmi
Description
cmdb_ci_disk
short_description
wmi
Disk space (GB)
cmdb_ci_disk
disk_space
wmi
Free space (GB)
cmdb_ci_disk
free_space
wmi
Name
cmdb_ci_disk
name
wmi
Volume serial number
cmdb_ci_disk
volume_serial_number wmi
Name
cmdb_running_process
name
wmi
Command
command
wmi
Connects to
connects_to
wmi
Listening on
listening_on
wmi
Type
type
wmi
PID
pid
wmi
Parameters
parameters
wmi
Name
cmdb_ci_network_adapter name
wmi
IP address
cmdb_ci_network_adapter ip_address
wmi
MAC address
cmdb_ci_network_adapter mac_address
wmi
Netmask
cmdb_ci_network_adapter netmask
wmi
DHCP enabled
cmdb_ci_network_adapter dhcp_enabled
wmi
Vendor
cmdb_ci_network_adapter vendor
wmi
Default gateway (Calgary release)
cmdb_ci_hardware
wmi
default_gateway
* Core counts and threads per core might not be accurate, due to issues with Microsoft reporting. See http:/ / msdn.
microsoft.com/en-us/library/windows/desktop/aa394373(v=vs.85).aspx [1] for details.
Versions Prior to the Dublin Release

Discovery stores information about Windows servers and workstations in the following tables and fields on versions
prior to Dublin.
View tables and fields on versions prior to Dublin
Windows
221
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_win_server
os
wmi
OS version
cmdb_ci_win_server
os_version
wmi
OS service pack
cmdb_ci_win_server
os_service_pack
wmi
Name
cmdb_ci_win_server
name
DNS, NBT
Hostname
cmdb_ci_win_server
host_name
DNS, NBT
DNS domain
cmdb_ci_win_server
dns_domain
DNS
OS domain
cmdb_ci_win_server
os_domain
NBT
Assigned to
cmdb_ci_win_server
assigned_to
wmi
Department
cmdb_ci_win_server
department
Internal (User)
Short description
cmdb_ci_win_server
short_description
wmi
Manufacturer
cmdb_ci_win_server
manufacturer
wmi
Serial number
cmdb_ci_win_server
serial_number
wmi
CPU name
cmdb_ci_computer
cpu_name
wmi
CPU manufacturer
cmdb_ci_computer
cpu_manufacturer
wmi
CPU speed (MHz)
cmdb_ci_computer
cpu_speed
wmi
CPU count *
cmdb_ci_computer
cpu_count
wmi
CPU core count *
cmdb_ci_computer
cpu_core_count
wmi
CPU core thread * (Calgary release) cmdb_ci_computer
cpu_core_thread
wmi
Model ID
cmdb_ci
model_id
wmi
RAM (MB)
cmdb_ci_computer
ram
wmi
Disk space (GB)
cmdb_ci_computer
disk_space
wmi
Type
cmdb_ci_disk
type
wmi
Description
cmdb_ci_disk
short_description
wmi
Disk space (GB)
cmdb_ci_disk
disk_space
wmi
Free space (GB)
cmdb_ci_disk
free_space
wmi
Name
cmdb_ci_disk
name
wmi
cmdb_ci_disk
volume_serial_number wmi
Name
name
wmi
Command
command
wmi
Type
type
wmi
PID
pid
wmi
Parameters
parameters
wmi
Name
wmi
IP address
wmi
MAC address
wmi
Netmask
wmi
DHCP enabled
wmi
Vendor
cmdb_ci_network_adapter vendor
wmi
Windows
222
Default gateway (Calgary release)
cmdb_ci_hardware
default_gateway
wmi
* Core counts and threads per core might not be accurate, due to issues with Microsoft reporting. See http:/ / msdn.
microsoft.com/en-us/library/windows/desktop/aa394373(v=vs.85).aspx [1] for details.
Enhancements
Dublin
The Running Processes [cmdb_running_process] table contains new fields to track the list of TCP ports a process
listens on (listening_on) and connects to (connects_to).
References
[1] http:/ / msdn. microsoft. com/ en-us/ library/ windows/ desktop/ aa394373(v=vs. 85). aspx
Solaris
Discoverable Solaris Operating Systems
Discovery can classify and discover Solaris servers and workstations that use the following operating systems:
Oracle Solaris 10
Oracle Solaris 11
You must provide SSH credentials for the systems you want to discover.
Tables and Fields

Discovery stores information about Solaris computers in the following tables and fields.
Label
Table
Field Name
Source
Operating System
cmdb_ci_computer
os
uname
Short description
cmdb_ci_solaris_server
short_description
uname
Name
name
DNS, NBT
Hostname
host_name
DNS, NBT
DNS domain
dns_domain
DNS
Start date
start_date
uptime
CPU type
cmdb_ci_computer
cpu_type
kstat
CPU speed (MHz)
cmdb_ci_computer
cpu_speed
kstat
CPU count
cmdb_ci_computer
cpu_count
kstat
CPU core count
cmdb_ci_computer
cpu_core_count
kstat
CPU core thread (Calgary release) cmdb_ci_computer
cpu_core_thread
kstat
Model number
model_number
suntype
Model ID
model_id
suntype
RAM (MB)
cmdb_ci_computer
ram
prtconf
Solaris
223
Disk space (GB)
disk_space
iostat
Serial Number
serial_number
sneep
Manufacturer
cmdb_ci_disk
manufacturer
iostat
Model ID
cmdb_ci_disk
model_id
iostat
cmdb_ci_disk
volume_serial_number iostat
Disk space (GB)
cmdb_ci_disk
disk_space
iostat
Name
cmdb_ci_disk
name
iostat
Name
cmdb_ci_file_system
name
df
Capacity (MB
cmdb_ci_file_system
capacity
df
Available Space (MB)
cmdb_ci_file_system
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
showrev
Name
name
ps
Command
command
ps
Connects to
connects_to
lsof
Listening on
listening_on
lsof
Type
type
ps
PID
pid
ps
Parameters
parameters
ps
Name
ifconfig
IP address
ifconfig
MAC address
ifconfig
Netmask
ifconfig
Default gateway (Calgary release) cmdb_ci_hardware
default_gateway
netstat

Discovery stores information about Solaris computers in the following tables and fields in versions prior to Dublin.
Label
Table
Field Name
Source
Operating System
os
uname
Short description
short_description
uname
Name
name
DNS, NBT
Hostname
host_name
DNS, NBT
DNS domain
dns_domain
DNS
Start date
start_date
uptime
CPU type
cpu_type
kstat
CPU speed (MHz)
cpu_speed
kstat
CPU count
cpu_count
kstat
Solaris
224
CPU core count
cmdb_ci_computer
cpu_core_count
kstat
cpu_core_thread
kstat
Model number
model_number
suntype
Model ID
model_id
suntype
RAM (MB)
ram
prtconf
Disk space (GB)
disk_space
iostat
Serial Number
serial_number
sneep
Manufacturer
cmdb_ci_disk
manufacturer
iostat
Model ID
cmdb_ci_disk
model_id
iostat
cmdb_ci_disk
volume_serial_number iostat
Disk space (GB)
cmdb_ci_disk
disk_space
iostat
Name
cmdb_ci_disk
name
iostat
Name
cmdb_ci_file_system
name
df
Capacity (MB
cmdb_ci_file_system
capacity
df
cmdb_ci_file_system
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
showrev
Name
name
ps
Command
command
ps
Type
type
ps
PID
pid
ps
Parameters
parameters
ps
Name
ifconfig
IP address
ifconfig
MAC address
ifconfig
Netmask
ifconfig
default_gateway
netstat
Enhancements
Dublin
Linux
225
Linux
Data Collected by the SSH probe or Linux - Identity multiprobes on Linux Computers
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_linux_server
os
uname
OS Version
cmdb_ci_computer
os_version
uname -a or cat /etc/*release
Short description
short_description
uname
Name
name
DNS, NBT
Hostname
host_name
DNS, NBT
DNS domain
dns_domain
DNS
Start date
start_date
uptime
Manufacturer
cmdb_ci_computer
manufacturer
dmidecode
Serial number
cmdb_ci_computer
serial_number
dmidecode
CPU type
cpu_type
/proc/cpuinfo
CPU speed (MHz)
cpu_speed
/proc/cpuinfo
CPU count
cpu_count
/proc/cpuinfo
CPU core count
cmdb_ci_computer
cpu_core_count
/proc/cpuinfo
cpu_core_thread
/proc/cpuinfo
CPU manufacturer
cpu_manufacturer /proc/cpuinfo
Model number
cmdb_ci_computer
model_number
dmidecode
Model ID
cmdb_ci_computer
model_id
dmidecode
RAM (MB)
ram
meminfo
Disk space (GB)
disk_space
/proc/ide, /proc/scsi, /var/log/dmesg
Type
cmdb_ci_disk
type
Model ID
cmdb_ci_disk
model_id
Disk space (GB)
cmdb_ci_disk
disk_space
Name
cmdb_ci_disk
name
Name
cmdb_ci_file_system
name
df
Capacity (MB)
cmdb_ci_file_system
capacity
df
cmdb_ci_file_system
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
name
ps
Command
command
ps
Type
type
ps
PID
pid
ps
Parameters
parameters
ps
Name
ifconfig
IP address
ifconfig
Linux
226
MAC address
ifconfig
Netmask
ifconfig
default_gateway
route
Linux Kernel-based Virtual Machines (KVM)

Overview
Discovery identifies Linux kernel-based virtual machines (KVM) when the process classifier detects libvirtd
running on a Linux server (starting with the Dublin release). The classification triggers the creation of a
cmdb_ci_kvm record, and launches the SSHCommand probes to explore the Linux server with virsh, lbvert utility,
and virtual machine configuration data.
Discovery creates a cmdb_ci_kvm_instance record for each virtual machine on the server. Discovery matches the
cmdb_ci_kvm_instance record to a corresponding cmdb_ci_computer record using the MAC addresses of installed
network adapters.
Tables used by Discovery on Linux KVM

Discovery uses the following tables to store configuration records for kernel-based virtual machines.
Table Name
cmdb_ci_kvm
Extends
cmdb_ci_vm
Description
Source
A hypervisor that manages kernel-based Process classifier detects libvirtd running on Linux
virtual machines (KVMs)
servers
cmdb_ci_kvm_vm_instance cmdb_ci_vm_instance A virtual machine instance on this

hypervisor
virsh list -all and dumpxml command
cmdb_ci_kvm_object
cmdb_ci_vm_object
An object connected to a virtual

machine instance
<network>, <storage pool>, and <storage volume>

elements from the dumpxml command
cmdb_kvm_device
N/A
A device connected to a virtual machine <devices> element from the dumpxml command
instance
Data Collected by Discovery on Linux KVM

Discovery finds the following information for kernel-based virtual machines.
Label
Table Name
Field Name
Source
Linux Host
cmdb_ci_kvm
linux_host
Reference to the cmdb_ci_linux_server that is running this virtual machine
Details
cmdb_ci_kvm
details_xml
dumpxml
Object ID
cmdb_ci_kvm_vm_instance object_id
virsh dumpxml
State
cmdb_ci_kvm_vm_instance state
virsh list -all
CPUs
cmdb_ci_kvm_vm_instance cpus
virsh dumpxml
Memory
cmdb_ci_kvm_vm_instance memory
virsh dumpxml
Disks
cmdb_ci_kvm_vm_instance disks
virsh dumpxml
Disks size
cmdb_ci_kvm_vm_instance disks_size
virsh domblkinfo
Linux Kernel-based Virtual Machines (KVM)
227
Network adapters cmdb_ci_kvm_vm_instance nics
virsh dumpxml
Name
virsh dumpxml
cmdb_ci_kvm_vm_instance name
Short description cmdb_ci_kvm_vm_instance short_description virsh desc

Details
cmdb_ci_kvm_object
details_xml
XML element from dumpxml
KVM instance
cmdb_kvm_device
kvm_instance
Reference to cmdb_ci_kvm_instance
Device
cmdb_kvm_device
device
disk, controller, interface, etc.
Type
cmdb_kvm_device
type
depends on device
Details
cmdb_kvm_device
details_xml
XML element from dumpxml
KVM Relationships
Discovery collects the following relationship data.
Relationship
Parent Table
Child Table
Registered On::Has Registered
KVM [cmdb_ci_kvm]
KVM Virtual Machine Instance

[cmdb_ci_kvm_vm_instance]
Provided By::Provides
KVM [cmdb_ci_kvm]
Network [cmdb_ci_kvm_network]
Defines resource for::Gets

resources from
KVM [cmdb_ci_kvm]
Storage Pool [cmdb_ci_kvm_storage_pool]
Connected By::Connects

Network [cmdb_ci_kvm_network]
Instantiated By::Instantiates

Virtualized By::Virtualizes
KVM [cmdb_ci_kvm]
Provides storage for::Stored on
Storage Pool [cmdb_ci_kvm_storage_pool]

HPUX
228
HPUX
Data Collected by Discovery on HPUX Computers
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_hpux_server
os
uname
Short description
cmdb_ci_hpux_server
short_description uname
Name
cmdb_ci_hpux_server
name
DNS, NBT
Hostname
cmdb_ci_hpux_server
host_name
DNS, NBT
DNS domain
cmdb_ci_hpux_server
dns_domain
DNS
Start date
cmdb_ci_hpux_server
start_date
uptime
Manufacturer
cmdb_ci_computer
manufacturer
dmidecode
Serial number
cmdb_ci_hpux_server
serial_number
uname
CPU type
cmdb_ci_hpux_server
cpu_type
cpuinfo
CPU speed (MHz)
cmdb_ci_hpux_server
cpu_speed
adb
CPU count
cmdb_ci_hpux_server
cpu_count
cpuinfo
Model ID
cmdb_ci_hpux_server
model_id
model
RAM (MB)
cmdb_ci_hpux_server
ram
adb
Name
cmdb_ci_file_system
name
df
Capacity (MB)
cmdb_ci_file_system
capacity
df
Available Space (MB) cmdb_ci_file_system
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
swlist
Name
name
ps
Command
command
ps
Type
type
ps
PID
pid
ps
Parameters
parameters
ps
Name
hifconfig
IP address
hifconfig
MAC address
hifconfig
Netmask
hifconfig
AIX
229
AIX
Tables and Fields
Discovery stores information about AIX computers in the following tables and fields.
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_computer
os
uname
OS version
cmdb_ci_computer
os_version
oslevel
OS service pack
cmdb_ci_computer
os_service_pack
oslevel
Short description
cmdb_ci_aix_server
Name
cmdb_ci_aix_server
name
DNS, NBT
Hostname
cmdb_ci_aix_server
host_name
DNS, NBT
DNS domain
cmdb_ci_aix_server
dns_domain
DNS
Start date
cmdb_ci_aix_server
start_date
uptime
CPU type
cmdb_ci_computer
cpu_type
lsdev, lsattr
CPU speed (MHz)
cmdb_ci_computer
cpu_speed
lsdev, lsattr
CPU count
cmdb_ci_computer
cpu_count
lsdev, lsattr
Manufacturer
cmdb_ci_aix_server
manufacturer
lsattr
Model ID
cmdb_ci_aix_server
model_id
lsattr
RAM (MB)
cmdb_ci_computer
ram
lsdev, lsattr
Name
cmdb_ci_file_system
name
df
Capacity (MB)
cmdb_ci_file_system
capacity
df
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
instfix
Name
name
ps
Command
command
ps
Connects to
connects_to
lsof
Listening on
listening_on
lsof
Type
type
ps
PID
pid
ps
Parameters
parameters
ps
Name
ifconfig, netstat
IP address
ifconfig, netstat
MAC address
ifconfig, netstat
Netmask
ifconfig, netstat
AIX
230

Discovery stores information about AIX computers in the following tables and fields in versions prior to Dublin.
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_aix_server
os
uname
OS version
cmdb_ci_aix_server
os_version
oslevel
OS service pack
cmdb_ci_aix_server
os_service_pack
oslevel
Short description
cmdb_ci_aix_server
Name
cmdb_ci_aix_server
name
DNS, NBT
Hostname
cmdb_ci_aix_server
host_name
DNS, NBT
DNS domain
cmdb_ci_aix_server
dns_domain
DNS
Start date
cmdb_ci_aix_server
start_date
uptime
CPU type
cmdb_ci_aix_server
cpu_type
lsdev, lsattr
CPU speed (MHz)
cmdb_ci_aix_server
cpu_speed
lsdev, lsattr
CPU count
cmdb_ci_aix_server
cpu_count
lsdev, lsattr
Manufacturer
cmdb_ci_aix_server
manufacturer
lsattr
Model ID
cmdb_ci_aix_server
model_id
lsattr
RAM (MB)
cmdb_ci_aix_server
ram
lsdev, lsattr
Name
cmdb_ci_file_system
name
df
Capacity (MB)
cmdb_ci_file_system
capacity
df
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
instfix
Name
name
ps
Command
command
ps
Type
type
ps
PID
pid
ps
Parameters
parameters
ps
Name
ifconfig, netstat
IP address
ifconfig, netstat
MAC address
ifconfig, netstat
Netmask
ifconfig, netstat
AIX
231
Enhancements
Dublin
Mac
Tables and Fields
Discovery stores information about Mac (OS/X) computers in the following tables and fields.
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_computer
os
uname
OS Version
cmdb_ci_computer
os_version
system_profiler
OS Service pack
cmdb_ci_computer
os_service_pack
system_profiler
Short description
cmdb_ci_computer
short_description
uname
Name
cmdb_ci_computer
name
DNS, NBT
Hostname
cmdb_ci_computer
host_name
DNS, NBT
DNS domain
cmdb_ci_computer
dns_domain
DNS
Start date
cmdb_ci_computer
start_date
uptime
Manufacturer
cmdb_ci_computer
manufacturer
Assumed to be Apple
Serial number
cmdb_ci_computer
serial_number
system_profiler
CPU type
cmdb_ci_computer
cpu_type
system_profiler
CPU speed (MHz)
cmdb_ci_computer
cpu_speed
system_profiler
CPU count
cmdb_ci_computer
cpu_count
system_profiler
Model ID
cmdb_ci_computer
model_id
system_profiler
RAM (MB)
cmdb_ci_computer
ram
system_profiler
Disk space (GB)
cmdb_ci_comptuer
disk_space
system_profiler
Volume name
cmdb_ci_disk
volume_name
system_profiler
Volume serial number cmdb_ci_disk
volume_serial_number system_profiler
Disk space (GB)
cmdb_ci_disk
disk_space
system_profiler
Name
cmdb_ci_disk
name
system_profiler
Device ID
cmdb_ci_disk
device_id
system_profiler
Free space (GB)
cmdb_ci_disk
free_space
system_profiler
File system
cmdb_ci_disk
file_system
system_profiler
Name
name
ps
Command
command
ps
Connects to
connects_to
lsof
Listening on
listening_on
lsof
Mac
232
Type
type
ps
PID
pid
ps
Parameters
parameters
ps
Name
system_profiler
IP address
system_profiler
MAC address
system_profiler
Netmask
system_profiler
MAC manufacturer
cmdb_ci_network_adapter mac_mfr
Assumed to be Apple
DHCP enabled
system_profiler

Discovery stores information about Mac (OS/X) computers in the following tables and fields on versions prior to
Dublin.
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_computer
os
uname
OS Version
cmdb_ci_computer
os_version
system_profiler
OS Service pack
cmdb_ci_computer
os_service_pack
system_profiler
Short description
cmdb_ci_computer
short_description
uname
Name
cmdb_ci_computer
name
DNS, NBT
Hostname
cmdb_ci_computer
host_name
DNS, NBT
DNS domain
cmdb_ci_computer
dns_domain
DNS
Start date
cmdb_ci_computer
start_date
uptime
Manufacturer
cmdb_ci_computer
manufacturer
Assumed to be Apple
Serial number
cmdb_ci_computer
serial_number
system_profiler
CPU type
cmdb_ci_computer
cpu_type
system_profiler
CPU speed (MHz)
cmdb_ci_computer
cpu_speed
system_profiler
CPU count
cmdb_ci_computer
cpu_count
system_profiler
Model ID
cmdb_ci_computer
model_id
system_profiler
RAM (MB)
cmdb_ci_computer
ram
system_profiler
Disk space (GB)
cmdb_ci_comptuer
disk_space
system_profiler
Volume name
cmdb_ci_disk
volume_name
system_profiler
Volume serial number cmdb_ci_disk
volume_serial_number system_profiler
Disk space (GB)
cmdb_ci_disk
disk_space
system_profiler
Name
cmdb_ci_disk
name
system_profiler
Device ID
cmdb_ci_disk
device_id
system_profiler
Free space (GB)
cmdb_ci_disk
free_space
system_profiler
File system
cmdb_ci_disk
file_system
system_profiler
Mac
233
Name
name
ps
Command
command
ps
Type
type
ps
PID
pid
ps
Parameters
parameters
ps
Name
system_profiler
IP address
system_profiler
MAC address
system_profiler
Netmask
system_profiler
MAC manufacturer
cmdb_ci_network_adapter mac_mfr
Assumed to be Apple
DHCP enabled
system_profiler
Enhancements
Dublin
Solaris Zones
Label
Version
Table Name
cmdb_ci_vm_zones
Correlation ID cmdb_ci_vm_zones
Field Name
version
Source
zoneadm, zonename
correlation_id zoneadm, zonename
Name
cmdb_ci_vm_instance name
zoneadm, zonename
Parent
cmdb_ci_vm_instance parent
Internal
CMDB CI
cmdb_ci_vm_instance cmdb_ci
Internal
Correlation ID cmdb_ci_vm_instance correlation_id zoneadm, zonename
Netware
234
Netware
Data Collected by Discovery on Netware
Label
Name
Table Name
Field Name
cmdb_ci_netware_server name
Source
snmp
Serial number cmdb_ci_netware_server serial_number snmp

OS Version
cmdb_ci_netware_server os_version
snmp
RAM
cmdb_ci_netware_server ram
snmp
CPU count
cmdb_ci_netware_server cpu_count
snmp
ESX Servers
Overview
ServiceNow Discovery can explore the VMware vCenter process running on a Windows host machine. See VMware
Component Relationships for a description of the VMware architecture and component relationships.
Required Roles
Users with the itil and asset roles can access ESXi and ESX configuration item (CI) records. To run discovery on
vCenter servers, users must have the discovery_admin role.
Credential Requirements
Three sets of credentials are needed to run a complete Discovery of vCenter/ESX servers:
Windows credentials: Allows Discovery to access the Windows host on which the vCenter server runs
vCenter credentials: Allows a vCenter probe to explore a vCenter server
ESX credentials: Allows Discovery to access the serial numbers of discovered ESX servers
ESX Server Discovery Components

ESX Server discovery uses the following components to classify and explore virtual machines (starting with the
Dublin release):
ESX Servers
235
Name
Description
Component
Classifier
vCenter
Classifies stand-alone vCenter servers.
Probe
VMWare - vCenter
Exploration probe that extracts the list of ESX hosts, resource pools, and virtual machines from the vCenter
host. Implementation details for this probe are located in a MID server script include called
VMWarevCenterProbe.
Probe
CIM - ESX Chassis

Serial Number
Exploration probe that queries each ESX server for its serial number.
When Discovery runs, a classifier called vCenter, classifies the process running on a Windows machine and
launches the VMware - vCenter probe. This probe logs into the vCenter instance with the credentials provided and
uses the vCenter API to return information about ESX machines, virtual machines, and resource pools. If using a
domain account to access vCenter, specify the domain with the username in the credential record in one of the
supported formats such as Domain\UserName. In order to discover ESX server serial numbers, Discovery launches
the CIM - ESX Chassis Serial Number probe against each ESX server. This probe is required because the vCenter
API does not provide a way to retrieve the ESX serial numbers.
Click the plus for versions prior to Dublin
In versions prior to Dublin, Discovery used SSH to classify ESX servers.
Component
Name
Description
Classifier
ESX
Classifies stand-alone vCenter servers.
Multiprobe
UNIX - Classify Retrieve information to classify the type of UNIX-based CI.

Includes these probes:
Probe
ESX - OS
ESX - OS
UNIX - OS
Determine if the target is an ESX
vCenter and ESX Data Collected by Discovery

When Discovery detects the vCenter process running on a host machine, it launches exploration probes to gather
typical server CI data as well as the following data specific to ESX Servers.
Tables and Fields
ESX Servers
236
Label
Table
Field Name
Source
CPU expandable
ESX Resource Pool [cmdb_ci_esx_resource_pool]
cpu_expendable
CPU limit (MHz)
cpu_limit_mhz
CPU reserved (MHz)
cpu_reserved_mhz VMWare - vCenter probe
CPU shares
cpu_shares
Full path
fullpath
Memory expandable
mem_expandable
Memory limit (MB)
mem_limit_mb
Memory reserved (MB)
mem_reserved_mb VMWare - vCenter probe
Memory shares
mem_shares
Owner
owner
Owner Managed Object

Reference ID
owner_morid
URL
url
Managed object reference ID
VMware vCenter Server Object

[cmdb_ci_vcenter_server_obj]
morid
Serial Number
Serial Number [cmdb_serial_number]
serial_number
CIM - ESX Chassis Serial

Number probe
Relationships
Discovery collects the following relationship data for ESX Servers.
Base Class
Relationship
Dependent Class
ESX Resource Pool [cmdb_ci_esx_resource_pool] Defines resources for ESX Server [cmdb_ci_esx_server]
Gets resources from
Virtual Machine Instance [cmdb_ci_vm_instance] Registered on
Has registered
Virtual Machine Instance [cmdb_ci_vm_instance]
Manages
Managed by
Enhancements
Dublin
Discovery uses vCenter and CIM probes instead of SSH to explore ESX servers. Discovery will continue to
classify an ESX server if it finds the SSH port open, but it will not launch SSH probes to collect additional
information.
237
Network Gear
Routers
Overview
Modern network routers and switches often have very similar capabilities. It is very common for a switch to have IP
routing capability (sometimes these switches are known as "Layer 3 switches"). Larger routers with optional
modules may accept switching modules. Because of these overlaps and the resulting ambiguity of a particular
device's classification, Discovery collects the same data for both routers and switches, if it is available in any given
device.
Router and Switch Data

Label
Table Name
Field Name
Source
Serial number
cmdb_ci
serial_number
SNMP, various MIBs
Start date
cmdb_ci
start_date
SNMP, RFC1213 MIB
Manufacturer
cmdb_ci
manufacturer
SNMP, RFC1213 MIB
Model ID
cmdb_ci
model_id
SNMP, RFC1213 MIB
IP address
SNMP, IP MIB
MAC address
SNMP, IF MIB
Can route IP
cmdb_ci_netgear
can_route
SNMP, IP MIB, BGP MIB
Can switch IP
cmdb_ci_netgear
can_switch
SNMP, dot1dBridge MIB
Can partition VLANs cmdb_ci_netgear
can_partitionvlans
Can hub
cmdb_ci_netgear
can_hub
SNMP, IP MIB
Name
dscy_router_interface
name
SNMP, IP MIB
Type
type
SNMP, IP MIB
Number
number
SNMP, IP MIB
IP address
ip_address
SNMP, IP MIB
MAC address
mac_address
SNMP, IP MIB
Destination network
dscy_route_interface
dest_ip_network
SNMP, IP MIB
Type
type
SNMP, IP MIB
Destination network
dscy_route_next_hop
dest_ip_network
SNMP, IP MIB
Type
dscy_route_next_hop
type
SNMP, IP MIB
Next hop
dscy_route_next_hop
next_hop_ip_address SNMP, IP MIB
Base IP address
dscy_swtch_partition
base_ip_address
Base MAC address
base_mac_address
Base netmask
base_netmask
Routers
238
Type
type
Transparent
transparent
Sourceroute
sourceroute
Name
name
Status
status
Interface number
interface_number
Type
dscy_switchport
type
Status
dscy_switchport
status
MAC address
dscy_switchport
mac_address
Port number
dscy_switchport
port_number
Interface name
dscy_switchport
interface_name
Interface number
dscy_switchport
interface_number
MAC address
dscy_swtch_fwd_rule
mac_address
MAC manufacturer
dscy_swtch_fwd_rule
mac_mfr
Status
dscy_swtch_fwd_rule
status
IP address
dscy_swtch_fwd_rule
ip_address
Netmask
dscy_swtch_fwd_rule
netmask
Load Balancer Data

Source of Load Balancer Data
Discovery uses the following SNMP MIBs to collect data for load balancers.
F5-BIGIP-COMMON-MIB
F5-BIGIP-LOCAL-MIB
F5-BIGIP-SYSTEM-MIB
Tables Used by Discovery on Load Balancers

Discovery uses the following tables to store configuration records for load balancers.
Table Name
Label
Extends
cmdb_ci_lb
Load Balancer
Server [cmdb_ci_server]
cmdb_ci_lb_bigip
F5 BIG-IP
Load Balancer [cmdb_ci_lb]
cmdb_ci_lb_interface
Load Balancer Interface
Configuration Item [cmdb_ci]
cmdb_ci_lb_pool
Load Balancer Pool
cmdb_ci_lb_pool_member Load Balancer Pool Member
cmdb_ci_lb_service
Load Balancer Service
cmdb_ci_lb_vlan
Load Balancer VLAN
cmdb_lb_service_vlan
Load Balancer Service VLAN
N/A
cmdb_lb_vlan_interface
Load Balancer VLAN Interface N/A
Routers
239
Data Collected by Discovery for Load Balancers

Discovery collects the following information for load balancers.
Table Name
Field Name
Label
cmdb_ci_lb
operational_status
Operational status
cmdb_ci_lb
name
Name
cmdb_ci_lb_bigip
failover_mode
Failover Mode
cmdb_ci_lb_bigip
failover_peer
Failover Peer
cmdb_ci_lb_bigip
serial_number
Serial Number
install_status
Status
load_balancer
Load Balancer
name
Name
cmdb_ci_lb_pool
load_balancer
Load Balancer
cmdb_ci_lb_pool
load_balance_method Load Balancing Method
cmdb_ci_lb_pool
name
Name
cmdb_ci_lb_pool_member ip_address
IP Address
cmdb_ci_lb_pool_member pool
Pool
cmdb_ci_lb_pool_member service_port
Service Port
cmdb_ci_lb_service
ip_address
IP Address
cmdb_ci_lb_service
load_balancer
Load Balancer
cmdb_ci_lb_service
port
Port
cmdb_ci_lb_vlan
load_balancer
Load Balancer
cmdb_ci_lb_vlan
tag
Tag
service
Service
vlan
Vlan
interface
Interface
tagged
Tagged
trunked
Trunked
vlan
Vlan
Switches
240
Switches
Overview
Modern network routers and switches often have very similar capabilities. It is very common for a switch to have IP
routing capability (sometimes these switches are known as "Layer 3 switches"). Larger routers with optional
modules may accept switching modules. Because of these overlaps and the resulting ambiguity of a particular
device's classification, Discovery collects the same data for both routers and switches, if it is available in any given
device.
Router and Switch Data

Label
Table Name
Field Name
Source
Serial number
cmdb_ci
serial_number
SNMP, various MIBs
Start date
cmdb_ci
start_date
SNMP, RFC1213 MIB
Manufacturer
cmdb_ci
manufacturer
SNMP, RFC1213 MIB
Model ID
cmdb_ci
model_id
SNMP, RFC1213 MIB
IP address
SNMP, IP MIB
MAC address
SNMP, IF MIB
Can route IP
cmdb_ci_netgear
can_route
SNMP, IP MIB, BGP MIB
Can switch IP
cmdb_ci_netgear
can_switch
Can partition VLANs cmdb_ci_netgear
can_partitionvlans
Can hub
cmdb_ci_netgear
can_hub
SNMP, IP MIB
Name
name
SNMP, IP MIB
Type
type
SNMP, IP MIB
Number
number
SNMP, IP MIB
IP address
ip_address
SNMP, IP MIB
MAC address
mac_address
SNMP, IP MIB
Destination network
dest_ip_network
SNMP, IP MIB
Type
type
SNMP, IP MIB
Destination network
dscy_route_next_hop
dest_ip_network
SNMP, IP MIB
Type
dscy_route_next_hop
type
SNMP, IP MIB
Next hop
dscy_route_next_hop
next_hop_ip_address SNMP, IP MIB
Base IP address
base_ip_address
Base MAC address
base_mac_address
Base netmask
base_netmask
Type
type
Transparent
transparent
Sourceroute
sourceroute
Name
name
Switches
241
Status
status
Interface number
interface_number
Type
dscy_switchport
type
Status
dscy_switchport
status
MAC address
dscy_switchport
mac_address
Port number
dscy_switchport
port_number
Interface name
dscy_switchport
interface_name
Interface number
dscy_switchport
interface_number
MAC address
dscy_swtch_fwd_rule
mac_address
MAC manufacturer
dscy_swtch_fwd_rule
mac_mfr
Status
dscy_swtch_fwd_rule
status
IP address
dscy_swtch_fwd_rule
ip_address
Netmask
dscy_swtch_fwd_rule
netmask
Load Balancer Data

Source of Load Balancer Data
Discovery uses the following SNMP MIBs to collect data for load balancers.
F5-BIGIP-COMMON-MIB
F5-BIGIP-LOCAL-MIB
F5-BIGIP-SYSTEM-MIB
Tables Used by Discovery on Load Balancers

Discovery uses the following tables to store configuration records for load balancers.
Table Name
Label
Extends
cmdb_ci_lb
Load Balancer
Server [cmdb_ci_server]
cmdb_ci_lb_bigip
F5 BIG-IP
Load Balancer [cmdb_ci_lb]
cmdb_ci_lb_pool
Load Balancer Pool
cmdb_ci_lb_pool_member Load Balancer Pool Member
cmdb_ci_lb_service
cmdb_ci_lb_vlan
Load Balancer VLAN
Load Balancer Service VLAN
N/A
Load Balancer VLAN Interface N/A
Switches
242
Data Collected by Discovery for Load Balancers

Discovery collects the following information for load balancers.
Table Name
Field Name
Label
cmdb_ci_lb
operational_status
Operational status
cmdb_ci_lb
name
Name
cmdb_ci_lb_bigip
failover_mode
Failover Mode
cmdb_ci_lb_bigip
failover_peer
Failover Peer
cmdb_ci_lb_bigip
serial_number
Serial Number
install_status
Status
load_balancer
Load Balancer
name
Name
cmdb_ci_lb_pool
load_balancer
Load Balancer
cmdb_ci_lb_pool
load_balance_method Load Balancing Method
cmdb_ci_lb_pool
name
Name
cmdb_ci_lb_pool_member ip_address
IP Address
cmdb_ci_lb_pool_member pool
Pool
cmdb_ci_lb_pool_member service_port
Service Port
cmdb_ci_lb_service
ip_address
IP Address
cmdb_ci_lb_service
load_balancer
Load Balancer
cmdb_ci_lb_service
port
Port
cmdb_ci_lb_vlan
load_balancer
Load Balancer
cmdb_ci_lb_vlan
tag
Tag
service
Service
vlan
Vlan
interface
Interface
tagged
Tagged
trunked
Trunked
vlan
Vlan
243
Other Hardware Devices

Network Printers
Data Collected by Discovery on Network Printers
Label
Table Name
Field Name
Source
Serial number
cmdb_ci
serial_number
SNMP, various MIBs
Start date
cmdb_ci
start_date
SNMP, RFC1213 MIB
Manufacturer
cmdb_ci
manufacturer
SNMP, RFC1213 MIB
Model ID
cmdb_ci
model_id
SNMP, RFC1213 MIB
IP address
SNMP, IP MIB
MAC address
SNMP, IF MIB
Printer type
cmdb_ci_printer
print_type
SNMP, PRINT MIB
Use count
cmdb_ci_printer
use_count
SNMP, PRINT MIB
Use count units
cmdb_ci_printer
use_units
SNMP, PRINT MIB
Colors
cmdb_ci_printer
colors
SNMP, PRINT MIB
Horizontal resolution cmdb_ci_printer
horizontal_resolution SNMP, PRINT MIB
Vertical resolution
cmdb_ci_printer
vertical_resolution
SNMP, PRINT MIB
Resolution units
cmdb_ci_printer
resolution_units
SNMP, PRINT MIB
Description
discovery_printer_supplies description
SNMP, PRINT MIB
Supply type
discovery_printer_supplies supply_type
SNMP, PRINT MIB
Supply class
discovery_printer_supplies supply_class
SNMP, PRINT MIB
Current level
discovery_printer_supplies current_level
SNMP, PRINT MIB
Max capacity
discovery_printer_supplies max_capacity
SNMP, PRINT MIB
Uninterruptible Power Supplies (UPSs)
244

Data Collected by Discovery on Uninterruptible Power Supplies (UPSs)
Label
Table Name
Field Name
Source
Serial number
cmdb_ci
serial_number
SNMP, various MIBs
Start date
cmdb_ci
start_date
SNMP, RFC1213 MIB
Manufacturer
cmdb_ci
manufacturer
SNMP, RFC1213 MIB
Model ID
cmdb_ci
model_id
SNMP, RFC1213 MIB
IP address
SNMP, IP MIB
MAC address
SNMP, IF MIB
UPS software version
cmdb_ci_ups
ups_software_version
SNMP, UPS MIB
Agent software version
cmdb_ci_ups
agent_software_version
SNMP, UPS MIB
Attached devices
cmdb_ci_ups
attached_devices
SNMP, UPS MIB
Battery status
cmdb_ci_ups
battery_status
SNMP, UPS MIB
Seconds remaining on battery
cmdb_ci_ups
seconds_on_battery
SNMP, UPS MIB
Estimated minutes remaining on battery cmdb_ci_ups
est_mins_remaining
SNMP, UPS MIB
Estimated charge% remaining
cmdb_ci_ups
est_charge_remaining
SNMP, UPS MIB
Battery voltage
cmdb_ci_ups
battery_voltage
SNMP, UPS MIB
Battery current
cmdb_ci_ups
battery_current
SNMP, UPS MIB
Battery temperature (C)
cmdb_ci_ups
battery_temperature
SNMP, UPS MIB
Input line bads
cmdb_ci_ups
input_line_bads
SNMP, UPS MIB
Output source
cmdb_ci_ups
output_source
SNMP, UPS MIB
Output frequency
cmdb_ci_ups
output_freq
SNMP, UPS MIB
Bypass frequency
cmdb_ci_ups
bypass_freq
SNMP, UPS MIB
Nominal input voltage
cmdb_ci_ups
nom_input_volt
SNMP, UPS MIB
Nominal input frequency
cmdb_ci_ups
nom_input_freq
SNMP, UPS MIB
Nominal output voltage
cmdb_ci_ups
nom_output_volt
SNMP, UPS MIB
Nominal output frequency
cmdb_ci_ups
nom_output_freq
SNMP, UPS MIB
Rated output VA
cmdb_ci_ups
rated_output_va
SNMP, UPS MIB
Rated output power
cmdb_ci_ups
rated_output_power
SNMP, UPS MIB
Low battery threshold minutes
cmdb_ci_ups
low_battery_threshold_mins SNMP, UPS MIB
Audible alarm status
cmdb_ci_ups
audible_alarm_status
SNMP, UPS MIB
Low voltage transfer point
cmdb_ci_ups
low_voltage_transfer_point
SNMP, UPS MIB
High voltage transfer point
cmdb_ci_ups
high_voltage_transfer_point SNMP, UPS MIB
Input index
cmdb_ci_ups_input
input_index
SNMP, UPS MIB
Input frequency (Hz)
cmdb_ci_ups_input
input_freq
SNMP, UPS MIB
Input voltage (RMS VAC)
cmdb_ci_ups_input
input_volt
SNMP, UPS MIB
Input current (RMS AAC)
cmdb_ci_ups_input
input_current
SNMP, UPS MIB
245
Input power (Watts)
cmdb_ci_ups_input
input_power
SNMP, UPS MIB
Output index
cmdb_ci_ups_output
output_index
SNMP, UPS MIB
Output load (%)
cmdb_ci_ups_output
output_load
SNMP, UPS MIB
Output voltage (RMS VAC)
cmdb_ci_ups_output
output_volt
SNMP, UPS MIB
Output current (RMS AAC)
cmdb_ci_ups_output
output_current
SNMP, UPS MIB
Output power (Watts)
cmdb_ci_ups_output
output_power
SNMP, UPS MIB
Bypass index
cmdb_ci_ups_bypass
bypass_index
SNMP, UPS MIB
Bypass voltage (RMS VAC)
cmdb_ci_ups_bypass
bypass_volt
SNMP, UPS MIB
Bypass current (RMS AAC)
cmdb_ci_ups_bypass
bypass_current
SNMP, UPS MIB
Bypass power (Watts)
cmdb_ci_ups_bypass
bypass_power
SNMP, UPS MIB
Alarm index
cmdb_ci_ups_alarm
alarm_index
SNMP, UPS MIB
Alarm type
cmdb_ci_ups_alarm
alarm_type
SNMP, UPS MIB
Alarm time
cmdb_ci_ups_alarm
alarm_time
SNMP, UPS MIB
Common Information Model (CIM) storage

devices
Overview
CIM probes can explore any device based on the Common Information Model (CIM) by querying a CIM server, also
referred to as a CIMOM - Common Information Model Object Manager. By default, Discovery uses CIM probes to
explore storage systems as well as to get the serial numbers of ESX servers.
Architecture
The following components are part of CIM:
Common Information Model (CIM): CIM [8] allows multiple parties to exchange information about managed
elements. CIM represents these managed elements and the management information, while providing the
mechanism to actively control and manage the elements.
Storage Management Initiative Specification (SMI-S): SMI-S [1] is a standard of use that describes methods for
storage discovery on the vendor's side. ServiceNow uses SMI-S to determine how to discover CIM. SMI-S is
based on the Common Information Model (CIM) and the Web-Based Enterprise Management (WBEM)
standards, which define management functionality via HTTP. The main objective of SMI-S is to enable
management of dissimilar storage products. ServiceNow supports SMI-S version 1.5 or higher.
Common Information Model (CIM) storage devices
Web-Based Enterprise Management (WBEM): WBEM [7] defines a particular implementation of CIM,
including protocols for discovering and accessing each CIM implementation.
Service Location Protocol (SLP): SLP [2] is an ad hoc protocol for retrieving and associating configuration
information about CIM servers, such as default paths, capabilities, and the exact interop namespace [3].
ServiceNow Discovery retrieves the interop namespace of a CIM server via SLP and passes that information to
the CIM Classify probe. SLP, referred to here as the SLP server, uses service agents (SA) to gather and
disseminate information about a CIM server on a subnet. A subnet can have multiple service agents.
246
How CIM Discovery Works

1. The Shazzam probe launches the wbem port probe as part of network discovery.
2. The wbem port probe detects activity on target ports SLP 427, CIM 5989 and 5988, and then examines the
Service Registry Queries related list, at Discovery Definition > Port Probes, for the SLP query. The base
system provides this query is provided to detect the service:wbem service type, which indicates the presence of
an SLP server.
3. The Shazzam probe launches a scanner for the WBEM service type. The scanner retrieves:
The attributes of the service from the SLP server.
The interop namespaces [3] of CIM servers in the network.
4. The scanner appends the namespace values it finds to the port probe results.
5. The wbem port probe appends the SLP data it carries to the CIM Classify probe.
6. The CIM Classify probe uses that information to explore the CIM servers.
wbem Port Probe

The wbem probe stores the data it retrieves in the CIM Classification [discovery_classy_cim] table. The wbem port
probe is defined in Discovery Definition > Port Probes.
247
SLP Query
The SLP query detects the wbem service (service:wbem) on an SLP server and gathers the attributes of the service.
To access the SLP query:

1. Navigate to Discovery Definition > Port Probes'.
2. Select the wbem port probe record.
3. From the Service Registry Queries related list, select the SLP Query.
CIM Classify Probe

The wbem port probe appends the SLP data it carries to the CIM Classify probe before launching it. The CIM
Classify probe extracts VMware ESX serial numbers and connector relationships between the SAN and NAS
components from CIM Servers in the network.
To access the CIM Classify probe:

2. Select the CIM - Classify probe.
248
Enhancements
Eureka
Provides more efficient querying of SMI-S compliant storage devices using CimIQL queries.
249
250
Software
Apache Web Servers
Data Collected by Discovery on Apache Web Servers
Label
Table Name
Field Name
Source
Name
cmdb_ci_web_server name
apcfg
Version
cmdb_ci_web_server version
httpd
Description cmdb_ci_web_server short_description httpd
JBoss Servers
Data Collected by Discovery on JBoss Servers
Label
Table Name
Field Name
Source
Name
cmdb_ci_web_service
name
jboss-service.xml
App server
cmdb_ci_web_service
app_server
Internal reference
Description
cmdb_ci_web_application short_description web.xml
Name
cmdb_ci_web_application name
web.xml
Document base cmdb_ci_web_application document_base
web.xml
App server
web.xml
cmdb_ci_web_application app_server
MySQL Servers
251
MySQL Servers
Data Collected by Discovery on MySQL Servers
Label
Table Name
Version
Field Name
Source
cmdb_ci_db_mysql_instance version
mysqld
MySQL configuration cmdb_ci_db_mysql_instance myconf
my.cnf
Oracle Databases
Data Collected by Discovery on Oracle Databases
Label
Version
Table Name
Field Name
cmdb_ci_db_ora_instance version
Source
lsnrctl
Oracle configuration cmdb_ci_db_ora_instance pfile
init.ora
SID
cmdb_ci_db_ora_instance sid
lsnrctl
Configuration
cmdb_ci_db_ora_listener
configuration Process Classifications
Oracle Home
cmdb_ci_db_ora_listener
oracle_home
Tomcat Servers
Discoverable Web Applications
Discovery can identify and classify Web applications present in either the CATALINA_BASE or
CATALINA_HOME directories.
Tables and Fields

Discovery stores information about Tomcat servers and Web applications in the following tables and fields.
Data Collected by Discovery on Tomcat Servers

Label
Table Name
Field Name
Source
Server port
cmdb_ci_app_server_tomcat server_port
server.xml
Version
cmdb_ci_app_server_tomcat version
server.info
Tomcat
cmdb_ci_tomcat_connector
tomcat
server.xml
Port
cmdb_ci_tomcat_connector
port
server.xml
App server
cmdb_ci_web_service
app_server
Internal reference
Description
cmdb_ci_web_application
short_description web.xml
Document base cmdb_ci_web_application
document_base
web.xml
Tomcat Servers
252
App server
cmdb_ci_web_application
app_server
web.xml
Websphere Servers
Data Collected by Discovery on Websphere Servers
Label
Name
Table Name
cmdb_ci_websphere_cell
Field Name
Source
name
server.xml
App server cmdb_ci_web_service
app_server
Internal reference
Name
cmdb_ci_web_service
name
server.xml
Name
cmdb_ci_web_application name
App server cmdb_ci_web_application app_server
serverindex.xml
serverindex.xml
Microsoft IIS Servers

Data Collected by Discovery on Microsoft IIS Servers
Label
Table Name
Field Name
Source
Version
cmdb_ci_web_server version
Windows registry
Name
cmdb_ci_web_site
name
wmi
Log directory
cmdb_ci_web_site
log_directory
wmi
Description
cmdb_ci_web_site
short_description wmi
Correlation ID cmdb_ci_web_site
correlation_id
Internal
IP address
cmdb_ci_web_site
ip_address
wmi
TCP port
cmdb_ci_web_site
tcp_port
wmi
Note: You must install IIS Management Scripts and Tools on a Microsoft IIS Server in order for Discovery to collect data from it.
General Software Packages
253
General Software Packages

Data Collected by Discovery on General Software Packages
Label
Table Name
Field Name
Source
Name
cmdb_ci_spkg
name
Various
Version
cmdb_ci_spkg
version
Various
Install count
cmdb_ci_spkg
install_count
Various
License count
cmdb_ci_spkg
license_count Various
Microsoft SMS ID cmdb_ci_spkg
msft_sms_id
Various
Installed on
cmdb_software_instance installed_on
Various
Software
cmdb_software_instance software
Various
VMware vCenter
Overview
These options are available for getting VMware vCenter data:
ServiceNow Discovery can run the VMWare - vCenter probe when it identifies a VMware vCenter process
running on a Windows machine.
ServiceNow Orchestration can run the VMWare - vCenter probe from a workflow.
See VMware Component Relationships for a description of the VMware architecture and component relationships.
Discovery Configuration and Process Flow

Discovery of vCenter CIs requires at least two credentials: the Windows credential for the host on which the vCenter
server runs and the VMware credential for the vCenter server. When Discovery runs, a classifier called vCenter
classifies the process running on a Windows machine and launches the VMware - vCenter probe. This probe logs
into the vCenter instance with the credentials provided and uses the vCenter API to return information about ESX
machines, virtual machines, and resource pools. If using a domain account to access vCenter, specify the domain
with the user name in the credential record in one of the supported formats such as Domain\UserName.
Note: Make sure to select a credential Type of VMware.
VMware vCenter
254
Orchestration Configuration and Workflow

Administrators can configure configure instances with Orchestration to run a workflow called Discover vCenter to
populate the CMDB with vCenter data without having to activate the Discovery plugin. This workflow is particularly
useful for an administrator who has just installed vCenter and wants to begin using it for cloud provisioning, but has
not purchased Discovery. This workflow is available starting with the Calgary release.
The workflow resolves the DNS name and populates the CMDB by running the standard VMware - vCenter probe
(installed by default). You must have a properly configured MID Server connected to the ServiceNow instance to
use this feature.
You can discover a vCenter instance using one of these methods available on the VMware vCenter Instance form:
Discover vCenter Details: This related link is available to users with the vmware_operator role.
Scheduled discoveries: Users with the cloud_admin role can create and edit scheduled discoveries from this
related list. Users with the vmware_operator role can view scheduled discoveries.
Note: For more information about these roles and capabilities, see Cloud Provisioning Security.
To discover a single vCenter instance:

2. Select the vCenter instance you want to discover.
3. Under Related Links, click Discover vCenter Details.
The list of vCenter instances appears. ServiceNow sends you an email confirmation when the scan is
complete.
To create a scheduled discovery:

VMware vCenter
255
2.
3.
4.
5.
Select the vCenter instance you want to discover.

Click New in the Scheduled discoveries related list.
Enter a unique and descriptive name for this schedule.
Select the day and time to run this discovery, using the field descriptions from the Discovery Schedules form as a
reference.
6. [Optional] Select the Conditional check box to script a condition that defines a custom run time.
7. Click Submit.
The Discovery vCenter workflow runs in silent mode for this type of discovery and does not send
notifications.
8. Click Execute Now to run this discovery immediately.
vCenter Data Collected

Discovery and Orchestration collect the following data for VMware vCenter servers.
Tables and Fields

Field Label
Table Name
Column Name
Source
API version
api_version
Full name
fullname
Instance UUID
instance_uuid
URL
url
Effective CPU
effectivecpu
Effective memory
effectivememory VMWare - vCenter probe
Number of effective hosts
effectivehosts
Number of hosts
numhosts
Total CPU
totalcpu
Total memory
totalmemory
VMware vCenter
256
Top level folder for hosts
host_morid
Top level folder for VMs
folder_morid
Accessible
accessible
Capacity (GB)
capacity
Free space (GB)
freespace
Type
type
URL
url
Full path
VMware vCenter Folder [cmdb_ci_vcenter_folder]
fullpath
Accessible
VMware vCenter Network [cmdb_ci_vcenter_network]
accessible
Managed object reference ID VMware vCenter Object [cmdb_ci_vcenter_object]
morid
vCenter Instance UUID
vcenter_uuid
vCenter Reference
vcenter_ref
Managed object reference ID VMware vCenter Server Object [cmdb_ci_vcenter_server_obj] morid
Folder
folder
Type
type
Relationships
Discovery automatically creates relationships for vCenter components using data from a key class. Subsequent
Discoveries use the same key class to automatically validate and remove relationships that are no longer valid.
Parent Class
Relationship Type
Child Class
Relationship Key
Class

Child

Connected by::Connects

Parent

Provided by::Provides
Parent

Provides storage for::Stored

on

Parent

Used by::Uses
Child

Members::Member of
Child
ESX Resource Pool


resources from

Parent
ESX Resource Pool


resources from
Parent


Parent


Parent

Virtual Machine Template

[cmdb_ci_vmware_template]
Parent
VMware vCenter
257


Parent


Parent


Parent

Parent


Parent


Parent
Enhancements
Eureka
Automatically validates and updates relationships for vCenter CIs. This process also removes stale relationships.
In addition to the new logic to remove stale relationships, code existed in previous versions to perform the
following tasks:
Remove records in the cmdb_ci_vmware_instance table that are no longer associated to a record in the
cmdb_ci_esx_server table, including the corresponding Registered on::Has registered relationship.
Remove records in the cmdb_ci_computer table that are no longer associated to a record in the
cmdb_ci_esx_server table with a Virtualized by::Virtualizes relationship.
Remove duplicate records in the cmdb_ci_vcenter table that have the same instance_uuid or ip_address fields
as the CI that is currently being discovered.
Calgary
An Orchestration workflow Discover vCenter can populate the CMDB with vCenter data without having to
install the Discovery plugin. See Orchestration Configuration and Workflow.
258
Other Stuff
Services/Daemons
Data Collected by Discovery on Services and Daemons
Label
Table Name
Field Name
Source
Name
cmdb_ip_service
name
Various
Port
cmdb_ip_service
port
Various
Description cmdb_ip_service_ci description
Various
CI
cmdb_ip_service_ci ci
Internal reference
Service
cmdb_ip_service_ci service
Internal reference
IP Addresses
Data Collected by Discovery on IP Addresses
Label
Table Name
Field Name
Source
IP Address
discovery_ip_address ip_address
Various internal
Hostname
discovery_ip_address host_name
Various internal
Discovered
discovery_ip_address discovered
Various internal
Agent
discovery_ip_address agent
Various internal
Discoverer
discovery_ip_address discoverer
Various internal
In Ranges
discovery_ip_address in_ranges
Various internal
MAC address
discovery_ip_address mac
Various internal
CMDB CI
discovery_ip_address cmdb_ci
Various internal
SSH attempted
discovery_ip_address ssh_attempted
Various internal
SNMP attempted discovery_ip_address snmp_attempted Various internal
IP Networks
259
IP Networks
Data Collected by Discovery on IP Networks
Label
Table Name
Field Name
Source
Discover
cmdb_ci_ip_network discover
Various internal
Subnet
cmdb_ci_ip_network subnet
Various internal
Network discovery cmdb_ci_ip_network network_discovery Various internal

Last discovered
cmdb_ci_ip_network last_discovered
Various internal
MID server
cmdb_ci_ip_network mid_server
Various internal
Router
cmdb_ci_ip_network router
Various internal
State
cmdb_ci_ip_network state
Various internal
Relationships
Data Collected by Discovery on Relationships
Label
Table Name
Field Name
Source
Parent
cmdb_rel_ci
parent
Internal
Child
cmdb_rel_ci
child
Internal
Type
cmdb_rel_ci
type
Internal
Connections
260
Connections
Tables and Fields
Discovery stores information about TCP connections in the following tables and fields.
Label
Absent
Table Name
cmdb_tcp
Computer cmdb_tcp
Field Name
Source
absent
Internal
computer
Internal
IP
cmdb_tcp_connection ip
Internal
PID
cmdb_tcp
pid
Internal
Port
cmdb_tcp
port
Internal
Process
cmdb_tcp
process
Internal
Type
cmdb_tcp
type
Internal

Discovery stores information about TCP connections in the following tables and fields on releases prior to Dublin.
Label
Table Name
Field Name
Source
Application cmdb_tcp_half
application
Internal
Computer
cmdb_tcp_half
computer
Internal
PID
cmdb_tcp_half
pid
Internal
Command
cmdb_tcp_half
command
Internal
From IP
cmdb_tcp_half
from_ip
Internal
From port
cmdb_tcp_half
from_port
Internal
To IP
cmdb_tcp_half
to_ip
Internal
To port
cmdb_tcp_half
to_port
Internal
Type
cmdb_tcp_half
type
Internal
Computer
cmdb_tcp_connection computer
Internal
PID
cmdb_tcp_connection pid
Internal
Command
cmdb_tcp_connection command
Internal
From IP
cmdb_tcp_connection from_ip
Internal
From port
cmdb_tcp_connection from_port
Internal
To IP
cmdb_tcp_connection to_ip
Internal
To port
cmdb_tcp_connection to_port
Internal
State
cmdb_tcp_connection state
Internal
Connections
261
Enhancements
Dublin
The Running Processes [cmdb_running_process] table contains new fields (listening_to and connecting_to) to
track the list of TCP ports a process listens on and connects to.
A new table TCP Connections [cmdb_tcp] replaces the cmdb_tcp_connection and cmdb_tcp_half tables.
The Application Instance [cmdb_ci_appl] table contains new fields to track the classifier that created the instance
record and the running process that matched the classifier.
F5 BIG-IP
Discovery of F5 BIG-IP Load Balancers
Discovery of F5 BIG-IP load balancers is performed by SNMP. VMware images of BIG-IP for testing are available
with free 90-day keys: https://www.f5.com/trial.
Discovery for F5 BIG-IP load balancers is available starting with the Dublin release.
Model
The F5 BIG-IP load balancer model represents a generic load balancer and its components. The abstract class is
Load Balancer (cmdb_ci_lb). The implementation class, extended from Load Balancer, is F5 BIGIP
(cmdb_ci_lb_bigip). The load balancer components are modeled as follows.
Component
Table Name
Description
cmdb_ci_lb_service
A virtual service that the device balances by forwarding requests to members within a
pool.
Load Balancer Pool
cmdb_ci_lb_pool
A collection of host-to-port mappings to be balanced.
Load Balancer Pool Member
cmdb_ci_lb_pool_member A host-to-port mapping of a request to be balanced.
Load Balancer VLAN
cmdb_ci_lb_vlan
Load Balancer VLAN

Member
cmdb_ci_lb_vlan_member A map of an interface to a VLAN.
A virtual LAN segment.
A network interface.
Storage Devices
262
Storage Devices
Overview
Discovery uses CIM probes to explore storage systems based on the Common Information Model (CIM) such as
Storage Area Network (SAN) and Network-Attached Storage (NAS) components. The CIM probe uses WBEM
protocols to query a particular CIM server, the CIM Object Manager, for a set of data objects and properties. For
more information, see CIM Discovery.
Tables and Fields

Discovery uses the following tables and fields for storage devices.
Label
Table Name
Field Name
sys_id
Source
Sys ID
Storage Disk [cmdb_ci_storage_disk]
N/A
File Share ID
Storage File Share [cmdb_ci_storage_fileshare] fileshare_id
CIM probe
Path
Storage File Share [cmdb_ci_storage_fileshare] path
CIM probe
Disk space (GB)
Storage Pool [cmdb_ci_storage_pool]
disk_space
CIM probe
Pool ID
Storage Pool [cmdb_ci_storage_pool]
pool_id
CIM probe
Speed (GFC)
Storage Port [cmdb_ci_storage_port]
speed
CIM probe
WWPN
Storage Port [cmdb_ci_storage_port]
wwpn
CIM probe
Device ID
Storage HBA [cmdb_ci_storage_hba]
device_id
CIM probe
Firmware version Storage Server [cmdb_ci_storage_server]
firmware_version CIM probe
Disk Space (GB)
Storage Volume [cmdb_ci_storage_volume]
disk_space
CIM probe
LUN
lun
CIM probe
Storage Relationships
Discovery establishes the correct relationships between Network-Attached Storage (NAS) storage devices and
remotely mounted client servers that consume the storage. Discovery maps NAS file shares by matching the IP or
hostname of a remotely-mounted disk on the client computer to the IP or hostname of the storage server providing
the exported file system.
Storage relationships are available starting with the Eureka release.
Linux CI Relationships
Discovery creates the following relationships for storage CIs running on Linux OS hosts.
Storage Devices
263
Parent Component
Relationship
Child Component
Storage File Share [cmdb_ci_storage_fileshare] Allocated from::Allocated to File System [cmdb_ci_file_system]

Allocated from::Allocated to File System [cmdb_ci_file_system]
Windows CI Relationships
Discovery creates the following relationships for storage CIs running on Windows OS hosts.
Parent Component
Relationship
Child Component
Storage File Share [cmdb_ci_storage_fileshare] Allocated from::Allocated to Disk [cmdb_ci_disk]

Allocated from::Allocated to Disk [cmdb_ci_disk]
Storage NAS Host

Discovery maps NAS file shares by matching the IP or hostname of a remotely mounted disk on the client computer
to the IP or hostname of the storage server providing the exported file system.
Parent Component
Relationship
Child Component
Storage Server [cmdb_ci_storage_server] Allocated from::Allocated to Storage File Share [cmdb_ci_storage_fileshare]
Article Sources and Contributors

Getting Started Source: http://wiki.servicenow.com/index.php?oldid=219174 Contributors: Bow, CapaJC, G.yedwab, Guy.yedwab, Joseph.messerschmidt, Pat.Casey, Steven.wood, Valor,
Vaughn.romero, Vhearne
Discovery Made Easy Source: http://wiki.servicenow.com/index.php?oldid=191686 Contributors: Bow, CapaJC, G.yedwab, Guy.yedwab, Ishrath.razvi, Jerrod.bennett, Joseph.messerschmidt,
Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Discovery Agentless Architecture Source: http://wiki.servicenow.com/index.php?oldid=237898 Contributors: Bow, CapaJC, Chuck.tomasi, Dan.greenbaum, Dawn.bunting, G.yedwab,
Guy.yedwab, Joseph.messerschmidt, Publishing.user, Rob.woodbyrne, Steven.wood, Vaughn.romero, Vhearne
Setting up Discovery Source: http://wiki.servicenow.com/index.php?oldid=225231 Contributors: CapaJC, Cheryl.dolan, David.Bailey, Emily.partridge, Joseph.messerschmidt, Steven.wood,
Vaughn.romero
MID Server Plugin Source: http://wiki.servicenow.com/index.php?oldid=89866 Contributors: Aburruss, Bow, CapaJC, Cheryl.dolan, Christen.mitchell, Chuck.tomasi, Dan.sherwin, David
Loo, David.Bailey, Dawn.bunting, Doogiesd, G.yedwab, Guy.yedwab, Jeremiah.hall, John.andersen, John.roberts, Joseph.messerschmidt, Mark.odonnell, Neola, Phillip.salzman, Publishing.user,
Rob.woodbyrne, Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
MID Server Requirements for Discovery Source: http://wiki.servicenow.com/index.php?oldid=67960 Contributors: Bow, CapaJC, David Loo, Doogiesd, Gadi.yedwab, Guy.yedwab,
Joseph.messerschmidt, Rob.woodbyrne, Steven.wood, Valor, Vaughn.romero, Vhearne
MID Server Installation Source: http://wiki.servicenow.com/index.php?oldid=239231 Contributors: Joseph.messerschmidt, Katharine.sohler, Phillip.salzman, Publishing.user, Rachel.sienko,
Steven.wood, Vaughn.romero
Deploying Multiple MID Servers Source: http://wiki.servicenow.com/index.php?oldid=207788 Contributors: CapaJC, Chuck.tomasi, Joseph.messerschmidt, Peter.smith, Steven.wood
MID Server Configuration Source: http://wiki.servicenow.com/index.php?oldid=238965 Contributors: Aleck.lin, Bow, Cheryl.dolan, David.Bailey, Dawn.bunting, Emily.partridge,
Guy.yedwab, Jim.holthaus, Joseph.messerschmidt, Publishing.user, Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne, Voytek.blonski
MID Server Clusters Source: http://wiki.servicenow.com/index.php?oldid=191732 Contributors: Joseph.messerschmidt, Steven.wood
Controlling the MID Server Version Source: http://wiki.servicenow.com/index.php?oldid=232589 Contributors: Dawn.bunting, Emily.partridge, Joseph.messerschmidt, Rachel.sienko,
Steven.wood
MID Server Heartbeat Source: http://wiki.servicenow.com/index.php?oldid=103817 Contributors: Joseph.messerschmidt, Steven.wood, Tom.dilatush
MID Server User Security Source: http://wiki.servicenow.com/index.php?oldid=103753 Contributors: Cheryl.dolan, Joseph.messerschmidt, Neola, Steven.wood
Shazzam Probe Source: http://wiki.servicenow.com/index.php?oldid=224211 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Rachel.sienko, Steven.wood, Tom.dilatush,
Vaughn.romero
Port Probes Source: http://wiki.servicenow.com/index.php?oldid=191739 Contributors: Aleck.lin, Ishrath.razvi, Joseph.messerschmidt, Steven.wood
CIM Probe Source: http://wiki.servicenow.com/index.php?oldid=225127 Contributors: Cheryl.dolan, George.rawlins, Joseph.messerschmidt, Roy Laurie, Vaughn.romero
Database Catalogs Source: http://wiki.servicenow.com/index.php?oldid=191665 Contributors: G.yedwab, Joseph.messerschmidt, Rachel.sienko, Steven.wood
Custom Probe - Text File Source: http://wiki.servicenow.com/index.php?oldid=194006 Contributors: CapaJC, Doogiesd, G.yedwab, Guy.yedwab, Joseph.messerschmidt, Michael.randall,
Neola, Rachel.sienko, Steven.wood
Device Classifications Source: http://wiki.servicenow.com/index.php?oldid=191668 Contributors: Aleck.lin, David.Bailey, Emily.partridge, G.yedwab, Joseph.messerschmidt, Steven.wood,
Vaughn.romero
Process Classifications Source: http://wiki.servicenow.com/index.php?oldid=214882 Contributors: Aleck.lin, Cheryl.dolan, George.rawlins, Joseph.messerschmidt, Rachel.sienko,
Steven.wood, Vaughn.romero
Discovery Classification Parameters Source: http://wiki.servicenow.com/index.php?oldid=191684 Contributors: G.yedwab, Joseph.messerschmidt, Steven.wood, Tom.dilatush
Discovery Identifiers Source: http://wiki.servicenow.com/index.php?oldid=231121 Contributors: Aleck.lin, Cheryl.dolan, Dawn.bunting, G.yedwab, Joseph.messerschmidt, Peter.smith,
Steven.wood, Tom.dilatush
Credentials Source: http://wiki.servicenow.com/index.php?oldid=239195 Contributors: Aleck.lin, Bow, CapaJC, Cheryl.dolan, Dawn.bunting, Doogiesd, G.yedwab, George.rawlins,
Guy.yedwab, Joseph.messerschmidt, Phillip.salzman, Rachel.sienko, Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne, Voytek.blonski
Discovery Schedules Source: http://wiki.servicenow.com/index.php?oldid=224192 Contributors: David.Bailey, G.yedwab, Joseph.messerschmidt, Steven.wood, Vaughn.romero,
Voytek.blonski
Network Discovery Source: http://wiki.servicenow.com/index.php?oldid=234053 Contributors: Aleck.lin, Chuck.tomasi, G.yedwab, Joseph.messerschmidt, Steven.wood, Suzanne.smith
Discovery Status Source: http://wiki.servicenow.com/index.php?oldid=215612 Contributors: Cheryl.dolan, David.Bailey, G.yedwab, Joseph.messerschmidt, Steven.wood, Vaughn.romero,
Voytek.blonski
Discovery Timelines Source: http://wiki.servicenow.com/index.php?oldid=191694 Contributors: Joseph.messerschmidt, Steven.wood, Wallymarx
Resource Throttling Source: http://wiki.servicenow.com/index.php?oldid=191689 Contributors: Joseph.messerschmidt, Steven.wood, Vaughn.romero
External Credential Storage Source: http://wiki.servicenow.com/index.php?oldid=232464 Contributors: Cheryl.dolan, David.Bailey, Joseph.messerschmidt, Steven.wood, Vaughn.romero
Application Profile Discovery Source: http://wiki.servicenow.com/index.php?oldid=232373 Contributors: Cheryl.dolan, George.rawlins, Joseph.messerschmidt, Rachel.sienko, Steven.wood,
Vaughn.romero
Example Source: http://wiki.servicenow.com/index.php?oldid=191637 Contributors: Joseph.messerschmidt, Michelle.Corona, Vaughn.romero
Customization Source: http://wiki.servicenow.com/index.php?oldid=237123 Contributors: Cheryl.dolan, Joseph.messerschmidt, Steven.wood
DiscoverNow Source: http://wiki.servicenow.com/index.php?oldid=191672 Contributors: Cheryl.dolan, Joseph.messerschmidt, Rachel.sienko, Steven.wood, Vaughn.romero
PowerShell Source: http://wiki.servicenow.com/index.php?oldid=238967 Contributors: Cheryl.dolan, Dawn.bunting, Emily.partridge, George.rawlins, Jim.holthaus, Joseph.messerschmidt,
Publishing.user, Rachel.sienko, Steven.wood, Vaughn.romero
VMware vCenter Source: http://wiki.servicenow.com/index.php?oldid=236057 Contributors: Cheryl.dolan, Dawn.bunting, Ishrath.razvi, Joseph.messerschmidt, Steven.wood, Vaughn.romero
Hyper-V Source: http://wiki.servicenow.com/index.php?oldid=191706 Contributors: Joseph.messerschmidt, Rachel.sienko, Steven.wood, Vaughn.romero
CIM Discovery Source: http://wiki.servicenow.com/index.php?oldid=232455 Contributors: Joseph.messerschmidt, Rachel.sienko, Steven.wood, Vaughn.romero
264

SQL Server Clusters Source: http://wiki.servicenow.com/index.php?oldid=239225 Contributors: Byukich, Cheryl.dolan, Joseph.messerschmidt, Publishing.user, Rachel.sienko, Steven.wood
Discovery Behavior Source: http://wiki.servicenow.com/index.php?oldid=120680 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Rachel.sienko, Russ.sarbora, Steven.wood
Discovery Behavior - Load Balancing Source: http://wiki.servicenow.com/index.php?oldid=120682 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Steven.wood
Discovery Behavior - Multiple Domains Source: http://wiki.servicenow.com/index.php?oldid=120684 Contributors: G.yedwab, Joseph.messerschmidt, Steven.wood
Discovery Behavior - Access Control Lists (ACL) Source: http://wiki.servicenow.com/index.php?oldid=120686 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Steven.wood
Discovery FAQ Source: http://wiki.servicenow.com/index.php?oldid=238165 Contributors: Aleck.lin, Bow, CapaJC, Cheryl.dolan, Dan.greenbaum, Dawn.bunting, Doogiesd, Fred.luddy,
Guy.yedwab, Joseph.messerschmidt, Rob.phillips, Steven.wood, Tom.dilatush, Vhearne
Discovery Bandwidth Source: http://wiki.servicenow.com/index.php?oldid=191677 Contributors: Dan.sherwin, G.yedwab, Guy.yedwab, John.roberts, Joseph.messerschmidt, Steven.wood,
Vhearne
Discovery Resource Utilization Source: http://wiki.servicenow.com/index.php?oldid=191690 Contributors: Bow, CapaJC, Doogiesd, G.yedwab, Guy.yedwab, Joseph.messerschmidt,
Steven.wood, Tom.dilatush, Vhearne
Application Dependency Mapping Source: http://wiki.servicenow.com/index.php?oldid=232110 Contributors: Cheryl.dolan, Dan.sherwin, Eprokopow@enernoc.com, G.yedwab,
George.rawlins, Guy.yedwab, Joseph.messerschmidt, Rob.phillips, Rob.woodbyrne, Steven.wood, Vaughn.romero, Vhearne
VMware Component Relationships Source: http://wiki.servicenow.com/index.php?oldid=191768 Contributors: Aleck.lin, Joseph.messerschmidt, Steven.wood
Hyper-V Component Relationships Source: http://wiki.servicenow.com/index.php?oldid=191688 Contributors: Joseph.messerschmidt, Steven.wood, Vaughn.romero
Windows Source: http://wiki.servicenow.com/index.php?oldid=202637 Contributors: Aleck.lin, G.yedwab, Joseph.messerschmidt, Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Solaris Source: http://wiki.servicenow.com/index.php?oldid=219298 Contributors: Aleck.lin, Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Linux Source: http://wiki.servicenow.com/index.php?oldid=190269 Contributors: Aleck.lin, George.rawlins, Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Linux Kernel-based Virtual Machines (KVM) Source: http://wiki.servicenow.com/index.php?oldid=189789 Contributors: Vaughn.romero
HPUX Source: http://wiki.servicenow.com/index.php?oldid=160154 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
AIX Source: http://wiki.servicenow.com/index.php?oldid=197639 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Mac Source: http://wiki.servicenow.com/index.php?oldid=191195 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Solaris Zones Source: http://wiki.servicenow.com/index.php?oldid=160162 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Netware Source: http://wiki.servicenow.com/index.php?oldid=160163 Contributors: Steven.wood, Vaughn.romero
ESX Servers Source: http://wiki.servicenow.com/index.php?oldid=191305 Contributors: Joseph.messerschmidt, Vaughn.romero
Routers Source: http://wiki.servicenow.com/index.php?oldid=190359 Contributors: George.rawlins, Ishrath.razvi, Joseph.messerschmidt, Ludwig.adriaansen, Steven.wood, Tom.dilatush,
Switches Source: http://wiki.servicenow.com/index.php?oldid=190359 Contributors: George.rawlins, Ishrath.razvi, Joseph.messerschmidt, Ludwig.adriaansen, Steven.wood, Tom.dilatush,
Network Printers Source: http://wiki.servicenow.com/index.php?oldid=160168 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Uninterruptible Power Supplies (UPSs) Source: http://wiki.servicenow.com/index.php?oldid=160170 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Common Information Model (CIM) storage devices Source: http://wiki.servicenow.com/index.php?oldid=232455 Contributors: Joseph.messerschmidt, Rachel.sienko, Steven.wood,
Vaughn.romero
Apache Web Servers Source: http://wiki.servicenow.com/index.php?oldid=160172 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
JBoss Servers Source: http://wiki.servicenow.com/index.php?oldid=160175 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
MySQL Servers Source: http://wiki.servicenow.com/index.php?oldid=160178 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Oracle Databases Source: http://wiki.servicenow.com/index.php?oldid=204946 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Tomcat Servers Source: http://wiki.servicenow.com/index.php?oldid=200432 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Websphere Servers Source: http://wiki.servicenow.com/index.php?oldid=160185 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Microsoft IIS Servers Source: http://wiki.servicenow.com/index.php?oldid=203911 Contributors: Doogiesd, Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
General Software Packages Source: http://wiki.servicenow.com/index.php?oldid=160189 Contributors: Doogiesd, Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
VMware vCenter Source: http://wiki.servicenow.com/index.php?oldid=236057 Contributors: Cheryl.dolan, Dawn.bunting, Ishrath.razvi, Joseph.messerschmidt, Steven.wood, Vaughn.romero
Services/Daemons Source: http://wiki.servicenow.com/index.php?oldid=160192 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
IP Addresses Source: http://wiki.servicenow.com/index.php?oldid=160193 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
IP Networks Source: http://wiki.servicenow.com/index.php?oldid=160194 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Relationships Source: http://wiki.servicenow.com/index.php?oldid=160196 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
Connections Source: http://wiki.servicenow.com/index.php?oldid=191200 Contributors: Steven.wood, Tom.dilatush, Vaughn.romero, Vhearne
F5 BIG-IP Source: http://wiki.servicenow.com/index.php?oldid=189854 Contributors: Vaughn.romero
Storage Devices Source: http://wiki.servicenow.com/index.php?oldid=238215 Contributors: Dawn.bunting, Joseph.messerschmidt, Michael.randall, Publishing.user, Vaughn.romero
265
Image Sources, Licenses and Contributors

Image:Tick.png Source: http://wiki.servicenow.com/index.php?title=File:Tick.png License: unknown Contributors: Mark.odonnell, Publishing.user
Image:Discovery class.jpg Source: http://wiki.servicenow.com/index.php?title=File:Discovery_class.jpg License: unknown Contributors: Bow
Image:MID_Server_Probe_Simple_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Probe_Simple_Diagram.png License: unknown Contributors:
Steven.wood
Image:Discovery_Communications_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Communications_Diagram.png License: unknown Contributors:
Publishing.user, Steven.wood, Vaughn.romero
Image:Warning.gif Source: http://wiki.servicenow.com/index.php?title=File:Warning.gif License: unknown Contributors: CapaJC
Image:Discovery_Data_Collection_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Data_Collection_Diagram.png License: unknown Contributors:
Publishing.user, Steven.wood, Vaughn.romero
Image:discovery_ecc_queue_view.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_ecc_queue_view.png License: unknown Contributors: Maintenance script
Image:Discovery_Log2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Log2.png License: unknown Contributors: Maintenance script, Steven.wood
Image:Discovery_CI_Sources.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_CI_Sources.png License: unknown Contributors: Steven.wood
Image:JAR_File_Sync.png Source: http://wiki.servicenow.com/index.php?title=File:JAR_File_Sync.png License: unknown Contributors: Steven.wood
Image:mid server menu.png Source: http://wiki.servicenow.com/index.php?title=File:Mid_server_menu.png License: unknown Contributors: Vaughn.romero
Image:MID_Server_Download_Dublin.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Download_Dublin.png License: unknown Contributors: Vaughn.romero
Image:Caution-diamond.png Source: http://wiki.servicenow.com/index.php?title=File:Caution-diamond.png License: unknown Contributors: John.roberts, Publishing.user
Image:MID config.png Source: http://wiki.servicenow.com/index.php?title=File:MID_config.png License: unknown Contributors: Steven.wood, Tom.dilatush
Image:MID config xml.png Source: http://wiki.servicenow.com/index.php?title=File:MID_config_xml.png License: unknown Contributors: Tom.dilatush
Image:MID_Server_Script_File_Sync.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Script_File_Sync.png License: unknown Contributors: Steven.wood
Image:MID_Server_Script_File_Sync2.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Script_File_Sync2.png License: unknown Contributors: Steven.wood
Image:MID_Server_Unblock_Config.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Unblock_Config.png License: unknown Contributors: Steven.wood
Image:MID_Server_Clusters_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Clusters_Diagram.png License: unknown Contributors: Steven.wood
Image:MID_Server_Cluster1.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Cluster1.png License: unknown Contributors: Steven.wood
Image:MID_Server_Monitor_Interval.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Monitor_Interval.png License: unknown Contributors: Steven.wood
Image:MID_Server_Roles.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Roles.png License: unknown Contributors: Steven.wood
Image:Discovery Port Probe2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Port_Probe2.png License: unknown Contributors: Steven.wood
Image:Database Catalog Menu.gif Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalog_Menu.gif License: unknown Contributors: Steven.wood
Image:Database Catalog2.png Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalog2.png License: unknown Contributors: Steven.wood
Image:Database Catalogs1.gif Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalogs1.gif License: unknown Contributors: Steven.wood
Image:Database Catalog Form.gif Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalog_Form.gif License: unknown Contributors: Steven.wood
Image:Probe_Parameters.png Source: http://wiki.servicenow.com/index.php?title=File:Probe_Parameters.png License: unknown Contributors: Steven.wood
Image:Newprobe.png Source: http://wiki.servicenow.com/index.php?title=File:Newprobe.png License: unknown Contributors: Doogiesd, Steven.wood
Image:Newsensor.png Source: http://wiki.servicenow.com/index.php?title=File:Newsensor.png License: unknown Contributors: Doogiesd, Steven.wood
Image:Discovery Identifiers Diagram.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers_Diagram.gif License: unknown Contributors: Steven.wood
Image:Discovery Classification Diagram.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Diagram.gif License: unknown Contributors: Steven.wood
Image:Discovery Classification Win Server.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Win_Server.png License: unknown Contributors:
Steven.wood
Image:Discovery Classification Criteria2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Criteria2.png License: unknown Contributors: Steven.wood
Image:Reclassify_XP1.png Source: http://wiki.servicenow.com/index.php?title=File:Reclassify_XP1.png License: unknown Contributors: Steven.wood
Image:Reclassify_XP2.png Source: http://wiki.servicenow.com/index.php?title=File:Reclassify_XP2.png License: unknown Contributors: Steven.wood
Image:when_process_classification_runs.png Source: http://wiki.servicenow.com/index.php?title=File:When_process_classification_runs.png License: unknown Contributors:
Vaughn.romero
Image:process_classification_workflow.png Source: http://wiki.servicenow.com/index.php?title=File:Process_classification_workflow.png License: unknown Contributors: Vaughn.romero
Image:process_classification_workflow_pre-dublin.png Source: http://wiki.servicenow.com/index.php?title=File:Process_classification_workflow_pre-dublin.png License: unknown
Contributors: Vaughn.romero
Image:process_classification.png Source: http://wiki.servicenow.com/index.php?title=File:Process_classification.png License: unknown Contributors: George.rawlins, Vaughn.romero
Image:Discovery Classification Process.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Process.gif License: unknown Contributors: Steven.wood
Image:Discovery Classification Criteria.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Criteria.gif License: unknown Contributors: Steven.wood
Image:pending_process_classification.png Source: http://wiki.servicenow.com/index.php?title=File:Pending_process_classification.png License: unknown Contributors: George.rawlins
Image:review_process_applications.png Source: http://wiki.servicenow.com/index.php?title=File:Review_process_applications.png License: unknown Contributors: George.rawlins,
Vaughn.romero
Image:create_application_table.png Source: http://wiki.servicenow.com/index.php?title=File:Create_application_table.png License: unknown Contributors: Vaughn.romero
Image:processor_class_add_conditions.png Source: http://wiki.servicenow.com/index.php?title=File:Processor_class_add_conditions.png License: unknown Contributors: George.rawlins,
Vaughn.romero
Image:create_ignore_process_handler.png Source: http://wiki.servicenow.com/index.php?title=File:Create_ignore_process_handler.png License: unknown Contributors: Vaughn.romero
Image:dublin_process_handler.png Source: http://wiki.servicenow.com/index.php?title=File:Dublin_process_handler.png License: unknown Contributors: Vaughn.romero
Image:Discovery Classifier Criteria New2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classifier_Criteria_New2.gif License: unknown Contributors: Steven.wood
Image:Discovery Nmap Scan.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Nmap_Scan.gif License: unknown Contributors: Steven.wood
Image:Discovery IP Service.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_IP_Service.gif License: unknown Contributors: Steven.wood
Image:Discovery Functionality Def.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Functionality_Def.gif License: unknown Contributors: Steven.wood
Image:Discovery Port Probe.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Port_Probe.gif License: unknown Contributors: Steven.wood
Image:Discovery Application Classifier.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Application_Classifier.gif License: unknown Contributors: Steven.wood
Image:Discovery XML Parameters.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_XML_Parameters.gif License: unknown Contributors: Steven.wood
Image:Discovery XML Parameters2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_XML_Parameters2.gif License: unknown Contributors: Steven.wood
Image:Discovery Classification Parameter.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Parameter.gif License: unknown Contributors: Steven.wood
Image:Discovery Mode CI Item.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Mode_CI_Item.png License: unknown Contributors: Steven.wood
Image:Discovery Multiprobe Select.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Multiprobe_Select.gif License: unknown Contributors: Steven.wood
Image:Discovery Multisensor and Script.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Multisensor_and_Script.gif License: unknown Contributors: Steven.wood
Image:Discovery Classification Identity Probe.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Identity_Probe.png License: unknown Contributors:
Steven.wood
266

Image:Discovery Identifiers2 Diagram.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers2_Diagram.gif License: unknown Contributors: Steven.wood
Image:Discovery Identifiers Form.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers_Form.png License: unknown Contributors: Steven.wood
Image:Discovery Identifiers Order.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers_Order.png License: unknown Contributors: Steven.wood
Image:Credentials_Affinity_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Credentials_Affinity_Diagram.png License: unknown Contributors: Steven.wood
Image:Discovery Credentials.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Credentials.png License: unknown Contributors: Steven.wood
Image:discovery_schedule_post_calgary.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_schedule_post_calgary.png License: unknown Contributors: Vaughn.romero
Image:Discovery Quick Ranges_Calgary.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Quick_Ranges_Calgary.png License: unknown Contributors: Steven.wood
Image:Discovery_Quick_Ranges2_Calgary.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Quick_Ranges2_Calgary.png License: unknown Contributors:
Steven.wood
Image:Exclude_IP_Address_Calgary.png Source: http://wiki.servicenow.com/index.php?title=File:Exclude_IP_Address_Calgary.png License: unknown Contributors: Steven.wood
Image:Exclude_IP_Address_Calgary1.png Source: http://wiki.servicenow.com/index.php?title=File:Exclude_IP_Address_Calgary1.png License: unknown Contributors: Steven.wood
Image:Private_IP_Addresses.png Source: http://wiki.servicenow.com/index.php?title=File:Private_IP_Addresses.png License: unknown Contributors: Steven.wood
Image:Network_Discovery_Schedule.png Source: http://wiki.servicenow.com/index.php?title=File:Network_Discovery_Schedule.png License: unknown Contributors: Steven.wood
Image:IP_Network_Form.png Source: http://wiki.servicenow.com/index.php?title=File:IP_Network_Form.png License: unknown Contributors: Steven.wood
Image:IP_Network_List.png Source: http://wiki.servicenow.com/index.php?title=File:IP_Network_List.png License: unknown Contributors: Steven.wood
Image:Discovery_Status.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Status.png License: unknown Contributors: Steven.wood
Image:Discovery Log2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Log2.gif License: unknown Contributors: Steven.wood
Image:Discovery Log3.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Log3.gif License: unknown Contributors: Steven.wood
Image:Discovery Device List.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Device_List.png License: unknown Contributors: Steven.wood
Image:Discovery Device.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Device.png License: unknown Contributors: Steven.wood
Image:Discovery Details.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Details.png License: unknown Contributors: Steven.wood
Image:Discovery_Status_IPs.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Status_IPs.png License: unknown Contributors: Steven.wood
Image:Discovery ECC Queue.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_ECC_Queue.gif License: unknown Contributors: Steven.wood
Image:Discovery_Timeline_Related_Link.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline_Related_Link.png License: unknown Contributors: Steven.wood
Image:Discovery Timeline.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline.png License: unknown Contributors: Steven.wood
Image:Discovery_Timeline_Shazzam_Sensor.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline_Shazzam_Sensor.png License: unknown Contributors:
Steven.wood
Image:Discovery_Timeline_ECC_Queue.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline_ECC_Queue.png License: unknown Contributors: Steven.wood
File:Throttling_Scheduled.png Source: http://wiki.servicenow.com/index.php?title=File:Throttling_Scheduled.png License: unknown Contributors: Steven.wood
File:Throttling_Scheduled_Items.png Source: http://wiki.servicenow.com/index.php?title=File:Throttling_Scheduled_Items.png License: unknown Contributors: Steven.wood
File:Throttling_Message.png Source: http://wiki.servicenow.com/index.php?title=File:Throttling_Message.png License: unknown Contributors: Steven.wood
Image:Discovery_Credentials_HS.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Credentials_HS.png License: unknown Contributors: Steven.wood
Image:Application_Discovery_Instrumentation_Diagram_Rev.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Discovery_Instrumentation_Diagram_Rev.png
License: unknown Contributors: George.rawlins
File:APD_Win_Registry.png Source: http://wiki.servicenow.com/index.php?title=File:APD_Win_Registry.png License: unknown Contributors: Steven.wood
Image:ADI_Properties.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Properties.png License: unknown Contributors: Steven.wood
Image:ADI_Example_Environment.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Example_Environment.png License: unknown Contributors: Steven.wood
Image:ADI_Example_Version.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Example_Version.png License: unknown Contributors: Steven.wood
Image:ADI_Example_Classification.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Example_Classification.png License: unknown Contributors: Steven.wood
Image:ADI_Example_Discovery2.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Example_Discovery2.png License: unknown Contributors: Steven.wood
Image:ADI_Example_Discovery1.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Example_Discovery1.png License: unknown Contributors: Steven.wood
Image:ADI_Example_Environment_RL2.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Example_Environment_RL2.png License: unknown Contributors: Steven.wood
Image:ADI_Example_Environment_RL.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Example_Environment_RL.png License: unknown Contributors: Steven.wood
Image:BSM_icon.png Source: http://wiki.servicenow.com/index.php?title=File:BSM_icon.png License: unknown Contributors: Steven.wood
Image:ADI_Example_BSM_Map.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Example_BSM_Map.png License: unknown Contributors: Steven.wood
Image:ADI_Windows_Path.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Windows_Path.png License: unknown Contributors: Steven.wood
Image:ADI_Example_Proxy.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Example_Proxy.png License: unknown Contributors: Steven.wood
Image:ADI_Custom_Environment_Record.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Custom_Environment_Record.png License: unknown Contributors:
Steven.wood
Image:ADI_Custom_Version.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Custom_Version.png License: unknown Contributors: Steven.wood, Vaughn.romero
Image:ADI_Custom_Classification.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Custom_Classification.png License: unknown Contributors: Steven.wood,
Vaughn.romero
Image:ADI_Custom_Discovery.png Source: http://wiki.servicenow.com/index.php?title=File:ADI_Custom_Discovery.png License: unknown Contributors: Steven.wood, Vaughn.romero
File:Quick_Discovery_Button.png Source: http://wiki.servicenow.com/index.php?title=File:Quick_Discovery_Button.png License: unknown Contributors: Steven.wood
File:Quick_Discovery_Dialog.png Source: http://wiki.servicenow.com/index.php?title=File:Quick_Discovery_Dialog.png License: unknown Contributors: Steven.wood
File:Quick_Discovery_Status_List.png Source: http://wiki.servicenow.com/index.php?title=File:Quick_Discovery_Status_List.png License: unknown Contributors: Steven.wood
File:Discover_vCenter_UIAction.png Source: http://wiki.servicenow.com/index.php?title=File:Discover_vCenter_UIAction.png License: unknown Contributors: Steven.wood
File:Discover_vCenter_Message.png Source: http://wiki.servicenow.com/index.php?title=File:Discover_vCenter_Message.png License: unknown Contributors: Steven.wood
File:Scheduled_Discovery.png Source: http://wiki.servicenow.com/index.php?title=File:Scheduled_Discovery.png License: unknown Contributors: Steven.wood
Image:CIM_SMI-S_Standard_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_SMI-S_Standard_Diagram.png License: unknown Contributors: Steven.wood
Image:CIM_Agents_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_Agents_Diagram.png License: unknown Contributors: Joseph.messerschmidt, Steven.wood
Image:CIM_Shazzam_Processing_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_Shazzam_Processing_Diagram.png License: unknown Contributors:
Steven.wood
Image:CIM_wbem_Port_Probe.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_wbem_Port_Probe.png License: unknown Contributors: Steven.wood
Image:CIM_SLP_Query.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_SLP_Query.png License: unknown Contributors: Steven.wood
Image:Shazzam_with_CIM_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Shazzam_with_CIM_Diagram.png License: unknown Contributors: Steven.wood
Image:CIM_CLassify_Probe.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_CLassify_Probe.png License: unknown Contributors: Steven.wood
Image:SQL_Cluster_New_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:SQL_Cluster_New_Diagram.png License: unknown Contributors: Steven.wood
Image:SQL_Cluster_Node.png Source: http://wiki.servicenow.com/index.php?title=File:SQL_Cluster_Node.png License: unknown Contributors: Steven.wood
Image:SQL_Cluster.png Source: http://wiki.servicenow.com/index.php?title=File:SQL_Cluster.png License: unknown Contributors: Steven.wood
267

Image:SQL_Instance_CI.png Source: http://wiki.servicenow.com/index.php?title=File:SQL_Instance_CI.png License: unknown Contributors: Steven.wood
Image:SQL_CLient_Instance.png Source: http://wiki.servicenow.com/index.php?title=File:SQL_CLient_Instance.png License: unknown Contributors: Steven.wood
Image:SQL_Cluster_Parameter.png Source: http://wiki.servicenow.com/index.php?title=File:SQL_Cluster_Parameter.png License: unknown Contributors: Steven.wood
Image:Discovery Behavior.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Behavior.png License: unknown Contributors: Steven.wood
Image:Discovery Functionality Criteria.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Functionality_Criteria.gif License: unknown Contributors: Steven.wood
Image:Behavior LoadBalance1.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LoadBalance1.png License: unknown Contributors: Steven.wood
Image:Behavior LocalDomain_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain_New.png License: unknown Contributors: Steven.wood
Image:Behavior LocalDomain2_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain2_New.png License: unknown Contributors: Steven.wood
Image:Behavior LocalDomain New Schedule.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain_New_Schedule.png License: unknown Contributors:
Steven.wood
Image:Behavior ACL_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL_New.png License: unknown Contributors: Steven.wood
Image:Behavior ACL1_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL1_New.png License: unknown Contributors: Steven.wood
Image:Behavior ACL Schedule_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL_Schedule_New.png License: unknown Contributors: Steven.wood
Image:Plugin.gif Source: http://wiki.servicenow.com/index.php?title=File:Plugin.gif License: unknown Contributors: CapaJC, Joseph.messerschmidt
Image:Traffic2.JPG Source: http://wiki.servicenow.com/index.php?title=File:Traffic2.JPG License: unknown Contributors: Dan.sherwin
Image:Discovery_Bandwidth_Graph.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Bandwidth_Graph.png License: unknown Contributors: Steven.wood
Image:Application_Dependency_Map_Icon.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map_Icon.png License: unknown Contributors:
Steven.wood
Image:Application_Dependency_Map.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map.png License: unknown Contributors: Steven.wood
Image:UpstreamDownstream_Relationships.png Source: http://wiki.servicenow.com/index.php?title=File:UpstreamDownstream_Relationships.png License: unknown Contributors:
Steven.wood
Image:Application Dependency Map2.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map2.png License: unknown Contributors: Steven.wood
Image:Application_Dependency_Map4.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map4.png License: unknown Contributors: Steven.wood
Image:Jboss2 apache.jpg Source: http://wiki.servicenow.com/index.php?title=File:Jboss2_apache.jpg License: unknown Contributors: Dan.sherwin
Image:Application_Dependency_Add_Icon.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Add_Icon.png License: unknown Contributors:
Steven.wood
Image:Define_Relationship.png Source: http://wiki.servicenow.com/index.php?title=File:Define_Relationship.png License: unknown Contributors: Steven.wood
Image:Application_Dependency_Map3.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map3.png License: unknown Contributors: Steven.wood
Image:runs_auto_applications.png Source: http://wiki.servicenow.com/index.php?title=File:Runs_auto_applications.png License: unknown Contributors: George.rawlins, Vaughn.romero
Image:screencap_adm_pending_classifier.png Source: http://wiki.servicenow.com/index.php?title=File:Screencap_adm_pending_classifier.png License: unknown Contributors:
George.rawlins
Image:screencap_adm_pending_classifier_ui_action_no_classify.png Source: http://wiki.servicenow.com/index.php?title=File:Screencap_adm_pending_classifier_ui_action_no_classify.png
License: unknown Contributors: George.rawlins
Image:screencap_adm_pending_classifier_ui_action_create_table.png Source:
http://wiki.servicenow.com/index.php?title=File:Screencap_adm_pending_classifier_ui_action_create_table.png License: unknown Contributors: George.rawlins, Steve.bandow
Image:screencap_adm_pending_classifier_ui_action_delete_apps.png Source:
http://wiki.servicenow.com/index.php?title=File:Screencap_adm_pending_classifier_ui_action_delete_apps.png License: unknown Contributors: George.rawlins
Image:map_local_connections.png Source: http://wiki.servicenow.com/index.php?title=File:Map_local_connections.png License: unknown Contributors: Maintenance script, Vaughn.romero
Image:VMWare_VCenter_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:VMWare_VCenter_Diagram.png License: unknown Contributors: Steven.wood
Image:VMWare_No_VCenter_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:VMWare_No_VCenter_Diagram.png License: unknown Contributors: Steven.wood
File:Hyper-V_Schema_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Hyper-V_Schema_Diagram.png License: unknown Contributors: Steven.wood
268

Discovery

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Discovery

Caricato da

Copyright:

Formati disponibili

Discovery

Data Collected by Discovery

What Discovery Does with the Information

Discoverable Windows Operating Systems

Discovery vs. Help the Help Desk

Discovery Help the Help Desk

Automatic discovery by schedule

* Returns information about Windows server machines when Discovery is installed.

Discovery Made Easy

The Census Agent

Discovery Made Easy

Probing the Neighborhood

Discovery Made Easy

MID Server Preparation

Discovery Made Easy

Discovery Agentless Architecture

Discovery Agentless Architecture

Discovery Agentless Architecture

Data Collection and Processing (Probes and Sensors)

Meet Discovery prerequisites.

Enable the Discovery Plugin

Deploy MID Servers

Ensure MID Server Connectivity

Define and Run Discovery Schedules

Viewing a probe payload in XML

The Discovery Log provides the following information:

Sample discovery log

Displays the probe name that generated the log message.

Manually Changing the Discovery Source Name

Update the system property glide.discovery.source_name to have a value of ServiceNow.

Previous version enhancements

MID Server Plugin

JAR File Synchronization

4GB of available RAM per application

MID Server Plugin

Scripted Web Service [sys_web_service]

MID Server Plugin

MID Server Requirements for Discovery

MID Server Requirements for Discovery

4GB of available RAM per application

External Connectivity Requirements

MID Server Requirements for Discovery

MID Server Requirements for Discovery

http:/ / en. wikipedia. org/ wiki/ Secure_Shell

MID Server Installation

How to Set Up Multiple MID Servers on the Same Host Computer

Satisfying Connection Prerequisites

MID Server Installation

Downloading MID Server Files

MID Server application menu

Installing a MID Server on Linux

You can install a MID server on a 32-bit or 64-bit Linux computer. If

1. Run mkdir -p /servicenow/<mid server name> to create the installation directory.

MID Server Installation

Installing a 32-bit MID Server on 64-bit Linux

Installing a MID Server on Windows

MID Server Installation

Installing the MID Server as a Windows Service

Configuring MID Server Service Credentials

Open the Windows Services console.

Stop the running MID Server service.

MID Server Installation

Installing Multiple MID Servers on a Single System

MID Server Installation