ServiceNow Discovery in Detail PDF

Discovery
ServiceNow
PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information.
PDF generated at: Tue, 20 Nov 2012 00:44:21 PST
1
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). Discovery supports Bourne Shell (sh) and Bourne-again Shell
(bash).
• 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 2
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 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 3
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. That’s
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 (e.g.,
34.237.9.72) is the address to a computer on a network. The census agent can get to your house just fine, using your
address, 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, and
credentials. This is simple enough. Now that we have Discovery configured, we need to start working. Nothing gets
accomplished if the census agent doesn’t 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.
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 will scan 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
Discovery Made Easy 4
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.
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 (e.g., 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 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.
The port scan sees that the machine is listening on port 22, which means that this must be a UNIX or Linux
machine.
3. The MID Server advises the instance of what it has discovered.
4. The sensor creates the Get Operating System probe and delivers it when the MID Server checks in for jobs again.
5. The MID server probes the Linux machine to determine its operating system.
6. When the machine replies Linux, the MID Server passes this information to the sensor.
7. 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.
8. 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 7
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 - blue 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 blue lines).
The MID Server is deployed in the internal network, so it has access to connect directly to discoverable devices
(orange 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)
Discovery Agentless Architecture 8
• Windows PowerShell
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 (green lines). Sensors (red box) within the ServiceNow instance process the information
gathered and update the CMDB.
9
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.
Enhancements
October 2011 Preview 1

• Oracle database Discovery: Discovery now detects the Oracle instance name, the Oracle listener, and the port on
which the listener communicates. In this release, Discovery replaces the generic Oracle name in the Oracle
Instance form (Configuration > Database Instances > Oracle) with the discovered instance name.
Oracle listener
Setting up Discovery 10
Click the link to the listener in the Oracle Instance form.
The new Oracle Listener form appears.
• DNS in device history: Personalize the device history list to display DNS names for discovered devices.
• Passing parameters to a probe: It is now possible to use the g_probe_parameters hashmap from within a sensor,
a device classification, or a process classification script to set probe parameters for any configured, triggered
probes.
• The following MID Server parameters were added:
• mid.ssh.local: Executes commands for the MID Server host machine (localhost) via SSH rather than from a
console.
• mid.ssh_max_retries: The maximum number of times to retry an SSH operation after a time-out. This setting
overrides the MID Server default retry setting.
• Windows uninstall strings: A new column was added to the Software Installed related list in a Windows Server
configuration item (CI) record that displays the paths used by the Add or Remove Programs utility to uninstall
software detected on Windows operating systems.
• Ports added to process applications: Discovery now uses the process identifier (PID) of any application classified
as a process to discover the listening ports used by that process. With this release the TCP port field in the
process form is automatically populated with one or more ports. In previous versions, this field was populated
manually.
October 2011 Preview 2

DNS Name Resolver probe: This probe resolves DNS names into IP addresses.
Aspen
Support for clustered process Discovery has been generalized to extend beyond Microsoft SQL Server.
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.
Task 1: Prerequisites
• Select a MID Server host: Select 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.
Task 2: Enable the Discovery Plugin

Contact ServiceNow to activate the Discovery Plugin.
Task 3: Deploy the MID Server to the Host

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. The better use of multiple MID Servers can be
utilized through Discovery Behaviors which can balance the work of an overall schedule between two or more MID
Servers to help complete discoveries quicker.
Task 4: 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 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. This log is located in the MID Server directory on the host machine in
agent\logs\agent0.log0.
• If Basic Authentication is enabled, a user name 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.
Task 5: Set Credentials on the Instance

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.
Task 6: Define Discovery Schedules and Run Discovery

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.
Note: For advanced discoveries, such as those requiring load balancing or scanning across multiple domains, use Discovery
Behaviors.
Task 7: Validate the 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 what types of data are 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, select
Discovery Log in the Related List of a Status record. The log record allows users to drill down into other records
from this list. The Discovery Log provides the following information:
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
Message Message describing the action taken on the information returned by the probe.
Source Probe name
CMDB The CI discovered. Click this link to display the record from the CMDB for this CI.
CI
Sensor Displays the type of sensor that responded to the probe in this entry. Click this link to open the ECC Queue record for the sensor,
including the XML payload.
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.
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 such Discovery issues 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)
Common Procedures
Troubleshoot a Discovery using the procedures outlined in the following stages:
1. Port Scanning
2. Classification
3. Identification
4. Exploration
15
MID Server
MID Server Plugin

Overview
The Management, Instrumentation, and Discovery (MID) Server is a Java server 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. The MID Server is installed automatically for new
instances.
Enhancements
Aspen Patch 3
The localhost MID Server, which was used as the default MID Server in Discovery Schedules, was removed from
the platform with the Aspen Patch 3 release. This MID Server originally was intended for demonstration purposes
and was not intended as a supported feature.
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. Auto Upgrade
2. Heartbeat
3. Queue Monitor
4. Queue Sender
5. Synchronizers
• Altiris
• LanDesk
• Microsoft SMS
• IBM Tivoli CCMDB
• JDBC
Workers
1. Command Line
2. JDBC
3. File
MID Server Plugin 16
4. Probes
• HTTP
• WMI
• SNMP
• SSH
JAR File Synchronization

In the Aspen release, 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.
The platform makes the JAR file available to any MID Server configured to communicate with the instance.
System Requirements
The MID Server has run and been tested in the following environments:
• Windows Server 2003 and later. Virtual hosts and 64 bit systems are supported.
• Linux RedHat ES 3+. On 64-bit Linux systems, the 32-bit GNU C library [1] (glibc) must be installed.
• Solaris 2.8+
• HP-UX 11.0
The minimum configuration suggested 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)
MID Server Plugin 17
Applications
The MID Server is used by the following applications:
• Discovery
• Runbook Automation
• Import Sets
• Altiris
• Microsoft SMS / SCCM
• Avocent LANDesk
• HP OpenView Operations
• Microsoft System Center Operations Manager (SCOM)
• Borland Starteam Integration
• Microsoft MIIS
References
[1] http:/ / www. gnu. org/ s/ libc/
MID Server Requirements for Discovery

Overview
The ServiceNow MID Server is used for enterprise application and service monitoring, integration, Runbook
Automation, and Discovery. The requirements in this page are specifically for the use of MID Servers with the
ServiceNow Discovery and Runbook Automation products.
System Requirements
The MID Server has run and been tested in the following environments:
• Windows Server 2003 and later. Virtual hosts and 64 bit systems are supported.
• Linux RedHat ES 3+. On 64-bit Linux systems, the 32-bit GNU C library [1] (glibc) must be installed.
• Solaris 2.8+
• HP-UX 11.0
The minimum configuration suggested 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
MID Server Requirements for Discovery 18
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
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. Runbook Automation 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. Runbook Automation 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 Runbook. Detailed information is listed below about these methods.
SSH - UNIX
For UNIX-like machines, Discovery and Runbook use SSH [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.
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. Runbook Automation 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. Runbook activities for PowerShell require a credentials Type of Windows.
MID Server Requirements for Discovery 19
SNMP - Network
For network devices, a SNMP scan [5] is used 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.
The out-of-box Runbook activity SNMP Query returns the OID of a device and requires SNMP credentials.
WBEM
Web-Based Enterprise Management (WBEM [6]) defines a particular implementation of the Common
Information Model (CIM [7]): , 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] http:/ / en. wikipedia. org/ wiki/ Secure_Shell
[2] http:/ / en. wikipedia. org/ wiki/ Windows_Management_Instrumentation
[3] http:/ / support. microsoft. com/ kb/ 832017
[4] http:/ / support. microsoft. com/ kb/ 968929
[5] http:/ / en. wikipedia. org/ wiki/ SNMP
[6] http:/ / en. wikipedia. org/ wiki/ Web-Based_Enterprise_Management
[7] http:/ / en. wikipedia. org/ wiki/ Common_Information_Model_(computing)
MID Server Installation 20
MID Server Installation

Deployment
The MID Server must be able to communicate with the machines it is configured to probe. There are several reasons
why a probe may fail, even though the MID Server can ping the target device. Ensure that the machine on which the
MID Server is installed is granted the following network privileges:
• Any firewalls between the MID Server and the target devices must be configured to allow a connection. If your
network uses a DMZ, 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.
• Target devices must be configured to allow the MID Server probe to connect. If network security prevents you
from configuring new machines that can connect to the targets, then the MID Server must be installed on an
existing machine with connection privileges.
• The MID Server must be installed with the proper account: either local or domain administrator.
Note: The size and complexity of your network might require the deployment of multiple MID Servers. See Deploying Multiple MID
Servers for details.
Installation
After the MID Server plugin is enabled on your instance, you will see the MID Server application in the Application
Navigator. If you have enabled Discovery, Runbook Automation, or any integration that requires the use of the
MID Server, this application is also included during these plugin activations.
To download and install a MID Server, navigate to Mid Server > Downloads on your instance. Select and download
the MID Server for the operating system you are targeting in the form that appears.
Windows
Select from the following procedures for installing one or more MID Servers on a single machine.
Installing a Single MID Server on a Machine

1. Logon to the host machine on which 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. Extract the downloaded MID Server zip file into your new directory. Right click the package and select Extract
All from the pop-up menu.
4. Navigate to the \agent directory that was created when the file was extracted and open the config.xml file using a
text editor such as WordPad.
5. Edit this file as follows:
• Modify <parameter name="url" value="https://YOUR_INSTANCE.service-now.com" /> and enter the
URL to your instance.
• Enter the user credentials if basic authentication is enabled (default behavior) in the
mid.instance.username/password parameters.
• Modify <parameter name="name" value="YOUR_MIDSERVER_NAME_GOES_HERE" /> and enter the
name of your MID Server.
• Enter connection information for any proxy server used and be sure to remove the comment tags from the
proxy configuration information.
NOTE: If this MID Server is installed on a machine that contains other MID Servers, edit the wrapper.conf
file as described below in the procedure for installing multiple MID Servers.
6. Install the MID Server as a Windows service:
a. For Windows XP, Windows 2000 Server, or Windows Server 2003:
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, type command prompt or cmd.exe.
3. In the result 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.
7. Edit the MID Server's credentials.

a. Open the Windows Services console.
b. Double-click on the ServiceNow <MID Server name> service.
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.
8. Re-start the ServiceNow <MID Server name> service and make sure that ServiceNow\<MID Server
name>\agent\logs\agent0.log does not have error messages.
9. In the instance to which this MID Server is connected, navigate to MID Server > Servers. If Discovery is
installed, navigate to Discovery > MID Servers.
All MID Servers connected to this instance are listed.
10. Make sure that the Status of the MID Server you just installed is Up.
Installing Multiple MID Servers on a Single Machine

You can install multiple MID Servers on a single host or on a virtual machine.
1. Logon to the host machine or virtual machine on which you want to install multiple MID Servers.
2. Create a directory for the MID Server on the top level of the drive, with a distinctive name, such as
ServiceNow\<MID Server name>.
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 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.
4. Using WordPad, edit the config.xml file in each MID Server \agent directory as follows:
• Modify <parameter name="url" value="https://YOUR_INSTANCE.service-now.com" /> and enter the URL
to your instance.
• Enter the user credentials if basic authentication is enabled (default behavior) in the
mid.instance.username/password parameters.
• Modify <parameter name="name" value="YOUR_MIDSERVER_NAME_GOES_HERE" /> and enter the
name of your MID Server.
5. Using WordPad, edit the wrapper.conf file for each MID Server in the following directory:
\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> example: snc_agent2: This is the internal Windows name for the
service and is not displayed. This name must be unique.
• 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 your services correctly before you complete the next step.
6. Install the MID Server as a Windows service:

a. For Windows XP, Windows 2000 Server, or Windows Server 2003:
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, type command prompt or cmd.exe.
3. In the result 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.
7. Edit each MID Server's credentials.
a. Open the Windows Services console.
b. Double-click on 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.
8. Re-start each ServiceNow MID Server service and make sure that \ServiceNow\<MID Server
name>\agent\logs\agent0.log does not have error messages.
9. In each instance to which these MID Servers are connected, navigate to MID Server > Servers. If Discovery is
10. Make sure that the Status of the MID Servers you just installed is Up.
Unix/Linux
1. Run mkdir -p /servicenow/<mid server name> to create the installation directory.
2. Unzip the downloaded MID Server zip 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 /agent directory (cd /service-now/<mid server name>/agent) and edit the config.xml file as follows:
• Modify the <parameter name="url" value="https://YOUR_INSTANCE.service-now.com" /> and enter
the URL to your instance.
• Enter user credentials if basic authentication is enabled (on by default) in the
mid.instance.username/password parameters
4. Execute the shell script start.sh.
5. In the instance to which this MID Server is connected, navigate to MID Server > Servers. If Discovery is
6. Make sure that the Status of the MID Server you just installed is Up.
Uninstalling
The MID Server runs as a stand-alone service and 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. Stop the running MID Server service.
2. Open a command window (Start > Run > cmd).
3. Go to the \agent\bin folder in the MID Server installation folder.
4. Double-click the uninstall.bat file.
Upgrading and Testing

With the Aspen release, the MID Server is upgraded automatically when the instance is upgraded. The MID Server
automatically tests connectivity through a public scripted Web Service.
Downgrading
MID Server downgrades are only possible within the same release family. For example, you can downgrade from
Berlin Patch 3 to Berlin Patch 2, but not from Berlin to Aspen.
Upgrade Error Messages

The following MID Server upgrade error messages are available:
Message Description
Unable to refresh packages Generic error when no reason is given
Failed to query instance for MID Instance is offline or there is a major version mismatch between the MID Server and the instance. This
server buildstamp message is available in versions at Berlin or later.
Not a valid package buildstamp InstanceInfo returned an assigned buildstamp that was not in the correct format (possible version mismatch).
This message is available in versions at Berlin or later.
Using Basic Authentication

To enforce basic authentication on each request from the service via SOAP messages, you may set the property
glide.basicauth.required.soap to true. If you do so, each SOAP request would have to contain the "Authorization"
header as specified in the Basic Authentication [1] protocol. Because the request is non-interactive, we always require
the Authorization header during a request.
Supplying basic authentication information, whether or not it is required, has the added advantage that the data
created or updated as a result of the Web Service invocation is done on behalf of the user supplied in the basic
authentication credentials. As an example, when creating an Incident record, the journal fields will have the user id
of basic authenticated user, instead of the default "Guest" user.
Note: The user ID used in the MID server connection is only for authentication if enforcing strict security is not required from the
Web Service properties. Enabling the Enforce strict security property will cause the usage of roles associated with the user ID to
enforce access control on the tables the MID server is accessing, this is not usual.
Navigate to C:\Program Files\ServiceNow\<MID Server name>\agent and edit the config.xml file as follows, using
Wordpad:
• Find <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 <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="NY12bqp1A"/>.
• Enter the display name that appears for this MID Server in your ServiceNow instance in the following line:
<parameter name="name" value="YOUR_MIDSERVER_NAME_GOES_HERE"/>
Monitoring Your MID Server

To ensure uninterrupted service from the Windows-based MID Server, monitor the application host for the
following:
• A running snc_agent service, or custom agent names for multiple installations of the MID Server on a host
machine.
• Running java.exe and wrapper.exe processes.
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 maximum configured memory, as defined in ~\agent\conf\wrapper.conf.
• ~\agent\logs\agent0.log.0 and ~\agent\logs\wrapper.txt for warning/critical/severe errors with appropriate
thresholds.
• Standard server state-of-health metrics: CPU/Mem/Disk utilization and NT Event log/syslog monitoring
Troubleshooting Startup Errors

The MID Server agent log displays detailed information about errors encountered when connecting to the
ServiceNow instance. This log is created automatically in the \logs directory in the \agent installation directory. The
log provides detailed information about the instance and the MID Server each time the MID Server is started. Use
this data to ensure that the instance and MID Server versions are compatible and that the MID Server is configured
to contact the correct instance. The log record also indicates if basic authentication and strict security are enabled on
the instance.
This feature is available with the Aspen release.
Connection Failure
A number of possible network issues can prevent connection, including a blocking firewall, an improperly
configured proxy server, or a DNS issue. The wording of the message can vary, depending on the cause of the
failure.
Note: If you configured the MID Server config.xml file to use a proxy server, ensure that the comment tags were removed from
around the proxy sections configured.
08/29/11 12:31:46 (055) main Running under Java version: 1.6.0_26

08/29/11 12:31:46 (077) main Initializing MID Server
08/29/11 12:31:46 (180) MIDServer MID Server starting
08/29/11 12:31:46 (397) MIDServer Using configuration:
/glide/workspace/com.service_now.agent/config.xml
08/29/11 12:31:46 (858) MIDServer Agent home path:

/glide/workspace/com.service_now.agent
08/29/11 12:31:46 (959) MIDServer MID Server started
08/29/11 12:31:46 (983) StartupSequencer Setting basic authentication
with user swhipple
log4j:WARN No appenders could be found for logger
(org.apache.commons.httpclient.HttpClient).
log4j:WARN Please initialize the log4j system properly.
08/29/11 12:31:47 (109) StartupSequencer SEVERE *** ERROR *** Problem
invoking InstanceInfo on http://10.0.5.37/glide/: IOException:
Connection refused
InstanceInfo
If the error log displays an issue with InstanceInfo (as in the log sample in the previous section), navigate to System
Web Services > Scripted Web Services and ensure that the InstanceInfo scripted Web Service is active. If this
Web Service was disabled or modified incorrectly, the MID Server cannot get the information from the instance that
it needs to connect.
Authentication Failure
The user name and/or password configured in the MID Server config.xml file is incorrect or the user is incorrectly
configured on the instance.
08/30/11 15:16:19 (656) MIDServer Using configuration: C:\Service-now\DocMIDServer01\agent\config.xml
08/30/11 15:16:20 (078) MIDServer Agent home path: C:\Service-now\DocMIDServer01\agent
08/30/11 15:16:20 (093) StartupSequencer Setting basic authentication with user swhipple
08/30/11 15:16:21 (031) StartupSequencer Successfully connected to instance:
08/30/11 15:16:21 (031) StartupSequencer Install name: Demo Server
08/30/11 15:16:21 (031) StartupSequencer Instance name: demosw
08/30/11 15:16:21 (031) StartupSequencer Node: 9b1a9ce90a0a3c1801834233f12ce49e
08/30/11 15:16:21 (031) StartupSequencer Build date: 08-28-2011_2100
08/30/11 15:16:21 (031) StartupSequencer Build tag:
08/30/11 15:16:21 (031) StartupSequencer Instance ID: 8026b1fa0a0a3c180142bbe642c6e92b
08/30/11 15:16:21 (031) StartupSequencer System ID: bosdemo01.service-now.com:demosw_16245
08/30/11 15:16:21 (031) StartupSequencer Instance IP: 10.10.60.24
08/30/11 15:16:21 (031) StartupSequencer MID version: 08-28-2011_1352
08/30/11 15:16:21 (296) StartupSequencer WARNING *** WARNING *** Could not authenticate user 'swhipple' on the ServiceNow instance
Missing Roles
If the configured user is missing any roles, the message names the roles. The configured MID Server user must have
the following roles. The hierarchy indicates which roles are contained within other roles.
• soap_ecc
• mid_server
• soap
• soap_delete
• soap_query
• soap_update
• soap_create
• soap_script
If the configured user has the required roles, the message states User <user name> has all necessary roles.
08/30/11 15:22:25 (218) StartupSequencer SOAP basic authentication is enabled
08/30/11 15:22:25 (218) StartupSequencer SOAP strict security is enabled
08/30/11 15:22:25 (218) StartupSequencer WARNING *** WARNING *** Missing role from user swhipple: mid_server
ACL Issues
If ACLs on the ServiceNow instance block the MID Server from accessing necessary tables or fields on the instance,
the error message names the table or field that is blocked. In this example, read, create, and write privileges on the
MID Server [ecc_agent] table are blocked by access control rules configuration.

08/30/11 14:02:52 (843) StartupSequencer SOAP basic authentication is enabled
08/30/11 14:02:52 (843) StartupSequencer SOAP strict security is enabled
08/30/11 14:02:52 (843) StartupSequencer User swhipple has all necessary roles
08/30/11 14:02:52 (859) File sync worker: ecc_agent_mib Starting file synchronization: ecc_agent_mib
08/30/11 14:02:52 (859) StartupSequencer Enabling monitor: FileSyncer
08/30/11 14:02:52 (859) File sync worker: ecc_agent_jar Starting file synchronization: ecc_agent_jar
08/30/11 14:02:53 (218) File sync worker: ecc_agent_mib Finishing file synchronization: ecc_agent_mib
08/30/11 14:02:53 (828) File sync worker: ecc_agent_jar Finishing file synchronization: ecc_agent_jar
08/30/11 14:02:54 (890) StartupSequencer Getting instance ACLs for table: ecc_agent_property
08/30/11 14:02:55 (875) StartupSequencer Getting instance ACLs for table: ecc_agent
08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't read because table ACL denies it: ecc_agent
08/30/11 14:02:56 (250) StartupSequencer Agent record not found, creating new record. Instance: DocMIDServer1
08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't write because table ACL denies it: ecc_agent
08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't create because table ACL denies it: ecc_agent
08/30/11 14:02:56 (250) StartupSequencer SEVERE *** ERROR *** Unable to create new agent record on instance: DocMIDServer1
References
[1] http:/ / www. w3. org/ Protocols/ HTTP/ 1. 0/ draft-ietf-http-spec. html#BasicAA
Deploying Multiple MID Servers 29
Deploying Multiple MID Servers

Overview
Depending upon how you use the MID Server (for an external integration, Discovery, or Runbook Automation) 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 Runbook
Automation.
Deploying Multiple MID Servers 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)
Runbook Automation
When determining if multiple MID Servers are necessary to executes Runbook 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 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 Runbook 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).
MID Server Configuration 31
MID Server Configuration

Overview
You must complete all the steps in MID Server Installation before attempting any of the configuration steps
explained here. Set MID Server configuration parameters in either of the following places:
• The Configuration Parameters related list in the MID Server record.
• The config.xml file in the \agent folder of your MID Server installation folder.
Setting MID Server Memory Size

In the base ServiceNow system, the MID Server is configured with reasonable values for its resource consumption.
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. MID
Server memory is set to 512MB by default and is configurable in the \agent\conf\wrapper.conf file in the MID
Server installation directory.
To edit the memory allocation:
1. Navigate to <MID Server name>\agent\conf and open the wrapper.conf file in a text editor.
2. Locate the following lines in the file:
3. # Maximum Java Heap Size (in MB)
4. wrapper.java.maxmemory=512
5. Edit the memory allocation.
6. Save the file.
7. Restart the MID Server service.
Available Parameters
Note: Changes to parameters only take effect when the MID server is started (or restarted).
Description Name(s) Details
Credentials mid.credentials.provider
provider
Debug debug.logging Optional, true/false, default false. If set to true, enables logging of MID server
logging events and messages (both sent and received). Normally this parameter is only used
enable by developers, but it is occasionally useful when troubleshooting a problem. Be
aware that setting this parameter to true will cause intensive logging on the MID
server, potentially using considerable disk space.
Debug debug.level Optional, integer (0-3), default 0. Controls how much debug logging will take place
logging level (if debug mode is enabled): 0 = none, 1 = little, 2 = some, and 3 = all.
Debug mode debug Optional, true/false, default false. If true, enables debug logging on the MID server.
enable 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 will
cause intensive logging on the MID server, potentially using considerable disk space.
Disable disable_monitors Optional, true/false, default false. It true, disables MID Server from actively
monitor checking for monitors on the instance.
checking
Enable mid.snmp.enable_auto_public Optional, true/false, default true. To disable the SNMP public community string,
automatic set this parameter to false.
inclusion of
SNMP public
community
string
Enable mid.use_powershell Optional, true/false, default false. PowerShell must be installed on the MID Server
PowerShell and must be at Version 2 for PowerShell with Discovery to operate. If the correct
for Discovery version of PowerShell cannot be found, the MID Server uses WMIRunner instead.
Environment mid.ssh.set_path Optional, true/false, default true. Sets the PATH environment variable for SSH
variable for commands.
SSH
commands
Execute mid.ssh.local Optional, true/false, default false. If set to true, executes commands for the MID
long-running Server host machine (localhost) via SSH rather than from a console. This allows
commands long-running commands to execute properly.
against
localhost
Fixed MID mid.pinned.version Optional, string build timestamp. Names the fixed version for the MID Server.
Server version
Instance date instance.date.format Optional, string date/time pattern, default "yyyy-MM-dd HH:mm:ss". Set or
format change this parameter to let the MID server know what format the instance uses for
date/times. The primary impact of setting this parameter is to allow the MID server to
correctly refresh its start and stop times on the ServiceNow instance's MID server
record. The format of this date/time string is identical to that used by the Java
[1]
SimpleDateFormat class, documented here in the section titled Date and Time
Patterns.
Instance mid.instance.password or Optional, string. If your ServiceNow instance has authentication enabled (the
password glide.glidesoap.password normal case), set this parameter to define the password the MID server should use to
log into the instance.
Instance mid.instance.use_proxy or Optional, true/false, default false. If your MID server must go through a web proxy
proxy enable mid.proxy.use_proxy to access the ServiceNow instance, set this parameter to true to instruct the MID
server to use the proxy. Note that you must also set the proxy server's host and port,
and perhaps the user name and password as well.
Instance mid.proxy.host Optional, string. If your MID server must go through a web proxy to access the
proxy host ServiceNow instance, set this parameter to define the proxy's host.
Instance mid.proxy.password Optional, string. If your MID server must go through a web proxy to access the
proxy ServiceNow instance, and your proxy requires a password, set this parameter to
password define that password.
Instance mid.proxy.port Optional, integer (0 - 65535). If your MID server must go through a web proxy to
proxy port access the ServiceNow instance, set this parameter to define the proxy's port.
Instance mid.proxy.username Optional, string. If the MID Server must go through a web proxy to access the
proxy user ServiceNow instance, and the proxy requires a user name, set this parameter to define
name that user name.
Instance URL url Required, string. Tells the MID server where to contact its associated ServiceNow
instance. Normally this would be a URL like [2], where “example” would be replaced
by the name of your instance. If your are hosting your own ServiceNow instance,
then this URL will be determined by your organization.
Instance user mid.instance.username or Optional, string. If your ServiceNow instance has authentication enabled (the
name glide.glidesoap.username normal case), set this parameter to define the user name the MID server should use to
log into the instance.
MID Server auto_upgrade Optional, true/false, default true. If true or absent, enables the MID server to
auto-upgrade periodically check whether it should upgrade. If it is set to false, the MID server will
enable remain on the same version – generally neither safe or useful.
MID Server mid.connection_cache Optional, true/false, default true. By default this property causes connections to be
connection cached. Set to false to disable connection caching. Used for ssh connections only
cache (Discovery).
MID Server query_backoff Optional, true/false, default false. Allows the interval at which the MID Server
ECC query queries the ECC Queue to lengthen if the MID Server is idle. By default, the MID
interval 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.
MID Server mid_sys_id Required, automatically set, string (GUID). Records the unique identifier of the
ID MID server's record on the ServiceNow instance. This parameter should be empty
when you initially configure a MID server, and you should never change it.
MID Server glide.mid.fast.responses Optional, true/false, default false. Normally the MID server sends message to the
immediate ServiceNow instance serially (that is, one message at a time). Setting this parameter
response to true instructs the MID server to try sending messages to the instance as soon as
enable they are ready. In Discovery, when many probes can be run in parallel, this means
that often there will be multiple messages being 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 on the instance, decreasing the instance's
overall responsiveness. If there are communications problems, this parameter can
also cause a "logjam" on the MID server, as threads normally used for running probes
may become consumed for sending messages. Overall we recommend leaving this
parameter out of your configuration; it would take a very special circumstance for it
to make sense to set it true.
MID Server mid.jmx.enabled Optional, true/false, default false. If set to true, this parameter enables a JMX server
JMX enable on the MID server, exposing some management information to JMX consoles. This is
an experimental feature, not officially released yet. Also, implementing JMX requires
additional (and fairly complicated) configuration of the Java runtime environment.
Setting this parameter to true is only recommended for those with detailed knowledge
of the Java security architecture, a specific need for JMX, and a strong desire to take
unreasonable risks with production software.
MID Server glide.mid.max.sender.queue.size Optional, string, default "0.5g". When the MID server generates messages to the
max ServiceNow instance faster than it can send them, it queues them temporarily on the
transmission file system of the MID server's host. This queue is normally quite small, and is
queue size completely emptied as soon as the MID server is quiescent for a short period.
However, when there are communications problems between the MID server and the
instance, and especially if there is an integration running on the MID server, this
queue can grow in size. This parameter places an upper bound on how large the
queue is allowed to get – the MID server will start deleting queued messages if this
bound would be exceeded. 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". Whitespace is liberally tolerated. The following strings
all represent valid parameters: "1000000000", "0.5m", "5 GB", "7.67gigas",
"145.69392 mothers", and "1.1 tomatoes".
MID Server threads.max Optional, integer, default 25. Controls the number of execution threads
maximum (simultaneous work) that may be used by probes. This parameter provides direct
number of control over how much CPU resource the MID server will consume on the computer
probe threads that hosts it. To throttle the MID server's CPU consumption down, lower the number
of threads. To make the MID server work faster, increase the number of threads.
MID Server name Required, string, default is YOUR_MIDSERVER_NAME_GOES_HERE If you

name do not supply this parameter, the MID server will use the default value. Use this
parameter to supply a name that's meaningful for you.
MID Server mid.poll.time Optional, integer, default 15. Allows you to override the default MID Server polling
poll time interval (in seconds).
MID Server MIDServerRefreshRate Optional, integer, default 65. Controls how often (in seconds) the MID server
refresh rate checks with the instance to determine if the MID Server should upgrade itself. The
usual value for this parameter is 65 seconds. To change this value, add the parameter
to the MID Server config.xml file, using the following syntax:
<parameter name="MIDServerRefreshRate" value="<N>"/>
MID Server mid.ssh_connections_per_host Optional, integer, default 3. Controls the number of concurrent probes the MID
SSH Server can run against a given host. Lowering the number of concurrent connections
connection can slow Discovery.
per host
MSSQL mid.powershell.use_mssqlauth Optional, true/false, default false. This parameter determines whether PowerShell
credentials for should use Windows integrated security or SQL authentication when attempting to
PowerShell log into the MSSQL instance. PowerShell uses Windows integrated security by
default.
Port probe mid.shazzam.regulator.interval_ms Optional, integer, default 1. Sets the interval, in milliseconds, in which Shazzam
packet can launch packets. This parameter works with the
interval 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.
Port probe mid.shazzam.regulator.packets_per_interval Optional, integer, default 1. Sets the number of packets that Shazzam can launch in
packets the configured time interval. This parameter works with the
launched per mid.shazzam.regulator.interval_ms parameter, which sets that interval. By default,
regulator Shazzam launches one packet each millisecond.
interval
PowerShell mid.powershell.use_credentials Optional, true/false, default true. This parameter tells Discovery to use the
credentials Windows credentials in the credentials table for PowerShell. 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.
PowerShell mid.powershell.path Optional, string URL. This parameter enables an administrator to point to a specific
executable PowerShell on a MID Server in cases where more than one PowerShell is installed.
path Supply the path (e.g. C:\mypowershell or C:\mypowershell\) to the folder containing
the PowerShell executable, and powershell.exe is appended automatically to the
URL. This parameter might be necessary, for example, when 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\".
Query logging mid.show.queries Optional, true/false, default false. Setting this parameter to true instructs the MID
enable server to log details about every query it makes to the ServiceNow instance.
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 will
cause intensive logging on the MID server, potentially using considerable disk space.
Remote disable.remote.logging Optional, true/false, default false. If this parameter is set to true, the MID server
logging will not log any information to the MID server log on the ServiceNow instance.
disable Relatively little information is logged on the instance in any case, but setting this
parameter will cut that to zero.
Set the PATH mid.ssh.path_override Optional, string. Configure an alternate SSH command path with this parameter to
environment override the possible default paths (/usr/sbin: /usr/bin: /bin: /sbin). This MID Server
paths for SSH parameter is overridden if an alternate SSH command path is configured in a probe
commands parameter.
Shazzam mid.shazzam.chunk_size Optional, integer, default 100. The maximum number of IP addresses that Shazzam
chunk size scans in parallel. This parameter primarily controls outbound port consumption.
SSH mid.ssh_max_retries Optional, integer, default 1. The maximum amount of times to retry an SSH
connection operation after a time-out. The system sleeps two seconds between each connection
error retry attempt. By default, the MID Server retries once only. Use the mid.ssh.max_retries
parameter setting to override that default. Set the parameter to 0 to disable retries.
SSH remove mid.ssh.alt_rm Optional, string, default /bin/rm -f. Sets a different SSH remove file command.
command
override
Status sending disable.status Optional, true/false, default false. Normally the MID server sends a status report to
disable the ServiceNow instance every 10 minutes. Setting this parameter to true will
eliminate that report.
Suppress mid.ssh.suppress_history Optional, true/false, default false. Suppress generation of the SSH history file.
history file
generation for
SSH
Timeout in mid.ssh.socket_timeout Optional, integer, default 60,000. Some devices (such as systems with embedded
ms for SSH controllers, like UPSs and PDUs) with SSH enabled require more than 30 seconds to
socket open respond to an authentication request. To prevent issues created by a socket timeout,
this parameter provides a way to set a higher value.
Upgrade glide.mid.autoupgrade.branch or Optional, string. Defines a branch (a directory on the distribution server) from
branch mid.upgrade.branch which the MID server should download its upgrades from. This might be set if you
had a special MID server version for some reason. Normally you should not have this
parameter in your configuration, and you should never include it without consulting
with ServiceNow.
Upgrade mid.upgrade.use_proxy Optional, true/false, default false. If your MID server must go through a web proxy
proxy enable to access the upgrade URL, set this parameter to true to instruct the MID server to use
the proxy. Note that you must also set the proxy server's host and port. Note that if
the instance proxy user name and password are set, they will be used for the upgrade
proxy as well.
Upgrade glide.mid.autoupgrade.proxy_host or Optional, string. If your MID server must go through a web proxy to access the
proxy host glide.glidesoap.proxy_host upgrade URL, define the proxy's host here.
Upgrade glide.mid.autoupgrade.proxy_port or Optional, integer (0 - 65535). If your MID server must go through a web proxy to
proxy port glide.glidesoap.proxy_port access the upgrade URL, define the proxy's port here.
Upgrade glide.mid.autoupgrade.proxy_user Optional, string. If your MID server must go through a web proxy to access the
proxy user upgrade URL, define the proxy's user name here.
Upgrade glide.mid.autoupgrade.proxy_password Optional, string. If your MID server must go through a web proxy to access the
proxy upgrade URL, define the proxy's password here.
password
Upgrade URL glide.mid.autoupgrade.host Optional, string URL, default. [3] Controls where the MID server will download its
upgrades from. Normally you should not set this parameter.
Use keyboard mid.ssh.use_keyboard_interactive Optional, true/false, default false. Uses the keyboard interactive authentication
interactive mode in SSH daemons for MID Servers on which it is activated.
authentication
for SSH
Managing Configuration from the ServiceNow Instance

You can view and manage your MID server's 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
• Runbook Automation > MID Servers
2. From the list of MID servers shown, select the one 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 MID server's configuration file is modified to include the new parameter.
Changes to existing parameters are reflected in the MID server's configuration file as well. Changes made to
the MID server's configuration file do not take place immediately, but rather the next time the MID server is
restarted. The MID server page has a convenient link to use to restart the MID server at any time.
Note: No changes can be made (such as modifying or deleting parameters) that would make the MID server lose communications
with the instance. For example, the url property cannot be changed for this reason. Any changes to these protected properties must be
made by directly editing the MID server's config.xml file.
Editing the config.xml File

The MID Server's configuration is controlled by an XML file called config.xml. This file is located in the agent
directory, immediately under the directory in which the MID Server was installed. Edit this file directly to make any
configuration changes. Many configuration changes (those that do not disrupt communication between the MID
Server and the ServiceNow instance) may also be made from the instance.
The sample file here is from FireFox. Conventional text editors, such as Notepad, Wordpad, or TextEdit, do not
display colors and variable fonts. 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. The name attribute contains the name of
each parameter, and the value attribute contains the value of the parameter. 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. Note 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.
Configuring Thread Use

By default, the MID Server is configured to use a maximum of 25 threads. For most CPUs, this requires little effort.
However, 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 very much 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 are useful:
• Most MID Server tasks require file handles to do their job. On the Windows operating system, file handles are a
rather precious resource 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 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.
• Each thread on the MID Server requires some memory. Exactly how much memory varies considerably from task
to task and is also dependent 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:
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, with consideration to the cautions described above.
4. Save the record.
5. Restart the MID Server service.
Adding SSL Certificates

You can configure your MID server to connect over SSL by adding the following certificates to the cacerts keystore
file:
• Signing Certificate Authority (CA) certificate
• MID Server certificate
To add a certificate to a MID server:
1. Open a Command Prompt and navigate to the folder containing your JRE's keytool [4]. For example:
cd C:\Program Files (x86)\ServiceNow\<MidServer(s)>\agent\jre\bin
2. Enter the following keytool command to import a certificate into the MID server's cacerts keystore:
keytool -import -alias <certificate alias> -file "<path to certificate>"
-keystore "<path to MID Server(s)>\agent\jre\lib\security\cacerts"
For example:
keytool -import -alias MyCA -file "C:\myca.cer" -keystore "C:\Program Files
(x86)\ServiceNow\MIDserver\agent\jre\lib\security\cacerts"
Note: Keytool prompts for a certificate password and, if the certificate is for a CA, whether to trust the certificate authority.
The mid_server Role

The existing mid_server role was added to the ACLs, allowing 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 necessary soap roles are added automatically with the mid_server role.
Windows Enhanced Security and PowerShell

Enhanced security on Windows operating systems can block PowerShell from working with Discovery and
Runbook. If PowerShell does not run with Discovery or Runbook Automation, unblock the following MID Server
files.
• Credentials.psm1
• LaunchProc.psm1
• MSSqlAuth.ps1
• MSSqlWinAuth.ps1
• PSScript.ps1
• WMIFetch.psm1
• XmlUtil.psm1
Perform this procedure on each MID Server machine:
1. Navigate to the MID Server \agent\lib folder.
2. Right-click on the first file in the list and select Properties from the pop-up menu.
3. In the Properties dialog box, click Unblock.

4. Repeat the procedure for each of the remaining files.
References
[1] http:/ / java. sun. com/ j2se/ 1. 4. 2/ docs/ api/ java/ text/ SimpleDateFormat. html
[2] https:/ / example. service-now. com
[3] http:/ / install. service-now. com/ glide/ distribution/ builds/ mid/
[4] http:/ / docs. oracle. com/ javase/ 1. 3/ docs/ tooldocs/ win32/ keytool. html
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, Runbook Automation, 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
MID Server Clusters 41
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.
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. Navigate to MID Server > Clusters.
2. Click New.
3. Name the cluster and select the cluster type: Failover or Load Balance.
4. Right click in the header bar and select Save from the context menu.
5. Click Edit in the Includes MID Servers Related List.
6. 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.
MID Server Clusters 42
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.version
• mid.version.override
Note: Downgrades are only possible within the same release family. For example, you can downgrade from Berlin Patch 3 to Berlin
Patch 2, but not from Berlin to Aspen.
Enhancements
Aspen Release
The MID Server:
• Upgrades automatically when the instance is upgraded.
• Tests connectivity through a public scripted web service.
Berlin Release
• The MID Server property, mid_buildstamp, replaces the mid.version property in versions at or later than Berlin.
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 date and time format for the mid.version.override property has changed yyyy-mm-dd-hhmm.
mid.version
The mid.version property provides the current version of the MID Server (the version determined by ServiceNow to
be correct for the current application version) and is configurable. The MID Server checks for version information
hourly. If no override version is configured, the MID Server looks at the mid.version 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.
Controlling the MID Server Version 43
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.version property. If an override version is configured, the MID Server uses
this value and ignores the version information in the mid.version 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.version
property.
Create the property and then set the value.
1. In the Navigation pane filter, type sys_properties.list.
The list of system properties appears.
2. Click New.
3. Type mid.version.override in the Name field.
4. Enter a description, such as, Set an override value for the current MID Server version.
5. Enter a version for the MID Server to use that is different from the version ServiceNow has selected in the
mid.version property.
6. Click Submit.
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.
MID Server Heartbeat 44
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.
MID Server User Security 45
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 existing mid_server role was added to the ACLs, allowing 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 necessary soap roles are added automatically with the mid_server role.
46
Probes and Sensors
Shazzam Probe Parameters

Overview
When you run Discovery, the Shazzam probe (Scan mode) finds all active devices in your network by scanning
specified ports on specified IP address ranges. You control the behavior of the Shazzam probe using two types of
parameters: Basic and Advanced. To access the Shazzam probe, navigate to Discovery Definition > Probes and
select Shazzam. 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 these 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.
Parameter Description Default

Value
shazzam_chunk_size The maximum number of IP addresses Shazzam will scan in parallel. This parameter primarily controls 100
outbound port consumption.
regulator_max_packets The maximum number of packets allowed per regulator period. 1
regulator_period_ms The number of milliseconds per regulator period. 1
Advanced Parameters
These parameters are available for fine tuning your Shazzam probe. You define these values in the probe record
only.
Parameter Description Default

Value
report_inactive If set to true, reports device as alive but inactive (e.g. no ports are open, but at least one was true
refused).
report_dead If set to true, reports dead IP addresses (e.g., all ports are closed). false
GenericTCP_waitForConnectMS Sets the number of milliseconds for the GenericTCP scanner to wait for a connection. 1000
BannerTCP_waitForConnectMS Sets the number of milliseconds for the BannerTCP scanner to wait for a connection and banner. 1500
HTTP_waitForConnectMS Sets the number of milliseconds for the HTTP scanner to wait for a connection. 500
HTTP_waitForResponseMS Sets the number of milliseconds for the HTTP scanner to wait for a response. 500
NBT_waitForResponseMS Sets the number of milliseconds for the NBT scanner to wait 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) for the SNMP scanner to attempt. 2
SNMP_tapIntervalMS Sets the number of milliseconds for the SNMP scanner to wait between taps. 1000
Shazzam Probe Parameters 47
SNMP_waitForResponseMS Sets the number of milliseconds for the SNMP scanner to wait 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 for the DNS scanner to wait for a response. 1000
DNS_alternativePort Sets an alternative port number for the DNS scanner. N/A
debug Set to true to enable debug logging. false
scanner_log Set to true to enable scanner logging (this logging information appears in the Shazzam probe false
response).
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:

Port Probes 48
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 Indicates which services define the port usage. Use this setting to define non-standard port usage and pair the port number with
services 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.
Use Names the appropriate classification table, based on the protocol being explored.
classification
Classification 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,
priority 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.
Database Catalogs 49
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 50
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.
Custom Probe - Text File 51
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.
• 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.
3. Right-click in the header bar and select Save from the context menu.
4. Select the Probe Parameters tab in the Probe form, and then click New.
5. Enter WMI_GetFiles.js as the Name of this parameter.
6. Copy the script below into the Script field and edit as needed.
7. Click Submit.
The completed probe form looks like this:
//
// 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 BGInofo files.
• Reacts to probe: The name of the probe created in the previous procedure: Windows - Get BGInofo 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
//
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:

55
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
• SNMP - Classify: SNMP commands for all netgear 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.
Discoverable Windows Operating Systems

The out-of-box Discovery system provides separate classifiers for the following Windows server versions:
• Windows NT Server
• Windows Cluster VIP
The Windows classifier supports the following Windows workstation operating systems:
• Windows XP
• Windows Vista
• Windows 7
Device Classifications 56
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):
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 This script runs if classification criteria are met. Use this script to perform any special tasks after a device is classified. With the
classification October2011 Preview 1 release, it is possible to use the g_probe_parameters hashmap from within a classification script to set
script 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 These criteria are formed from specific parameters and the values that they must contain to match devices that Discovery finds in
Criteria the network with CIs in the CMDB. For a detailed discussion of these parameters, see Discovery Classification Parameters.
Triggers These are the exploration probes that Discovery launches to gather detailed information about a CI that it has classified in the
probes network.
A completed CI classification form with exploration probes defined is shown here. For instruction on creating
probes, see Creating a Probe. The probes defined here are launched when the device is properly classified, unless
Discovery is configured to stop after classification.
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:
Debugging Classifications
To log debugging information about classifications, add the glide.discovery.debug.classification property and set
the value to true. 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.
To add the property:
1. In the navigation filter, type sys_properties.list.
The list of properties appears.
2. Click New.
3. Enter glide.discovery.debug.classification in the Name field.
4. Enter a description, such as Log debugging information about Discovery Classifications.
5. Select true/false as the property Type.
6. Type in a Value of true.
7. Click Submit.
Process Classifications 61
Process Classifications
Overview
Process classification in Discovery tracks services, such as database servers, that play an important business role in
your instance. Discovery classifies processes during the exploration phase, after the devices have been identified.
Process classification, like device classification, uses classification criteria and can launch probes, but unlike device
classification, creates child configuration items (CI) with Runs on::Runs relationships. For information on how
Discovery creates and maintains dependent relationships between CI, including processes, see Application
Dependency Mapping.
The Classification Form

Select Discovery Definition > CI Classification > Process in the navigation pane. ServiceNow includes
classifications in the base platform that discover most common processes. ServiceNow provides the following
unique fields for creating new classifications or edit existing ones.
Field Input Value
Table Select the a table for this classification. For example, if this record classifies a router, select the cmdb_ci_ip_router table.
Relation type Select the CI relationship types for this classification. The relationship field is only available for Process and Scan Application
classifications. The relationships that are most appropriate for Discovery are:
• 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 which criteria must match to classify this device - Any of the parameters or All of the parameters.
On This script runs if classification criteria are met. Use this script to perform any special tasks after a device is classified. With the
classification October2011 Preview 1 release, it is possible to use the g_probe_parameters hashmap from within a classification script to set
script 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 These criteria are formed from specific parameters and the values that they must contain to match devices that Discovery finds in
Criteria the network with CIs in the CMDB. For a detailed discussion of these parameters, see Discovery Classification Parameters.
Triggers These are the exploration probes that Discovery launches to gather detailed information about a CI that it has classified in the
probes network.
A completed process classification form with an exploration probe defined is shown below. For instruction on
creating probes, see Creating a Probe. The probes defined here are launched when the device is properly classified,
unless Discovery is configured to stop after classification.
Classification Criteria
The classification criteria for a Discovery 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 out-of-box classification, see Discovery Classification Parameters. In this example
from the out-of-box ServiceNow system, the process that is started with the command sqlservr.exe is classified as
Microsoft SQL Server.
The On classification script field can be used to further customize the application record being created. There are
currently some objects that are exposed for this purpose.
• 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)
• 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.
By default, we create the name of the application 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, we create an application with the name,
mysql@machineA. If this is not the desired name, we can customize it using exposed variables in the following
script in the On classification script field:
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 use the name, command and parameter variables. For example, looking at an
Eclipse process, we might have the following values in these variables:
• name => "eclipse"
• command => "/glide/eclipse/Eclipse.app/Contents/MacOS/eclipse"
• parameter => "-psn_0_1884620"
For an Eclipse application running on a computer called machineA, we create an application with the name,
eclipse@machineA. If this is not the desired name, we can customize it differently (in the On classification script
field). In the following example, we append the parameter value as part of the name of the application we create.
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 will become eclipse-psn_0_1884620@machineA.
Also, sometimes it's useful to pass certain values to the triggered probes in the process classification, we can achieve
this by adding the name/value pair to the g_probe_parameters object.
g_probe_parameters['processCommand'] = command;
In the example above, if there is a probe triggered from the classification record, it automatically gets the parameter
called "processCommand" with the value of the command variable attached to the probe.
Debugging Classifications
To log debugging information about classifications, add the glide.discovery.debug.classification property and set
the value to true. 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.
To add the property:
1. In the navigation filter, type sys_properties.list.
The list of properties appears.
2. Click New.
3. Enter glide.discovery.debug.classification in the Name field.
4. Enter a description, such as Log debugging information about Discovery Classifications.
5. Select true/false as the property Type.
6. Type in a Value of true.
7. Click Submit.
Discovery Classification Parameters 64
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.
UNIX Parameters
The UNIX parameters define the characteristics of several types of computers, such as Linux, Solaris, and HP-UX,
communicating with the SSH protocol.
output The raw output of the classifier probe (uname -a).
type Returns the classification UNIX.
IP address Returns the IP address of the device being discovered.
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.
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.
SNMP Parameters
The SNMP parameters can define the characteristics of several types of devices, such as routers, switches, and
printers.
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).
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.
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
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
References
[1] http:/ / www. zytrax. com/ tech/ web/ regex. htm
72
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.
Discovery Identifiers 73
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.
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. Navigate to Discovery Definition > Probes.
2. Select Multiprobe in the Probe Type field.
3. In the Includes Probes Related List, click Edit to select simple probes to include in this multiprobe.
4. 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.
Multiprobe Includes these probes
AIX - Identify • AIX - Network: Determines network interfaces, IPs, and MACs
• AIX - Serial Number: Retrieves the AIX serial number
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.
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.
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 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.
to
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:

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 Yes No

matched in CMDB
Device not matched Yes - if the device has matchable information available, such Yes - if the device has matchable information available, such
in CMDB 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 No No
matched in CMDB
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.
Out-of-Box Identifiers
The following Identifiers are included in the out-of-box ServiceNow system.
Identifier Description Details
Serial Number Identify CIs in the CMDB This identifier matches the discovered serial number against the serial_number in the Serial
Table & Class based on serial number(s) Number [cmdb_serial_number] table. If the discovered serial number matches a CI in the
Name in the serial number table cmdb_serial_number table and the class name, then the CI is declared identified. Note that in the
and sys_class_name. out-of-box 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).
Serial Number Identify CIs in the CMDB This identifier matches the discovered serial numbers against the serial number field in the base CI
& Class Name based on the record. If a discovered serial number and class type (sys_class_name) matches a CI, then that CI is
serial_number field and declared identified. The matching class name requirement means that Discovery will not identify
matching sys_class_name. CIs that are not in the same class. For example, a computer and a printer have the same serial
number, but since their class name differs, Discovery will 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 Identify CIs in the CMDB This identifier matches the discovered name against the name field in the base CI record. If a
Name based on name field and discovered name and class type (sys_class_name) matches a CI, then that CI is declared identified.
matching sys_class_name. 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 Identify CIs in the CMDB This identifier matches the discovered network adapters against those in the Network Adapter
based on IPs and MAC [cmdb_ci_network_adapter] table, using the IP address and MAC address. If all the discovered
Address(es) in the network network adapters match a CI in the network adapter table, then the CI is declared identified.
adapter table.
Network & Identify CIs in the CMDB This identifier matches the discovered IP address and MAC address of the base CI against those in
Class Name based on the mac_address the base CI record. If a discovered IP address, MAC address and class type (sys_class_name)
field and the ip_address matches a CI, then that CI is declared identified. The matching class name requirement means that
field and matching Discovery will not identify CIs that are not in the same class.
sys_class_name.
MAC Address Identify CIs in the CMDB This identifier matches the discovered MAC address of the base CI against those in the base CI
& Class Name based on the mac_address record. If a discovered MAC address and class type (sys_class_name) matches a CI, then that CI is
field and matching declared identified. The matching class name requirement means that Discovery will not identify
sys_class_name. CIs that are not in the same class.
IP Address & Identify CIs in the CMDB This identifier matches the discovered IP address of the base CI against those in the base CI record.
Class Name based on the ip_address If a discovered IP address and class type (sys_class_name) matches a CI, then that CI is declared
field and the matching identified. The matching class name requirement means that Discovery will not identify CIs that are
sys_class_name. not in the same class.
MACAddress Identify CIs in the CMDB This identifier matches the discovered MAC address of the base CI against those in the base CI
based on MAC Address(es) record. If a discovered MAC address and class type (sys_class_name) matches a CI, then that CI is
in the network adapter declared identified. The matching class name requirement means that Discovery will not identify
table. CIs that are not in the same class.
Generic Serial Identify CIs in the CMDB This identifier matches the discovered serial number against the serial number field in the base CI
Number based on serial_number record. If a discovered serial number matches a CI, then that CI is declared identified. Note here that
field. 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 Identify CIs in the CMDB This identifier matches the discovered IP address and MAC address of the base CI against those in
Network based on the mac_address the base CI record. If a discovered IP address and MAC address matches a CI, then that CI is
field and the ip_address declared identified. The matching class name is NOT a requirement, which means that Discovery
field. will identify CIs that are not in the same class.
Generic Name Identify CIs in the CMDB This identifier matches the discovered name against the name field in the base CI record. If a
based on name field. 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 Identify CIs in the CMDB This identifier matches the discovered MAC address of the base CI against those in the base CI
Address based on MAC address record. If a discovered MAC address matches a CI, then that CI is declared identified. The matching
field. class name is NOT a requirement, which means that Discovery will identify CIs that are not in the
same class.
Generic IP Identify CIs in the CMDB This identifier matches the discovered IP address of the base CI against those in the base CI record.
Address based on IP address field. 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.
Credentials 82
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 Runbook Automation. The platform
stores these credentials in an encrypted field on the Credentials table, and once they are entered, they cannot be
viewed.
Versions at Berlin or later can use a feature called credential tagging to assign individual credentials to any activity
in a runbook workflow or assign different credentials to each occurrence of the same activity type in a runbook
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 Runbook 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 Runbook create an affinity between the credentials and the device using the
Credential Affinity [dscy_credentials_affinity] table. All subsequent discoveries or Runbook 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 Runbook try all available credentials again until they create a new affinity.
Note: If Runbook and Discovery are installed, and if 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. The credentials are decrypted on the instance with the fixed key.
2. The credentials are re-encrypted on the instance with the fixed Web Service key.
3. The credentials are encrypted on the instance with SSL.
4. The credentials are decrypted on the MID Server with SSL.
5. The credentials are decrypted on the MID Server with the fixed Web Service key.
Credentials 83
Note: The platform does not have separate encryption keys for multi-tenant instances.
Discovery and Runbook 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 Runbook must have access to the necessary credentials to execute commands on computers in
the network as specified by the Workflow activities. Runbook 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 Runbook explore UNIX and Linux devices by using commands executed over SSH, 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 Runbook have the root credentials to any UNIX or Linux system, then no
further configuration is required.
• Give other credentials for Discovery or Runbook, 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 Runbook 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).
Configuring sudo Commands to Grant Root Privileges

Each command for which Discovery or Runbook 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 Runbook

Credentials 84
Command Platform(s) Purpose /etc/sudoers line example Used By
dmidecode All Linux Gathers several pieces of information about Disco ALL=(root) /sbin/dmidecode Discovery
the hardware, including the serial number
embedded within the motherboard.
lsof All Linux and Determines the relationship between Disco ALL=(root) /sbin/lsof Discovery
Mac versions processes and the connections being made to
the system.
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 Changes user passwords. Disco ALL=(root) /etc/chpasswd Runbook
UNIX versions
chage All Linux and Changes the number of days between Disco ALL=(root) /etc/chage Runbook
UNIX versions password changes and the date of the last
password change.
oratab All Unix Grants read access to the oratab file for N/A Discovery
versions locating the Oracle Home and pfile.
Windows Credentials
Windows credentials are used differently by Discovery and Runbook.
Discovery
Discovery explores Windows computers using Microsoft's secure remote architecture to run remote WMI queries
and to access the administrative share. This access must use Microsoft components and must run in the context of a
Windows user with the required privileges. Discovery accomplishes this by using a MID server installed as a
Windows service with either Windows domain administrator privileges, or with local administrator privileges for the
computers being discovered. This ensures that the MID Servers can query all Windows devices in an IP address
range. Local security policies may vary.
Runbook
Runbook activities in the out-of-box system that run commands on Windows machines can use Windows
PowerShell [4] credentials (from the ServiceNow Credentials table) or the domain administrator credentials of the
MID Server service. If Runbook cannot find PowerShell credentials in the Credentials table (of the type Windows),
Runbook uses the login credentials of the MID Server service. The advantage to using PowerShell is that one MID
Server can execute Runbook activities across multiple domains, reducing the number of MID Servers required.
Credentials 85
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 Runbook 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 running on the machine, 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.
Runbook 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 Runbook 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).
Credential Order
When Runbook 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 Runbook 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
Runbook 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 those credentials with a high order
value.
Credentials 86
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 Runbook 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.
• MSSQL: 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.
User name Enter a user name for this type of credential. Avoid leading or trailing spaces in user names. These spaces can prevent the VMware -
vCenter probe from connecting to vCenter.
Password Type the password to use. If you have selected SNMP type credentials, you type the community string here.
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 Runbook tries the
credentials in a random order.
SSH Type a secure SSH passphrase. This field is available only for SSH Private Key credentials.
passphrase
SSH Private 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
Key credentials.
MID Select one or more MID Servers from the list of available MID Servers. The credentials configured in this record are available to the
servers 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:
Credentials 87
References
[1] http:/ / www. sudo. ws/ sudo/ sudo. html
Discovery Schedules
Overview
The Discovery Schedule form is the starting point for all Discovery activities. The schedule determines what is going
to be discovered, when it will be discovered (the day and time), and how Discovery will be performed (the MID
Servers to use).
You 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 Discovery runs in your network.
• Configure the use of multiple MID Servers for tasks such as load balancing.
• Run 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 various 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 Schedules 88
Solaris Serial Number Probe

An exploration probe and accompanying sensor, included in the baseline system, enable Discovery to detect the
serial numbers of Solaris devices. This probe, called Solaris - Serial Number, requires the installation of a
command line tool from Sun Microsystems called SNEEP. To download and install [1] this tool, log onto the
Oracle website. After this tool is installed, the serial number probe runs automatically when Discovery detects a
Solaris device.
Schedule Form
To access a list of Discovery Schedules, navigate to Discovery > Discovery Schedules. The scheduler form provides
the following fields:
Field Input Value
Name Type a unique, descriptive name for your schedule.
Discover Select one of the following types:

• 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: Select this type of scan to discover devices without the use of credentials. IP address 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.
• Networks: Use this selection to discover IP Networks (routers and switches). Results from this search are used to populate the IP
Network table (cmdb_ci_ip_network) in Discovery > IP Networks with a list of IP network addresses and network masks.
Network Discovery updates routers and layer 3 switches in the CMDB.
Behavior Select a Behavior that you have 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 scan types (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 for Configuration items scans.
MID Server Select the MID Server to use for this schedule. This field is available for Configuration items and Networks scan types. If you
select a MID Server, you cannot select a behavior to run on the same Discovery. The localhost MID Server, which was used as the
default MID Server in Discovery Schedules, was removed from the platform with the Aspen Patch 3 release. This MID Server
originally was intended for demonstration purposes and was not intended as a supported feature.
Location Pick 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 Set a limit to the amount of time Discovery can run on this schedule. When the configured time elapses, the remaining tasks for this
Time 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 will run until complete.
Active Select the check box (true) to enable this schedule. If you clear the check box, the schedule for this action is disabled, but you can
still run Discovery manually from this form, using the configured values.
Include alive Select this check box to include all 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 doesn't known anything about it. If this check box is not checked, Discovery returns all active devices
(those that have at least one open port).
Log state Select this check box to create a log entry every time the state changes during a Discovery. View the Discovery states in the
changes Completed activity and Current activity fields in the Discovery Devices list in the Status form. An example of a state change is
when Discovery for a specific device goes from Active to Classifying.
Run Select when to run Discovery on this schedule: daily, weekly, etc. If you select Once, Discovery runs one time only, when you
update the record.
Day Select a day of the week on which to run Discovery on this schedule. This field appears when you select a Weekly or Monthly
schedule. You can select a particular day of the week or any day of the month.
Time Select the time of day this schedule should run. All times are local and use a 24 hour clock.
Repeat Select the number of days between scheduled Discovery runs. This selection is available when you choose Periodically in the Run
Interval field.
Quick Define IP addresses and address ranges to scan by entering IP addresses in multiple formats (network, range, or list) in a single,
Ranges comma-delimited string. For details, see Quick Ranges in this page.
Discovery This related list defines the ranges of IP addresses to scan using this schedule. If you are using a simple CI scan (no behaviors), this
IP Ranges is the way to define the IP addresses to discover.
Discovery Each range set in a schedule defines IP addresses that will be scanned using this schedule. All the range sets listed will be scanned
Range Sets by this schedule.
Note: You can run a Discovery scan manually at any time using the settings in a schedule record by clicking Discover now under
Related Links. This action does not affect the schedule. The schedule will run as configured, despite manual execution.
A completed Discovery Schedule looks like this:

Configuring IP Addresses
You can select the IP address you want to discover by using the following formats:
• IP Address List
• IP Address Range
• IP Network
Use one or more of these methods in any combination to define your network or network segment for Discovery to
query.
Note: If you do not know the IP addresses in your network to scan, run Network Discovery first to determine your IP networks, and
then convert the IP networks into IP address range sets.
IP Address List
Use IP address lists to add individual addresses for Discovery to query that are not included in any range or network
specified. You have a choice of entering the IP address of the device or a host name (DNS name). If you configure a
host name, it must be resolveable 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 you must ensure that you include only the addresses of single, manageable
devices in the network. Discovery has no way of knowing if the network or broadcast addresses are included in the
range, 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.
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 using either of
the following notations:
• 192.168.0.0/24
• 192.168.0.1/255.255.255.0
This lets Discovery know that it is scanning an IP network, and that it should 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. Because of this built-in control, IP Networks are the best method of telling Discovery what
ranges of IP addresses to query.
Quick Ranges Feature

To create IP address ranges, networks, and lists quickly, click the Quick Ranges link under Related Links. This
feature enables an administrator to define IP addresses to scan by entering all three formats in a single,
comma-delimited string. For example, type 10.10.10.0/24,10.10.11.0-10.10.11.165,10.10.11.200,10.10.11.235 to
scan addresses in a network, a range, and a list without having to create three separate records.
Note: The Quick Range interface is for the entry of IP addresses only and cannot be used to edit IP addresses that have already been
submitted.
When the Quick Ranges definitions are submitted, the instance automatically displays each in the proper format. To
make any changes to the IP address ranges, drill into these records.
Excluding IP Addresses
Specific IP addresses in a range or network might need to be excluded from an established Discovery Schedule. This
is necessary if a subnet contains critical-use devices that cannot be discovered due to a local policy that prevents
interacting with those devices. An example of a device that might be excluded is one with an intentionally
unorthodox configuration that causes an authentication issue each time it is discovered.
1. In the Discovery Schedule, click the link for the Type of IP address range that contains the address to exclude.
For example, if we want to exclude 10.10.10.82, we select the IP Network for 10.10.10.0/24, the range of IP
addresses that contains our target address.
The Discovery IP Range form appears.
2. Click New in the Discovery Range Item Excludes Related List.

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 in the record's header bar and select Save from the pop-up menu.
The Discovery Range Item IPs Related List appears.
5. Click New in this list.
An entry form for the IP addresses or hostnames 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 at the bottom of the Discovery
Range Item Exclude form for that IP address Type.
7. Click Update to save your excluded address and return to the Discovery Schedule.
References
[1] https:/ / login. oracle. com/ mysso/ signon. jsp
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).
Note: As of the Aspen release, SNMP MIB uses a new synching method. This change should not negatively affect existing custom
MIBs. Also, remote attachments are no longer used.
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.
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.
Network Discovery 95
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.
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 Controls whether Network Discovery exploration of routers running the BGP protocol is Yes
Exploration disabled. Normally such exploration IS disabled because of the huge size of BGP routing
Disable 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).
Maximum The maximum number of bits in a regular netmask for networks that will be discovered by 28
Netmask Size Network Discovery. By "regular netmask" we mean a netmask that can be expressed in
for binary as a string of ones followed by a string of zeroes (255.255.255.0 is regular,
Discoverable 255.255.255.64 is irregular). Regular networks are commonly expressed like this:
Networks (bits) 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.
Network This property controls the method used to decide (during Network Discovery) which router Most Networks
Router should be selected as the router to be associated with a given IP Network. The possible
Selection values are: "First Router" (the first router that discovers the network is associated), "Last
Method 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).
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 7,8,9,26,53,62,69,71,78,115,117,209
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".
Stale Network The number of days before which discovered information about network gear is considered -1
Discovery "stale". While performing network discovery, if a router (or other device capable of routing)
Threshold has not been discovered, or if the discovered information is stale, then network discovery
(Days) 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 Enables extensive logging (for debugging purposes) of all Network Discovery activities on Yes
Discovery the instance. Normally this is only set to "yes" by developers.
Debugging
Discovery Status 98
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 Displays the maximum amount of time Discovery was permitted to run on this schedule.
Time
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 Indicates that state changes were logged during this Discovery. Discovery states can be seen in the Last and Current fields in the
changes Discovery Devices list in this form.
A Discovery Status record looks like this:

Discovery Status 99
Discovery Timelines
A Discovery Timeline generates a graphical display of the ECC Queue for a Discovery, including information
about each probe and sensor running. To display a timeline, click the Show Discovery Timeline Related Link on
any Discovery Status form. No additional configuration is required.
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
Discovery Status 100
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 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.
CI
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.
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.
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 Indicates the outcome of Discovery for this device or the last completed activity for a Discovery in progress, such as Identified
activity 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. This field was added for the October 2011 Preview 1 release.
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.
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 Displays the name of the probe or sensor in the Discovery sequence whose activity triggered this probe or sensor. A single sensor can
to 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:

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.
Discovery Timelines 106
Discovery Timelines
Overview
A Discovery Timeline generates a graphical display of the ECC Queue for a Discovery, including information
about each probe and sensor running. To display a timeline, click the Show Discovery Timeline Related Link on
any Discovery Status form. No additional configuration is required.
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.
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.
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.
109
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 Select the MID Servers to use for this behavior, the desired execution phase, and the pre-configured functionality for each
Functionality MID Server (protocols to scan).
The completed Discovery Behavior form looks like this:

Discovery Behavior 110
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 Define criteria here for Windows MID Servers. See the following section for details.
Criteria
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 111
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 Leave the default criteria of Any.

criteria
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.
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.
In our example, we select LoadBalanced.
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 location.
6. Save the record.
7. Create additional schedules for each time zone or region in the network and select the same behavior.
Discovery Behavior - Multiple Domains 114
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.
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.
Match Change the criteria to All.

criteria
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:
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.
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
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.
Match Leave the default criteria of Any. Criteria are not used for non-WMI functionalities.
criteria
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
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.

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

• 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.
The completed criteria appear 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.
5. Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this location.
6. Save the record.
7. Create an additional schedule if more than one time zone is involved.
Discovery Behavior - Access Control Lists (ACL) 119
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.
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.
Match Leave the default criteria of Any. Criteria are not used for SNMP functionalities.
criteria
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
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.

criteria

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

• 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.
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.
5. Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this domain.
6. Save the record.
123
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 124
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.
Discovery FAQ 125
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.
Discovery FAQ 126
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. Once entered, the system has no way of ever displaying
them again.
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.
Discovery FAQ 127
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 IBM CCMDB, 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 Runbook. 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).
128
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 129
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.
Application Dependency Mapping 130
Application Dependency Mapping

Overview
Application Dependency Mapping determines which machines are communicating with one another, and on which
port, and determines which processes are running on these machines. You can use the data from running processes to
determine which machines to drill into for more application-specific configuration data. Discovery maps this data
automatically into upstream and downstream relationships, using the following types:
• Runs on/Runs
• Depends on/Used by
• Hosted on/Hosts
• Virtualized by/Virtualizes
• Contains/Contained by
• 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 (Servers, Database Servers, Database Instances, etc.).
2. Select a specific CI from the list.
3. In the CI record, select 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.
Deleting CIs
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.
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.
3. Create and run an appropriate filter to make the desired CI visible in the list of available CIs.
4. Move the CI from the list of available CIs to the dependent list.
5. Save the relationship.
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.
VMware Component Relationships 134
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 Runbook Automation 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
Runbook Automation to create and manage virtual servers, Discovery populates records automatically and detects
changes in the network. Without Discovery, all the records for Runbook Automation 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:
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.
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.
Article Sources and Contributors 137
Article Sources and Contributors

Getting Started Source: http://wiki.servicenow.com/index.php?oldid=127508 Contributors: Bow, CapaJC, G.yedwab, Guy.yedwab, Joseph.messerschmidt, Pat.Casey, Steve.wood, Swood,
Valor, Vhearne
Discovery Made Easy Source: http://wiki.servicenow.com/index.php?oldid=127505 Contributors: Bow, CapaJC, G.yedwab, Guy.yedwab, Ishrath.razvi, Jerrod.bennett, Joseph.messerschmidt,
Steve.wood, Swood, Tom.dilatush, Vhearne
Discovery Agentless Architecture Source: http://wiki.servicenow.com/index.php?oldid=100677 Contributors: Bow, CapaJC, Chuck.tomasi, Dan.greenbaum, G.yedwab, Guy.yedwab,
Joseph.messerschmidt, Rob.woodbyrne, Steve.wood, Swood, Vhearne
Setting up Discovery Source: http://wiki.servicenow.com/index.php?oldid=130199 Contributors: CapaJC, Cheryl.dolan, Emily.partridge, Joseph.messerschmidt, Steve.wood, Swood
MID Server Plugin Source: http://wiki.servicenow.com/index.php?oldid=89866 Contributors: Aburruss, Bow, CapaJC, Christen.mitchell, Chuck.tomasi, Dan.sherwin, David Loo, Doogiesd,
G.yedwab, Guy.yedwab, Jeremiah.hall, John.andersen, John.roberts, Joseph.messerschmidt, Mark.odonnell, Neola, Rob.woodbyrne, Steve.wood, Swood, Tom.dilatush, 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, Steve.wood, Swood, Valor, Vaughn.romero, Vhearne
MID Server Installation Source: http://wiki.servicenow.com/index.php?oldid=92534 Contributors: Steve.wood, Swood
Deploying Multiple MID Servers Source: http://wiki.servicenow.com/index.php?oldid=100485 Contributors: Chuck.tomasi, Joseph.messerschmidt, Steve.wood, Swood
MID Server Configuration Source: http://wiki.servicenow.com/index.php?oldid=134387 Contributors: Aleck.lin, Bow, Emily.partridge, Guy.yedwab, Jim.holthaus, Joseph.messerschmidt,
Steve.wood, Swood, Tom.dilatush, Vaughn.romero, Vhearne, Voytek.blonski
MID Server Clusters Source: http://wiki.servicenow.com/index.php?oldid=135017 Contributors: Joseph.messerschmidt, Steve.wood, Swood
Controlling the MID Server Version Source: http://wiki.servicenow.com/index.php?oldid=135800 Contributors: Emily.partridge, Joseph.messerschmidt, Steve.wood, Swood
MID Server Heartbeat Source: http://wiki.servicenow.com/index.php?oldid=103817 Contributors: Joseph.messerschmidt, Steve.wood, Swood, Tom.dilatush
MID Server User Security Source: http://wiki.servicenow.com/index.php?oldid=103753 Contributors: Cheryl.dolan, Joseph.messerschmidt, Neola, Steve.wood, Swood
Shazzam Probe Parameters Source: http://wiki.servicenow.com/index.php?oldid=134399 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Rachel.sienko, Steve.wood, Swood,
Tom.dilatush
Port Probes Source: http://wiki.servicenow.com/index.php?oldid=122653 Contributors: Aleck.lin, Ishrath.razvi, Joseph.messerschmidt, Steve.wood, Swood
Database Catalogs Source: http://wiki.servicenow.com/index.php?oldid=101685 Contributors: G.yedwab, Joseph.messerschmidt, Rachel.sienko, Steve.wood, Swood
Custom Probe - Text File Source: http://wiki.servicenow.com/index.php?oldid=101893 Contributors: CapaJC, Doogiesd, G.yedwab, Guy.yedwab, Joseph.messerschmidt, Neola,
Rachel.sienko, Steve.wood, Swood
Device Classifications Source: http://wiki.servicenow.com/index.php?oldid=102047 Contributors: Aleck.lin, G.yedwab, Joseph.messerschmidt, Steve.wood, Swood
Process Classifications Source: http://wiki.servicenow.com/index.php?oldid=105158 Contributors: Aleck.lin, Joseph.messerschmidt, Steve.wood
Discovery Classification Parameters Source: http://wiki.servicenow.com/index.php?oldid=100607 Contributors: G.yedwab, Joseph.messerschmidt, Steve.wood, Swood, Tom.dilatush
Discovery Identifiers Source: http://wiki.servicenow.com/index.php?oldid=100679 Contributors: G.yedwab, Joseph.messerschmidt, Steve.wood, Swood, Tom.dilatush
Credentials Source: http://wiki.servicenow.com/index.php?oldid=133843 Contributors: Aleck.lin, Bow, CapaJC, Cheryl.dolan, Doogiesd, G.yedwab, Guy.yedwab, Joseph.messerschmidt,
Steve.wood, Swood, Tom.dilatush, Vhearne, Voytek.blonski
Discovery Schedules Source: http://wiki.servicenow.com/index.php?oldid=111451 Contributors: G.yedwab, Joseph.messerschmidt, Steve.wood, Swood, Voytek.blonski
Network Discovery Source: http://wiki.servicenow.com/index.php?oldid=102065 Contributors: Aleck.lin, Chuck.tomasi, G.yedwab, Joseph.messerschmidt, Steve.wood, Suzannes, Swood
Discovery Status Source: http://wiki.servicenow.com/index.php?oldid=113561 Contributors: Cheryl.dolan, G.yedwab, Joseph.messerschmidt, Steve.wood, Swood, Voytek.blonski
Discovery Timelines Source: http://wiki.servicenow.com/index.php?oldid=122654 Contributors: Joseph.messerschmidt, Steve.wood, Swood, Wallymarx
Discovery Behavior Source: http://wiki.servicenow.com/index.php?oldid=120680 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Rachel.sienko, Russ.sarbora, Steve.wood,
Swood
Discovery Behavior - Load Balancing Source: http://wiki.servicenow.com/index.php?oldid=120682 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Steve.wood, Swood
Discovery Behavior - Multiple Domains Source: http://wiki.servicenow.com/index.php?oldid=120684 Contributors: G.yedwab, Joseph.messerschmidt, Steve.wood, Swood
Discovery Behavior - Access Control Lists (ACL) Source: http://wiki.servicenow.com/index.php?oldid=120686 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Steve.wood,
Swood
Discovery FAQ Source: http://wiki.servicenow.com/index.php?oldid=122794 Contributors: Aleck.lin, Bow, CapaJC, Cheryl.dolan, Dan.greenbaum, Doogiesd, Fred.luddy, Guy.yedwab,
Joseph.messerschmidt, Rob.phillips, Steve.wood, Swood, Tom.dilatush, Vhearne
Discovery Bandwidth Source: http://wiki.servicenow.com/index.php?oldid=100167 Contributors: Dan.sherwin, G.yedwab, Guy.yedwab, John.roberts, Joseph.messerschmidt, Swood, Vhearne
Discovery Resource Utilization Source: http://wiki.servicenow.com/index.php?oldid=103761 Contributors: Bow, CapaJC, Doogiesd, G.yedwab, Guy.yedwab, Steve.wood, Swood,
Tom.dilatush, Vhearne
Application Dependency Mapping Source: http://wiki.servicenow.com/index.php?oldid=120665 Contributors: Dan.sherwin, Eprokopow@enernoc.com, G.yedwab, Guy.yedwab,
Joseph.messerschmidt, Rob.phillips, Rob.woodbyrne, Steve.wood, Swood, Vhearne
VMware Component Relationships Source: http://wiki.servicenow.com/index.php?oldid=120722 Contributors: Aleck.lin, Joseph.messerschmidt, Steve.wood, Swood
Image Sources, Licenses and Contributors 138
Image Sources, Licenses and Contributors

Image:Tick.png Source: http://wiki.servicenow.com/index.php?title=File:Tick.png License: unknown Contributors: Mark.odonnell
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:
Steve.wood
Image:Discovery_Communications_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Communications_Diagram.png License: unknown Contributors:
Steve.wood
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:
Steve.wood
Image:Discovery_Oracle_Instance.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Oracle_Instance.png License: unknown Contributors: Steve.wood
Image:Discovery_Oracle_Listener.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Oracle_Listener.png License: unknown Contributors: Steve.wood
Image:Discovery_Process_Ports.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Process_Ports.png License: unknown Contributors: Steve.wood
Image:Discovery ECC Queue View.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_ECC_Queue_View.gif License: unknown Contributors: Swood
Image:Discovery_Log2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Log2.png License: unknown Contributors: Swood
Image:JAR_File_Sync.png Source: http://wiki.servicenow.com/index.php?title=File:JAR_File_Sync.png License: unknown Contributors: Steve.wood
Image:Mid server app.jpg Source: http://wiki.servicenow.com/index.php?title=File:Mid_server_app.jpg License: unknown Contributors: David Loo, Steve.wood
Image:MID_Server_Download.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Download.png License: unknown Contributors: Steve.wood, Swood
Image:Caution-diamond.png Source: http://wiki.servicenow.com/index.php?title=File:Caution-diamond.png License: unknown Contributors: John.roberts
Image:MID config.png Source: http://wiki.servicenow.com/index.php?title=File:MID_config.png License: unknown Contributors: Swood, 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_Roles.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Roles.png License: unknown Contributors: Swood
Image:MID_Server_Unblock_Config.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Unblock_Config.png License: unknown Contributors: Steve.wood
Image:MID_Server_Clusters_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Clusters_Diagram.png License: unknown Contributors: Swood
Image:MID_Server_Cluster1.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Cluster1.png License: unknown Contributors: Swood
Image:MID_Server_Monitor_Interval.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Monitor_Interval.png License: unknown Contributors: Swood
Image:Discovery Port Probe2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Port_Probe2.png License: unknown Contributors: Swood
Image:Database Catalog Menu.gif Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalog_Menu.gif License: unknown Contributors: Swood
Image:Database Catalog2.png Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalog2.png License: unknown Contributors: Steve.wood
Image:Database Catalogs1.gif Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalogs1.gif License: unknown Contributors: Swood
Image:Database Catalog Form.gif Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalog_Form.gif License: unknown Contributors: Swood
Image:Probe_Parameters.png Source: http://wiki.servicenow.com/index.php?title=File:Probe_Parameters.png License: unknown Contributors: Steve.wood
Image:Newprobe.png Source: http://wiki.servicenow.com/index.php?title=File:Newprobe.png License: unknown Contributors: Doogiesd, Steve.wood
Image:Newsensor.png Source: http://wiki.servicenow.com/index.php?title=File:Newsensor.png License: unknown Contributors: Doogiesd, Steve.wood
Image:Discovery Identifiers Diagram.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers_Diagram.gif License: unknown Contributors: Swood
Image:Discovery Classification Diagram.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Diagram.gif License: unknown Contributors: Swood
Image:Discovery Classification Win Server.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Win_Server.png License: unknown Contributors:
Steve.wood
Image:Discovery Classification Criteria2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Criteria2.png License: unknown Contributors: Steve.wood
Image:Reclassify_XP1.png Source: http://wiki.servicenow.com/index.php?title=File:Reclassify_XP1.png License: unknown Contributors: Swood
Image:Reclassify_XP2.png Source: http://wiki.servicenow.com/index.php?title=File:Reclassify_XP2.png License: unknown Contributors: Swood
Image:Discovery Classification Process.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Process.gif License: unknown Contributors: Swood
Image:Discovery Classification Criteria.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Criteria.gif License: unknown Contributors: Swood
Image:Discovery Classifier Criteria New2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classifier_Criteria_New2.gif License: unknown Contributors: Swood
Image:Discovery Nmap Scan.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Nmap_Scan.gif License: unknown Contributors: Swood
Image:Discovery IP Service.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_IP_Service.gif License: unknown Contributors: Swood
Image:Discovery Functionality Def.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Functionality_Def.gif License: unknown Contributors: Swood
Image:Discovery Port Probe.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Port_Probe.gif License: unknown Contributors: Swood
Image:Discovery Application Classifier.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Application_Classifier.gif License: unknown Contributors: Swood
Image:Discovery XML Parameters.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_XML_Parameters.gif License: unknown Contributors: Swood
Image:Discovery XML Parameters2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_XML_Parameters2.gif License: unknown Contributors: Swood
Image:Discovery Classification Parameter.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Parameter.gif License: unknown Contributors: Swood
Image:Discovery Mode CI Item.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Mode_CI_Item.png License: unknown Contributors: Swood
Image:Discovery Multiprobe Select.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Multiprobe_Select.gif License: unknown Contributors: Swood
Image:Discovery Multisensor and Script.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Multisensor_and_Script.gif License: unknown Contributors: Swood
Image:Discovery Classification Identity Probe.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Identity_Probe.png License: unknown Contributors:
Swood
Image:Discovery Identifiers2 Diagram.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers2_Diagram.gif License: unknown Contributors: Swood
Image:Discovery Identifiers Form.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers_Form.png License: unknown Contributors: Swood
Image:Discovery Identifiers Order.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers_Order.png License: unknown Contributors: Swood
Image:Credentials_Affinity_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Credentials_Affinity_Diagram.png License: unknown Contributors: Steve.wood
Image:Discovery Credentials.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Credentials.png License: unknown Contributors: Steve.wood
Image:Discovery Schedule2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Schedule2.png License: unknown Contributors: Steve.wood, Swood
Image:Discovery Quick Ranges1.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Quick_Ranges1.gif License: unknown Contributors: Steve.wood, Swood
Image:Discovery Quick Ranges2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Quick_Ranges2.gif License: unknown Contributors: Swood
Image:Exclude IP Address.png Source: http://wiki.servicenow.com/index.php?title=File:Exclude_IP_Address.png License: unknown Contributors: Swood
Image:Exclude IP Address3.png Source: http://wiki.servicenow.com/index.php?title=File:Exclude_IP_Address3.png License: unknown Contributors: Swood
Image Sources, Licenses and Contributors 139
Image:Private_IP_Addresses.png Source: http://wiki.servicenow.com/index.php?title=File:Private_IP_Addresses.png License: unknown Contributors: Swood

Image:Network_Discovery_Schedule.png Source: http://wiki.servicenow.com/index.php?title=File:Network_Discovery_Schedule.png License: unknown Contributors: Swood
Image:IP_Network_Form.png Source: http://wiki.servicenow.com/index.php?title=File:IP_Network_Form.png License: unknown Contributors: Swood
Image:IP_Network_List.png Source: http://wiki.servicenow.com/index.php?title=File:IP_Network_List.png License: unknown Contributors: Swood
Image:Discovery_Status.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Status.png License: unknown Contributors: Steve.wood, Swood
Image:Discovery Log2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Log2.gif License: unknown Contributors: Swood
Image:Discovery Log3.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Log3.gif License: unknown Contributors: Swood
Image:Discovery Device List.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Device_List.png License: unknown Contributors: Swood
Image:Discovery Device.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Device.png License: unknown Contributors: Swood
Image:Discovery Details.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Details.png License: unknown Contributors: Swood
Image:Discovery_Status_IPs.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Status_IPs.png License: unknown Contributors: Swood
Image:Discovery ECC Queue.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_ECC_Queue.gif License: unknown Contributors: Swood
Image:Discovery_Timeline_Related_Link.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline_Related_Link.png License: unknown Contributors: Swood
Image:Discovery Timeline.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline.png License: unknown Contributors: Swood
Image:Discovery_Timeline_Shazzam_Sensor.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline_Shazzam_Sensor.png License: unknown Contributors:
Swood
Image:Discovery_Timeline_ECC_Queue.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline_ECC_Queue.png License: unknown Contributors: Swood
Image:Discovery Behavior.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Behavior.png License: unknown Contributors: Steve.wood, Swood
Image:Discovery Functionality Criteria.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Functionality_Criteria.gif License: unknown Contributors: Swood
Image:Behavior LoadBalance1.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LoadBalance1.png License: unknown Contributors: Swood
Image:Behavior LocalDomain_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain_New.png License: unknown Contributors: Swood
Image:Behavior LocalDomain2_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain2_New.png License: unknown Contributors: Swood
Image:Behavior LocalDomain New Schedule.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain_New_Schedule.png License: unknown Contributors:
Swood
Image:Behavior ACL_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL_New.png License: unknown Contributors: Swood
Image:Behavior ACL1_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL1_New.png License: unknown Contributors: Swood
Image:Behavior ACL Schedule_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL_Schedule_New.png License: unknown Contributors: Swood
Image:Plugin.gif Source: http://wiki.servicenow.com/index.php?title=File:Plugin.gif License: unknown Contributors: CapaJC
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: Steve.wood
Image:Application_Dependency_Map_Icon.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map_Icon.png License: unknown Contributors: Swood
Image:Application_Dependency_Map.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map.png License: unknown Contributors: Swood
Image:UpstreamDownstream_Relationships.png Source: http://wiki.servicenow.com/index.php?title=File:UpstreamDownstream_Relationships.png License: unknown Contributors: Swood
Image:Application Dependency Map2.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map2.png License: unknown Contributors: Swood
Image:Application_Dependency_Map4.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map4.png License: unknown Contributors: Swood
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: Swood
Image:Define_Relationship.png Source: http://wiki.servicenow.com/index.php?title=File:Define_Relationship.png License: unknown Contributors: Swood
Image:Application_Dependency_Map3.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map3.png License: unknown Contributors: Swood
Image:VMWare_VCenter_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:VMWare_VCenter_Diagram.png License: unknown Contributors: Swood
Image:VMWare_No_VCenter_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:VMWare_No_VCenter_Diagram.png License: unknown Contributors: Swood

ServiceNow Discovery in Detail PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ServiceNow Discovery in Detail PDF

Transféré par

Droits d'auteur :

Formats disponibles

Discovery

What Discovery Does with the Information

Discoverable Windows Operating Systems

Discovery vs. Help the Help Desk

Capability Discovery Help the Help Desk

Automatic discovery by schedule

Automatic discovery on user login

Manually initiated discovery

Unix systems (Solaris, AIX, HP-UX, Mac (OSX))

Network devices (switches, routers, UPS, etc.)

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

The Census Agent

Probing the Neighborhood

MID Server Preparation

Discovery Agentless Architecture

Note: Proper login credentials are required for accessing devices.

Data Collection and Processing (Probes and Sensors)

October 2011 Preview 1

Click the link to the listener in the Oracle Instance form.

The new Oracle Listener form appears.

October 2011 Preview 2

Task 2: Enable the Discovery Plugin

Task 3: Deploy the MID Server to the Host

Task 4: Ensure MID Server Connectivity

Task 5: Set Credentials on the Instance

Task 6: Define Discovery Schedules and Run Discovery

Task 7: Validate the Results

Source Probe name

MID Server Plugin

JAR File Synchronization

MID Server Requirements for Discovery

External Connectivity Requirements

MID Server Installation

Installing a Single MID Server on a Machine

7. Edit the MID Server's credentials.

Installing Multiple MID Servers on a Single Machine

6. Install the MID Server as a Windows service:

Upgrading and Testing

Upgrade Error Messages

Unable to refresh packages Generic error when no reason is given

Using Basic Authentication

Monitoring Your MID Server

Troubleshooting Startup Errors

08/29/11 12:31:46 (055) main Running under Java version: 1.6.0_26

08/29/11 12:31:46 (858) MIDServer Agent home path:

08/30/11 15:16:19 (656) MIDServer Using configuration: C:\Service-now\DocMIDServer01\agent\config.xml

08/30/11 15:16:20 (078) MIDServer Agent home path: C:\Service-now\DocMIDServer01\agent

08/30/11 15:16:20 (187) MIDServer MID Server started

08/30/11 15:16:21 (031) StartupSequencer Successfully connected to instance:

08/30/11 15:16:21 (031) StartupSequencer Install name: Demo Server

08/30/11 15:16:21 (031) StartupSequencer Instance name: demosw

08/30/11 15:16:21 (031) StartupSequencer Node: 9b1a9ce90a0a3c1801834233f12ce49e

08/30/11 15:16:21 (031) StartupSequencer Build date: 08-28-2011_2100

08/30/11 15:16:21 (031) StartupSequencer Build tag:

08/30/11 15:16:21 (031) StartupSequencer Instance ID: 8026b1fa0a0a3c180142bbe642c6e92b

08/30/11 15:16:21 (031) StartupSequencer System ID: bosdemo01.service-now.com:demosw_16245

08/30/11 15:16:21 (031) StartupSequencer Instance IP: 10.10.60.24

08/30/11 15:16:21 (031) StartupSequencer MID version: 08-28-2011_1352

08/30/11 15:22:23 (203) MIDServer Using configuration: C:\Service-now\DocMIDServer01\agent\config.xml

08/30/11 15:22:23 (578) MIDServer Agent home path: C:\Service-now\DocMIDServer01\agent