Beruflich Dokumente
Kultur Dokumente
PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information.
PDF generated at: Thu, 18 Dec 2014 18:02:42 PST
Introduction
Getting Started
Overview
Discovery uses conventional techniques and technology to extract information from computers and other devices. It
uses a wide variety of probes (simple commands or queries) to gather information, and matching sensors (small,
simple programs, usually in JavaScript that you can modify) to analyze that information and load it into the CMDB.
Discovery uses these probes and sensors to explore any given computer or device, starting first with basic probes and
then using more specific probes as it learns more.
Discovery finds out about the existence of any device connected to the network by using the Shazzam probe to
determine what TCP ports are open, and whether the device responds to SNMP queries. From this information,
Discovery infers what kind of device is at that IP address a Unix server, a Windows computer, network switch, and
so on.
For each type of device, Discovery uses different kinds of probes to extract more information about the computer or
device, and the software that's running on it:
Windows computers and servers: remote WMI queries, shell commands
Unix and Linux servers: shell command (via SSH protocol, version 2). Discovery supports Bourne Shell (sh) and
Bourne-again Shell (bash).
Storage: CIM/WBEM queries
Printers: SNMP queries
Network gear (switches, routers, etc.): SNMP queries
Web servers: HTTP header examination
Uninterruptible Power Supplies (UPS): SNMP queries
Getting Started
Discovery Architecture
ServiceNow is normally hosted in ServiceNow's data center, and it does not have the ability to access the enterprise's
network but Discovery needs access to do its job. Many enterprises have multiple networks, often separated by
slow WAN links or security barriers and Discovery needs access to all of them.
Discovery uses special server processes (called MID Servers), that are installed on each enterprise network that has
computers or devices to be discovered. Each MID server is a lightweight Java process that can run on a Linux, Unix,
or Windows server. A dedicated server is not required, as the MID server's resource consumption is quite low (and is
controllable). The MID server's job during Discovery is simply to execute probes and return the results back to the
ServiceNow instance for processing; it does not retain any information. In effect, a MID server is a remote extension
of the ServiceNow instance, on an enterprise network.
MID servers communicate with the ServiceNow instance they are associated with by a simple model: they query the
instance for probes to run, and they post the results of probes they've completed back to the instance. There, the data
collected by the probes is processed by sensors, which decide how to proceed. The MID server starts all
communications, using SOAP on HTTPS which means that all communications are secure, and all
communications are initiated inside the enterprise's firewall. No special firewall rules or VPNs are required.
Discovery is agentless - meaning that it does not require any permanent software to be installed on any computer or
device to be discovered. The MID server uses several techniques to probe devices without using agents. For
example, the MID server will use SSH to connect to a Unix or Linux computer, and then run a standard command
(such as uname or df) to gather information. Similarly, it will use the Simple Network Management Protocol
(SNMP) to gather information from a network switch or a printer.
For more details, see Discovery Agentless Architecture.
Windows NT Server
Windows 2000 Server
Windows 2003 Server
Windows 2008 Server
Windows 2012 Server (starting with the Dublin release)
Windows XP
Windows Vista
Windows 7
Getting Started
Capability
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
Hopefully, you have a basic understanding of Discovery by now. To recap, we'll go over the fundamentals of
Discovery, then run through a scenario that uses these fundamentals.
Discovery is the process of extracting information out of devices and recording it in a uniform way.
The Discovery process uses your ServiceNow instance and one or more MID Servers.
The MID Server is a light-weight (small and simple) agent that runs on a server in your network.
The MID Server needs ranges of IP Addresses and credentials (user names and passwords) before it can begin
discovering.
The MID Server gathers information (using probes) and passes it to the instance to be processed (using sensors).
No Secrets
The MID Server is very adept at ferreting out information, but it's up to you to give it the tools it needs to do the job.
Here's a simple scenario, stepped out to make it easy to follow. Your ServiceNow instance is running, and Discovery
is enabled. You also have a MID Server somewhere in your network that you think is communicating with your
instance. We'll do a Discovery on a single device.
Discovery Happens
Once Discovery has started, it's all up to the MID Server.
1. The instance prepares a probe for the MID Server with a range of IP addresses to test, and then delivers the probe
when the MID Server checks in for jobs to do.
2. The MID Server visits 10.10.10.5 (knocking on the device's door) and scans the ports.
3.
4.
5.
6.
7.
8.
The port scan sees that the machine is listening on port 22, which means that this must be a UNIX or Linux
machine.
The MID Server advises the instance of what it has discovered.
The sensor creates the Get Operating System probe and delivers it when the MID Server checks in for jobs again.
The MID server probes the Linux machine to determine its operating system.
When the machine replies Linux, the MID Server passes this information to the sensor.
Because this is a Linux machine, the sensor asks the MID Server to send a few more probes to get information
about the hard disk, the network adapters, and any processes that are running.
The MID Server runs each of those probes and sends the results back to the sensor, which translates the findings
for the instance.
Have We Met?
So now you have a list of devices that you found and a lot of information about those devices, but what can you do
with this information? Chances are, you already know about many of the devices that Discovery finds in your
network. Most of the computers, routers, printers, and so forth that you have in your Configuration Management
Database (CMDB) will show up every time you run Discovery. Then there are those devices that you don't know
about yet - devices recently added to the network perhaps - that are not in your CMDB. Well, it makes sense that you
should add those new devices to your database, and it also makes sense to update existing devices, particularly if
someone has installed new memory, new software, or added a disk drive. Discovery can do these things
automatically.
Discovery can launch probes that return identity data from the devices it finds. Discovery then feeds that information
into a handy tool called an Identifier that searches the CMDB for a matching device. If the Identifier determines that
ServiceNow already has a record of the device, the Identifier can tell Discovery to launch more probes and update
the existing record. If the Identifier cannot find a matching device in the database, it can tell Discovery to continue
exploring and then create a new record in the database. If you don't want these automatic updates for any reason, you
can tell the Identifier to stop Discovery and not change anything in the CMDB.
And that's all there is to it! We've learned how to Discover a device by using lightweight, remote probes, and we've
learned that we can use the information returned to update our Configuration Management Database automatically.
Communications
This diagram demonstrates a typical Discovery setup for a hosted ServiceNow instance. The MID Server is installed
on the local internal network (intranet). All communications between the MID Server and the ServiceNow instance
is done via SOAP over HTTPS (Secure HTTP - grey lines). Since we use the highly secure and common protocol
HTTPS, the MID Server can connect to the instance directly without having to open any additional ports on the
firewall. The MID Server can also be configured to communicate through a proxy server if certain restrictions apply
(dashed lines).
The MID Server is deployed in the internal network, so it has access to connect directly to discoverable devices (red
lines). Typical protocols the MID Server uses to communicate with devices are:
UDP
SNMP (Routers / Switches / Printers)
TCP
SSH (Secure Shell, UNIX)
WMI (Windows Management Instrumentation)
Windows PowerShell
8
Note: Proper login credentials are required for accessing devices.
At ServiceNow, we refer to "Data Collection" as a Probe and "Data Processing" as a Sensor. Hence when you hear
the term "Probes and Sensors" you can think of "Data Collection and Processing". The purple lines represent the
MID Server probing for information. The MID Server then passes the results of each probe to the ServiceNow
instance via SOAP/HTTPS (grey lines). Sensors (red box) within the ServiceNow instance process the information
gathered and update the CMDB.
If a CI that Discovery found in a previous run does not respond, the CMDB data remains the same as the previously
run Discovery. For example, if a server or database is down, and there is no response to the probe on that port, the
port is ignored for that Discovery run.
Discovery Tasks
Setting up Discovery
Overview
Discovery can run on a regular, configurable schedule or can be launched manually. Whenever a Discovery runs, it
runs over a specified IP address range which tells the Discovery process which specific devices to investigate. To
retrieve useful information, Discovery needs credentials (usually a user name and password pair) for devices within
a particular range so that Discovery can connect to and run various probes on the devices it finds. Discovery
compares the devices it finds with configuration items (CI) in the CMDB and updates any matching devices. If
Discovery does not find a matching CI in the CMDB, it creates a new CI.
For details on how Discovery works, see Getting Started with Agentless Discovery.
To set up Discovery and configure it to update the CMDB accurately, perform the following tasks in the order in
which they appear.
1.
2.
3.
4.
5.
6.
7.
Meet Prerequisites
Grant Discovery role: Verify that users who are expected to configure and execute Discovery in your network
have the discovery_admin role. This role grants access to the tables in the Discovery application.
Select a MID Server host: Designate a computer to host the MID Server. See MID Server Requirements for
Discovery for a complete list of MID Server requirements.
Gather credentials: Gather the login credentials that the MID server must use to access the devices it is expected
to discover. See Discovery Credentials for instructions on providing Discovery with the proper credentials.
Select IP Address Ranges: Determine the IP addresses that Discovery must scan. In a very complex network, it
is good practice to group IP ranges into a Range Set, which is reusable for different schedules. Discovery will not
scan anything outside of these ranges.
Setting up Discovery
Add Credentials
Set the Discovery Credentials on the instance for all the devices in the network - Windows and UNIX computers,
printers, and network gear. Credentials for Windows devices (using the WMI protocol) are provided by the logon
configured for the MID Server service on the Windows server host. Credentials for UNIX, vCenter, and SNMP must
be configured on the instance. Discovery will automatically figure out which credentials work for a particular
computer or device.
10
Setting up Discovery
11
Note: For advanced discoveries, such as those requiring load balancing or scanning across multiple domains, use Discovery
Behaviors.
Validate Results
Initial Discoveries often reveal unexpected results, such as previously unknown devices and processes or failed
authentication. Results should also accurately identify known devices and update the CMDB appropriately. Become
familiar with the network that is being Discovered and the types of data returned for the different types of
discoveries. Use the Discovery Log and the ECC Queue to monitor the Discovery process as data is returned from
the probes. To view the actual payload of a probe, click the XML icon in a record in the ECC Queue.
Discovery Log
Use the Discovery Log form for a quick look at how the probes are
doing. To display the Discovery Log, navigate to Discovery >
Discovery Log.
Column
Information
Created
Displays the timestamp for the probe launched. Click this link to view the record for the probe launched in this list.
Level
Displays the type of data returned by this probe. The possible levels are:
Debug
Error
Information
Warning
ECC queue
input
Displays the ECC queue name associated with the log message.
Message
Message describing the action taken on the information returned by the probe.
CI
The CI discovered. Click this link to display the record from the CMDB for this CI.
Source
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.
Setting up Discovery
Discovery Source
The Source [sys_object_source] table stores information identifying the source of a Discovery (ServiceNow or
another product), the ID of that source, and the date/time of the last scan. To view this information, personalize a CI
form and add the Sources list. This table is populated automatically when the Discovery plugin is enabled.
Troubleshooting
Navigate to Discovery > Status and examine the status record for the current Discovery. From this record, use the
links to examine the following:
Discovery Log: this log shows Discovery issues such as:
Failed credentials
Inaccessible ports
Problems with Windows Firewall
Viruses or intrusion products running in the network
WMI Services not running
WMI drivers not installed
UNIX devices with ACLs running to restrict access
ECC Queue: examine the payloads of the individual probes and sensors to validate information returned against
what was expected. These results can help explain suspicious errors, such as why no software was detected
running on a network server.
To check returned data, run queries on the MID Server machine from products such as:
Scriptomatic (WMI)
PuTTY (SSH)
iReasoning (SNMP)
12
Setting up Discovery
Common Procedures
Troubleshoot a Discovery using the procedures outlined in the following stages:
1.
2.
3.
4.
Port Scanning
Classification
Identification
Exploration
Enhancements
Eureka
Changes the Discovery source name to ServiceNow.
Calgary
Obsolete configuration parameter: The MID Server configuration parameter
mid.powershell.use_mssqlauth is obsolete and was removed from the platform. Microsoft SQL Server
discoveries use the PowerShell probe, which uses the MID Server's credentials. The PowerShell MSSQL probe
was also removed.
Schedule field visible: A previously hidden field called Starting is now available on the default Discovery
Schedule form. The run_start field enables an administrator to select the date and time that a one-time or
periodic discovery runs. This field appears when a user selects the Once or Periodic option in the Run field.
SNMP object identifier (OID): ServiceNow first attempts to classify an SNMP device using system OIDs. If
that fails, the platform tries to classify the device using the regular OIDs. In previous versions, SNMP
classification with system OIDs could cause an issue if a device was also matched through regular OIDs.
Process handlers: Process handlers prevent the creation of duplicate CIs by filtering out parameters known to
have inconsistent values before process classification occurs.
Gathering vCenter data without Discovery: A new workflow populates the CMDB with vCenter data without
having to install the Discovery plugin. This workflow requires a MID Server and runs the standard VMware
vCenter probe from a Related Link on the VMware vCenter Instance form. See Gathering vCenter Data without
Discovery for details.
New value for wmi_timeout probe parameter: All Windows probes now have a default timeout value of 5
minutes (configured with the wmi_timeout probe parameter), except for the Windows - Installed Software
probe, which is configured with a timeout value of 15 minutes.
Obsolete credential type: The MSSQL credential type was removed from the Credentials
[discovery_credentials] table.
User Name validation: A warning appears if the platform detects leading or trailing spaces in the User Name
field. These spaces prevent the VMware - vCenter probe from connecting to vCenter.
Configuration storage menu: The Configuration menu now contains a Storage section with direct access to
CIM storage tables. Previous access to these tables was through the CI record from a device link in a Discovery
Status record.
Access privileges for discovery_admin: The discovery_admin role was updated to grant access to all the tables
that a user needs to configure and run Discovery.
Storage forms: The HBA and Port related lists were removed from the Storage Pools, Storage Disks, and
Storage Volumes forms to eliminate confusion. These related lists did not have a direct relationship to the forms.
Hyper-V table structure: When you upgrade an instance, ServiceNow migrates virtualization data to a new table
schema and creates a backup table structure to protect existing data.
13
Setting up Discovery
Aspen Patch 3
The localhost MID Server, which was used as the default MID Server in Discovery Schedules, was removed from the platform. The localhost MID
Server originally was intended for demonstration purposes and was not intended to be a supported feature.
Aspen
Support for clustered process Discovery has been generalized to extend beyond Microsoft SQL Server.
14
15
MID Server
MID Server Plugin
Overview
The Management, Instrumentation, and Discovery (MID) Server is a Java application that runs as a Windows service
or UNIX daemon. The MID Server facilitates communication and movement of data between the ServiceNow
platform and external applications, data sources, and services.
For specific requirements for using the MID Server with Discovery, see MID Server Requirements for Discovery.
See the following pages for installation and configuration information:
MID Server Installation
MID Server Configuration
Functional Architecture
The MID Server is a Java process that oversees 2 main functional groups of sub-processes, namely Monitors and
Workers. A Monitor runs in a separate thread as a timer object and is configured to execute a task periodically,
returning its result to ServiceNow's ECC Queue (External Communication Channel Queue). A Worker is an
on-demand thread that executes a task when a corresponding ECC output queue record is read from ServiceNow
(The Queue Monitor reads the ECC output queue and triggers a Worker). For example, a Discovery probe is a
Worker.
Monitors
1.
2.
3.
4.
5.
Auto Upgrade
Heartbeat
Queue Monitor
Queue Sender
Synchronizers
Altiris
LanDesk
Microsoft SMS
JDBC
Workers
1.
2.
3.
4.
Command Line
JDBC
File
Probes
HTTP
WMI
SNMP
SSH
5. Click Submit.
6. Restart the MID Server service.
The platform makes the JAR file available to any MID Server configured to communicate with the instance.
System Requirements
ServiceNow has tested the MID Server in the following environments:
Windows Server 2003, 2008, and 2012. All Windows Server 2008 and 2012 editions are supported. Virtual
machines and 64-bit systems are supported.
Linux: Virtual machines and 64-bit systems are supported. On 64-bit Linux systems, you must install the 32-bit
GNU C library [1] (glibc). The installation command for CentOS is: yum install glibc.i686
The minimum suggested configuration is:
16
17
Applications
The MID Server is used by the following applications:
Discovery
Orchestration
Import Sets
Altiris
Microsoft SMS / SCCM
Avocent LANDesk
HP OpenView Operations
Microsoft System Center Operations Manager (SCOM)
Borland Starteam Integration
Microsoft MIIS
Reports
The following global reports are available for MID Server analytics (starting with the Eureka release).
MID: Avg Max Memory Percent Use Last 30 Days
MID Host: Avg CPU Use Percent Per Last 30 Days
Enhancements
Fuji
The following records can no longer be modified or deleted:
Table
Public Page [sys_public]
Record
InstanceInfo
InstanceInfo
GetMIDInfo
MIDAssignedPackages
MIDFieldForFileProvider
MIDFileSyncSnapshot
MIDServerCheck
MIDServerFileProvider
Eureka
MID Server upgrades support an HTTPS connection over port 443.
Provides a new SSH client with improved connectivity.
Provides new reports for MID Server analytics.
Dublin
Administrators can install a 64-bit MID Server on a 64-bit host system.
Script File synchronization stores all MID Server scripts in the ServiceNow instance to simplify distribution and
security. It is no longer necessary to manually unblock MID Server scripts on the host machine.
Several new business rules ensure that changing a MID Server's name in the configuration parameter also changes
the name in MID Server record. See Available Parameters.
Calgary
Configuration parameter for SSH command delay: The MID Server configuration parameter
mid.ssh.initial_delay_ms enables an administrator to configure the amount of time (in milliseconds)
that an SSH probe must wait to run a command after connecting to a target device.
Configuration parameter for credentials: The MID Server configuration parameter
mid.powershell.local_mid_service_credential_fallback enables the MID Server to use the
login credentials of its service to access a device if all other credentials fail. This parameter replaces the parameter
mid.powershell.use_mssqlauth. This parameter defaults to true.
Access for the discovery_admin role: Users with the discovery_admin role can now access the MID Server
application and all its modules from the application navigator. In previous versions, this role had some access to
MID Server tables, but no access through the user interface.
Configuration parameter for MSSQL credentials with PowerShell: The MID Server configuration parameter
mid.powershell.use_mssqlauth was removed from the platform. MSSQL discoveries with PowerShell
now use either the user account running the MID Server or an Active Discovery credential.
Configuration parameter for fallback credentials: The MID Server configuration parameter
mid.powershell.local_mid_service_credential_fallback was added to allow the MID Server
to use the login credentials of its service to access a device if all other credentials fail.
Configuration parameter for 64-bit Windows hosts: The parameter mid.powershell.path can only
discover 64-bit applications running on Windows hosts if the MID Server is also running on a 64-bit Windows
host.
wrapper.conf configuration file: The wrapper.conf configuration file is not available for user configuration
in Calgary and is replaced for that purpose by the wrapper-override.conf file.
Requirements: Support for certain operating systems has changed in Calgary. The installation command for Linux
CentOS is provided in the documentation.
References
[1] http:/ / www. gnu. org/ s/ libc/
18
System Requirements
ServiceNow has tested the MID Server in the following environments:
Windows Server 2003, 2008, and 2012. All Windows Server 2008 and 2012 editions are supported. Virtual
machines and 64-bit systems are supported.
Linux: Virtual machines and 64-bit systems are supported. On 64-bit Linux systems, you must install the 32-bit
GNU C library [1] (glibc). The installation command for CentOS is: yum install glibc.i686
The minimum suggested configuration is:
Internal Requirements
The three methods used for discovering various devices on a network are SSH, WMI and SNMP. SSH is used for
accessing UNIX-like machines. Discovery logs into a machine with SSH and runs commands within an encrypted
session to gather system information. Orchestration logs in to UNIX and Linux machines using SSH to perform
Workflow activities. WMI is used by Discovery for Windows based machines and is used for querying the remote
WMI protocol on targets for gathering of Windows information. Orchestration uses PowerShell to run activities on
Windows machines. And lastly, SNMP v1/v2 is used on various network devices (Routers, Switches, Printers) by
Discovery and Orchestration. Detailed information is listed below about these methods.
19
SSH - UNIX
For UNIX-like machines, Discovery and Orchestration use SSH protocol, version 2 [1] to access target machines.
SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices.
SSH communicates on port 22 within an encrypted datastream and requires a login to access the targets using two
available methods of authentication: a user name and password combination and a user name and shared private key.
Specify SSH authentication information and type in the Credentials module. If multiple credentials are entered, the
platform tries one after the other until a successful connection is established or all are ultimately denied. To provide
for application relationships a limited number of SUDO commands must be available to be run. Additional details to
these requirements can be found in UNIX/Linux commands requiring root privileges for Discovery and
Orchestration.
WMI - Windows
For Windows machines, Discovery uses the Windows Management Instrumentation (WMI) [2] interface to query
devices. Due to Microsoft security restrictions for WMI, the MID Server application executing the WMI queries
must run as a domain user with local (target) administrator privileges. When Discovery detects activity on port 135,
it launches a WMI query. The response from the Windows device is sent over a Distributed Component Object
Model (DCOM) port configured for WMI on Windows machines. This can be any port [3]. Ensure that the MID
Server application host machine has access to the targets on all ports due to the unique nature of the WMI
requirements.
Windows PowerShell
PowerShell [4] is built on the Windows .NET Framework and is designed to control and automate the administration
of Windows machines and applications. Orchestration uses PowerShell to run Workflow activities on Windows
machines. PowerShell must be installed on any MID Server that executes these activities. MID Servers using
PowerShell must be installed on a supported Windows operating system. ServiceNow supports PowerShell 2.0.
Orchestration activities for PowerShell require a credentials Type of Windows.
SNMP - Network
For network devices, Discovery uses a SNMP scan [5] to get device specific MIBs and OIDs. SNMP is a common
protocol used on most routers, switches, printers, load balancers and various other network enabled devices. Use a
"community string" (password) for authentication when scanning a device via SNMP. Many devices have an
out-of-box community string of public which Discovery (by default) uses when querying a target. Define additional
community strings in the Credentials module which are tried in succession, along with public, until a successful
query returns. In addition to the credentials, the platform also requires the ability to make port 161 SNMP requests
from the MID Server to the target. If Access Control Lists (ACLs) are in place to control the IP addresses that can
make these queries, ensure that the IP address of the MID Server is in the ACL. ServiceNow Discovery supports
SNMP versions 1 and 2c [6].
The out-of-box Orchestration activity SNMP Query returns the OID of a device and requires SNMP credentials.
20
21
WBEM
Web-Based Enterprise Management (WBEM [7]) defines a particular implementation of the Common
Information Model (CIM [8]): , including protocols for discovering and accessing each CIM implementation.
WBEM requires either of two ports, 5989 or 5988 and uses the HTTP transport protocol. WBEM supports SSL
encryption and uses CIM user name/password credentials. ServiceNow Discovery launches a WBEM port probe to
detect activity on the target ports and to append gathered data to a classification probe that explores CIM Servers.
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
Video Tutorials
How to Set Up a MID Server
22
Uninstalling
A MID Server running on Linux operates as a single process. You can end this process to accommodate such tasks
as redeploying the MID Server to another host machine or changing the unique name of a MID Server when
deploying multiple MID Servers.
1. Stop the MID Server process by executing the shell script stop.sh.
2. Verify that the MID Server is running by executing the shell script bin/mid.sh status.
3. After the MID Server stops, delete the files in the agent directory.
23
Uninstalling
The MID Server runs as a stand-alone service. It can be removed easily to accommodate such tasks as redeploying
the MID Server to another host machine or changing the unique name of a MID Server when deploying multiple
MID Servers.
1.
2.
3.
4.
24
25
Confirming Connectivity
1. Restart each ServiceNow MID Server or MID Server service and make sure that \ServiceNow\<MID Server
name>\agent\logs\agent0.log does not have error messages.
2. In each instance these MID Servers are connected to, navigate to MID Server > Servers. If Discovery is
installed, navigate to Discovery > MID Servers.
All MID Servers connected to this instance are listed.
3. Make sure that the Status is Up for the MID Servers you just installed.
26
27
28
Description
The MID Server displays this as a generic error when the error is not handled by a defined error
message.
Instance is offline or there is a major version mismatch between the MID Server and the instance.
InstanceInfo returned an assigned buildstamp that was not in the correct format, such as a version
mismatch.
References
[1]
[2]
[3]
[4]
[5]
[6]
29
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
30
Discovery
When determining if you need multiple MID Servers to discover the configuration items in your network efficiently,
the following factors must be considered:
WAN deployment: When determining where to deploy MID Servers in a WAN, consider the bandwidth
available between your local area networks. In most cases, the best practice is to install a MID Server on each
LAN to probe devices locally, rather than deploying MID Servers that must probe devices across slow WAN
connections. An alternative to this type of deployment is to install MID Servers that probe other LANs via VPN
connections that take advantage of fast Internet connections. If the bandwidth of your WAN connections is
comparable to that of your Internet connection, then there is no performance impact in running MID Server
probes across WAN connections.
DMZ: Your network policy might require you to install one or more MID Servers in your DMZ to probe the
devices there. This is common in networks that tightly regulate the ports that are opened on the inside firewall.
High capacity: Deploy multiple MID Servers where capacity is an issue, as when Discovery has to gather
information about thousands of configuration items quickly.
Security: If your security policy controls access to network devices (e.g. switches and routers) with an access
control lists (ACL), it might be necessary to install one or more MID Servers on a machine in the network that is
already on the ACL.
Probe types: If you are conducting probes of different operating systems, your network policy might require a
separate MID Server for each type of probe (e.g., one MID server for Windows WMI probes and another for SSH
probes on UNIX)
Orchestration
When determining if multiple MID Servers are necessary to execute Orchestration activities, consider the following
factors:
WAN deployment: When determining where to deploy MID Servers in a WAN, consider the bandwidth
available between your local area networks. In most cases, the best practice is to install a MID Server on each
LAN to probe devices locally, rather than deploying MID Servers that must probe devices across slow WAN
connections. An alternative to this type of deployment is to install MID Servers that probe other LANs via VPN
connections that take advantage of fast Internet connections. If the bandwidth of the WAN connections is
comparable to that of the Internet connection, then there is no performance impact in running MID Server probes
across WAN connections.
DMZ: Network policy might require the installation of one or more MID Servers in the DMZ to probe the
devices there. This is common in networks that tightly regulate the ports that are opened on the inside firewall.
Security: If a security policy controls access to computers with an access control list (ACL), it might be necessary
to install one or more MID Servers on a machine in the network that is already on the ACL.
Probe types: If Orchestration launches probes for different operating systems, network policy might require a
separate MID Server for each type of probe (e.g., one MID server for Windows PowerShell and another for SSH
probes on UNIX).
31
32
Components affected
Overrides
Either:
None
Description
Name
Enter the property name. See the Name(s) column in Required Parameters or Optional Configuration parameters for a list of parameter
and property names.
Value
MID
Server
Leave this field blank to set a MID Server property that affects all MID Servers. To set a MID Server property for a particular MID
Server, select the MID Server.
33
Note: The sample file here is from FireFox. Conventional text editors, such as Notepad, Wordpad, or TextEdit, do not display colors
and variable fonts.
34
35
Required Configuration
All MID Servers require the following configuration settings.
Required Parameters
The following parameters are required for all MID Servers.
Note: Using special characters in an XML configuration file requires you to encode them.
Label
Instance
URL
Names
url
Description
Specifies the URL to the associated ServiceNow instance. Normally the URL is similar to
https://instance.service-now.com, where you replace instance with the instance name. If you host your
own ServiceNow instance, use the URL set by your organization.
MID
Server ID
mid_sys_id
Records the MID Server record's unique identifier. This parameter should be empty when you initially
configure a MID Server. Do not change the value.
MID
Server
name
name
mid.instance.username or
glide.glidesoap.username
mid.instance.password or
glide.glidesoap.password
Type: string
Default value: YOUR_MIDSERVER_NAME_GOES_HERE
If the ServiceNow instance has authentication enabled, as it is by default, set this parameter to define
the user name the MID Server should use to log in to the instance. This user should have the mid_server
role on the ServiceNow instance in order to access necessary tables and fields.
Instance
password
Type: string
Default value: automatically set (GUID)
Use this parameter to supply a name that is meaningful for you. If you do not supply this parameter, the
MID Server uses the default value. A set of business rules synchronizes the name in the configuration
file with the name in the MID Server record (starting with the Dublin release). The business rules
ensure that changing the name in one location also changes the name in the other location.
Instance
user name
Type: string
Default value: none
Type: string
Default value: none
If your ServiceNow instance has authentication enabled, as it is by default, set this parameter to define
the password the MID Server should use to log in to the instance.
Type: string
Default value: none
Optional Configuration
The following configuration settings are optional. While a MID Server should start with the default settings, you
may want to change the default values to improve performance or follow your organization's business practices.
36
The instance creates each script file in the parent directory on the MID Server using the record Name from the
ecc_agent_script_file table as the file name and the Script field payload as the file contents. A script file record
looks like this:
37
38
Credentials.psm1
LaunchProc.psm1
MSSqlAuth.ps1 (Removed in the Calgary release)
MSSqlWinAuth.ps1 (Removed in the Calgary release)
PSScript.ps1
WMIFetch.psm1
XmlUtil.psm1
39
Names
Max length of a
payload that a
MID Server will
return
Description
mid.discovery.max_payload_size Specifies the maximum string length of Discovery probe results that the MID Server will
send to the instance. The MID Server verifies the size of the Discovery probe results before
sending them to the instance. If the Discovery probe results exceed the limit, the MID Server
discards them and returns a warning message. This applies only to probes where the Used by
Discovery field is true. Set the value to any negative number to disable the payload limit
and allow Discovery payloads of any size to be sent to the instance. For example, -1. This
parameter is available starting with the Eureka release.
Max length of an
ECCQ payload
XML that a MID
Server will send
to the instance
mid.eccq.max_payload_size
Specifies the maximum string length of a payload that the MID Server will send to the
instance. The MID Server verifies the size of the payload before sending it to the instance. If
the payload size exceeds the limit, the MID Server saves a copy of the payload to the
filesystem on the MID Server host, and returns an error message that contains the location of
the file.
CIM Parameters
This parameters determine how a MID Server conducts CIM Discovery.
Label
Interval to wait between
requests to the same CIMOM
(ms)
Names
mid.cim.request.interval
Description
Specifies the number of milliseconds to wait between requests to the same
Common Information Model Object Manager (CIMOM). This parameter is
available starting with the Eureka release.
Connection Parameters
Label
40
Names
The maximum
amount of
standard
messages to
queue in memory
for processing
mid.max.messages
Instance date
format
instance.date.format
Description
Specifies the maximum number of messages to hold in memory for processing. The default
value is computed from the threads.max parameter.
Specifies the format the instance uses for dates and times. The primary impact of setting this
parameter is to allow the MID Server to correctly refresh its start and stop times on the MID
Server record in ServiceNow. The format of this date/time string is identical to that used by
[1]
the Java SimpleDateFormat class, documented here
in the section titled Date and Time
Patterns.
MID Server
immediate
response enable
glide.mid.fast.responses
Enables a JMX server on the MID Server, which exposes some management information to
JMX consoles. Implementing JMX requires additional configuration of the Java runtime
environment. Setting this parameter to true is only recommended for those with detailed
knowledge of the Java security architecture and a specific need for JMX.
Instructs the MID Server to try sending messages to the instance as soon as they are ready.
Normally the MID Server sends message to the ServiceNow instance serially (that is, one
message at a time). Since many probes can be run in parallel, there can be multiple messages
simultaneously transmitted to the instance. Setting this parameter to true may decrease the
time between a probe's completion and its response arriving at the instance. However, the
multiple simultaneous messages consume resources, decreasing the overall instance
responsiveness. If there are communications problems, this parameter's value can also cause a
logjam on the MID Server, as threads normally used for running probes may become
consumed for sending messages. Generally, leave this parameter out of your configuration.
Setting it to true is meaningful only under very special circumstances.
Type: integer
Default value: [10 * threads.max]
glide.mid.max.sender.queue.size Places an upper limit on how large the queue is allowed to get. The MID Server starts
deleting queued messages if this limit is exceeded. When the MID Server generates messages
to the ServiceNow instance faster than it can send them, it queues them temporarily on the
file system of the MID Server's host. This queue is normally quite small, and is completely
emptied as soon as the MID Server processing slows for a short period. However, this queue
can grow in size when there are communication problems between the MID Server and the
instance, and especially if there is an integration running on the MID Server, .
The parameter is of the form {number}{multiplier}, where {number} is any positive decimal
number including non-integers, and the optional multiplier is any spelling of bytes, kilobytes,
megabytes, gigabytes, or terabytes (only the first character is tested, and the test is
case-insensitive). The default multiplier is bytes. White space is liberally tolerated. The
following strings all represent valid parameters: "1000000000", "0.5m", "5 GB", "7.67gigas",
"145.69392 meg", and "1.1 terra".
Type: string
Default value: 0.5g
MID Server
maximum
number of probe
threads
41
threads.max
Controls the number of execution threads (simultaneous work) that probes may use. This
parameter provides direct control over what CPU resources the MID Server consumes on the
computer that hosts it. To decrease the MID Server's CPU consumption, lower the number of
threads. To make the MID Server work faster, increase the number of threads. See Setting
MID Server Thread Use.
mid.poll.time
Credentials Parameters
Label
Names
Description
Credentials provider mid.credentials.provider Specifies the Java class name of the credentials provider.
Type: string
Default value: com.service_now.mid.creds.standard.StandardCredentialsProvider
Debug Parameters
Label
Debug logging
enable
Names
Description
debug.logging
Specifies whether to enable logging of MID Server events and messages (both sent and received). Normally this
parameter is only used by developers, but it is occasionally useful when troubleshooting a problem. Be aware
that setting this parameter to true causes intensive logging on the MID Server, potentially using considerable
disk space.
Debug mode
enable
debug
Specifies whether to enable debug logging on the MID Server. Normally this parameter is only used by
developers, but it is occasionally useful when troubleshooting a problem. Be aware that setting this parameter to
true causes intensive logging on the MID Server, potentially using considerable disk space.
Enables debug
logging for CIM
/ WBEM / SLP /
SMI-S
mid.cim.debug Specifies whether to enable debug logging for CIM, WBEM, SLP, or SMI-S.
Enable debug
logging for
ServiceNow
SSH Client
mid.ssh.debug Enables SSH debug information in the log file. The parameter usage depends on whether the ServiceNow SSH
client is enabled (starting with the Eureka release).
When the ServiceNow SSH client is enabled, the parameter functions as follows:
Type: string
Default value: false
42
The following string values are valid for the ServiceNow SSH client:
When the ServiceNow SSH client is disabled, the parameter enables or disables SSH debug information in the
log file:
DNS Parameters
Label
Names
Description
Specifies the interval between DNS scans in milliseconds.
Type: integer
Default value: 10
mid.dns_scan.default_name_servers
mid.dns_scan.additional_name_servers
mid.dns_scan.load_balancing_enable
Type: string
Default value: none
Type: integer
Default value: 1
Type: string
Default value: none
43
Names
Description
The amount of
mid.eccq.monitor.window Specifies the time period to look behind on the ECC Queue in seconds. The default value is 30
time to
minutes.
look-behind on the
Type: integer
ECCQ when
Default value: 1800 seconds
querying for more
work (s)
MID Server ECC
query interval
query_backoff
Allows the interval at which the MID Server queries the ECC Queue to lengthen if the MID Server
is idle. By default, the MID Server queries the ECC Queue for work every 15 seconds. In a system
that employs a large number of MID Servers, these queries can produce unnecessary traffic during
periods of light MID Server activity. When the query_backoff parameter is set to true, the
query interval slowly lengthens for an idle MID Server. Eventually, the interval slows to one query
every four minutes and holds at that rate until the MID Server has a job to do. When the MID
Server starts work again, the query interval for that MID Server immediately increases to once
every 15 seconds and continues at that rate until the demand on the MID Server backs off again.
Logging Parameters
Label
Names
Disable
monitor
checking
disable_monitors
Query
logging
enable
mid.show.queries
Description
Specifies whether to disable the MID Server from actively checking for monitors on the instance.
Instructs the MID Server whether to log details about every query it makes to the ServiceNow instance.
Typically this parameter is only used by developers, but it is occasionally useful when troubleshooting a
problem. Be aware that setting this parameter to true causes intensive logging on the MID Server,
potentially using considerable disk space.
Remote
logging
disable
disable.remote.logging Prevents the MID Server from logging any information to the MID Server log on the ServiceNow instance.
Relatively little information is logged on the instance in any case, but setting this parameter to true
eliminates all logging to the instance.
Status
sending
disable
disable.status
Prevents the MID Server from sending a status report to the ServiceNow instance every 10 minutes.
44
Names
Description
If your MID Server must go through a web proxy to access the ServiceNow instance, set this
parameter to true to instruct the MID Server to use the proxy. You must also set the proxy
server's host and port, and perhaps the user name and password as well.
If your MID Server must go through a web proxy to access the ServiceNow instance, set this
parameter to define the proxy's host.
If your MID Server must go through a web proxy to access the ServiceNow instance, and your
proxy requires a password, set this parameter to define that password.
Type: string
Default value: none
Type: string
Default value: none
If your MID Server must go through a web proxy to access the ServiceNow instance, set this
parameter to define the proxy's port.
If the MID Server must go through a web proxy to access the ServiceNow instance, and the
proxy requires a user name, set this parameter to define that user name.
Type: string
Default value: none
Shazzam Parameters
Label
Port probe
packet
interval
Names
mid.shazzam.regulator.interval_ms
Description
Sets the interval, in milliseconds, in which Shazzam can launch packets. This
parameter works with the
mid.shazzam.regulator.packets_per_interval parameter to set the
number of packets allowed in this interval. By default, Shazzam launches one packet
each millisecond.
Type: integer
Default value: 1
Port probe
mid.shazzam.regulator.packets_per_interval Sets the number of packets that Shazzam can launch in the configured time interval.
packets
This parameter works with the mid.shazzam.regulator.interval_ms
launched per
parameter, which sets that interval. By default, Shazzam launches one packet each
regulator
millisecond.
interval
Type: integer
Default value: 1
Shazzam
chunk size
mid.shazzam.chunk_size
Specifies the maximum number of IP addresses that Shazzam scans in parallel. This
parameter primarily controls outbound port consumption.
Type: integer
Default value: 100
45
Names
Description
mid.snmp.request.timeout
mid.snmp.session.timeout
Type: integer
Default value: 1500 milliseconds
Type: integer
Default value: 500 milliseconds
Names
mid.connection_cache
Description
Specifies whether to cache connections. Set to false' to disable connection caching.
This parameter applies to SSH connections only.
mid.ssh.set_path
Process commands
against localhost via
SSH rather than
console
mid.ssh.local
mid.ssh_connections_per_host
Specifies whether to set the PATH environment variable for SSH commands.
Specifies whether to execute commands for the MID Server host machine
(localhost) via SSH rather than from a console. This allows long-running commands
to execute properly. This parameter applies to the legacy SSH client only.
Controls the number of concurrent probes the MID Server can run against a given
host. Lowering the number of concurrent connections can slow Discovery.
Type: integer
Default value:
mid.ssh.sudo_preserve_environment Specifies whether to use sudo [5] to preserve the environment for SSH.
mid.ssh.path_override
46
Overrides the default paths set before executing a command. Enter one or more
override paths delimited by a colon (:). The default path is /usr/sbin: /usr/bin: /bin:
/sbin.
The ServiceNow SSH client accepts the following prefixes in front of the
path_overide value.
Enable ServiceNow
SSH Client
mid.ssh.use_snc
append: Appends the override path to the end of the hosts path. This is the
default behavior.
replace: Replaces the host path with the path_overide value.
prepend: Appends the override path to the front of the host path.
Enables the ServiceNow SSH client. The ServiceNow SSH client is active by default
on new instances starting with the Eureka release. Customers upgrading to Eureka or
a later release can manually switch to the ServiceNow SSH client with this
parameter. Enabling the ServiceNow SSH client disables the legacy SSH client. This
parameter is available starting with the Eureka release.
Specifies the maximum amount of times to retry an SSH operation after a time-out.
The system sleeps two seconds between each connection attempt. By default, the
MID Server retries once only. Set the parameter to 0 to disable retries.
Sets a different
remove file command
to replace the default
'/bin/rm -f'
mid.ssh.alt_rm
mid.ssh.suppress_history
mid.ssh.socket_timeout
mid.ssh.channel_timeout
Specifies the timeout value for the SSH socket to prevent issues created by a socket
timeout. Some devices, such as systems with embedded controllers like UPSs and
PDUs, that have SSH enabled require more time to respond to an authentication
request. The default value of 1 minute ensures such requests do not timeout
prematurely.
Timeout in ms for
SSH channel activity
Suppresses the generation of the SSH history file. This parameter applies to the
legacy SSH client only.
Timeout in ms for
SSH socket read
Type: string
Default value: none
Delays sending any SSH probe commands to a server after connecting to the target
for the time specified, in milliseconds. This parameter is available starting with the
Calgary release. This parameter applies to the legacy SSH client only.
Type: integer
Default value: 1
Specifies the amount of time that the MID Server waits for activity on the SSH
socket before closing the connection. If there has been no activity on the SSH socket
for the specified timeout value, the MID Server closes the connection. Some
devices, such as systems with embedded controllers like UPSs and PDUs, that have
SSH enabled may require more time to respond to an authentication request. This
parameter is available starting with the Eureka release.
Timeout in ms for
SSH socket read
47
mid.ssh.session_timeout
Specifies the amount of time that a cached session remains in memory after last use.
Excessively small values tend to decrease performance. This parameter applies to
the ServiceNow SSH client only.
mid.ssh.command_timeout_ms
Use keyboard
mid.ssh.use_keyboard_interactive
interactive
authentication for SSH
Specifies the minimum group length in bits used for generating a "shared secret" key
[7]
in Diffie-Hillman key exchange . The larger the key the more secure the SSH
connection is but at the cost of performance. This parameter is available starting
with the Eureka release.
mid.ssh.dh_group_length_min
mid.ssh.dh_group_length_max
Specifies the maximum group length in bits used for generating a "shared secret"
[7]
key in Diffie-Hillman key exchange . The larger the key the more secure the SSH
connection is but at the cost of performance. This parameter is available starting
with the Eureka release.
/usr/sbin
/usr/bin
/bin
/sbin
Upgrade Parameters
Label
Names
Fixed MID
Server version
mid.pinned.version
MID Server
auto-upgrade
enable
auto_upgrade
Description
Name of the version to which this MID Server is pinned.
Type: string
Default value: build timestamp
If true or absent, enables the MID Server to periodically check whether it should
upgrade. If false, the MID Server remains on the same version, which is
generally neither safe or useful.
Upgrade branch
48
glide.mid.autoupgrade.branch or
mid.upgrade.branch
Defines a branch (a directory on the distribution server) the MID Server should
download its upgrades from. This might be set if you had a special MID Server
version for some reason. Consult with ServiceNow before adding this parameter
to your configuration.
Upgrade proxy
enable
mid.upgrade.use_proxy
If your MID Server must go through a web proxy to access the upgrade URL, set
this parameter to true to instruct the MID Server to use the proxy. You must also
set the proxy server's host and port. If the instance proxy user name and
password are set, they are used for the upgrade proxy as well.
Upgrade proxy
host
glide.mid.autoupgrade.proxy_host or
glide.glidesoap.proxy_host
glide.mid.autoupgrade.proxy_port or
glide.glidesoap.proxy_port
glide.mid.autoupgrade.proxy_user
glide.mid.autoupgrade.proxy_password
glide.mid.autoupgrade.host
If your MID Server must go through a web proxy to access the upgrade URL,
define the proxy's password here.
Upgrade URL
If your MID Server must go through a web proxy to access the upgrade URL,
define the proxy's user name here.
Upgrade proxy
password
If your MID Server must go through a web proxy to access the upgrade URL,
define the proxy's port here. You must restart the instance after changing this
property to apply the change in versions prior to Calgary Patch 6.
Upgrade proxy
user
If your MID Server must go through a web proxy to access the upgrade URL,
define the proxy's host here. You must restart the instance after changing this
property to apply the change in versions prior to Calgary Patch 6.
Upgrade proxy
port
Type: string
Default value: none
Controls where the MID Server downloads its upgrades from. Normally, you
should not set this parameter.
Names
mid.powershell.enforce_utf8
Description
Enable this parameter to force commands on a target Windows system
to return UTF-8 encoded output. Disabling it allows the target system
to use its default encoding. This parameter is only valid when
PowerShell is enabled. Setting this value to false may result in
incorrect values in the CMDB when non-ASCII characters are returned
by a probe.
Enable
PowerShell for
Discovery
mid.use_powershell
49
Specifies whether to enable PowerShell for Discovery. The MID
Server requires PowerShell version 2 to operate. If the MID Server
cannot find the correct version of PowerShell, it uses WMIRunner
instead.
Enable/Disable
mid.powershell.local_mid_service_credential_fallback Specifies the login credentials the MID Server uses if all other
automatically
credentials fail. This parameter is available starting with the Calgary
falling back to the
release.
MID Server
Type: true | false
service user
Default value: true
credential if all
other credentials
fail
Timeout for
Windows probes
mid.windows.probe_timeout
Specifies the timeout value for the Windows probe, in seconds. The
default value is 5 minutes.
MSSQL
credentials for
PowerShell
mid.powershell.use_mssqlauth
Type: integer
Default value: 300 seconds
Powershell use
credentials table
mid.powershell.use_credentials
Path to
Powershell
executable
mid.powershell.path
50
windows_probe_timeout
Sets the timeout interval for all Windows probes on a specific MID
Server. This value is overridden by the values configured for
individual probes with the wmi_timeout probe parameter.
Type: integer
Default value: none
References
[1] http:/ / java. sun. com/ j2se/ 1. 4. 2/ docs/ api/ java/ text/ SimpleDateFormat. html
[2] http:/ / en. wikipedia. org/ wiki/ Subnetwork
[3] http:/ / en. wikipedia. org/ wiki/ Simple_Network_Management_Protocol#Security_implications
[4] http:/ / en. wikipedia. org/ wiki/ Object_identifier
[5] http:/ / en. wikipedia. org/ wiki/ Sudo
[6] http:/ / en. wikipedia. org/ wiki/ Secure_Shell#Architecture
[7] http:/ / en. wikipedia. org/ wiki/ Diffie%E2%80%93Hellman_key_exchange
[8] http:/ / install. service-now. com/ glide/ distribution/ builds/ mid/
[9] http:/ / msdn. microsoft. com/ en-us/ library/ aa292114(VS. 71). aspx
[10] http:/ / support. microsoft. com/ kb/ 942589
51
Table
Description
Business Rule
mid_server.cluster.down MID Server Cluster [ecc_agent_cluster] A MID server cluster has failed MID Server Cluster Management
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.
2.
3.
4.
5.
6.
52
mid_buildstamp
The mid.buildstamp property identifies the MID Server version with an identifier based on the date of the build.
This property uses a date and time format of yyyy-mm-dd-hhmm.
The MID Server checks for version information hourly. If no override version is configured, the MID Server looks at
the mid_buildstamp property for the version to use. This property resets itself to the default version (the version that
matches your instance version) when the instance is restarted or upgraded, so any user changes are lost at that time.
mid.version.override
Use this property to set an override condition for the current MID Server version. When the MID Server checks the
version each hour, it looks at the mid.version.override property first. If this property is empty, the MID Server will
get its version information from the mid_buildstamp property. If an override version is configured, the MID Server
uses this value and ignores the version information in the mid_buildstamp property. This override value remains
when the instance is restarted and is passed to the MID Server at check in. However, the version in the
mid.version.override property is deleted during an upgrade, allowing the MID Server to reset itself to the version in
the mid_buildstamp property.
Create the property and then set the value.
1. In the Navigation pane filter, type sys_properties.list.
2.
3.
4.
5.
53
System Events
When a MID Server transitions from one state to another, one of these events is triggered:
mid_server.up: The MID Server goes from a status of Down to a status of Up.
mid_server.down: The MID Server goes from a status of Up to a status of Down.
Scheduled Job
To change the trigger interval for the Heartbeat probe, navigate to System Scheduler > Scheduled Jobs > Scheduled
Jobs. Open the MID Server Monitor record and edit the interval.
54
55
56
Max range
size
Description
Default
The maximum number of IPs to scan in a single Shazzam probe. If a range has more IPs than are specified here, the probe 100000
is skipped and a warning is logged.
Parameters
You control the behavior of individual Shazzam probes using basic and advanced parameters.
1. Navigate to Discovery Definition > Probes.
2. Select Shazzam.
3. Add or edit parameters in the Probe Parameters related list.
Basic Parameters
These parameters are defined in the config.xml file on the MID Server, but you can edit the values in the Shazzam
probe record as well. Changes to specific parameters that could disconnect you from the MID Server are prohibited
in the probe record and can only be made in the configuration file.
Shazzam Probe
57
Parameter
shazzam_chunk_size
Description
The maximum number of IP addresses Shazzam will scan in parallel. This parameter primarily controls
outbound port consumption.
Default
Value
100
regulator_max_packets Sets the number of packets that Shazzam can launch in the time interval specified by the
regulator_period_ms parameter.
regulator_period_ms
Advanced Parameters
These parameters are available for fine tuning the Shazzam probe. These values are defined in the probe record only.
Parameter
Description
Default
Value
report_inactive
When true, reports device that are alive but inactive. For example, a device has no ports open but true
refuses at least one port connection request.
report_dead
When true, reports devices with dead IP addresses. For example, a device that has all ports
closed.
false
GenericTCP_waitForConnectMS Sets the number of milliseconds the GenericTCP scanner waits for a connection.
1000
BannerTCP_waitForConnectMS
Sets the number of milliseconds the BannerTCP scanner waits for a connection and banner.
1500
HTTP_waitForConnectMS
Sets the number of milliseconds the HTTP scanner waits for a connection.
500
HTTP_waitForResponseMS
Sets the number of milliseconds the HTTP scanner waits for a response.
500
NBT_waitForResponseMS
Sets the number of milliseconds the NBT scanner waits for a response.
500
NBT_alternativePort
N/A
SNMP_taps
SNMP_tapIntervalMS
Sets the number of milliseconds the SNMP scanner waits between taps.
1000
SNMP_waitForResponseMS
Sets the number of milliseconds the SNMP scanner waits for a response after the last tap.
1000
SNMP_alternativePort
N/A
DNS_waitForResponseMS
Sets the number of milliseconds the DNS scanner waits for a response.
1000
DNS_alternativePort
N/A
debug
false
scanner_log
Enables scanner logging if set to true. This logging information appears in the Shazzam probe
response.
false
Port Probes
58
Port Probes
Overview
Port probes are used in Discovery by the Shazzam probe to detect protocol activity on open ports on devices it
encounters. When a port probe encounters a protocol in use, the Shazzam sensor checks the port probe record to
determine which classification probe to launch. The common protocols SSH, WMI, and SNMP in the out-of-box
system have priority numbers that control the order in which they are launched. The WMI probe is always launched
first, and if it is successful on a device, no other port probes are launched for that device. If the WMI probe is not
successful, then the SSH probe gathers information on the device. The SNMP probe is always the last to scan, after
the other port probes have failed. This method allows Discovery to classify a device correctly if the device is running
more than one protocol (e.g. SSH and SNMP).
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
Triggered by
services
Indicates which services define the port usage. Use this setting to define non-standard port usage and pair the port number with
the protocol.
Triggers probe
Indicates which probe is triggered by the results of this port probe. This is the name of the appropriate classify probe.
Port Probes
59
Use
classification
Names the appropriate classification table, based on the protocol being explored.
Classification
priority
Establishes the priority in which this port probes must be run. If the first port probe fails, then the next probe runs on the device,
and so forth, until the correct data is returned. This allows for the proper classification of a device that has two running protocols,
such as SSH and SNMP. The default priorities for the Discovery protocols are:
1 - WMI
2 - SSH
3 - SNMP.
CIM Probe
Overview
The CIM probe uses WBEM protocols to query a particular CIM server, the CIM Object Manager, for a set of data
objects and properties.
Parameters
The following parameters may be passed to the CIM probe:
Parameter
Description
Default Value
source
None
port
The port to connect to. If empty, the value is determined by the "schema" parameter: http = 5988, https =
5989.
5988 or 5989
schema
http
namespace
None
queries
[Required] A semicolon-delimited list of CIM probe queries to process and return results for.
None
retries
The number of times to retry a query if it fails due to network connectivity issues.
5000
socket_timeout
5000
Query Language
The CIM Intermediate Query Language (CimIQL) uses keys, filters, and dot-walking to traverse the CIM schema.
Parameter Expansion
The CIM query language supports standard SNC preprocessed probe parameter expansion. Place variables in queries
by encapsulating their names like this:
${foobar}.CIM_RunningOS[0].Name
CIM_ComputerSystem.${barfoo}
The text ${foobar} is replaced with the contents of the foobar probe parameter passed to the CIM probe;
likewise for barfoo.
Database Catalogs
60
Database Catalogs
Overview
In ServiceNow, the Database Catalog lists all the catalog objects, or databases, discovered for an instance of a
database. For example, the ServiceNow catalog view of a single instance of Microsoft SQL Server might contain
several dozen catalogs, each of which contains SQL Server tables. In the base platform, ServiceNow enables
administrators to populate catalog views of common database products such as Oracle, MySQL, and SQL Server,
and provides a Discovery probe and sensor for creating Microsoft SQL Server catalog views and for updating those
catalogs in the CMDB.
Note: Different database manufacturers use the term catalog differently. For example, MySQL uses database to mean catalog.
An example of a database catalog is the Microsoft SQL Server catalog on the sandb01 server, which is populated in
the CMDB automatically by a default probe called Windows - Get SQL Information. Click the link in the
Database Instance column to view the CI for the selected SQL Server database. The list of catalogs for that
database is included in the MSFT SQL Catalogs related list.
Database Catalogs
Generating Catalogs
Database catalogs can be imported into ServiceNow from a third-party discovery tool, entered into the platform
manually, or discovered by ServiceNow Discovery. The Windows - Get SQL Information probe is configured to
populate the MSSQL Database Catalog in the CMDB. To generate catalog data for other databases with Discovery,
create probes and sensors for those databases. See Discovery Probes and Sensors for instructions. To use Discovery
to generate database catalogs, install the Discovery Plugin.
61
3.
4.
5.
6.
7. Click Submit.
The completed probe form looks like this:
62
//
// Use ServiceNow WMIAPI to gather stats
//
var CMD_RETRIES = 3;
var scanner = getScanner();
if (scanner) {
var output = "";
for(var i = 0; i < CMD_RETRIES; i++) {
output = scanner.winExec("%SystemRoot%\\system32\\cmd.exe /C type
\\\"C:\\Information Systems\\BgInfo\\*.txt\\\"");
if (output)
break;
}
scanner.appendToRoot("output", output);
}
Creating a Sensor
1. Navigate to Discovery Definition > Probes, and then click New.
2. Complete the following fields:
Name: Use the same name as the matching probe. In this example, we use Windows - Get BGInfo files.
Reacts to probe: The name of the probe created in the previous procedure: Windows - Get BGInfo files
Sensor type: Select the type of sensor to create - in this example Sensor.
Description: Describes the function of this sensor.
Script: Copy the script below into the Script field and edit as needed.
Sensor type: Determines how the answer from the probe is processed - in this example Javascript.
3. Click Submit.
//
// Sensor Script text
63
64
65
66
Device Classification
Device Classifications
Overview
After Discovery detects active devices in your network using a port scan (Shazzam probe), Discovery attempts to
classify the devices so that it can gather additional information. Discovery launches classify probes that query
devices to find out such things as operating system and version information. For information, see Data Collected by
Discovery.
The following classify probes are included with the platform:
UNIX - Classify: SSH commands for all UNIX operating systems. ServiceNow supports SSH protocol, version 2
only.
SNMP - Classify: SNMP commands for all network devices, such as printers, routers, or UPS.
Windows - Classify: WMI commands for all Windows machines
Windows NT Server
Windows 2000 Server
Windows 2003 Server
Windows 2008 Server
Windows 2012 Server (Starting with the Dublin release)
Windows Cluster VIP
The Windows classifier supports the following Windows workstation operating systems:
Windows XP
Windows Vista
Windows 7
Windows 8 (Starting with the Dublin release)
Device Classifications
Classification
Device classification occurs only when a Discovery Schedule is configured to discover Configuration items. This
scan type enables Discovery Identifiers and is the only scan that can be used to update the CMDB.
When Discovery has determined the device's class, it launches an identity probe - a multiprobe - that is configured to
run one or more commands with a single authentication. The identity probe in the out-of-box system can be
configured to ask the device for information such as its serial numbers (there can be more than one), name, and
network identification. The results of this scan are processed by an identity sensor, which then passes the results to
the Identifier. The Identifier then attempts to find a matching device in the CMDB. If the identifier finds a matching
CI, the Identifier either updates that CI or does nothing. If the identifier cannot find a matching CI, it either creates a
new CI or does nothing. If Discovery is configured to continue, the Identifier launches the exploration probes
configured in the Classification record to gather additional information about the device. Exploration probes can be
multiprobes or simple probes.
This diagram shows the processing flow for classifying and probing devices with Identifiers configured.
IP Scan Mode
The IP Scan mode enables credential-less Discovery, which attempts to identify devices and software based on just
the open ports and banners it finds. If the classification criteria are met for a device in the IP Scan mode, Discovery
automatically updates the CI in the CMDB. After a device is properly classified, Discovery launches the exploration
probes configured for that class of device and begins gathering detailed information about the CI. For example, in
the default ServiceNow system, the Linux classification triggers eleven exploration probes that return information
such as disk size, memory, and the number of current connections. The data from these probes returns at different
times and is stored in the ECC Queue until processing is complete.
This diagram shows the processing flow for classifying and probing devices with Discovery IP Scan (no Identifiers):
67
Device Classifications
Input Value
Name
Active
Order
Configure the order (sequence) in which the platform run this classifier,
Table
Select the a table for this classification. For example, if this record classifies a Windows server, select the Windows Server
[cmdb_ci_win_server] table.
Match Criteria Select which criteria must match to classify this device - Any of the parameters or All of the parameters.
On
classification
script
This script runs if classification criteria are met. Use this script to perform any special tasks after a device is classified. It is
possible to use the g_probe_parameters hashmap from within a classification script to set probe parameters for any configured,
triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all triggered probes.
These criteria are formed from specific parameters and the values that they must contain to match devices that Discovery finds in
the network with CIs in the CMDB. For a detailed discussion of these parameters, see Discovery Classification Parameters.
Triggers
probes
These are the exploration probes that Discovery launches to gather detailed information about a CI that it has classified in the
network.
A completed CI classification form with exploration probes defined is shown here. For instruction on creating
probes, see Discovery Probes and Sensors. The probes defined here are launched when the device is properly
classified, unless Discovery is configured to stop after classification.
68
Device Classifications
69
Classification Criteria
The classification criteria for a device classification includes a parameter, an operator, and a value. The available
parameters are those returned by Discovery classify probes for each class of device found. The values configured for
these parameters are the values that Discovery is looking for to establish a device's class. For available parameters
for each default classification, see Discovery Classification Parameters. In this example from the base ServiceNow
platform, the device to be classified has a name value that starts with Windows 2003.
The On classification script field can be used to further customize the application record being created. The
following objects are exposed for this purpose.
Parameter Description
isNode
type
isVIP
ip_address
name
Device Classifications
name
dsn_domain
os_domain
ip_address
serial_number
The following procedure reclassifies any Windows workstation operating system (Windows Vista, XP, or Windows
7) that is acting as a server.
1. Navigate to Discovery Definition > CI Classification > Windows.
2. Create a new classification record, such as Windows XP Server.
3. Select Windows Server [cmdb_ci_win_server] as the table.
4. Right-click in the header bar and select Save from the context menu.
The Classification Criteria and Triggers Probes Related Lists appear.
5. Configure the following Classification Criteria:
Name: Select a variable to use as the classification criteria from the list above. For example, to reclassify a
machine by name, enter cidata.name. This works for servers that have a uniform naming convention, such as
SRV001, SRV002, etc., regardless of operating system.
Operator: Select an operator for the classification condition. In networks containing servers named with a
specific convention, you might select starts with or contains.
Value: Enter the value for the condition. In our example of a network with a server naming convention, this
value would be the root of that convention, such as SRV.
This condition will classify all computers as servers if their machine name is SRVXXX.
6. Select the Triggers Probe Related List and add the appropriate probes.
a. Copy the list of probes from another Windows server classification, including the Condition scripts.
b. Ensure that the Windows - Identity probe has a phase of Identification (the default is Exploration).
The completed form looks like this:
70
Device Classifications
71
Debugging Classifications
To log debugging information about classifications, add the following system property. The resulting log entries list
the name of each classifier that runs, along with all the names and values that are available to the criteria in the
classifier.
System Property
Description
Enhancements
Dublin
Offers discovery support for new Windows Operating Systems.
Process Classifications
72
Process Classifications
Overview
Process classification in Discovery tracks services, such as database servers, running on computer CIs in your
instance. Discovery classifies processes during the exploration phase, after identifying devices in the Computer
[cmdb_ci_computer] table and its extensions. Like device classification, process classification has its own
classification criteria and also has the ability to launch probes. Unlike device classification, process classification
creates child configuration items (CI) with Runs on::Runs relationships. By default, Discovery includes
classifications for most common processes.
For information on how Discovery creates and maintains dependent relationships between CIs, including processes,
see Application Dependency Mapping.
Process Classifications
If a process does not match any existing classification criteria, Discovery checks if the process is communicating
with other processes (Dublin). If the process communicates with other processes, Discovery automatically generates
both a new process classification and application CI from the process name and the list of the other processes it
communicates with. After Discovery is complete, review these automatically generated records to determine whether
you want to define a new application class for this process.
This feature has been significantly revised for the Dublin release. If you are using an older release, see previous
version information.
73
Process Classifications
74
Field
Input Value
Table
Select the table where this classification generates CI records. This table must be an extension of the Computer
[cmdb_ci_computer] table such as Applications [cmdb_ci_appl].
Relation type
Select the CI relationship type for this classification. The relationship field is only available for Process and Scan Application
classifications. Discovery process classifications typically use one of these relationship types:
Runs on::Runs: Defines the relationship of an application to the host on which it runs. This relationship is expressed from the
perspective of the host and the application. For example: My database application runs on server001::server001 runs my
database application.
Depends on::Used by: Defines the relationship of an application that communicates with another application. This relationship
is expressed from the perspective of each application. For example: The Tomcat application depends on the MySQL database::
The MySQL database is used by Tomcat.
Virtualized by::Virtualizes: Defines the relationship of a virtual machine to its host. This relationship is expressed from the
perspective of the virtual machine and of the host. For example: server001 is virtualized by ServerESX::Server ESX virtualizes
server001.
Active
Select this option to enable the process classification record. Only active process classifications can create application CI records.
Order
Enter the order in which Discovery should run this process classification when there are multiple classifications available for a
table. Discovery runs process classifications from the lowest to highest order.
Test with
Lists the host CI where an automatically generated process classification conditions were met. Use this field to test changes to the
process classification to ensure that the updated classification behaves as expected (Dublin release).
Condition
Use the condition builder to create the match and classification criteria for the process classification. This field replaces both the
Match criteria field and Classification Criteria related list. The upgrade process converts all existing classification criteria into
conditions (Dublin release).
On
classification
script
Enter a script to run when the condition and classification criteria are met. Use this script to perform any special tasks after a device
is classified. It is possible to use the g_probe_parameters hashmap from within a classification script to set probe
parameters for any configured, triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all
triggered probes.
g_probe_parameters['node_port'] = 16001;
See Available Script Objects for additional script options.
Triggers
probes
Select the exploration probes you want Discovery to launch. These probes gather detailed information about a classified CI.
Discovery will not launch these probes if it is configured to stop after classification. See Probes for more information.
Applications
Use this related list to view the application CIs that match this process classification (Dublin release).
Test Results
Use this related list to view the how Discovery classifies processes on the Test with host and build better classification conditions
(Dublin release).
Parameters
Use this related list to view the parameters associated with this process and build better classification conditions (Dublin release).
Versions
Use this related list to view previous versions of the process classification record (Dublin release).
Process Classifications
75
Process Classifications
76
Input Value
Table
Select the table where this classification generates CI records. This table must be an extension of the Computer
[cmdb_ci_computer] table such as Applications [cmdb_ci_appl].
Relation type
Select the CI relationship type for this classification. The relationship field is only available for Process and Scan Application
classifications. Discovery process classifications typically use one of these relationship types:
Runs on::Runs: Defines the relationship of an application to the host on which it runs. This relationship is expressed from the
perspective of the host and the application. For example: My database application runs on server001::server001 runs my
database application.
Depends on::Used by: Defines the relationship of an application that communicates with another application. This
relationship is expressed from the perspective of each application. For example: The Tomcat application depends on the
MySQL database:: The MySQL database is used by Tomcat.
Virtualized by::Virtualizes: Defines the relationship of a virtual machine to its host. This relationship is expressed from the
perspective of the virtual machine and of the host. For example: server001 is virtualized by ServerESX::Server ESX virtualizes
server001.
Match criteria
Select how many criteria must match to classify this device: Any of the parameters or All of the parameters.
On
classification
script
Enter a script to run when the classification criteria are met. Use this script to perform any special tasks after a device is classified.
It is possible to use the g_probe_parameters hashmap from within a classification script to set probe parameters for any
configured, triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all triggered probes.
g_probe_parameters['node_port'] = 16001;
Triggers
probes
Select the exploration probes you want Discovery to launch. These probes gather detailed information about a classified CI.
Discovery will not launch these probes if it is configured to stop after classification. See Probes for more information.
Classification
Criteria
Select the parameters and values that cause Discovery to match devices with CIs in the CMDB. See Classification Criteria for
information on building classification criteria.
Process Classifications
77
Classification Criteria
Note: See Discovery Classification Parameters for a list of available parameters for each default classification.
whether the process was automatically discovered with the Pending: prefix.
whether the process is listening on or connecting to a TCP port.
the TCP port the process listens on or connects to.
Table: is Pending Application.
Relationship Type: is either Runs on::Runs or Depends on::Used by.
Condition: indicates the name, command, and key parameters of the process.
Test With: lists the host where the process was found.
Requirements
Discovery must have access to the following applications to
automatically generate classifications for processes.
Process Classifications
78
OS
Application Required
Windows WMI
Linux
lsof
Mac
Solaris
AIX
Process Classifications
79
2. If necessary, add additional conditions and classification criteria.
See Creating a Process Classification for additional options.
For example, we want to restrict our classification to process
where the running process is java.
Process Handlers
Discovery process handlers prevent the creation of duplicate CIs by
filtering out parameters known to have inconsistent values before
process classification occurs. For example, the Process Handler [discovery_proc_handler] table includes a
Websphere record. This record filters out a specific parameter that changes each time a WebSphere server restarts.
Process handlers are available starting with the Calgary release.
Process Handler to ignore process classification
Process Classifications
80
Field
Description
Name
Active
Classify
Select the check box to enable classification of any Running Process [cmdb_running_process] record that matches this Process
Handler's conditions. Clear the checkbox to disable classification of any Running Process [cmdb_running_process] record that matches
this Process Handler's conditions (Dublin release).
Condition Select the conditions that trigger the process handler to run the script. In most cases, this condition contains either specific executable
names or the presence of certain parameters.
Script
Enter the JavaScript you want to run on the current record in the Running Process [cmdb_running_process] table when the Condition is
met. The current variable is a reference to a Running Process GlideRecord. The script should examine current.parameters
for certain values, perform string replacement to manipulate these values, and save the result to current.key_parameters.
ServiceNow uses the key_parameters field, together with the process name, to determine whether the process is unique on a specific
machine. See Available Script Objects for additional options.
Debugging Classifications
To log debugging information about classifications, add the following system property. The resulting log entries list
the name of each classifier that runs, along with all the names and values that are available to the criteria in the
classifier.
System Property
Description
Enhancements
Dublin
Discovery automatically creates new process classifications for unclassified processes that listen on or connect to
a TCP port. Discovery admins can review these unrecognized processes to determine whether to create CIs from
them.
Process classification uses a condition builder instead of match criteria and classification criteria.
The process classification form has new related lists to view information about associated running processes and
application CIs.
Process Handlers have a new field to enable or disable classification of running processes that match the process
handler's conditions.
Calgary
Process Handlers allow Discovery to review parameter values to determine if a process represents a new or
existing application CI.
81
82
UNIX Parameters
The UNIX parameters define the characteristics of several types of computers, such as Linux, Solaris, and HP-UX,
communicating with SSH protocol, version 2.
Parameter Description
output
type
IP address
name
Name of the operating system for this UNIX CI. For example, Linux or HP-UX.
Windows Parameters
Windows parameters identify Windows computers communicating with the WMI protocol.
83
Parameter Description
isNode
type
isVIP
ip_address
name
SNMP Parameters
The SNMP parameters can define the characteristics of several types of devices, such as routers, switches, and
printers.
Parameter
Description
powering
A value of true indicates that this device is an uninterruptible power supply (UPS).
hosting
A value of true indicates that this device can host programs. Hosts are general purpose computers such as servers.
netware
A value of true indicates that this device is running the Netware operating system.
routing
A value of true indicates that this device has network routing capabilities.
ip_address
Returns the IP address through which the device is being discovered. A device can have multiple IP addresses.
sysdescr
Required descriptive field on any SNMP device that can contain useful classification data, such as the operating system
and its version.
vlans
A value of true indicates that this device can host a virtual local area network.
hint_router
A value of true indicates that Discovery has determined that this device is a router. This field only applies to devices
that can be used as both a router and a switch.
block_router_exploration If this parameter is true, Discovery will not launch exploration probes for routers it detects. This parameter is used for
network Discovery only.
switching
A value of true indicates that this device has network switching capabilities.
mfr_apc
A value of true indicates that this device is an uninterruptible power supply (UPS) manufactured by American Power
Conversion (APC).
printing
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 Description
parameter
command
output
type
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.
84
c. To use Basic Discovery, navigate to Discovery Definition > Functionality Definition and select the record
for All.
d. Add the new port probes to the list. This tells Discovery which port probes to run for IP address scans.
85
e. Save the record and navigate to Discovery Definition > Port Probes and click New.
f. Create a port probe using the new IP Service you just defined.
3. Create a new classification and add the parameter for IP address scanning.
In this example, we have created an application classifier that will discover Apache Tomcat, based on the port
information we received from the Nmap scan. See the following section for details about forming parameters
for IP address scans.
name
port
portprobe
protocol
result
service
86
Note: Optional fields that can be used to form parameters appear as child tags beneath the default fields. Example of these are the
sysDescr and banner_text fields.
Parameters are expressed in the form of <portprobe.service.field>. The value for field can come from any of the
fields or child tags in the XML file. For example, the following parameters classify a device as a UNIX server and
detect an installation of MySQL:
ssh.ssh.result
mysql.mysql.result
These parameters were derived from the values in the following XML file generated by a Shazzam probe conducting
an IP Scan. The result field returned a value of open for ports 22 and 3306 on the target device. The service field
indicates the services that normally communicate over those ports.
The sysDescr field can provide additional information about devices, depending upon the manufacturer. This XML
file from the Shazzam probe reveals the following about port 161 on the device at IP 10.10.11.149:
In the classification criteria, we can construct the following parameter with sysDescr that returns an Apple AirPort
wireless router.
snmp.snmp.sysDescr > contains > Apple AirPort
87
References
[1] http:/ / www. zytrax. com/ tech/ web/ regex. htm
88
89
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.
Discovery Identifiers
90
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).
Discovery Identifiers
91
Discovery Identifiers
92
Multiprobe
AIX - Identify
CIM - SMI-S - Identity CIM - SMI-S - Computer System: Retrieves a CIM Computer System using SMI-S.
HP-UX - Identify
Linux - Identify
Mac OS X - Identify
SNMP - Identify
Solaris - Identify
Windows - Identify
Discovery Identifiers
Device Classification
When a classification probe runs, it returns the device class and operating system (if the device is a computer).
Computer
Printer
Netgear
UPS
When you enable Identifiers, Discovery Classification determines what identity probe to launch. For example, if the
device class returned is Computer, and the operating system is Linux, then the classification record launches the
pre-configured Linux - Identity multiprobe. The out-of-box ServiceNow system has identity probes configured for
each classification, in addition to exploration probes, that can be launched after the results are evaluated.
To view all probes triggered by a classification, navigate to Discovery Definition > Classification. Computers are
listed by operating system. Non-computer classes use SNMP probes. The identity probe is listed in the Triggers
Probes Related List and is launched only when Identifiers are enabled. You can use the probes provided or click
Edit to select different probes. Click New to create a custom probe.
93
Discovery Identifiers
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.
94
Discovery Identifiers
Identifier Form
To create an Identifier record, navigate to Discovery Definition > CI Identification > Identifiers and click New. The
Identifier form provides the following unique fields:
Field
Input Value
Applies
to
Select the ServiceNow table of the device class for this Identifier. For example, if the class is Printer, then the table is cmdb_ci_printer.
Order
Configure the order in which the identification criteria are evaluated. An example might be serial number - 910, network name - 920, and
computer name - 930.
Script
Create the conditions that determine what Discovery should do when the results are returned from a search of the CMDB for this
Identifier. For example, you might want to stop Discovery if two or more CIs in the CMDB match this Identifier. Or you might want to
evaluate additional Identifiers even after a match has been established with this Identifier. Use the scripting methods described below to
tell Discovery how to respond.
95
Discovery Identifiers
96
Result States
The following table shows how the possible Discovery Identifier result states are used to decide the outcome of an
identity probe:
Continue Discovery
Create CI
Yes
No
Yes - if the device has matchable information available, such Yes - if the device has matchable information available, such
as IP address, MAC address, or class, and if there are no
as IP address, MAC address, or class, and if there are no
multiple matches.
multiple matches.
Multiple devices
matched in CMDB
No
No
Discovery Identifiers
97
Description
Details
Serial Number
Table & Class
Name
This identifier matches the discovered serial number against the serial_number in the Serial
Number [cmdb_serial_number] table. If the discovered serial number matches a CI in the
cmdb_serial_number table and the class name, the CI is declared identified. Note that in the base
system, Discovery populates the cmdb_serial_number table. Therefore, this identifier is important
for Discovery to use to find the CIs it has discovered in the past (assuming these were valid serial
numbers). For more information, see Serial Number Types.
Serial Number
& Class Name
This identifier matches the discovered serial numbers against the serial number field in the base CI
record. If a discovered serial number and class type (sys_class_name) matches a CI, that CI is
declared identified. The matching class name requirement means that Discovery will not identify
CIs that are not in the same class. For example, a computer and a printer have the same serial
number, but since their class names differ, Discovery does not identify them as the same CI.
Typically, imported data has the serial number field completed, but no matching value in the
cmdb_serial_number table. This identifier solves the issue of Discovery finding imported data in the
CMDB.
This identifier matches the discovered name against the name field in the base CI record. If a
discovered name and class type (sys_class_name) matches a CI, then that CI is declared identified.
The matching class name requirement means that Discovery will not identify CIs that are not in the
same class. For example, a computer and a printer have the same name, but since their class name
differs, Discovery will not identify them as the same CI.
Network
This identifier matches the discovered network adapters against those in the Network Adapter
[cmdb_ci_network_adapter] table, using the IP address and MAC address. If all the discovered
network adapters match a CI in the network adapter table, then the CI is declared identified.
Discovery Identifiers
98
Network &
Class Name
This identifier matches the discovered IP address and MAC address of the base CI against those in
the base CI record. If a discovered IP address, MAC address and class type (sys_class_name)
matches a CI, then that CI is declared identified. The matching class name requirement means that
Discovery will not identify CIs that are not in the same class.
MAC Address
& Class Name
This identifier matches the discovered MAC address of the base CI against those in the base CI
record. If a discovered MAC address and class type (sys_class_name) matches a CI, then that CI is
declared identified. The matching class name requirement means that Discovery will not identify
CIs that are not in the same class.
IP Address &
Class Name
This identifier matches the discovered IP address of the base CI against those in the base CI record.
If a discovered IP address and class type (sys_class_name) matches a CI, then that CI is declared
identified. The matching class name requirement means that Discovery will not identify CIs that are
not in the same class.
MACAddress
This identifier matches the discovered MAC address of the base CI against those in the base CI
record. If a discovered MAC address and class type (sys_class_name) matches a CI, then that CI is
declared identified. The matching class name requirement means that Discovery will not identify
CIs that are not in the same class.
Generic Serial
Number
This identifier matches the discovered serial number against the serial number field in the base CI
record. If a discovered serial number matches a CI, then that CI is declared identified. Note here that
the matching class name is NOT a requirement, which means that Discovery will identify CIs even
if they are not in the same class. For example, a computer and a printer have the same serial
number, but even though their class name differs, Discovery will still identify them as the same CI.
Generic
Network
This identifier matches the discovered IP address and MAC address of the base CI against those in
the base CI record. If a discovered IP address and MAC address matches a CI, then that CI is
declared identified. The matching class name is NOT a requirement, which means that Discovery
will identify CIs that are not in the same class.
Generic Name
This identifier matches the discovered name against the name field in the base CI record. If a
discovered name matches a CI, then that CI is declared identified. The matching class name is NOT
a requirement, which means that Discovery will identify CIs that are not in the same class.
Generic MAC
Address
This identifier matches the discovered MAC address of the base CI against those in the base CI
record. If a discovered MAC address matches a CI, then that CI is declared identified. The matching
class name is NOT a requirement, which means that Discovery will identify CIs that are not in the
same class.
Generic IP
Address
This identifier matches the discovered IP address of the base CI against those in the base CI record.
If a discovered IP address matches a CI, then that CI is declared identified. The matching class
name is NOT a requirement, which means that Discovery will identify CIs that are not in the same
class.
Linux
In the result of dmidecode | cat, the value on the left side is what Discovery looks for. The value on the right side is
how it is stored in the Serial Number [cmbd_serial_number] table.
Serial Number : system_serial_number
UUID : uuid_serial
Discovery Identifiers
Serial Number : baseboard_serial
Serial Number : chassis_serial
Windows
For Win32 WMI classes, the value on the left is the name by which it is stored in the Serial Number
[cmdb_serial_number] table. The value on the right is the WMI value.
('system' : Win32_ComputerSystemProduct.IdentifyingNumber);
('uuid' : Win32_ComputerSystemProduct.UUID);
('chassis' : Win32_SystemEnclosure.SerialNumber);
('bios' : Win32_BIOS.SerialNumber);
('baseboard' : Win32_BaseBoard.SerialNumber);
SNMP
For SNMP, the mapping below is based on the code. Physical types of serial numbers are from all instances of
iso.org.dod.internet.mgmt.mib-2.entityMIB.
'cisco_stack' :
'iso.org.dod.internet.private.enterprises.cisco.workgroup.ciscoStackMIB.chassisGrp.chassisSerialNumberString'
'cisco_chassis' :
'iso.org.dod.internet.private.enterprises.cisco.temporary.chassis.chassisId'
'foundry' :
'iso.org.dod.internet.private.enterprises.foundry.products.switch.snChassis.snChasGen.snChasSerNum'
'apc_pdu' :
'iso.org.dod.internet.private.enterprises.apc.products.hardware.masterswitch.sPDUIdent.sPDUIdentSerialNumber'
'printer' :
'iso.org.dod.internet.mgmt.mib-2.printmib.prtGeneral.prtGeneralEntry'
'standard' :
'iso.org.dod.internet.private.enterprises.apc.products.hardware.ups.upsIdent.upsAdvIdent.upsAdvIdentSerialNumber'
99
Credentials
100
Credentials
Overview
Credentials, such as user names and passwords, or certificates, are required to gain access to a computer or network
device for ServiceNow Discovery or to perform work on a computer using Orchestration. The platform stores these
credentials in an encrypted field on the Credentials table, and once they are entered, they cannot be viewed.
Credential tagging allows workflow creators to assign individual credentials to any activity in an Orchestration
workflow or assign different credentials to each occurrence of the same activity type in an Orchestration workflow.
Credential tagging also works with credential affinities.
Credential Affinity
It is not necessary to associate credentials with a device within Discovery. When Discovery or Orchestration first
attempts to access a device, they try all available credentials until they find the correct ones. After identifying the
credentials for a device, Discovery and Orchestration create an affinity between the credentials and the device using
the Credential Affinity [dscy_credentials_affinity] table. All subsequent discoveries or Orchestration activities
attempt to match the credentials in this table with a device for which an affinity exists. If credentials for a device
change, Discovery and Orchestration try all available credentials again until they create a new affinity.
Note: If Orchestration and Discovery are installed, and credential tagging is enabled, multiple affinities can exist. In this case, the
platform looks up credentials for each affinity and inserts the credential for the affinity with the lowest order into the probe.
Encryption/Decryption
Credentials are encrypted automatically with a fixed instance key when they are submitted or updated in the
Credentials [discovery_credentials] table. When credentials are requested by the MID Server, the platform decrypts
the credentials using the following process:
1.
2.
3.
4.
5.
The credentials are decrypted on the instance with the fixed key.
The credentials are re-encrypted on the instance with the fixed Web Service key.
The credentials are encrypted on the instance with SSL.
The credentials are decrypted on the MID Server with SSL.
The credentials are decrypted on the MID Server with the fixed Web Service key.
Credentials
101
Note: The platform does not have separate encryption keys for multi-tenant instances.
File or Directory
Access Required
Apache
httpd.conf
Read
JBoss
jboss-service.xml
Read
Read
web.xml
Read
MySQL
my.cnf
Read
Oracle
oratab
Read
Associated (s)pfiles
Read
Execute
Read
Credentials
102
Tomcat
Unix
catalina.jar
Read
server.xml
Read
web.xml
Read
/etc/*release
Read
/etc/bashrc
Read
/etc/profile
Read
/proc/cpuinfo
Read
/proc/vmware/sched/ncpus Read
WebSphere
/var/log/dmesg
Read
APD directory
Read
cell.xml
Read
server.xml
Read
serverindex.xml
Read
Platform(s)
Purpose
dmidecode
All Linux
lsof
Used By
Discovery
Discovery
vmware-cmd ESX
adb
HP-UX
Discovery
chpasswd
Orchestration
chage
Orchestration
oratab
All Unix
versions
N/A
Discovery
Credentials
/usr/ucb/ps
103
Solaris
Discovery
Windows Credentials
Discovery uses Windows credentials to explore Windows computers by:
Running remote WMI queries from WMI probes.
Running Powershell scripts from Powershell probes.
Accessing Windows administrative shares [2].
Orchestration uses Windows credentials to run workflow activities on Windows computers, which are typically
Powershell commands.
Requirements
Discovery and Orchestration have the following requirements for Windows credentials.
Install a MID Server on a Windows host as a service.
Add Windows credentials to one of these locations:
Credentials [discovery_credentials] table
MID Server service account
To have the MID Server use credentials from the Credentials table:
1. Add individual Windows credentials to the Credentials [discovery_credentials] table. See Credentials Form.
Verify each credential meets the permission requirements.
Verify each username meets the name format requirements.
Verify each credential meets the Windows domain requirements.
2. Configure the MID Server to use Powershell by setting the mid.use_powershell parameter to true. See
MID Server Configuration.
3. [Optional] By default, Discovery automatically uses the MID Server service account credentials if all credentials
in the Credentials table fail. If you do not want to use the MID Server service credentials as a fall back, set the
mid.powershell.local_mid_service_credential_fallback parameter to false. See MID Server
Configuration.
To have the MID Server use credentials from the MID Server service account:
1. Set the MID Server service account to a user who meets the permission requirements.
2. Verify the username meets the name format requirements.
3. Verify the credentials meet domain requirements.
Credentials
104
Permission Requirements
In order to provide sufficient permissions, Windows credentials must be one of the following:
A domain administrator
A domain user with local administrator access on the target Windows hosts
A user who meets the requirements of Discovery Windows Probes and Permissions (Discovery only)
A user who meets the requirements of the Orchestration activity to be run (Orchestration only)
MID Server host on the same Windows domain as the Windows host
None
MID Server host on a different Windows domain than the Windows host
MID Server host on a different Windows domain than the Microsoft SQL Server host See Microsoft SQL Servers
SNMP Credentials
Discovery explores many kinds of devices (switches, routers, printers, etc.) using the SNMP protocol. Credentials
for SNMP do not include a user name, just a password (the community string). The default read-only community
string for many SNMP devices is public, and Discovery will try that automatically. Enter the appropriate SNMP
credentials if they differ from the public community string.
The default Orchestration activity SNMP Query returns the OID of a device and requires SNMP credentials.
VMware Credentials
Discovery can explore VMware's vCenter running on a Windows machine. When Discovery detects the vCenter
process, Discovery automatically launches the VMware - vCenter probe. This probe logs into the vCenter instance
with the credentials provided and uses the vCenter API to return information about ESX machines, virtual machines,
and resource pools. Ensure that the credential Type selected is VMware.
Orchestration requires vCenter credentials for any work that it performs on vCenter, such as cloning a virtual
machine.
Note: Do not use VMware type credentials for Orchestration activities that perform work on the individual virtual machines cloned
by vCenter (for example, restarting a Linux VM). For these activities, the credential Type depends on the operating system of the
virtual machine (either SSH or Windows).
Credentials
105
CIM Credentials
Discovery can explore storage systems based on the Common Information Model (CIM) and can query a CIM server
(also referred to as a CIMOM - Common Information Model Object Manager) for information about VMware ESX
servers and the virtual machine hosts they serve. See CIM Discovery for information about the probes involved.
Credential Order
When Orchestration attempts to run a command on an SSH server (such as a Linux or UNIX machine), or when
Discovery attempts to query an SNMP device (such as a printer, router, or UPS), the application tries the credentials
in the Credentials table randomly, until it finds one that works. Credentials can be assigned an order value in the
Credentials Form, which forces Discovery and Orchestration to try all the credentials at their disposal in a certain
sequence. Ordering credentials is useful in the following situations:
The credentials table contains many credentials, with some used more frequently than others. For example, if the
table contains 150 SSH credentials, and 5 of those are used to log into 90% of the devices, it is good practice to
configure those five with low order numbers, which places them at the top of the execution list. Discovery and
Orchestration will work faster if they try these common credentials first. After the first successful connection, the
system knows which credentials to use the next time for each device.
The system has aggressive login security. For example, if the Solaris database servers in the network only allow
three failed login attempts before they lock out the MID Server, configure the database credentials with a low
order value.
Credentials
106
Credentials
107
type: "CustomCredTypeTestProb",
});
Other Considerations
Sometimes computers or devices have additional security measures configured, and these measures may interfere
with the MID Server's ability to run commands or queries on those systems. For example, a Linux server might be
configured to allow only certain IP address to connect to it via SSH. Similarly, a network router might be configured
to allow only certain IP address to query SNMP on it. To allow access in such cases, use one of the following
methods:
Update the configuration of those computers or devices to allow the desired MID Server to run commands or
query them. For example, a network router may be configured to only allow the network management systems to
query SNMP on it. In that case, add the MID Server as though it were another network management system.
Install a MID Server on a computer that already has access to the computers or network devices with such
restrictions. For example, to use Discovery within a DMZ (where communication from outside the DMZ will be
severely restricted), install a MID Server on a computer that is already in the DMZ.
Credentials Form
The Discovery Credentials form provides the following fields:
Field
Input Value
Name
Unique and descriptive name for this credential. For example, you might call it SSH Atlanta.
Type
User name Enter a user name for this type of credential. If a domain account is used to execute Powershell commands in Discovery, the user name
must include the domain. Avoid leading or trailing spaces in user names. These spaces can prevent the VMware - vCenter probe from
connecting to vCenter. A warning appears if the platform detects leading or trailing spaces in the user name.
Password
Enter the password to use. For SNMP type credentials, enter the community string here. For SSH Private Key type credentials, enter
the sudo password if one is required for the user name (starting with the Dublin release).
Order
The order (sequence) in which the platform tries this credential as it attempts to log onto devices. The smaller the number, the higher in
the list this credential appears. Establish credential order when using large numbers of credentials or when security locks out users
after three failed login attempts. If all the credentials have the same order number (or none), Discovery or Orchestration tries the
credentials in a random order.
SSH
Type a secure SSH passphrase. This field is available only for SSH Private Key credentials.
passphrase
Credentials
SSH
Private
Key
108
Enter a secure, private key that can be used instead of a password for SSH logins. This field is available only for SSH Private Key
credentials. The private key must be entered in the proper format to ensure it is correctly encrypted. The private key must start with the
string -----BEGIN.
Here is an example of a correctly formatted private key
-----BEGIN RSA PRIVATE KEY----MIIEogIBAAKCAQEAsEK65scPssPSobpDFMpR+Btv3MS4Q7NP8ERaStRZsh3IWz+x...
...7hrxV2dbSug60FahyupGWBGtPnXm5PaE2X5WPLuUj94ue48i1Fs=
-----END RSA PRIVATE KEY----The ServiceNow platform supports private keys in the PEM format generated by the OpenSSH ssh-keygen utility. To convert PPK
keys that were generated by PuTTY:
MID
servers
Select one or more MID Servers from the list of available MID Servers. The credentials configured in this record are available to the
MID Servers in this list. This field is available only when you select Specific MID servers from the Applies to field.
Applies to
Select whether to apply these credentials to All MID servers in your network, or to one or more Specific MID servers. Specify the
MID Servers that should use these credentials in the MID servers field.
Active
A completed credentials form for an SSH credential could look like this, but local configurations can vary:
Enhancements
Dublin
SSH Private Key credentials can also include a password if one is required for sudo commands. See Credentials
Form.
You can create custom credential types using JavaScript.
Calgary
Obsolete configuration parameter: The MID Server configuration parameter
mid.powershell.use_mssqlauth is obsolete and was removed from the platform. Microsoft SQL Server
discoveries use the PowerShell probe, which uses the MID Server's credentials. The PowerShell MSSQL probe
was also removed.
Obsolete credential type: The MSSQL credential type was removed from the Credentials
[discovery_credentials] table.
User Name validation: A warning appears if the platform detects leading or trailing spaces in the User Name
field. These spaces prevent the VMware - vCenter probe from connecting to vCenter.
Credentials
References
[1]
[2]
[3]
[4]
[5]
Discovery Schedules
Overview
A discovery schedule is the starting point for all discovery activities. The schedule determines what is going to be
discovered, the day and time when it will be discovered, and the MID Servers that will perform the discovery.
Use the Discovery Schedule module to:
Configure device identification by IP address or other identifiers.
Determine if credentials will be used in device probes.
Prerequisites
Before you begin with Discovery, configure the following:
MID Servers: Install and configure one or more MID Servers.
Credentials: Provide the MID Servers with the login credentials they need to query the devices in the network.
Schedules: Create a schedule record that defines what actions Discovery must take to scan the devices and
software in the network.
Classifications: Make sure the device and process classifications provided in the base platform are sufficient.
Create new classifications as needed for the devices, processes, and applications in the network.
109
Discovery Schedules
110
Field
Description
Name
Discover
Behavior
Configuration items: Configuration item scans use discovery identifiers to match devices with CIs in the CMDB and update the
CMDB appropriately. You can perform a simple discovery by selecting a specific MID Server to scan for all protocols (SSH,
WMI, and SNMP), or perform more advanced discoveries with discovery behaviors. When you select a behavior, the MID
Server field is not available.
IP addresses: IP address scans discover devices without the use of credentials. These scans discover all the active IP addresses in
the specified range and create device history records, but do not update the CMDB. IP address scans also show multiple IP
addresses that are running on a single device. Devices are identified by class and in some cases by type, such as Windows
computers and Cisco network gear. The Max range size Shazzam probe property determines the maximum number of IP
addresses Shazzam scans. See Configuring the Shazzam Probe.
Networks: Network scans discover IP networks (routers and switches). Results from this search are used to populate the IP
Network [cmdb_ci_ip_network] table in Discovery > IP Networks with a list of IP addresses and network masks. Network scans
update routers and layer 3 switches in the CMDB.
Select a behavior configured for the MID Servers in your network. When you select a behavior, the MID Server field is no longer
visible. Use a behavior when a single schedule requires the use of multiple MID Servers to perform any of the following:
Choose a location to assign to the CIs that are discovered by this schedule. If this field is blank, then no location is assigned.
Max Run
Time
Set a time limit for running this schedule. When the configured time elapses, the remaining tasks for the discovery are cancelled, even
if the scan is not complete. Use this field to limit system load to a desirable time window. If no value is entered in this field, this
schedule runs until complete.
Active
Select the check box to enable this schedule. If you clear the check box, the schedule is disabled, but you can still run a discovery
manually from this form, using the configured values.
Run
Select whether the discovery runs on a periodic schedule. If you select Once or Periodic, the form displays the Starting field for
selecting the date and time to run the discovery (Calgary release). If you select Once in versions prior to Calgary, Discovery runs one
time after an update to the record.
Day
Select the day of the week or month when Discovery runs in a weekly or monthly schedule. This field is available only if Run is set
to Weekly or Monthly.
Time
Select the time of day this schedule should run. All times are local and use a 24-hour clock.
Repeat
Interval
Select the number of days between scheduled discovery runs. This field is available only if Run is set to Periodically.
Discovery Schedules
Starting
Select a date and time to run the discovery once or periodically. This field is available only if Run is set to Once or Periodically.
This field is visible by default starting with the Calgary release.
Include
alive
Select this check box to include alive devices, which are devices that have at least one port that responds to the scan, but no open
ports. Discovery knows that there is a device there, but has no information about it. If this check box is cleared, Discovery returns all
active devices, which are devices that have at least one open port.
Log state
changes
Select this check box to create a log entry every time the state changes during a discovery, such as a device going from Active to
Classifying. View the discovery states from the Discovery Devices related list on the Discovery Status form. The Completed
activity and Current activity fields display the states.
Shazzam
batch size
Enter the number of IP addresses that each Shazzam probe will scan. Dividing the IP addresses into batches improves performance by
allowing classification for each batch to begin after the batch completes, rather than after all IP addresses have been scanned. The
probes run sequentially. For example, if this value is set to 1000 and a discovery must scan 10,000 IP addresses using a single MID
Server, it creates 10 Shazzam probes with each probe scanning 1000 IP addresses. By default, the batch size is 5000. A UI policy
enforces a minimum batch size of 256 because batch sizes below 256 IP addresses do not benefit from clustering. The policy converts
any value below 256 to a value of zero.
The value for this field cannot exceed the maximum range size property for the Shazzam probe.
This field is available starting with the Eureka release.
Shazzam
cluster
support
Select the check box to distribute Shazzam processing among multiple MID Servers in a cluster to improve performance. For
example, if 10 probes are running and there are 10 MID Servers in the cluster, each probe runs on a different MID Server.
Quick
ranges
Define IP addresses and address ranges to scan by entering IP addresses in multiple formats (network, range, or list) in a single,
comma-delimited string. For more information, see Quick Ranges.
Discovery
IP Ranges
This related list defines the ranges of IP addresses to scan with this schedule. If you are using a simple CI scan (no behaviors), use
this related list to define the IP addresses to discover.
Discovery
Range Sets
This related list defines each range set in a schedule to be scanned by one or more Shazzam probes.
Discovery
Status
This related list displays the results of current and past Discovery schedule runs.
Configuring IP Addresses
Use one or more of these methods in any combination to define the network or network segment for Discovery to
query:
IP address list
IP address range
IP network
Quick Ranges
Discover Now
Note: If you do not know the IP addresses in the network, run network discovery first to determine the IP networks. Then, convert the
IP networks into IP address range sets.
111
Discovery Schedules
IP Address List
Use IP address lists to add individual addresses for Discovery to query. These addresses should not be included in
any existing IP range or IP network. You can enter the IP address of the device or a host name (DNS name). If you
enter a host name, it must be resolvable from the ServiceNow instance.
IP Address Range
You can define arbitrary ranges of IP addresses for Discovery to query. This is a good way to include selected
segments of a network or subnet, but Discovery has no way of knowing if the IP range includes addresses for private
networks [1] or broadcast addresses [2], and so must ping all the addresses in the range. If the network and broadcast
addresses are included, then the results are inaccurate. For this reason, discoveries configured to detect IP networks
are generally more accurate than those configured for IP address ranges. ServiceNow recommends that any IP
address range only includes IP addresses reserved for manageable devices on the public network.
IP Network
An IP network includes the range of available IP addresses in that network, including the network address (the
lowest address in the range) and the broadcast address (the highest address in the range). An example of a class C
network range is 192.168.0.0 to 192.168.0.255. In the Range Set form, this network can be entered with either of the
following notations:
192.168.0.0/24
192.168.0.1/255.255.255.0
This notation indicates that Discovery is scanning an IP network, and Discovery does not scan the highest and lowest
numbers in the range. This prevents significant errors from being introduced into the Discovery data by the broadcast
address, which returns all the devices in the network, and the network address, which can add an arbitrary number of
redundant devices. This built-in control makes IP networks the best method of defining which IP address ranges to
query.
Quick Ranges
Quick ranges allow administrators to define IP addresses to scan in a single comma-delimited string without creating
separate records. You can enter IP addresses in one of the following formats:
An IP range defined by a slash and the number of bits in the subnetwork [2]. For example, the string
10.10.10.0/24 scans 24 bits of IP addresses from 10.10.10.0 to 10.10.10.254.
An IP range defined by a dash. For example, the string 10.10.11.0-10.10.11.165 scans the IP addresses
from 10.10.11.0 to 10.10.11.165.
A comma-separated list of specific IP addresses. For example the string 10.10.11.200,10.10.11.235
scans the IP addresses 10.10.11.200 and 10.10.11.235.
To create quick ranges:
1. Click the Quick Ranges related link on the Discovery Schedule form.
2. Enter the IP networks, IP ranges, and specific IP addresses to scan.
3. Click Make Ranges.
Note: The Quick Range interface is for entering IP addresses only and cannot be used to edit IP addresses that have already been
submitted.
112
Discovery Schedules
The instance automatically displays the entries in the proper format. To make any changes to IP address ranges,
select the IP address records.
Discover Now
Discover Now allows you to manually run a Discovery schedule. Manually running a schedule record does not affect
the schedule. It continues to run as configured, despite manual execution.
1. Navigate to Discovery > Discovery Schedules.
2. Select the schedule you want to manually run.
3. From Related links, click Discover now.
Excluding IP Addresses
Administrators can exclude specific IP addresses in a range or network from a Discovery Schedule. For example,
you might exclude a subnet containing devices restricted from interacting with other devices or exclude a device
with an intentionally unorthodox configuration that causes an authentication issue each time it is discovered.
To exclude an IP address:
1. In the Discovery Schedule form, click the link for the Type of IP address range that contains the address to
exclude. For example, to exclude 10.10.10.28, select the IP Network for 10.10.10.0/24, which is the range of IP
addresses that contains the target address.
113
Discovery Schedules
114
Discovery Schedules
The excluded IP address appears in the Discovery Range Item IPs related list for that IP address Type.
7. Click Update to save the excluded address and return to the Discovery Schedule.
115
Discovery Schedules
Enhancements
Eureka
Supports clustering of Shazzam probes across multiple MID Servers for improved performance.
Calgary
A new field Starting allows administrators to specify the start date for periodic and one-time discoveries. See
Discovery Schedule Form for more information.
References
[1] http:/ / en. wikipedia. org/ wiki/ Private_network
[2] http:/ / en. wikipedia. org/ wiki/ Broadcast_address
Network Discovery
Note: If you already know the IP address ranges in your network, it is not necessary to run Network Discovery. This procedure is
intended for organizations that do not have complete knowledge of the IP addresses available for Discovery in their networks.
Overview
Network Discovery discovers the internal IP networks within your organization. Discovery uses the information it
gathers to update routers and Layer 3 switches in the CMDB. Network Discovery is performed by a single MID
Server that begins its scan on a configurable list of starting (or seed) routers. Typically, the starting routers are the
default routers used by all the MID Server host machines in the network, but can be any designated routers. The
MID Server uses the router tables on the starting routers to discover other routers in the network. The MID Server
then spreads out through the network, using router tables it finds to discover other routers, and so on, until all the
routers and switches have been explored.
After running Network Discovery, convert the IP networks it finds into IP address Range Sets that you use in
Discovery Schedules to discover configuration items (CI).
116
Network Discovery
The default IP networks in this list are available to every Network Discovery you conduct and are sufficient
for most discoveries.
7. If your organization has additional private IP addresses, click New to add them.
8. Add starting routers to the schedule in the Discovery Range Sets list.
a. Click the Network Discovery Auto Starting Routers link to populate the list with the starting router for
each MID Server in your network.
b. Click Edit to add or delete routers from the list.
117
Network Discovery
118
If your IP Networks were created through Network Discovery, then these fields will be populated
automatically in the IP Networks Related List. However, if you entered the IP Networks manually, and you
want to convert your IP Networks into range sets through the UI Action, you must edit these field accordingly.
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.
Description
Default
BGP Router
Exploration
Disable
Controls whether Network Discovery exploration of routers running the BGP protocol is
Yes
disabled. Normally such exploration IS disabled because of the huge size of BGP routing
tables, and because generally such routers are only operating at the edge of large networks
where further network discovery would be irrelevant. The only time this value should be set
to "no" is in the unlikely case that your organization uses BGP routers as edge routers
between relatively small networks (such as between buildings on a single campus).
Network Discovery
119
Maximum
Netmask Size
for
Discoverable
Networks (bits)
The maximum number of bits in a regular netmask for networks that will be discovered by
Network Discovery. By "regular netmask" we mean a netmask that can be expressed in
binary as a string of ones followed by a string of zeroes (255.255.255.0 is regular,
255.255.255.64 is irregular). Regular networks are commonly expressed like this:
10.0.0.0/24, which means a network address of 10.0.0.0 with a netmask of 255.255.255.0.
Larger bit numbers mean networks with smaller numbers of addresses in them. For
example, the network 10.128.0.128/30 has four addresses in it: one network address
(10.128.0.128), one broadcast address (10.128.0.131), and two usable addresses
(10.128.0.129 and 10.128.0.130). Small networks like this are commonly configured in
network gear to provide loopback addresses or networks used strictly by point-to-point
connections. Since these sorts of networks generally don't need to be discovered by
Network Discovery, it would be useful to filter them out. By setting this property to a value
of 1 through 32, you can limit the sizes of regular networks that are discovered. Setting it to
any other value will cause all networks to be discovered. Irregular networks are always
discovered. The default value is 28, which means that regular networks with 8 or fewer
addresses will not be discovered.
28
Network
Router
Selection
Method
This property controls the method used to decide (during Network Discovery) which router
should be selected as the router to be associated with a given IP Network. The possible
values are: "First Router" (the first router that discovers the network is associated), "Last
Router" (the last router that discovers the network is associated), "Most Networks" (the
router with the most attached networks is associated), and "Least Networks" (the router
with the least attached networks is associated).
Most Networks
Physical
A comma-separated list of interface types that will be considered "physical" for the
6,117,9,71,209
Interface Types purposes of network discovery. In other words, if a router (or device capable of routing) has
an interface of this type, the networks connected to that interface will be considered locally
connected to that device. The default interface types include Ethernet, 802.11, and Token
Ring types. Interface type numbers are defined in the SNMP MIB-2, specifically in OID
1.3.6.1.2.1.2.2.1.3.
Switch
List of interface types (comma-separated) that will be considered Interface type numbers
Interface Types are defined in the SNMP MIB-2, specifically in OID 1.3.6.1.2.1.2.2.1.3. Devices with any
interface types that do not appear in this list will be classified as routers (if they have
routing capability). A complete list of the interface type numbers may be found on the
IANA web site, in the section "ifType definitions".
7,8,9,26,53,62,69,71,78,115,117,209
Stale Network
Discovery
Threshold
(Days)
The number of days before which discovered information about network gear is considered -1
"stale". While performing network discovery, if a router (or other device capable of routing)
has not been discovered, or if the discovered information is stale, then network discovery
will launch probes to freshen the information. Otherwise, it will reuse the information that
has already been discovered. If this number is negative, then any previously discovered
information is always considered stale, and network discovery will always launch probes to
freshen the information.
Network
Discovery
Debugging
Enables extensive logging (for debugging purposes) of all Network Discovery activities on
the instance. Normally this is only set to "yes" by developers.
Yes
Discovery Status
120
Discovery Status
Overview
The Discovery Status interface (Discovery > Status) displays all the details of a Discovery. Each record in the Status
list represents the execution of a Discovery by a schedule and displays such high level information as the date of the
Discovery, the mode, the number of probe messages sent to devices, and the number of sensor records that were
processed. From this record, you can drill down into the following data:
Probe and sensor records, including the instructions given to the probes and the information returned
The relationships between the probes and sensors
All log entries for the Discovery
Specific information about devices discovered
Use this data to troubleshoot the behavior of individual probes and sensors or even run those elements separately.
Use the status controls to enter probe/sensor threads at any point for a specific Discovery, and then follow the
process in either direction.
Input Value
Number
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
State
Started
The number of probe messages sent to devices from the MID Server.
Completed
The number of sensor records that were processed. This number must match the number of probes launched.
From Schedule
Discover
Shows the Discovery type. The possible types are: Configuration items, IP addresses, or Networks.
Max Run
Time
Displays the maximum amount of time Discovery was permitted to run on this schedule.
Include alive
Indicates that this Discovery includes devices on which one port responded to the scan, but no ports are open. Such a device is
considered to be alive. If this check box is not selected, only active devices with one or more open ports that Discovery can query
are displayed.
Log state
changes
Indicates that state changes were logged during this Discovery. Discovery states can be seen in the Last and Current fields in the
Discovery Devices list in this form.
Discovery Status
Discovery Timelines
A Discovery Timeline generates a graphical display of the Discovery Status records for a Discovery, including
information about each probe and sensor running.
Use Discovery Timelines to display the following:
The flow of probes and sensors through a Discovery
The duration of each probe and sensor that ran during a Discovery and the proportion of time required for queuing
and processing
Tooltips containing additional data about a probe or sensor
Records from the ECC Queue
121
Discovery Status
122
Discovery Log
The Discovery Log displays all the activity for this Discovery, including such things as classification failures,
CMDB updates, and authentication failures. From this list, click a link in the CMDB CI column to drill into the
record for that CI or click the link in the Created column to view an individual log record. To view the log records
for a particular device, click the IP adddress link in the Device column. This action opens the Discovery Devices
record.
Log Information
The Discovery Log provides the following information:
Field
Input Value
Created
Timestamp of the Discovery activity. Each timestamp defines the approximate time of the activity. Several Discovery events may occur
in random order within a second.
Level
Classifies the activity into one of the following levels for general sorting:
Error
Information
Warning
Message
Informative message detailing the outcome of the activity or the Discovery progress. Look here for the result of a classify probe or for
authentication failure.
Source
Names the particular activity, such as the Shazzam probe or a UNIX classify probe.
CMDB
CI
Names a device for which a matching CI was found in the CMDB. Click this link to drill down into the CI record for the device.
Sensor
Names the sensor that processed the results of a specific probe that was run. This field also indicates if the probe was a MultiProbe.
Click this link to view the sensor record, including the package that was processed.
Device
Lists the IP address of the CI discovered. All devices identified by IP address appear in the log, even if they refused all invitations to
communicate. Any port activity from a device places it into the log, even if all subsequent efforts to identify it fail. Click the IP address
of the device to view the events associated with discovering that device.
Discovery Status
Devices
Select the Devices Related List to view a summary for all the devices scanned. During a Discovery, the list tracks
current and completed activity and displays an incremental scan counter. When Discovery is finished for a device,
the final disposition is displayed in the Completed activity column. Successful Discoveries that result in updated or
created CIs are highlighted in green. To view the log entries for errors (such as connection failure) on a specific
device, click the Details link in the Issues column.
Click on the IP address of a device in this list for details about that device. The log results for that device are
displayed in the list at the bottom of the form.
123
Discovery Status
124
If there were issues, or if Discovery failed to complete, click the Details link to view the log records for the issue.
The failure of any probe is considered an issue, even if the device was eventually classified properly and updated in
the CMDB.
Input Value
Source
Completed
activity
Indicates the outcome of Discovery for this device or the last completed activity for a Discovery in progress, such as Identified
CI. Successful outcomes are indicated in green.
Current activity
The current scanning activity for this device for a Discovery in progress, such as Updating CI.
CMDB CI
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
Discovery Status
ECC Queue
The External Communication Channel (ECC) Queue lets you see all probe and sensor records for a particular device
for a particular Discovery. You can drill down in the ECC Queue from the beginning to the end of the Discovery, or
drop into the sequence of probes and sensors at any point. To open the ECC Queue, open a Discovery Status record,
and then select ECC Queue from the Related Links. You can sort the list by the timestamp or select any probe or
sensor record that interests you. You can see what activity launched the probe or answered the sensor's commands
and track the processing order for a Discovery in either direction. To determine whether a record is for a probe or a
sensor, look at the value in the Queue column. Sensor records are in the input queue, and probe records are in the
output queue.
This view of the ECC Queue is the best way to see the Shazzam and Ping probes without extensive drilling. Ping
probes can be chunked up to reduce the delay in returning results. The chunking of Ping probes is controlled by a
property in Discovery Definition > Properties called Max ping chunk size. This property is described as the
maximum number of IPs that will be pinged in one "chunk" of work. If a Discovery range has more than this number
of IPs in it, it will be automatically broken up into chunks no larger than this parameter's value.
125
Discovery Status
126
Input Value
Agent
Topic
Name
Identifying name of the probe or sensor. For SSH probes, this is the probe's message. For all others, the name is an identifying string
generated by the instance.
Source
The IP address of the Discovered device. The Shazzam and Ping probes do not have a source IP associated with them. These probes are
not directed toward a single device, but exist to scan all devices in the specified network range.
Response
to
Displays the name of the probe or sensor in the Discovery sequence whose activity triggered this probe or sensor. A single sensor can
launch several probes, but a sensor can only respond to a single probe.
Queue
Designates whether the record is for a probe or a sensor. Sensors are in the input queue, and probes are in the output queue.
State
Shows where the probe or sensor is in the process of completing its task (e.g. processed or processing)
Processed
Created
Sequence
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.
Discovery Status
Troubleshooting
If you are suspicious of the results of a Discovery (credential failure, for example), you can run individual probes
directly. To run a probe from the ECC Queue list, right-click the probe and select Run Again from the pop-up menu.
To run a probe directly from an ECC Queue record, click the Run Again UI action in Related Links.
127
Discovery Timelines
Discovery Timelines
Overview
A Discovery Timeline generates a graphical display of the Discovery Status records for a Discovery, including
information about each probe and sensor running.
Use Discovery Timelines to display the following:
The flow of probes and sensors through a Discovery
The duration of each probe and sensor that ran during a Discovery and the proportion of time required for queuing
and processing
Tooltips containing additional data about a probe or sensor
Records from the ECC Queue
Using Timelines
View timelines for an entire Discovery or for individual devices in a Discovery. In the out-of-box system, the
maximum size Discovery that can be displayed in a timeline is 300 entries in the ECC Queue (150 probes and 150
sensors). To display larger discoveries, change the default setting in the glide.discovery.timeline.max.entries
property.
Probe and sensor timelines are available automatically when Discovery starts. Partial timelines for any device or for
the entire Discovery can be viewed during the scanning process. View the progress of the Discovery by refreshing
the browser.
1. Navigate to Discovery > Status.
2. Select a Discovery from the record list.
3. Click the Show Discovery Timeline Related Link.
128
Discovery Timelines
The timeline for the entire Discovery appears, unless the size threshold is exceeded. If the timeline is too large
to display, an error message appears.
4. Clear the warning, and then select the Devices Related List.
5. Click the IP address of a device.
6. In the Device record, click the Show Discovery Timeline Related Link.
The Discovery timeline for that device appears.
7. Use the pink slider at the bottom of the timeline to change the perspective.
a. Move the slider from right to left to view all the tasks on a long timeline.
b. Adjust the end points of the slider to change the magnification.
A narrow slider zooms in on the spans and provides a more detailed view of complex timelines. A wide
slider pulls the view out and makes more of the timeline visible on the screen.
8. Use the selector range at the top of the screen to adjust the visible time frame. To limit the timeline to the length
of the Discovery, click Max.
The time scale adjusts automatically to the length of the Discovery. The available time scale range is from one
day to 1 year.
129
Discovery Timelines
Tooltips
Discovery timelines display probe and sensor performance data and CI information in tooltips. Hover the cursor over
a span to view this data. Probes are displayed by black spans. The queue time for a probe is shown as a silver bar
within the span, and the processing time is represented by the remaining space. Sensor spans are red, and the queue
time is shown as a green bar. Selected spans of any type display in yellow.
ECC Queue
Double-click on a span to open the ECC Queue record for that probe or sensor.
130
Resource Throttling
131
Resource Throttling
Overview
Discovery sensor processing is database intensive and can create performance issues on ServiceNow instances. For
example, Discovery could increase response times for activities in the user interface. To mitigate the impact
Discovery can have on performance, ServiceNow provides a mechanism that throttles (decreases) the speed at which
Discovery processes sensors. This control is a simple meter that creates an interval between Discovery sensor
processing jobs so that no two sensors are processed simultaneously. A throttled Discovery reduces performance
issues in the user interface, but takes longer to complete.
The throttling feature requires the Discovery Throttling plugin and is available starting with the Calgary release.
Required Role
To implement Discovery resource throttling, a user must have the discovery_admin role.
Tables
The following tables manage throttling data.
Table
Description
Stores the application configuration. This table only has a single row.
Stores the latest time a throttled sensor process is scheduled to run. This table
is not meant to be edited manually.
Throttling Mechanism
When Discovery throttling is enabled, a before business rule called Discovery - Sensor Throttler runs on the
Schedule Item [sys_trigger] table and applies the throttling level interval from the configuration form to Discovery
sensor processing. The business rule sets a time for each process to run which is at least the length of the throttling
level interval after the latest Discovery sensor has run.
The
configuration
form
automatically
sets
a
system
property
called
glide.discovery.throttling.enabled to tell the business rule whether or not to apply the throttling
level interval to a specific sensor processor.
Warning: Do not manually edit this property. Use the configuration form to enable throttling. Manually changing this property
can disable throttling.
Resource Throttling
Setup
Discovery throttling can be enabled or disabled while Discovery is running, with the following effects:
If you enable throttling during a discovery, there is no effect on the currently running discovery. The throttling
occurs on the next and all subsequent discoveries.
If you disable throttling during a discovery, new sensor jobs start immediately. Sensor jobs created when
throttling was enabled are processed on their original schedule.
To enable throttling:
1. Navigate to Discovery Definition > Performance > Sensor Throttling.
The Discovery Sensor Throttling Configuration record is set to Off by default. This is the only record in the
table.
2. Edit the following fields in the form:
Throttling Mode: Enable or disable throttling.
Off: Throttling is not applied to Discovery.
On: All Discovery sensors are subject to throttling at all times.
Scheduled: Schedules the time period in which throttling is applied to Discovery. Scheduled start and end
times are intended to occur on a single day (from 00:00:00 to 23:59:59). The following scheduling fields
appear only when this mode is selected.
Scheduled Start Time: The time of day to begin throttling.
Scheduled End Time: The time of day to stop throttling.
Weekdays Only: Only throttle Discovery Monday through Friday.
Throttling Level: Select the sensor processing interval.
Low: An interval of 333 ms that processes an average of 3 sensors per minute.
Medium: An interval of 500 ms that processes an average of 2 sensors per minute.
High: An interval of 1000 ms that processes an average of 1 sensor per minute.
3. Click Update.
Scheduler Snapshot
To view a count of scheduled jobs in the Schedule Item [sys_trigger] table, click the View schedule status related
link. The snapshot contains the following information:
Scheduled Job State Distribution: lists all the scheduled jobs in the instance and the number that are for
Discovery sensors. These jobs are categorized by their state: Running, Queued, or Ready.
Discovery Ready Job Distribution: lists the number of Discovery sensor jobs that are ready to run at the current
time and in the future. Each row lists a 30-minute interval. The table shows as many rows as needed to include all
scheduled Discovery sensor jobs. However, the list stops at the first row that has no scheduled sensor jobs.
132
Resource Throttling
Throttling Message
When you manually activate Discovery on an instance with throttling enabled, a message appears above the
Discovery Status list showing the schedule name and indicating that throttling is active.
References
[1] https:/ / hi. service-now. com/ nav_to. do?uri=com. glideapp. servicecatalog_cat_item_view.
do?sysparm_id=891f088e465667e234a3cb52ffa1d299
133
Enhancements
Calgary
The external credential storage feature is available for use with Orchestration in the Calgary release. Discovery is not
required.
Installed Components
The following components are installed with the External Credential Storage plugin.
Business Rule
The External Credential Storage business rule performs the following tasks when an administrator makes any
change to the external credential storage property:
Changes the view for the Credentials record list and form to the External Storage view. This view enables users to
to see the Credential ID column in the list.
Instructs the MID Server to refresh its credentials cache in preparation for a change in the way credentials are
obtained.
System Property
A property called Enable External Credential Storage enables or disables the External Credential Storage plugin
after it is activated. The property is located in Discovery Definition > Properties and Orchestration > MID
Server Properties, and is enabled when you activate the plugin.
Automatic Deactivation
If you disable external credential storage with the system property, the system automatically sets all the external
credentials to inactive in the instance. If you re-enable the feature with this property, the system does not reset the
external credential records to active. You must reactivate each credential record manually.
134
Configuration Tasks
To configure your instance to obtain credentials from a remote repository, complete these tasks in order. These
procedures assume that you already have an external repository configured with the credentials you want to protect.
The credential identifier configured in the ServiceNow instance must be mapped to the actual credential in the
repository through the JAR file.
135
136
public CredentialResolver() {
// Do whatever is needed to instantiate this class.
could be nothing at all,
This
137
138
}
}
5. Click Submit.
6. Restart the MID Server service.
The platform makes the JAR file available to any MID Server configured to communicate with the instance.
5. In Credential ID, enter the unique key configured for these credentials in the external repository.
This is the ID passed to the Java class in the parameter map:
public static final String ARG_ID
= "id";
Logging
If the repository encounters an error while attempting to resolve a credentials request, the MID Server posts log
messages with the following prefix:
Problem with client's CredentialResolver:
139
140
141
Requirements
Enable Application Profile Discovery: To enable APD, navigate to Discovery Definition > Properties and
select Yes in the Application Profile Discovery property.
Select a MID Server
Calgary: Application Profile Discovery now supports the use of MID Servers configured for PowerShell to
discover Windows machines.
Description
Table
Application Classification
[discovery_classy_appl]
Stores the results of application discoveries. Access application CIs in this table by navigating to
Discovery Definition > CI Classification > Application.
Category
DiscoveryAPDVersionSensor
DiscoveryAPDSensor
DiscoveryAPDEnvSensor
Environment File
The XML file that contains the application environment information must be created by a system administrator who
understands the relationships of the specified application. Ideally, this file is prepared when an application is
configured on a managed system. The environment file provides information relevant to the organization and to the
application. See the example to understand how Discovery displays data from environment files in configuration
item (CI) records.
142
<subservices>
<subservices_provided>
<subservice> label </subservice>
</subservices_provided>
<subservices_consumed>
<subservice> label </subservice>
</subservices_consumed>
</subservices>
</environment>
</config>
</apd>
Requirement
Description
Attributes
version
Mandatory
application
system
The system name represents the managed systems name, unique to a given system,
to which this environment configuration file belongs.
<label>
Mandatory
<description>
Optional
<ownership>
Optional
If ownership is not specified here, then it must be configured in the version file.
This value is typically a group-level ownership label that may be mapped to an
existing group in the Group [sys_user_group] table. This value appears in the
Support group field in the ServiceNow Environment record for this application.
To access the record, personalize the form to add the Environment related list to the
application record, and then drill down into the environment listed.
<business service>
Optional
The name of the business service that this application presents to the rest of an
organization. This business service has a Depends on::Used by relationship with
the application.
Tags
143
<application version
path>
Mandatory
This is the path to the version file for this application. Never place the version file
in the same directory as the environment file.
<subservices_provided>
Optional
These values can be used to describe the individual services provided to other
applications apart from this one. Configure sub-services provided in the
environment configuration file if they are different in each environment. Configure
them in the version configuration file if sub-services are hardwired into the
application. Sub-service configuration information can be used by the MID Server
to connect this application environment with other applications or application
environments.
<subservices_consumed> Optional
These values describe the individual services that this application consumes from
others. Configure sub-services consumed in the environment configuration file if
they are different in each environment. Configure them in the version configuration
file if sub-services are hardwired into the application. Sub-service configuration
information can be used by the MID Server to connect this application environment
with other applications or application environments.
UNIX
Place the environment files in one of the following locations. Discovery searches for the file in the order shown.
1. Environment variable: Put the environment configuration file in a path such as /usr/local/APD and set
the variable, $APDCONF, to describe the location of the file. How this environment variable is maintained is left
to the administrators of the local environment.
2. Discovery property: Navigate to Discovery Definition > Properties and set the file path in the Application
Profile Discovery location for UNIX based systems property
(glide.discovery.application_discovery.unix_location). The default path is /etc/opt/APD/.
Windows
Place the environment configuration file in one of the following locations on a Windows OS version that supports a
local machine registry.
1. Registry key: Before the MID Server retrieves a file from a managed Windows system, it checks the
HKEY_LOCAL_MACHINE (HKLM) hive, in the key HKLM\SOFTWARE\APD\APD\CONFIGPATH for a
REG_EXPAND_SZ or REG_SZ type registry value. The key value can require expansion for terms such as
%CommonAppDataFolder%. See Microsofts CSIDL [1] documentation for further details.
2. Discovery property: Navigate to Discovery Definition > Properties and set the file path in the Application
discovery location for Windows systems property
(glide.discovery.application_discovery.windows_location). The sample path is
%ALLUSERSPROFILE%\Application Data\APD, in which %ALLUSERSPROFILE% is the environment variable
for any Windows system. This variable points to different paths on different versions of Windows. For example,
on Windows 7, %ALLUSERSPROFILE% opens C:\ProgramData, and on Windows XP, it opens C:\Documents
and Settings\All Users.
Proxy Locations
Some managed systems, such as network routers, switches, and network load balancers, do not support locally stored
files or general purpose file systems that could store APD configuration files. In this case, you can name the target
managed system in an environment configuration file installed on a separate proxy server. Make sure to put the
configuration XML file in one of the approved locations on the proxy machine. The MID Server searches for this file
on every machine it discovers. When it finds an XML file in one of the expected locations, it identifies the correct
managed system by parsing the value for <managed system name> in the following line:
<config version=1.0 application=(optional) application-name type=environment system= (optional, if not local system) managed system name>
Version File
The XML file containing version information about the application is typically prepared as part of the software
packaging and release process and is identical across all managed systems using that version of the software. An
application on any given managed system can be fully described by one or more version files and one or more
environment files. Never place the version file in the same directory as the environment file. You can install the
version file in any other location on the managed system or proxy server that is visible to the MID Server. The MID
Server locates the version information related to an application by following a path defined within the environment
file. Install one copy of the version file per installed software version on a managed system. See the example of this
feature to understand how Discovery displays data from version files in configuration item (CI) records.
144
145
Application Details
Detail
Requirement
Description
Attributes
version
Mandatory
The version must be unique to the installed version of an application. This label displays the
application version or other distinguishing name.
application
Mandatory. Discovery
uses the application
name from the version
file to populate the
CMDB.
<label>
Optional
This label has information important to the organization, such as Production, UAT, QA, or
Development. The label and description appear only in the Environment related list in the
application record. You must personalize the form to add the Environment related list.
<description>
Optional
Tags
146
<ownership>
Mandatory
This value is typically a group-level ownership label that may be mapped to an existing group
in the Group [sys_user_group] table. This value names the owner who is responsible for this
software package or installation. If no value is specified in the environment file, then this
value is used to record ownership of the environment as well. A group owner selected from
the Group [sys_user_group] table appears in the Support group field in the ServiceNow
Environment record. To see this record, personalize the Application form to display the
Environment related list, and then drill into the environment listed.
<subservices_provided>
Optional
These values describe the individual services provided by this version of the software. Use
this value to define additional services provided by a new version of an existing application
already configured by an environment file. Discovery creates the relationships defined in the
environment file first and then adds any sub-services listed in the version file.
<subservices_consumed> Optional
These values describe the individual services this application consumes from other
applications. Use this value to define additional services consumed by a new version of an
existing application already configured by an environment file. Discovery creates the
relationships defined in the environment file first and then adds any sub-service relationships
listed in the version file.
Enhancements
Calgary
The following enhancements have been added as of the Calgary release:
PowerShell support: Application Profile Discovery supports the use of MID Servers configured for PowerShell
to discover applications on Windows machines.
References
[1] http:/ / msdn. microsoft. com/ en-us/ library/ windows/ desktop/ bb762494(v=vs. 85). aspx
Example
147
Example
Overview
This page contains these examples of Application Profile Discovery (APD):
Linux environments
Windows environments
Proxy servers
Example
4. Click Save.
2. Give the environment file a logical name, such as the name of the application (ResourceNow.xml) and save it to
the /APD directory.
148
Example
149
1. In an XML editor, open the version file template and complete it for the ResourceNow application using the
following values:
Version: Enter the version number for this application. For this example, enter 2.0.
Application: Use the application name that should appear in the CMDB. In this example, the application is
called ResourceNow.
Type: Leave the default as version.
Label: Enter a descriptive name. For this example, enter ResourceNow 2.0.
Description: Describe the purpose of the application briefly. For this example, enter Human Resources
management application.
Ownership: Add the name of an existing group from the Group [sys_user_group] table responsible for
managing this application. For this example, enter Enterprise Applications.
2. Give this file the same name as entered in the environment file as the version target.
In this example, use ResourceNow_version.xml.
Example
5. In the Classification Criteria record, enter name in the Name field.
6. Click Submit.
7. In the Classification Criteria related list, edit the list directly and save the following values:
Operator: Select contains.
Value: Enter ResourceNow.
8. Click Update.
150
Example
Computer CI
The CI Relations Formatter in the host computer CI record displays the relationships of all the business services
(including shared services) that run on the machine.
Application CI
The application CI record is populated with version and environment information and displays the business services
connected to that application in the CI Relations Formatter.
151
Example
152
Example
153
The complete path defined by that variable appears in the address bar.
2. Create an APD folder in the All Users folder for the environment file .
3. In ServiceNow, navigate to Discovery Definition > Properties.
4. Locate the Application discovery location for Windows based systems property
(glide.discovery.application_discovery.windows_location).
5. Using the environment variable, enter the entire path in the Windows file location property, including the APD
folder you just created .
In this example, enter %ALLUSERSPROFILE%\APD, which resolves to C:\Documents and Settings\All
Users\APD on Windows 2003.
6. Click Save.
7. Continue the procedure from Task 3 on this page and copy the completed environment file from that task into the
APD folder you created.
Example
2. On the Linux proxy server, create an APD folder in the default UNIX path: /etc/opt/apd/.
Note: By default, Discovery looks for the environment file in this location on all UNIX machines.
3. Use the template to create an SAP environment file for a Solaris server that does not have Discovery credentials.
system: The namer of the inaccessible computer on which the SAP application is running. For this example,
sol13.lab2 is the name of the Solaris computer with no credentials for Discovery.
application_version_path: Specify the path to the SAP version file on the proxy server. For this example,
enter /etc/opt/apd_version/sap_version.xml. The version file must be on the same computer as the environment
file but in different directories.
154
Customization
Customization
Overview
Application Profile Discovery (APD) enables administrators to define processes and dependencies for applications
that Discovery cannot explore. The base system provides the configuration to discover the relationships of business
services to an application and can be extended to return other data about the application. This example demonstrates
how to add additional data to the environment and version files and display that data in the application record.
For a task-based procedure on setting up and configuring APD to use default parameters, see the Application Profile
Discovery Example page.
Setup Tasks
This customization procedure assumes you have performed the following prerequisite tasks:
Enabled Application Profile Discovery on your instance.
Created environment and version files for your application.
Placed the environment file in a location where the MID Server is configured to search for it.
The tag name is arbitrary. This example uses <custom>, but the tag could also be named <notes>.
155
Customization
3. Create a nested tag inside the custom tag that names the field in the Application [cmdb_ci_appl] table you want to
populate.
This tag name is also arbitrary, but should be descriptive of the field selected. This example uses
<comments>.
4. Add a value to this tag that appears in the Discovery record for this application.
This example provides information about how this application is used in the company.
5. Save the environment file.
The tag name is arbitrary but must not contain any spaces. This example uses <custom>, but this tag could
also be named <tagNumber>.
3. Create a nested tag inside the custom tag that names the field in the Application [cmdb_ci_appl] table you want to
populate.
This tag name must match the name of a field in the Application [cmdb_ci_appl] table. This example uses
<asset_tag>.
4. Add a value for this tag.
This value appears in the appropriate field in the application record.
5. Save the version file.
156
Customization
6.
157
Customization
158
159
Extended Capabilities
DiscoverNow
Overview
DiscoverNow allows an administrator to run a CI Configuration discovery on a single IP address without requiring a
schedule. The platform automatically selects the correct MID Server to use for the discovery if one is associated with
the IP address selected. If no MID Server is configured for the network in which that address appears, the
administrator selects a MID Server. This feature enables an administrator to discover new devices in the network as
soon as they are connected to the network, rather than waiting for a regularly scheduled discovery. DiscoverNow is
available with the Calgary release.
Setup
To configure the system to automatically determine which MID Server to use, set up the IP range capabilities for
each MID Server in your system. Refer to Configuring a MID Server for an IP Address Range for instructions.
Using DiscoverNow
You can run DiscoverNow from a Discovery Schedule form or from a script.
A dialog box appears asking for an IP address and the name of the MID Server to use.
3. Enter the target IP address for a discovery in the Target IP field.
Note: DiscoverNow does not currently support IP network discovery. Make sure you enter a single IP address
only and not an entire network, such as 10.105.37.0/24.
If a MID Server is assigned to the subnet containing the target IP address and currently in an operational status
(Up), the MID Server name appears automatically in the MID Server field. If multiple MID servers are found,
the system selects one for you. The value in the MID Server field can be overwritten if you want to select a
different MID Server.
4. If no MID Server is defined for that network, select one from the list of available MID Servers.
DiscoverNow
160
PowerShell
161
PowerShell
Overview
PowerShell [4] is built on the Windows .NET Framework and is designed to control and automate the administration
of Windows machines and applications. ServiceNow Discovery supports the use of PowerShell to discover Windows
computers. MID Servers using PowerShell must be installed on a supported Windows operating system.
ServiceNow supports PowerShell 2.0.
Note: PowerShell is the preferred method for running Discovery over multiple Windows domains, because it allows a single MID
Server to authenticate on machines on different domains using credentials stored on the instance.
Enhancements
Calgary
The following enhancements are part of the Calgary release.
A new parameter mid.powershell.local_mid_service_credential_fallback specifies the
login credentials the MID Server uses if all other credentials fail. This parameter replaces the parameter
mid.powershell.use_mssqlauth. See MID Server Parameters.
The parameter mid.powershell.path can only discover 64-bit applications running on Windows hosts if
the MID Server is also running on a 64-bit Windows host. See MID Server Parameters.
The parameter mid.powershell.use_mssqlauth is obsolete and was removed from the platform.
Microsoft SQL Server discoveries use the PowerShell probe, which uses the MID Server's credentials. The
PowerShell MSSQL probe was also removed. See MID Server Parameters.
PowerShell
162
Description
PowerShell
credentials
Name(s)
mid.powershell.use_credentials
Details
Determines the credentials to use for Discovery with PowerShell. A setting
of true directs the MID Server to run probes with the Windows credentials
from the credentials table. To run probes with the credentials of the user for
the MID Server service, set this parameter to false.
Enable
mid.use_powershell
PowerShell
for Discovery
Enables PowerShell for Discovery. You must and restart the MID Server
after setting the parameter to true. If PowerShell is not installed or is not at
version 2.0, Discovery reverts to WMIRunner.
PowerShell
executable
path
mid.powershell.path
MID Server
credentials
mid.powershell.local_mid_service_credential_fallback Specifies the login credentials the MID Server uses if all other credentials
fail. This parameter is available with the Calgary release.
Enable or
Disable the
enforcement
of UTF-8 for
command
output
mid.powershell.enforce_utf8
PowerShell
163
Description
GenerateWMIScriptJS
Probe Parameter
A probe parameter called WMI_ActiveConnections.ps1 contains a script that runs netstat.exe on a target machine
for connection information (such as process IDs, ports, IP addresses) when PowerShell is enabled.
Credentials
Discovery uses Windows PowerShell credentials from the ServiceNow Credentials table or the domain administrator
credentials of the MID Server service. If Discovery cannot find PowerShell credentials in the Credentials table (of
the type Windows), it uses the login credentials of the MID Server service (starting with the Calgary Release).
References
[1] http:/ / technet. microsoft. com/ en-us/ scriptcenter/ dd772288
VMware vCenter
164
VMware vCenter
Overview
These options are available for getting VMware vCenter data:
ServiceNow Discovery can run the VMWare - vCenter probe when it identifies a VMware vCenter process
running on a Windows machine.
ServiceNow Orchestration can run the VMWare - vCenter probe from a workflow.
See VMware Component Relationships for a description of the VMware architecture and component relationships.
VMware vCenter
The list of vCenter instances appears. ServiceNow sends you an email confirmation when the scan is
complete.
5. Select the day and time to run this discovery, using the field descriptions from the Discovery Schedules form as a
reference.
6. [Optional] Select the Conditional check box to script a condition that defines a custom run time.
7. Click Submit.
165
VMware vCenter
166
The Discovery vCenter workflow runs in silent mode for this type of discovery and does not send
notifications.
8. Click Execute Now to run this discovery immediately.
Table Name
Column Name
Source
API version
api_version
Full name
fullname
Instance UUID
instance_uuid
URL
url
Effective CPU
effectivecpu
Effective memory
effectivehosts
Number of hosts
numhosts
Total CPU
totalcpu
Total memory
totalmemory
host_morid
folder_morid
Accessible
accessible
Capacity (GB)
capacity
freespace
Type
type
VMware vCenter
167
URL
url
Full path
fullpath
Accessible
accessible
morid
vcenter_uuid
vCenter Reference
vcenter_ref
Folder
folder
Type
type
Relationships
Discovery automatically creates relationships for vCenter components using data from a key class. Subsequent
Discoveries use the same key class to automatically validate and remove relationships that are no longer valid.
Parent Class
Relationship Type
Child Class
Relationship Key
Class
Child
Connected by::Connects
Parent
Provided by::Provides
Parent
Parent
Used by::Uses
Child
Members::Member of
Child
Parent
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
VMware vCenter
168
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Enhancements
Eureka
Automatically validates and updates relationships for vCenter CIs. This process also removes stale relationships.
In addition to the new logic to remove stale relationships, code existed in previous versions to perform the
following tasks:
Remove records in the cmdb_ci_vmware_instance table that are no longer associated to a record in the
cmdb_ci_esx_server table, including the corresponding Registered on::Has registered relationship.
Remove records in the cmdb_ci_computer table that are no longer associated to a record in the
cmdb_ci_esx_server table with a Virtualized by::Virtualizes relationship.
Remove duplicate records in the cmdb_ci_vcenter table that have the same instance_uuid or ip_address fields
as the CI that is currently being discovered.
Calgary
An Orchestration workflow Discover vCenter can populate the CMDB with vCenter data without having to
install the Discovery plugin. See Orchestration Configuration and Workflow.
Hyper-V
Hyper-V
Overview
Microsoft Hyper-V is a virtualization application that is included with the Windows Server 2008 operating system. A
physical machine running Hyper-V is divided into partitions (virtual machines), including a parent partition running
Windows Server 2008 and child partitions running supported guests. The parent partition manages the virtual
machines with the Hyper-V Manager application. On Windows Server 2008 this is done through the Microsoft
Management Console (MMC) service. On Windows 7, use the Remote Server Admin tools.
Hyper-V supports the following functionality:
Failover clustering: Failover is managed with Failover Cluster Manager.
Live migration: Virtual machines can be moved between failover cluster nodes without bringing down the virtual
machine.
ServiceNow Discovery can explore the Microsoft Hyper-V platform running on Windows Server 2008 and return the
following information:
The Hyper-V server running on the host computer
See Hyper-V Component Relationships for a description of the Hyper-V architecture and component relationships.
Hyper-V discovery is available with the Calgary release.
Required Roles
Users with the itil and asset roles can access Hyper-V configuration item (CI) records. To run discovery on Hyper-V
servers, users must have the discovery_admin role.
Credential Requirements
A Hyper-V discovery requires one of the following credentials:
Domain administrator: Discovery can authenticate on Hyper-V without additional credentials.
Enable PowerShell and provide Windows credentials for the Hyper-V server host: Enable PowerShell for
the MID Server used to discover Hyper-V servers and instances. See MID Server Parameters for instructions on
enabling PowerShell.
169
Hyper-V
170
Name
Description
Component
Classifier
Hyper-V Server
Classifies stand-alone Hyper-V servers only (servers not running on Windows 2008).
Probe
Hyper-V - VMs
Exploration probe that extracts the list of virtual machines and their attributes from the Hyper-V server. This
probe determines if Hyper-V is on or off on a Windows Server 2008 machine. This result is used to identify
standalone Hyper-V installations.
Probe
Hyper-V
Exploration probe that queries the Hyper-V server for virtual networks.
Virtual Networks
Probe
Hyper-V Clusters
Virtual Instances
Label
Field Name
Data Description
On
Off
Suspended
Changing
Stuck
Stored in Table
State
state
cmdb_ci_vm_instance
CPUs
cpus
Count
cmdb_ci_vm_instance
Memory
memory
Quantity in MB
cmdb_ci_vm_instance
Network adapters
nics
Count
cmdb_ci_vm_instance
Disks
disks
Count *
cmdb_ci_vm_instance
Disks size
disks_size
Capacity in GB *
cmdb_ci_vm_instance
cmdb_ci_hyper_v_instance
bios_serial
cmdb_ci_hyper_v_instance
chassis_serial
cmdb_ci_hyper_v_instance
BIOS GUID
bios_guid
* Discovery can only return this information if the virtual machine is running.
Hyper-V
171
Virtual Networks
Label
Field Name
Data Description
Stored in Table
Name
name
ID
object_id
cmdb_ci
Resource Pools
Label
Field Name
Data Description
Stored in Table
ID
object_id
cmdb_ci_vm_object
Capacity
capacity
cmdb_ci_hyper_v_resource_pool
resource_type
cmdb_ci_hyper_v_resource_pool
Type of resource discovered (for example, memory, or hard drive space) cmdb_ci_hyper_v_resource_pool
Clusters
Label
Windows
Cluster
Field Name
win_cluster
Data Description
Stored in Table
Reference Table
cmdb_ci_hyper_v_cluster cmdb_ci_win_cluster
Data Migration
When you upgrade an instance to the Calgary release, ServiceNow migrates your virtualization data to a new table
schema and creates a backup table structure to protect existing data. In versions prior to Calgary, records in the
existing Virtual Machine Instance [cmdb_ci_vm_instance] table contain data for VMware virtual machines.
Upgrading to Calgary migrates these records to a new table called VMware Virtual Machine Instance
[cmdb_ci_vmware_instance]. The Virtual Machine Instance [cmdb_ci_vm_instance] table becomes the base class
used for all virtualization platforms: VMware, Amazon EC2, and Hyper-V.
Backup Tables
The upgrade creates the following temporary tables to back up the existing virtual machine instances and associated
references:
temp_backup_cmdb_rel_ci
temp_backup_dictionary
temp_backup_vm_instance
temp_backup_vm_reference
Hyper-V
172
Upgrade Tasks
After creating the backup tables, the upgrade performs the following tasks:
1.
2.
3.
4.
5.
6.
7.
Copies records from the cmdb_ci_vm_instance table to the appropriate temp_backup_vm_instance table.
Backs up affected relationships, references, and dictionary references to the appropriate temp_backup tables.
Deletes the cmdb_ci_vm_instance table.
Creates new cmdb_ci_vmware_instance and cmdb_ci_vm_instance tables.
Copies and maps records from the temp_backup_vm_instance table into the cmdb_ci_vmware_instance table.
Restores relationships and references
Creates a clean-up job in Scheduled Jobs (Schedule Item [sys_trigger] table) called VMware Data Migration
Clean-up that deletes the backup files at a scheduled time three months in the future.
CIM Discovery
CIM Discovery
Overview
CIM probes can explore any device based on the Common Information Model (CIM) by querying a CIM server, also
referred to as a CIMOM - Common Information Model Object Manager. By default, Discovery uses CIM probes to
explore storage systems as well as to get the serial numbers of ESX servers.
Architecture
The following components are part of CIM:
Common Information Model (CIM): CIM [8] allows multiple parties to exchange information about managed
elements. CIM represents these managed elements and the management information, while providing the
mechanism to actively control and manage the elements.
Storage Management Initiative Specification (SMI-S): SMI-S [1] is a standard of use that describes methods for
storage discovery on the vendor's side. ServiceNow uses SMI-S to determine how to discover CIM. SMI-S is
based on the Common Information Model (CIM) and the Web-Based Enterprise Management (WBEM)
standards, which define management functionality via HTTP. The main objective of SMI-S is to enable
management of dissimilar storage products. ServiceNow supports SMI-S version 1.5 or higher.
Web-Based Enterprise Management (WBEM): WBEM [7] defines a particular implementation of CIM,
including protocols for discovering and accessing each CIM implementation.
Service Location Protocol (SLP): SLP [2] is an ad hoc protocol for retrieving and associating configuration
information about CIM servers, such as default paths, capabilities, and the exact interop namespace [3].
ServiceNow Discovery retrieves the interop namespace of a CIM server via SLP and passes that information to
the CIM Classify probe. SLP, referred to here as the SLP server, uses service agents (SA) to gather and
disseminate information about a CIM server on a subnet. A subnet can have multiple service agents.
173
CIM Discovery
174
CIM Discovery
SLP Query
The SLP query detects the wbem service (service:wbem) on an SLP server and gathers the attributes of the service.
175
CIM Discovery
176
CIM Discovery
177
Enhancements
Eureka
Provides more efficient querying of SMI-S compliant storage devices using CimIQL queries.
References
[1] http:/ / www. snia. org/ tech_activities/ standards/ curr_standards/ smi
[2] http:/ / en. wikipedia. org/ wiki/ Service_Location_Protocol
[3] http:/ / sfdoccentral. symantec. com/ ccstor/ 5. 1. 1/ win_unix/ html/ cc_hscg/ apas01. htm
Viewing Relationships
By default, a CI record for a server (node) hosting an SQL Server instance that is part of a cluster does not display
the instance or the cluster as related items. To see the cluster information on a CI record, personalize the form and
add the Cluster Nodes related list. This list displays the name of the node and the parent cluster.
Click the cluster in the related list to drill into the CI record for that cluster. Individual SQL Server instances running
on that cluster are listed in the Related Items hierarchy. The names in the list contain the instance name prepended
to the cluster name with the @ symbol. In this example, DISCO is the instance name, and cluster2003 is the name
of the SQL Server cluster.
178
The CI record for an individual SQL Server instance uses the combined instance/cluster name and displays the
relationship hierarchy to the configured number of levels, including the application that uses the instance and the
cluster on which the application runs.
179
180
In the CI for an application that Depends on an SQL Server instance, the Related Items hierarchy also displays all
downstream relationships, including the instance on which the application depends, the cluster on which the instance
runs, and the server on which the application runs.
Description
resourceType Resource type the platform should look for in the cluster's Windows Cluster Resources related list.
isMatch
Determines if the cluster resource that is found, based on the type, is a match for the classified process being examined.
181
182
Discovery Behavior
Discovery Behavior
Overview
A Discovery Behavior determines what probes Shazzam launches and from which MID Servers these probes are
launched. Unlike a scan in which a single MID Server that performs all protocol scans on a designated IP address
range, network, or list, a behavior can assign different tasks to multiple MID Servers on the same IP address segment
or on different network segments. Behaviors are available in Discovery Schedules for discoveries in which
configuration items (CI) are updated in the CMDB.
Behaviors can be used in the following scenarios:
Load balancing: A behavior enables load balancing in systems that use multiple MID Servers deployed across
one or more domains.
Multiple protocols in multiple domains: Configure one MID Server to scan for all protocols on one domain and
another MID Server to perform a WMI scan on a second domain.
Access Control Lists (ACL): Discovery can scan SNMP devices protected by an ACL if the MID Server host
machine is granted access by that ACL. Use a behavior to configure a MID Server to scan devices protected by an
ACL.
Devices running two protocols: Some devices might have two protocols running at the same time. Examples of
this are the SSH and SNMP protocols running concurrently on one device (most common). A behavior can
control which of the two protocols is explored for certain devices. The behavior then prevents the other protocol
from being explored.
Creating a Behavior
To create a behavior, navigate to Discovery Definition > Behavior and click 'New. The Behavior form provides the
following unique fields:
Field
Input Value
Name
Type a unique name that describes the use for this behavior, such as Two Domains or Load Balance.
Discovery
Functionality
Select the MID Servers to use for this behavior, the desired execution phase, and the pre-configured functionality for each
MID Server (protocols to scan).
Discovery Behavior
183
Discovery Functionality
Discovery Functionality defines what each MID Server in this behavior must do, specifically which protocols to
detect. This form provides the following unique fields:
Field
Input Value
Phase
A phase is an arbitrary integer used to group one or more functionalities together. All the functionalities within a phase are
executed together, and all phases are executed in numerical order. All functionalities in a behavior can have the same phase. The
Shazzam probe runs once for each phase in a behavior, which makes fewer phases desirable. Run multiple phases for behaviors
only when devices in the network are running multiple protocols (e.g. SSH and SNMP). In this example, set one phase for the SSH
scan and another phase for the SNMP scan.
Functionality
Select a pre-configured functionality that defines the protocol or list of protocols that each MID Server will scan. Access the
Functionality Definition records through the Functionality link in the Discovery Behavior form or by navigating to Discovery
Definitions > Functionality Definition.
MID Servers
Select one or more MID Servers to perform this functionality for the following Discovery types:
IP Scan
CI Scan
Discovery automatically balances the load when multiple MID Servers are selected.
Functionality
Criteria
Define criteria here for Windows MID Servers. See the following section for details.
Functionality Criteria
Functionality Criteria are required for Windows MID Servers only, and only when the behavior controls Discovery
across multiple domains. When the instance launches the Shazzam probe for a Discovery in which a behavior
defines multiple MID Servers to scan multiple domains, the Functionality Criteria determine which MID Server will
process the results of the probe.
The form provides the following unique fields:
Field Input Value
Name The name in the criteria is the variable that passes the following information:
mid_server: MID Server that processes the results from the Shazzam probe.
win_domain: Windows domain of the target device.
Value Enter the actual name of the MID Server (mid_server) or domain (win_domain) to pass to Discovery for this criteria. This field can also
have a value of mid_domain, which defines the Windows domain of the MID Server that is processing the Shazzam results.
Input Value
Phase
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
Match
criteria
184
Input Value
Name
We enter win_domain to name the Windows domain that Discovery will scan with the MID Servers we have defined.
This is the name of the Windows domain that these MID Servers will scan for devices.
Active
The completed criteria appear in the Discovery Functionality form for the Windows MID Servers.
Input Value
Phase
Type a phase number of 1 in this field. This phase will be executed at the same time as the WMI scans and with the same Shazzam
probe. We use the same phase number for efficiency and because we know that none of the devices in the target IP ranges are
running multiple protocols (e.g. SSH and SNMP). If any devices were running multiple protocols, we would want to specify a
second or even a third phase to discover the correct protocol first for each device.
Functionality Select All except windows (no WMI) from the list. This functionality causes the MID Server to scan all remaining protocols after
Discovery has run the WMI scans.
MID Servers Name the MID Server that will scan for all other devices. If we want to use automatic load balancing, we can add an additional MID
Server to this field.
The completed Discovery Behavior form looks like this. It is not necessary to create Functionality Criteria for this
MID Server.
185
186
187
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
Active
Match
criteria
188
Field
Input Value
Name
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.
For the mid_server value, enter the name of the MID Server that will scan Domain A for Windows devices.
For the win_domain value, enter the name of Domain A that this MID Server will scan for Windows devices.
Active
The completed criteria appear in the Discovery Functionality form for this behavior.
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 All except Windows (no WMI) from the list. This functionality will scan SSH and SNMP protocols only.
MID Servers
Active
Match
criteria
Leave the default criteria of Any. Criteria are not used for non-WMI functionalities.
189
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
Active
Match
criteria
Input Value
Name
Enter mid_server to name the MID Server that will execute the WMI scans on Domain B.
Enter win_domain to name the Windows domain that Discovery will scan with the MID Server defined.
For the mid_server value, enter the name of the MID Server that will scan Domain B for Windows devices.
For the win_domain value, enter the name of Domain B that this MID Server will scan for Windows devices.
Active
The completed criteria appear in the Discovery Functionality form for this behavior.
190
191
192
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
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 SNMP only from the list. This functionality defines the protocol that will be scanned.
MID Servers
We select a MID Server (sansol02_Solaris) installed on a Solaris host that is granted access to the SNMP devices by the ACL. You
can select multiple MID Servers if you want Discovery to load balance this functionality automatically.
Active
Match
criteria
Leave the default criteria of Any. Criteria are not used for SNMP functionalities.
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 protocol scans. A single phase, when feasible, is the most efficient use of the Shazzam probe.
Functionality Select All except SNMP from the list. This functionality defines the protocols for which scanning will occur. Because WMI is one
of the protocols selected, we must use a Windows MID Server for this functionality.
MID Servers
We select a Windows MID Server from our domain. In this case we select disco-win2003. You can select multiple MID Servers if
you want Discovery to load balance this functionality automatically.
Active
Match
criteria
193
Input Value
Name
Enter mid_server to name the MID Server that will execute the WMI scans.
Enter win_domain to name the Windows domain that Discovery will scan with the MID Server defined.
For the mid_server value, enter the name of the MID Server that will scan our domain for Windows devices.
For the win_domain value, enter the name of our Windows domain.
Active
The completed criteria appear as follows in the Discovery Functionality form for this behavior.
194
195
196
FAQ
Discovery FAQ
General Topics
What technologies are used for Discovery?
Discovery is deployed in an agentless framework and uses Internet Protocols to probe the network.
Discovery FAQ
What will you discover about Web Servers with specific credentials?
The applications installed and the database connections used.
197
Discovery FAQ
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.
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.
198
Discovery FAQ
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 are the resource requirements (network and CPU) during the discovery?
Resource consumption is remarkably low, see MID Server Requirements for details.
Security
How are the credentials secured?
They are stored in the database using 3DES encryption.
199
Discovery FAQ
Can you integrate with other CMDB technologies such as Atrium or AssetCenter?
Yes. This is something we do very well. Through web services, bi-directional integration can be created. We also
have standard integrations to many other popular systems such as HP OpenView, HP / Mercury MAM, IBM Tivoli,
Microsoft SMS, LanDesk, Oracle Financials, Altiris.
200
201
Reference
Discovery Bandwidth
Functionality described here requires the Discovery plugin.
Overview
The graph is in Bytes per second. It had a capture filter of (MIDservicenow01 or MIDservicenow02).
The Black line is the traffic to the Bluecoat, i.e ServiceNow.
The Red line represents New York.
The Green line represents L.A.
The traffic appears to be as follows - idle scanning for a site: typically not more than 320Kb/second (about 20 to
40KB/sec max), spiking very briefly to 1.6Mb/sec.
Bluecoat traffic for these servers looks to be 480Kb/sec.
UNIX - SSH
Typical SSH network traffic sizes are around 6k (kilobytes) plus commands being executed
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:
To get the base information from a Linux host, it uses about 82k of traffic per Discovery of the host.
202
203
Requirements
Your instance must meet the following requirements to use application dependency mapping.
ADM system properties are enabled
ADM probes are configured
Process classifications are configured
System Properties
Property
Description
glide.discovery.auto_adm
Type: string
Default value: true
Location: Add to the System Properties [sys_properties] table
Automatically creates process classifiers for application dependency mapping. When Discovery detects
processes that are communicating over the network, "Pending Process" classifiers are automatically
generated.
Type: string
Default value: false
Location: Add to the System Properties [sys_properties] table
204
ADM Probes
ADM uses the following probes (starting with the Dublin release).
Name
AIX ADM
Probe
Type
Multiprobe
Description
Queries for information about active (running) AIX processes and active connections - the
information required to perform application dependency mapping.
Includes Probes
HP-UX ADM
Solaris ADM
Unix ADM
Multiprobe
Multiprobe
Multiprobe
Queries for information about active (running) HP-UX processes and active connections - the
information required to perform application dependency mapping. This probe requires that lsof
be installed and the Unix - Active Connections probe be activated, which is inactive by default.
Queries for information about active (running) Solaris processes and active connections - the
information required to perform application dependency mapping. This probe requires that lsof
be installed.
Queries for information about active (running) Unix processes and active connections - the
information required to perform application dependency mapping.
Windows ADM
Multiprobe
Queries for information about active (running) Windows processes and active connections - the
information required to perform application dependency mapping.
Probe
Probe
Probe
ADM Sensors
ADM uses the following sensors (starting with the Dublin release).
AIX - Active
Connections
AIX - Active
Processes
Unix - Active
Connections
HP-UX - Active
Processes
Unix - Active
Connections
Solaris - Active
Processes
Unix - Active
Connections
Unix - Active
Processes
Windows - Active
Connections
Windows - Active
Processes
Name
AIX - ADM
Sensor
Type
Javascript
205
Description
Responds to Probes
Updates the running processes and active connections, and runs application dependency
mapping.
HP-UX ADM
Javascript
Updates the running HP-UX processes and active connections, and runs application
dependency mapping. This sensor requires that lsof be installed.
Solaris ADM
Javascript
Updates the running Solaris processes and active connections, and runs application
dependency mapping. This sensor requires that lsof be installed.
Unix - ADM
Javascript
Updates the running Unix processes and active connections, and runs application
dependency mapping.
Windows ADM
Javascript
Updates the running Windows processes and active connections, and runs application
dependency mapping.
Unix - Active
Connections
AIX - Active
Processes
Unix - Active
Connections
HP-UX - Active
Processes
Unix - Active
Connections
Solaris - Active
Processes
Unix - Active
Connections
Unix - Active
Processes
Windows - Active
Connections
Windows - Active
Processes
Javascript
Javascript
Javascript
Application Relationships
Discovery maps application data automatically into upstream and downstream relationships, using the following
types:
Runs on::Runs
Depends on::Used by
Hosted on::Hosts
Virtualized by::Virtualizes
Contains::Contained by
IP Connection::IP Connection
Note: For information on how Discovery classifies processes and establishes relationship types, see Process Classifications.
4. In the dependency map that appears, right-click on the arrow connectors between CIs to display the relationship
type.
206
Deleting CIs
When you delete a CI from the CMDB, ServiceNow also deletes all relationships with that CI. The cascade delete
feature that deleted upstream CIs was removed from the system starting with the Calgary release.
If the virtual server sannnm-01 is deleted, then so are the upstream CIs that have a one-to-one relationship with the
server. In our example, the MySQL instance, the web server and the SQL instance are all deleted, as is the web site
hosted by the web server.
207
Application Dependencies
This screenshot shows the application dependencies between three different JBoss application servers and the local
Apache web site. In this example, the three JBoss application servers on three different physical machines have a
TCP connection to the local Apache application on www.online1.com. Additionally, there are 5 Apache web servers
using the local JBoss application.
Adding CI Relationships
Discovery automatically maps the dependencies between CIs that it finds in the network and assigns the appropriate
type to each relationship. ServiceNow configuration enables administrators to add dependencies manually and to
define the appropriate relationship type between new configuration items based on lists of suggested relationships.
The best practice when adding application dependencies to a configuration item is to avoid the use of the Runs
on/Runs and Hosted on/Hosts types. When a configuration item is deleted, any upstream CIs with a relationship
type of Runs on or Hosted on is deleted as well. In some cases, manually added CIs might have other important
dependencies that are adversely affected by the cascade deletion triggered by these two relationship types.
To add a dependency:
1. In a CI record, click the + icon in the Related Items toolbar.
2. Select the appropriate relationship type from the list at the top of the page.
208
3. Create and run an appropriate filter to make the CI visible in the list of available CIs.
4. Move the CI from the list of available CIs to the dependent list.
5. Click Apply to.
Example
An example of the importance of selecting the proper relationship type is when the Business Service dependency,
PeopleSoft CRM, is added to the sannnm-01 virtual server in the following diagram. If PeopleSoft CRM is added
with a relationship type of Depends on, it is protected from the cascade delete triggered by the deletion of the
Windows server sannnm-01. This is important because PeopleSoft CRM has dependencies to other servers and must
not be deleted.
209
210
process
follows
these
naming
The name includes the name of the host running the process ater the
at (@) symbol.
211
Pending process classifiers are available starting with the Dublin release.
212
Deleting Application
Instances
Deleting application instances deletes
all application records that reference
the given classifier. The classifier is
also deleted. To delete the application
instance:
1. Under Related Links, click Delete
application instance.
2. Click Yes in the Confirm popup
box.
Create new table using the Application Instance table
Creating Pending
Processes Classifiers for
Local Connections
213
to a port on the local host and another process B listening on the same port of the same local host, these two
processes are considered a local connection.
To have Discovery create pending process classifiers for local connections:
1. Navigate to Discovery > Properties.
2. For Map local connections for pending process classifier, select Yes.
3. Click Save.
Note: This property only affects pending process classifiers. Discovery always applies existing process classifications if their
triggering conditions are met.
Enhancements
Eureka
Allows Discovery administrators the option to create pending process classifiers for processes communicating on
the same host.
Dublin
Creates pending process classifiers for processes found connecting to and listening on communications ports.
Uses new probes and sensors to explore applications and determine their relationships.
Displays relationships for automatically classified applications in the application dependency map.
References
[1] http:/ / technet. microsoft. com/ en-us/ library/ bb490947. aspx
[2] http:/ / support. microsoft. com/ hotfix/ KBHotfix. aspx?kbnum=907980& kbln=en-us
VMware Architecture
ServiceNow supports two basic types of VMware deployment using the VMware application:
VMware installed on an ESX Server, managed by vCenter.
VMware installed on a Windows or Linux host machine, not managed by vCenter.
ServiceNow Discovery can extract information from all the components in a VMware system, including vCenter.
Discovery creates records in the CMDB for vCenter, the host machine and all the virtual machines running on that
server. Discovery finds the stored templates and maps all the relationships between components. In networks that use
Orchestration to create and manage virtual servers, Discovery populates records automatically and detects changes in
the network. Without Discovery, all the records for Orchestration VMware Support must be created and updated
manually, including the relationships between VMware components.
vCenter Cloning
The vCenter management console can control multiple ESX Server machines, each of which is capable of hosting
multiple virtual servers cloned from stored templates. The relationships between VMware components for this type
of installation are shown in the following diagram:
214
Relationships
The components in a system managed by vCenter have the following relationships:
VCenter: Manages one or more ESX Servers
ESX Server:
Managed by vCenter
Gets resources from the Resource Pool
Has registered VMware instances
Virtualizes virtual machines.
Resource Pool: Defines resources for the ESX Server. See Resource Pools for more information.
VM Instances (including images and templates):
Registers on the ESX Server
Instantiates individual virtual machines.
Virtual machines:
Instantiated by VM instances (images and templates)
Virtualized by ESX Server
215
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
216
217
Hyper-V Architecture
ServiceNow stores Hyper-V configuration items (CI) in these tables:
Table
Purpose
Contains data about the physical machine running the Hyper-V server. This table has a
reference relationship with the existing Windows Server [cmdb_ci_win_server] table.
Contains data about Hyper-V clusters. This table has a reference relationship with the existing
Windows Cluster [cmdb_ci_win_cluster] table.
ServiceNow modifies these tables for use with multiple virtualization products:
Table
Purpose
Virtualization Server
[cmdb_ci_virtualization_server]
Contains data about various objects associated with a Hyper-V server, such as partitions,
networks, resource pools, and clusters.
218
Relationship
Child table
Instantiates::Instantiated by
Computer [cmdb_ci_computer]
Provided By::Provides
Hyper-V Network
[cmdb_ci_hyper_v_network]
Connected by::Connects to
Hyper-V Network
[cmdb_ci_hyper_v_network]
Members::Members of
219
Windows NT Server
Windows 2000 Server
Windows 2003 Server
Windows 2008 Server
Windows 2012 Server
Windows XP
Windows Vista
Windows 7
Windows 8
You may need to set Windows permissions on the systems you want to discover.
Table Name
Field Name
Source
Operating System
cmdb_ci_computer
os
wmi
OS version
cmdb_ci_computer
os_version
wmi
OS service pack
cmdb_ci_computer
os_service_pack
wmi
Name
cmdb_ci_win_server
name
DNS, NBT
Hostname
cmdb_ci_win_server
host_name
DNS, NBT
DNS domain
cmdb_ci_win_server
dns_domain
DNS
OS domain
cmdb_ci_computer
os_domain
NBT
Assigned to
cmdb_ci_win_server
assigned_to
wmi
Department
cmdb_ci_win_server
department
Internal (User)
Short description
cmdb_ci_win_server
short_description
wmi
Manufacturer
cmdb_ci_win_server
manufacturer
wmi
Serial number
cmdb_ci_win_server
serial_number
wmi
CPU name
cmdb_ci_computer
cpu_name
wmi
CPU manufacturer
cmdb_ci_computer
cpu_manufacturer
wmi
cmdb_ci_computer
cpu_speed
wmi
CPU count *
cmdb_ci_computer
cpu_count
wmi
cmdb_ci_computer
cpu_core_count
wmi
Windows
220
CPU core thread * (Calgary release) cmdb_ci_computer
cpu_core_thread
wmi
Model ID
cmdb_ci
model_id
wmi
RAM (MB)
cmdb_ci_computer
ram
wmi
cmdb_ci_computer
disk_space
wmi
Type
cmdb_ci_disk
type
wmi
Description
cmdb_ci_disk
short_description
wmi
cmdb_ci_disk
disk_space
wmi
cmdb_ci_disk
free_space
wmi
Name
cmdb_ci_disk
name
wmi
cmdb_ci_disk
volume_serial_number wmi
Name
cmdb_running_process
name
wmi
Command
cmdb_running_process
command
wmi
Connects to
cmdb_running_process
connects_to
wmi
Listening on
cmdb_running_process
listening_on
wmi
Type
cmdb_running_process
type
wmi
PID
cmdb_running_process
pid
wmi
Parameters
cmdb_running_process
parameters
wmi
Name
cmdb_ci_network_adapter name
wmi
IP address
cmdb_ci_network_adapter ip_address
wmi
MAC address
cmdb_ci_network_adapter mac_address
wmi
Netmask
cmdb_ci_network_adapter netmask
wmi
DHCP enabled
cmdb_ci_network_adapter dhcp_enabled
wmi
Vendor
cmdb_ci_network_adapter vendor
wmi
cmdb_ci_hardware
wmi
default_gateway
* Core counts and threads per core might not be accurate, due to issues with Microsoft reporting. See http:/ / msdn.
microsoft.com/en-us/library/windows/desktop/aa394373(v=vs.85).aspx [1] for details.
Windows
221
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_win_server
os
wmi
OS version
cmdb_ci_win_server
os_version
wmi
OS service pack
cmdb_ci_win_server
os_service_pack
wmi
Name
cmdb_ci_win_server
name
DNS, NBT
Hostname
cmdb_ci_win_server
host_name
DNS, NBT
DNS domain
cmdb_ci_win_server
dns_domain
DNS
OS domain
cmdb_ci_win_server
os_domain
NBT
Assigned to
cmdb_ci_win_server
assigned_to
wmi
Department
cmdb_ci_win_server
department
Internal (User)
Short description
cmdb_ci_win_server
short_description
wmi
Manufacturer
cmdb_ci_win_server
manufacturer
wmi
Serial number
cmdb_ci_win_server
serial_number
wmi
CPU name
cmdb_ci_computer
cpu_name
wmi
CPU manufacturer
cmdb_ci_computer
cpu_manufacturer
wmi
cmdb_ci_computer
cpu_speed
wmi
CPU count *
cmdb_ci_computer
cpu_count
wmi
cmdb_ci_computer
cpu_core_count
wmi
cpu_core_thread
wmi
Model ID
cmdb_ci
model_id
wmi
RAM (MB)
cmdb_ci_computer
ram
wmi
cmdb_ci_computer
disk_space
wmi
Type
cmdb_ci_disk
type
wmi
Description
cmdb_ci_disk
short_description
wmi
cmdb_ci_disk
disk_space
wmi
cmdb_ci_disk
free_space
wmi
Name
cmdb_ci_disk
name
wmi
cmdb_ci_disk
volume_serial_number wmi
Name
cmdb_running_process
name
wmi
Command
cmdb_running_process
command
wmi
Type
cmdb_running_process
type
wmi
PID
cmdb_running_process
pid
wmi
Parameters
cmdb_running_process
parameters
wmi
Name
cmdb_ci_network_adapter name
wmi
IP address
cmdb_ci_network_adapter ip_address
wmi
MAC address
cmdb_ci_network_adapter mac_address
wmi
Netmask
cmdb_ci_network_adapter netmask
wmi
DHCP enabled
cmdb_ci_network_adapter dhcp_enabled
wmi
Vendor
cmdb_ci_network_adapter vendor
wmi
Windows
222
Default gateway (Calgary release)
cmdb_ci_hardware
default_gateway
wmi
* Core counts and threads per core might not be accurate, due to issues with Microsoft reporting. See http:/ / msdn.
microsoft.com/en-us/library/windows/desktop/aa394373(v=vs.85).aspx [1] for details.
Enhancements
Dublin
The Running Processes [cmdb_running_process] table contains new fields to track the list of TCP ports a process
listens on (listening_on) and connects to (connects_to).
References
[1] http:/ / msdn. microsoft. com/ en-us/ library/ windows/ desktop/ aa394373(v=vs. 85). aspx
Solaris
Discoverable Solaris Operating Systems
Discovery can classify and discover Solaris servers and workstations that use the following operating systems:
Oracle Solaris 10
Oracle Solaris 11
You must provide SSH credentials for the systems you want to discover.
Table
Field Name
Source
Operating System
cmdb_ci_computer
os
uname
Short description
cmdb_ci_solaris_server
short_description
uname
Name
cmdb_ci_solaris_server
name
DNS, NBT
Hostname
cmdb_ci_solaris_server
host_name
DNS, NBT
DNS domain
cmdb_ci_solaris_server
dns_domain
DNS
Start date
cmdb_ci_solaris_server
start_date
uptime
CPU type
cmdb_ci_computer
cpu_type
kstat
cmdb_ci_computer
cpu_speed
kstat
CPU count
cmdb_ci_computer
cpu_count
kstat
cmdb_ci_computer
cpu_core_count
kstat
cpu_core_thread
kstat
Model number
cmdb_ci_solaris_server
model_number
suntype
Model ID
cmdb_ci_solaris_server
model_id
suntype
RAM (MB)
cmdb_ci_computer
ram
prtconf
Solaris
223
Disk space (GB)
cmdb_ci_solaris_server
disk_space
iostat
Serial Number
cmdb_ci_solaris_server
serial_number
sneep
Manufacturer
cmdb_ci_disk
manufacturer
iostat
Model ID
cmdb_ci_disk
model_id
iostat
cmdb_ci_disk
volume_serial_number iostat
cmdb_ci_disk
disk_space
iostat
Name
cmdb_ci_disk
name
iostat
Name
cmdb_ci_file_system
name
df
Capacity (MB
cmdb_ci_file_system
capacity
df
cmdb_ci_file_system
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
showrev
Name
cmdb_running_process
name
ps
Command
cmdb_running_process
command
ps
Connects to
cmdb_running_process
connects_to
lsof
Listening on
cmdb_running_process
listening_on
lsof
Type
cmdb_running_process
type
ps
PID
cmdb_running_process
pid
ps
Parameters
cmdb_running_process
parameters
ps
Name
cmdb_ci_network_adapter name
ifconfig
IP address
cmdb_ci_network_adapter ip_address
ifconfig
MAC address
cmdb_ci_network_adapter mac_address
ifconfig
Netmask
cmdb_ci_network_adapter netmask
ifconfig
default_gateway
netstat
Label
Table
Field Name
Source
Operating System
cmdb_ci_solaris_server
os
uname
Short description
cmdb_ci_solaris_server
short_description
uname
Name
cmdb_ci_solaris_server
name
DNS, NBT
Hostname
cmdb_ci_solaris_server
host_name
DNS, NBT
DNS domain
cmdb_ci_solaris_server
dns_domain
DNS
Start date
cmdb_ci_solaris_server
start_date
uptime
CPU type
cmdb_ci_solaris_server
cpu_type
kstat
cmdb_ci_solaris_server
cpu_speed
kstat
CPU count
cmdb_ci_solaris_server
cpu_count
kstat
Solaris
224
CPU core count
cmdb_ci_computer
cpu_core_count
kstat
cpu_core_thread
kstat
Model number
cmdb_ci_solaris_server
model_number
suntype
Model ID
cmdb_ci_solaris_server
model_id
suntype
RAM (MB)
cmdb_ci_solaris_server
ram
prtconf
cmdb_ci_solaris_server
disk_space
iostat
Serial Number
cmdb_ci_solaris_server
serial_number
sneep
Manufacturer
cmdb_ci_disk
manufacturer
iostat
Model ID
cmdb_ci_disk
model_id
iostat
cmdb_ci_disk
volume_serial_number iostat
cmdb_ci_disk
disk_space
iostat
Name
cmdb_ci_disk
name
iostat
Name
cmdb_ci_file_system
name
df
Capacity (MB
cmdb_ci_file_system
capacity
df
cmdb_ci_file_system
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
showrev
Name
cmdb_running_process
name
ps
Command
cmdb_running_process
command
ps
Type
cmdb_running_process
type
ps
PID
cmdb_running_process
pid
ps
Parameters
cmdb_running_process
parameters
ps
Name
cmdb_ci_network_adapter name
ifconfig
IP address
cmdb_ci_network_adapter ip_address
ifconfig
MAC address
cmdb_ci_network_adapter mac_address
ifconfig
Netmask
cmdb_ci_network_adapter netmask
ifconfig
default_gateway
netstat
Enhancements
Dublin
The Running Processes [cmdb_running_process] table contains new fields to track the list of TCP ports a process
listens on (listening_on) and connects to (connects_to).
Linux
225
Linux
Data Collected by the SSH probe or Linux - Identity multiprobes on Linux Computers
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_linux_server
os
uname
OS Version
cmdb_ci_computer
os_version
Short description
cmdb_ci_linux_server
short_description
uname
Name
cmdb_ci_linux_server
name
DNS, NBT
Hostname
cmdb_ci_linux_server
host_name
DNS, NBT
DNS domain
cmdb_ci_linux_server
dns_domain
DNS
Start date
cmdb_ci_linux_server
start_date
uptime
Manufacturer
cmdb_ci_computer
manufacturer
dmidecode
Serial number
cmdb_ci_computer
serial_number
dmidecode
CPU type
cmdb_ci_linux_server
cpu_type
/proc/cpuinfo
cmdb_ci_linux_server
cpu_speed
/proc/cpuinfo
CPU count
cmdb_ci_linux_server
cpu_count
/proc/cpuinfo
cmdb_ci_computer
cpu_core_count
/proc/cpuinfo
cpu_core_thread
/proc/cpuinfo
CPU manufacturer
cmdb_ci_linux_server
cpu_manufacturer /proc/cpuinfo
Model number
cmdb_ci_computer
model_number
dmidecode
Model ID
cmdb_ci_computer
model_id
dmidecode
RAM (MB)
cmdb_ci_linux_server
ram
meminfo
cmdb_ci_linux_server
disk_space
Type
cmdb_ci_disk
type
Model ID
cmdb_ci_disk
model_id
cmdb_ci_disk
disk_space
Name
cmdb_ci_disk
name
Name
cmdb_ci_file_system
name
df
Capacity (MB)
cmdb_ci_file_system
capacity
df
cmdb_ci_file_system
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_running_process
name
ps
Command
cmdb_running_process
command
ps
Type
cmdb_running_process
type
ps
PID
cmdb_running_process
pid
ps
Parameters
cmdb_running_process
parameters
ps
Name
cmdb_ci_network_adapter name
ifconfig
IP address
cmdb_ci_network_adapter ip_address
ifconfig
Linux
226
MAC address
cmdb_ci_network_adapter mac_address
ifconfig
Netmask
cmdb_ci_network_adapter netmask
ifconfig
default_gateway
route
Extends
cmdb_ci_vm
Description
Source
A hypervisor that manages kernel-based Process classifier detects libvirtd running on Linux
virtual machines (KVMs)
servers
cmdb_ci_kvm_object
cmdb_ci_vm_object
cmdb_kvm_device
N/A
A device connected to a virtual machine <devices> element from the dumpxml command
instance
Table Name
Field Name
Source
Linux Host
cmdb_ci_kvm
linux_host
Details
cmdb_ci_kvm
details_xml
dumpxml
Object ID
cmdb_ci_kvm_vm_instance object_id
virsh dumpxml
State
cmdb_ci_kvm_vm_instance state
CPUs
cmdb_ci_kvm_vm_instance cpus
virsh dumpxml
Memory
cmdb_ci_kvm_vm_instance memory
virsh dumpxml
Disks
cmdb_ci_kvm_vm_instance disks
virsh dumpxml
Disks size
cmdb_ci_kvm_vm_instance disks_size
virsh domblkinfo
227
virsh dumpxml
Name
virsh dumpxml
cmdb_ci_kvm_vm_instance name
cmdb_ci_kvm_object
details_xml
KVM instance
cmdb_kvm_device
kvm_instance
Reference to cmdb_ci_kvm_instance
Device
cmdb_kvm_device
device
Type
cmdb_kvm_device
type
depends on device
Details
cmdb_kvm_device
details_xml
KVM Relationships
Discovery collects the following relationship data.
Relationship
Parent Table
Child Table
KVM [cmdb_ci_kvm]
Provided By::Provides
KVM [cmdb_ci_kvm]
Network [cmdb_ci_kvm_network]
KVM [cmdb_ci_kvm]
Connected By::Connects
Network [cmdb_ci_kvm_network]
Instantiated By::Instantiates
Computer [cmdb_ci_computer]
Virtualized By::Virtualizes
Computer [cmdb_ci_computer]
KVM [cmdb_ci_kvm]
HPUX
228
HPUX
Data Collected by Discovery on HPUX Computers
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_hpux_server
os
uname
Short description
cmdb_ci_hpux_server
short_description uname
Name
cmdb_ci_hpux_server
name
DNS, NBT
Hostname
cmdb_ci_hpux_server
host_name
DNS, NBT
DNS domain
cmdb_ci_hpux_server
dns_domain
DNS
Start date
cmdb_ci_hpux_server
start_date
uptime
Manufacturer
cmdb_ci_computer
manufacturer
dmidecode
Serial number
cmdb_ci_hpux_server
serial_number
uname
CPU type
cmdb_ci_hpux_server
cpu_type
cpuinfo
cmdb_ci_hpux_server
cpu_speed
adb
CPU count
cmdb_ci_hpux_server
cpu_count
cpuinfo
Model ID
cmdb_ci_hpux_server
model_id
model
RAM (MB)
cmdb_ci_hpux_server
ram
adb
Name
cmdb_ci_file_system
name
df
Capacity (MB)
cmdb_ci_file_system
capacity
df
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
swlist
Name
cmdb_running_process
name
ps
Command
cmdb_running_process
command
ps
Type
cmdb_running_process
type
ps
PID
cmdb_running_process
pid
ps
Parameters
cmdb_running_process
parameters
ps
Name
cmdb_ci_network_adapter name
hifconfig
IP address
cmdb_ci_network_adapter ip_address
hifconfig
MAC address
cmdb_ci_network_adapter mac_address
hifconfig
Netmask
cmdb_ci_network_adapter netmask
hifconfig
AIX
229
AIX
Tables and Fields
Discovery stores information about AIX computers in the following tables and fields.
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_computer
os
uname
OS version
cmdb_ci_computer
os_version
oslevel
OS service pack
cmdb_ci_computer
os_service_pack
oslevel
Short description
cmdb_ci_aix_server
short_description uname
Name
cmdb_ci_aix_server
name
DNS, NBT
Hostname
cmdb_ci_aix_server
host_name
DNS, NBT
DNS domain
cmdb_ci_aix_server
dns_domain
DNS
Start date
cmdb_ci_aix_server
start_date
uptime
CPU type
cmdb_ci_computer
cpu_type
lsdev, lsattr
cmdb_ci_computer
cpu_speed
lsdev, lsattr
CPU count
cmdb_ci_computer
cpu_count
lsdev, lsattr
Manufacturer
cmdb_ci_aix_server
manufacturer
lsattr
Model ID
cmdb_ci_aix_server
model_id
lsattr
RAM (MB)
cmdb_ci_computer
ram
lsdev, lsattr
Name
cmdb_ci_file_system
name
df
Capacity (MB)
cmdb_ci_file_system
capacity
df
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
instfix
Name
cmdb_running_process
name
ps
Command
cmdb_running_process
command
ps
Connects to
cmdb_running_process
connects_to
lsof
Listening on
cmdb_running_process
listening_on
lsof
Type
cmdb_running_process
type
ps
PID
cmdb_running_process
pid
ps
Parameters
cmdb_running_process
parameters
ps
Name
cmdb_ci_network_adapter name
ifconfig, netstat
IP address
cmdb_ci_network_adapter ip_address
ifconfig, netstat
MAC address
cmdb_ci_network_adapter mac_address
ifconfig, netstat
Netmask
cmdb_ci_network_adapter netmask
ifconfig, netstat
AIX
230
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_aix_server
os
uname
OS version
cmdb_ci_aix_server
os_version
oslevel
OS service pack
cmdb_ci_aix_server
os_service_pack
oslevel
Short description
cmdb_ci_aix_server
short_description uname
Name
cmdb_ci_aix_server
name
DNS, NBT
Hostname
cmdb_ci_aix_server
host_name
DNS, NBT
DNS domain
cmdb_ci_aix_server
dns_domain
DNS
Start date
cmdb_ci_aix_server
start_date
uptime
CPU type
cmdb_ci_aix_server
cpu_type
lsdev, lsattr
cmdb_ci_aix_server
cpu_speed
lsdev, lsattr
CPU count
cmdb_ci_aix_server
cpu_count
lsdev, lsattr
Manufacturer
cmdb_ci_aix_server
manufacturer
lsattr
Model ID
cmdb_ci_aix_server
model_id
lsattr
RAM (MB)
cmdb_ci_aix_server
ram
lsdev, lsattr
Name
cmdb_ci_file_system
name
df
Capacity (MB)
cmdb_ci_file_system
capacity
df
available_space
df
Mount point
cmdb_ci_file_system
mount_point
df
Name
cmdb_ci_patches
name
instfix
Name
cmdb_running_process
name
ps
Command
cmdb_running_process
command
ps
Type
cmdb_running_process
type
ps
PID
cmdb_running_process
pid
ps
Parameters
cmdb_running_process
parameters
ps
Name
cmdb_ci_network_adapter name
ifconfig, netstat
IP address
cmdb_ci_network_adapter ip_address
ifconfig, netstat
MAC address
cmdb_ci_network_adapter mac_address
ifconfig, netstat
Netmask
cmdb_ci_network_adapter netmask
ifconfig, netstat
AIX
231
Enhancements
Dublin
The Running Processes [cmdb_running_process] table contains new fields to track the list of TCP ports a process
listens on (listening_on) and connects to (connects_to).
Mac
Tables and Fields
Discovery stores information about Mac (OS/X) computers in the following tables and fields.
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_computer
os
uname
OS Version
cmdb_ci_computer
os_version
system_profiler
OS Service pack
cmdb_ci_computer
os_service_pack
system_profiler
Short description
cmdb_ci_computer
short_description
uname
Name
cmdb_ci_computer
name
DNS, NBT
Hostname
cmdb_ci_computer
host_name
DNS, NBT
DNS domain
cmdb_ci_computer
dns_domain
DNS
Start date
cmdb_ci_computer
start_date
uptime
Manufacturer
cmdb_ci_computer
manufacturer
Assumed to be Apple
Serial number
cmdb_ci_computer
serial_number
system_profiler
CPU type
cmdb_ci_computer
cpu_type
system_profiler
cmdb_ci_computer
cpu_speed
system_profiler
CPU count
cmdb_ci_computer
cpu_count
system_profiler
Model ID
cmdb_ci_computer
model_id
system_profiler
RAM (MB)
cmdb_ci_computer
ram
system_profiler
cmdb_ci_comptuer
disk_space
system_profiler
Volume name
cmdb_ci_disk
volume_name
system_profiler
volume_serial_number system_profiler
cmdb_ci_disk
disk_space
system_profiler
Name
cmdb_ci_disk
name
system_profiler
Device ID
cmdb_ci_disk
device_id
system_profiler
cmdb_ci_disk
free_space
system_profiler
File system
cmdb_ci_disk
file_system
system_profiler
Name
cmdb_running_process
name
ps
Command
cmdb_running_process
command
ps
Connects to
cmdb_running_process
connects_to
lsof
Listening on
cmdb_running_process
listening_on
lsof
Mac
232
Type
cmdb_running_process
type
ps
PID
cmdb_running_process
pid
ps
Parameters
cmdb_running_process
parameters
ps
Name
cmdb_ci_network_adapter name
system_profiler
IP address
cmdb_ci_network_adapter ip_address
system_profiler
MAC address
cmdb_ci_network_adapter mac_address
system_profiler
Netmask
cmdb_ci_network_adapter netmask
system_profiler
MAC manufacturer
cmdb_ci_network_adapter mac_mfr
Assumed to be Apple
DHCP enabled
cmdb_ci_network_adapter dhcp_enabled
system_profiler
Label
Table Name
Field Name
Source
Operating System
cmdb_ci_computer
os
uname
OS Version
cmdb_ci_computer
os_version
system_profiler
OS Service pack
cmdb_ci_computer
os_service_pack
system_profiler
Short description
cmdb_ci_computer
short_description
uname
Name
cmdb_ci_computer
name
DNS, NBT
Hostname
cmdb_ci_computer
host_name
DNS, NBT
DNS domain
cmdb_ci_computer
dns_domain
DNS
Start date
cmdb_ci_computer
start_date
uptime
Manufacturer
cmdb_ci_computer
manufacturer
Assumed to be Apple
Serial number
cmdb_ci_computer
serial_number
system_profiler
CPU type
cmdb_ci_computer
cpu_type
system_profiler
cmdb_ci_computer
cpu_speed
system_profiler
CPU count
cmdb_ci_computer
cpu_count
system_profiler
Model ID
cmdb_ci_computer
model_id
system_profiler
RAM (MB)
cmdb_ci_computer
ram
system_profiler
cmdb_ci_comptuer
disk_space
system_profiler
Volume name
cmdb_ci_disk
volume_name
system_profiler
volume_serial_number system_profiler
cmdb_ci_disk
disk_space
system_profiler
Name
cmdb_ci_disk
name
system_profiler
Device ID
cmdb_ci_disk
device_id
system_profiler
cmdb_ci_disk
free_space
system_profiler
File system
cmdb_ci_disk
file_system
system_profiler
Mac
233
Name
cmdb_running_process
name
ps
Command
cmdb_running_process
command
ps
Type
cmdb_running_process
type
ps
PID
cmdb_running_process
pid
ps
Parameters
cmdb_running_process
parameters
ps
Name
cmdb_ci_network_adapter name
system_profiler
IP address
cmdb_ci_network_adapter ip_address
system_profiler
MAC address
cmdb_ci_network_adapter mac_address
system_profiler
Netmask
cmdb_ci_network_adapter netmask
system_profiler
MAC manufacturer
cmdb_ci_network_adapter mac_mfr
Assumed to be Apple
DHCP enabled
cmdb_ci_network_adapter dhcp_enabled
system_profiler
Enhancements
Dublin
The Running Processes [cmdb_running_process] table contains new fields to track the list of TCP ports a process
listens on (listening_on) and connects to (connects_to).
Solaris Zones
Label
Version
Table Name
cmdb_ci_vm_zones
Correlation ID cmdb_ci_vm_zones
Field Name
version
Source
zoneadm, zonename
Name
cmdb_ci_vm_instance name
zoneadm, zonename
Parent
cmdb_ci_vm_instance parent
Internal
CMDB CI
cmdb_ci_vm_instance cmdb_ci
Internal
Netware
234
Netware
Data Collected by Discovery on Netware
Label
Name
Table Name
Field Name
cmdb_ci_netware_server name
Source
snmp
cmdb_ci_netware_server os_version
snmp
RAM
cmdb_ci_netware_server ram
snmp
CPU count
cmdb_ci_netware_server cpu_count
snmp
ESX Servers
Overview
ServiceNow Discovery can explore the VMware vCenter process running on a Windows host machine. See VMware
Component Relationships for a description of the VMware architecture and component relationships.
Required Roles
Users with the itil and asset roles can access ESXi and ESX configuration item (CI) records. To run discovery on
vCenter servers, users must have the discovery_admin role.
Credential Requirements
Three sets of credentials are needed to run a complete Discovery of vCenter/ESX servers:
Windows credentials: Allows Discovery to access the Windows host on which the vCenter server runs
vCenter credentials: Allows a vCenter probe to explore a vCenter server
ESX credentials: Allows Discovery to access the serial numbers of discovered ESX servers
ESX Servers
235
Name
Description
Component
Classifier
vCenter
Probe
VMWare - vCenter
Exploration probe that extracts the list of ESX hosts, resource pools, and virtual machines from the vCenter
host. Implementation details for this probe are located in a MID server script include called
VMWarevCenterProbe.
Probe
Exploration probe that queries each ESX server for its serial number.
When Discovery runs, a classifier called vCenter, classifies the process running on a Windows machine and
launches the VMware - vCenter probe. This probe logs into the vCenter instance with the credentials provided and
uses the vCenter API to return information about ESX machines, virtual machines, and resource pools. If using a
domain account to access vCenter, specify the domain with the username in the credential record in one of the
supported formats such as Domain\UserName. In order to discover ESX server serial numbers, Discovery launches
the CIM - ESX Chassis Serial Number probe against each ESX server. This probe is required because the vCenter
API does not provide a way to retrieve the ESX serial numbers.
Click the plus for versions prior to Dublin
In versions prior to Dublin, Discovery used SSH to classify ESX servers.
Component
Name
Description
Classifier
ESX
Multiprobe
Probe
ESX - OS
ESX - OS
UNIX - OS
ESX Servers
236
Label
Table
Field Name
Source
CPU expandable
cpu_expendable
cpu_limit_mhz
CPU shares
cpu_shares
Full path
fullpath
Memory expandable
mem_expandable
mem_limit_mb
Memory shares
mem_shares
Owner
owner
owner_morid
URL
url
morid
Serial Number
serial_number
Relationships
Discovery collects the following relationship data for ESX Servers.
Base Class
Relationship
Dependent Class
ESX Resource Pool [cmdb_ci_esx_resource_pool] Defines resources for ESX Server [cmdb_ci_esx_server]
ESX Server [cmdb_ci_esx_server]
Has registered
Manages
Managed by
Enhancements
Dublin
Discovery uses vCenter and CIM probes instead of SSH to explore ESX servers. Discovery will continue to
classify an ESX server if it finds the SSH port open, but it will not launch SSH probes to collect additional
information.
237
Network Gear
Routers
Overview
Modern network routers and switches often have very similar capabilities. It is very common for a switch to have IP
routing capability (sometimes these switches are known as "Layer 3 switches"). Larger routers with optional
modules may accept switching modules. Because of these overlaps and the resulting ambiguity of a particular
device's classification, Discovery collects the same data for both routers and switches, if it is available in any given
device.
Table Name
Field Name
Source
Serial number
cmdb_ci
serial_number
Start date
cmdb_ci
start_date
Manufacturer
cmdb_ci
manufacturer
Model ID
cmdb_ci
model_id
IP address
cmdb_ci_network_adapter ip_address
SNMP, IP MIB
MAC address
cmdb_ci_network_adapter mac_address
SNMP, IF MIB
Can route IP
cmdb_ci_netgear
can_route
Can switch IP
cmdb_ci_netgear
can_switch
can_partitionvlans
Can hub
cmdb_ci_netgear
can_hub
SNMP, IP MIB
Name
dscy_router_interface
name
SNMP, IP MIB
Type
dscy_router_interface
type
SNMP, IP MIB
Number
dscy_router_interface
number
SNMP, IP MIB
IP address
dscy_router_interface
ip_address
SNMP, IP MIB
MAC address
dscy_router_interface
mac_address
SNMP, IP MIB
Destination network
dscy_route_interface
dest_ip_network
SNMP, IP MIB
Type
dscy_route_interface
type
SNMP, IP MIB
Destination network
dscy_route_next_hop
dest_ip_network
SNMP, IP MIB
Type
dscy_route_next_hop
type
SNMP, IP MIB
Next hop
dscy_route_next_hop
Base IP address
dscy_swtch_partition
base_ip_address
dscy_swtch_partition
base_mac_address
Base netmask
dscy_swtch_partition
base_netmask
Routers
238
Type
dscy_swtch_partition
type
Transparent
dscy_swtch_partition
transparent
Sourceroute
dscy_swtch_partition
sourceroute
Name
dscy_swtch_partition
name
Status
dscy_swtch_partition
status
Interface number
dscy_swtch_partition
interface_number
Type
dscy_switchport
type
Status
dscy_switchport
status
MAC address
dscy_switchport
mac_address
Port number
dscy_switchport
port_number
Interface name
dscy_switchport
interface_name
Interface number
dscy_switchport
interface_number
MAC address
dscy_swtch_fwd_rule
mac_address
MAC manufacturer
dscy_swtch_fwd_rule
mac_mfr
Status
dscy_swtch_fwd_rule
status
IP address
dscy_swtch_fwd_rule
ip_address
Netmask
dscy_swtch_fwd_rule
netmask
Label
Extends
cmdb_ci_lb
Load Balancer
Server [cmdb_ci_server]
cmdb_ci_lb_bigip
F5 BIG-IP
cmdb_ci_lb_interface
cmdb_ci_lb_pool
cmdb_ci_lb_service
cmdb_ci_lb_vlan
cmdb_lb_service_vlan
N/A
cmdb_lb_vlan_interface
Routers
239
Field Name
Label
cmdb_ci_lb
operational_status
Operational status
cmdb_ci_lb
name
Name
cmdb_ci_lb_bigip
failover_mode
Failover Mode
cmdb_ci_lb_bigip
failover_peer
Failover Peer
cmdb_ci_lb_bigip
serial_number
Serial Number
cmdb_ci_lb_interface
install_status
Status
cmdb_ci_lb_interface
load_balancer
Load Balancer
cmdb_ci_lb_interface
name
Name
cmdb_ci_lb_pool
load_balancer
Load Balancer
cmdb_ci_lb_pool
cmdb_ci_lb_pool
name
Name
cmdb_ci_lb_pool_member ip_address
IP Address
cmdb_ci_lb_pool_member pool
Pool
cmdb_ci_lb_pool_member service_port
Service Port
cmdb_ci_lb_service
ip_address
IP Address
cmdb_ci_lb_service
load_balancer
Load Balancer
cmdb_ci_lb_service
port
Port
cmdb_ci_lb_vlan
load_balancer
Load Balancer
cmdb_ci_lb_vlan
tag
Tag
cmdb_lb_service_vlan
service
Service
cmdb_lb_service_vlan
vlan
Vlan
cmdb_lb_vlan_interface
interface
Interface
cmdb_lb_vlan_interface
tagged
Tagged
cmdb_lb_vlan_interface
trunked
Trunked
cmdb_lb_vlan_interface
vlan
Vlan
Switches
240
Switches
Overview
Modern network routers and switches often have very similar capabilities. It is very common for a switch to have IP
routing capability (sometimes these switches are known as "Layer 3 switches"). Larger routers with optional
modules may accept switching modules. Because of these overlaps and the resulting ambiguity of a particular
device's classification, Discovery collects the same data for both routers and switches, if it is available in any given
device.
Table Name
Field Name
Source
Serial number
cmdb_ci
serial_number
Start date
cmdb_ci
start_date
Manufacturer
cmdb_ci
manufacturer
Model ID
cmdb_ci
model_id
IP address
cmdb_ci_network_adapter ip_address
SNMP, IP MIB
MAC address
cmdb_ci_network_adapter mac_address
SNMP, IF MIB
Can route IP
cmdb_ci_netgear
can_route
Can switch IP
cmdb_ci_netgear
can_switch
can_partitionvlans
Can hub
cmdb_ci_netgear
can_hub
SNMP, IP MIB
Name
dscy_router_interface
name
SNMP, IP MIB
Type
dscy_router_interface
type
SNMP, IP MIB
Number
dscy_router_interface
number
SNMP, IP MIB
IP address
dscy_router_interface
ip_address
SNMP, IP MIB
MAC address
dscy_router_interface
mac_address
SNMP, IP MIB
Destination network
dscy_route_interface
dest_ip_network
SNMP, IP MIB
Type
dscy_route_interface
type
SNMP, IP MIB
Destination network
dscy_route_next_hop
dest_ip_network
SNMP, IP MIB
Type
dscy_route_next_hop
type
SNMP, IP MIB
Next hop
dscy_route_next_hop
Base IP address
dscy_swtch_partition
base_ip_address
dscy_swtch_partition
base_mac_address
Base netmask
dscy_swtch_partition
base_netmask
Type
dscy_swtch_partition
type
Transparent
dscy_swtch_partition
transparent
Sourceroute
dscy_swtch_partition
sourceroute
Name
dscy_swtch_partition
name
Switches
241
Status
dscy_swtch_partition
status
Interface number
dscy_swtch_partition
interface_number
Type
dscy_switchport
type
Status
dscy_switchport
status
MAC address
dscy_switchport
mac_address
Port number
dscy_switchport
port_number
Interface name
dscy_switchport
interface_name
Interface number
dscy_switchport
interface_number
MAC address
dscy_swtch_fwd_rule
mac_address
MAC manufacturer
dscy_swtch_fwd_rule
mac_mfr
Status
dscy_swtch_fwd_rule
status
IP address
dscy_swtch_fwd_rule
ip_address
Netmask
dscy_swtch_fwd_rule
netmask
Label
Extends
cmdb_ci_lb
Load Balancer
Server [cmdb_ci_server]
cmdb_ci_lb_bigip
F5 BIG-IP
cmdb_ci_lb_interface
cmdb_ci_lb_pool
cmdb_ci_lb_service
cmdb_ci_lb_vlan
cmdb_lb_service_vlan
N/A
cmdb_lb_vlan_interface
Switches
242
Field Name
Label
cmdb_ci_lb
operational_status
Operational status
cmdb_ci_lb
name
Name
cmdb_ci_lb_bigip
failover_mode
Failover Mode
cmdb_ci_lb_bigip
failover_peer
Failover Peer
cmdb_ci_lb_bigip
serial_number
Serial Number
cmdb_ci_lb_interface
install_status
Status
cmdb_ci_lb_interface
load_balancer
Load Balancer
cmdb_ci_lb_interface
name
Name
cmdb_ci_lb_pool
load_balancer
Load Balancer
cmdb_ci_lb_pool
cmdb_ci_lb_pool
name
Name
cmdb_ci_lb_pool_member ip_address
IP Address
cmdb_ci_lb_pool_member pool
Pool
cmdb_ci_lb_pool_member service_port
Service Port
cmdb_ci_lb_service
ip_address
IP Address
cmdb_ci_lb_service
load_balancer
Load Balancer
cmdb_ci_lb_service
port
Port
cmdb_ci_lb_vlan
load_balancer
Load Balancer
cmdb_ci_lb_vlan
tag
Tag
cmdb_lb_service_vlan
service
Service
cmdb_lb_service_vlan
vlan
Vlan
cmdb_lb_vlan_interface
interface
Interface
cmdb_lb_vlan_interface
tagged
Tagged
cmdb_lb_vlan_interface
trunked
Trunked
cmdb_lb_vlan_interface
vlan
Vlan
243
Table Name
Field Name
Source
Serial number
cmdb_ci
serial_number
Start date
cmdb_ci
start_date
Manufacturer
cmdb_ci
manufacturer
Model ID
cmdb_ci
model_id
IP address
cmdb_ci_network_adapter ip_address
SNMP, IP MIB
MAC address
cmdb_ci_network_adapter mac_address
SNMP, IF MIB
Printer type
cmdb_ci_printer
print_type
Use count
cmdb_ci_printer
use_count
cmdb_ci_printer
use_units
Colors
cmdb_ci_printer
colors
Vertical resolution
cmdb_ci_printer
vertical_resolution
Resolution units
cmdb_ci_printer
resolution_units
Description
discovery_printer_supplies description
Supply type
discovery_printer_supplies supply_type
Supply class
discovery_printer_supplies supply_class
Current level
discovery_printer_supplies current_level
Max capacity
discovery_printer_supplies max_capacity
244
Table Name
Field Name
Source
Serial number
cmdb_ci
serial_number
Start date
cmdb_ci
start_date
Manufacturer
cmdb_ci
manufacturer
Model ID
cmdb_ci
model_id
IP address
cmdb_ci_network_adapter ip_address
SNMP, IP MIB
MAC address
cmdb_ci_network_adapter mac_address
SNMP, IF MIB
cmdb_ci_ups
ups_software_version
cmdb_ci_ups
agent_software_version
Attached devices
cmdb_ci_ups
attached_devices
Battery status
cmdb_ci_ups
battery_status
cmdb_ci_ups
seconds_on_battery
est_mins_remaining
cmdb_ci_ups
est_charge_remaining
Battery voltage
cmdb_ci_ups
battery_voltage
Battery current
cmdb_ci_ups
battery_current
cmdb_ci_ups
battery_temperature
cmdb_ci_ups
input_line_bads
Output source
cmdb_ci_ups
output_source
Output frequency
cmdb_ci_ups
output_freq
Bypass frequency
cmdb_ci_ups
bypass_freq
cmdb_ci_ups
nom_input_volt
cmdb_ci_ups
nom_input_freq
cmdb_ci_ups
nom_output_volt
cmdb_ci_ups
nom_output_freq
Rated output VA
cmdb_ci_ups
rated_output_va
cmdb_ci_ups
rated_output_power
cmdb_ci_ups
cmdb_ci_ups
audible_alarm_status
cmdb_ci_ups
low_voltage_transfer_point
cmdb_ci_ups
Input index
cmdb_ci_ups_input
input_index
cmdb_ci_ups_input
input_freq
cmdb_ci_ups_input
input_volt
cmdb_ci_ups_input
input_current
245
cmdb_ci_ups_input
input_power
Output index
cmdb_ci_ups_output
output_index
cmdb_ci_ups_output
output_load
cmdb_ci_ups_output
output_volt
cmdb_ci_ups_output
output_current
cmdb_ci_ups_output
output_power
Bypass index
cmdb_ci_ups_bypass
bypass_index
cmdb_ci_ups_bypass
bypass_volt
cmdb_ci_ups_bypass
bypass_current
cmdb_ci_ups_bypass
bypass_power
Alarm index
cmdb_ci_ups_alarm
alarm_index
Alarm type
cmdb_ci_ups_alarm
alarm_type
Alarm time
cmdb_ci_ups_alarm
alarm_time
Architecture
The following components are part of CIM:
Common Information Model (CIM): CIM [8] allows multiple parties to exchange information about managed
elements. CIM represents these managed elements and the management information, while providing the
mechanism to actively control and manage the elements.
Storage Management Initiative Specification (SMI-S): SMI-S [1] is a standard of use that describes methods for
storage discovery on the vendor's side. ServiceNow uses SMI-S to determine how to discover CIM. SMI-S is
based on the Common Information Model (CIM) and the Web-Based Enterprise Management (WBEM)
standards, which define management functionality via HTTP. The main objective of SMI-S is to enable
management of dissimilar storage products. ServiceNow supports SMI-S version 1.5 or higher.
Web-Based Enterprise Management (WBEM): WBEM [7] defines a particular implementation of CIM,
including protocols for discovering and accessing each CIM implementation.
Service Location Protocol (SLP): SLP [2] is an ad hoc protocol for retrieving and associating configuration
information about CIM servers, such as default paths, capabilities, and the exact interop namespace [3].
ServiceNow Discovery retrieves the interop namespace of a CIM server via SLP and passes that information to
the CIM Classify probe. SLP, referred to here as the SLP server, uses service agents (SA) to gather and
disseminate information about a CIM server on a subnet. A subnet can have multiple service agents.
246
247
SLP Query
The SLP query detects the wbem service (service:wbem) on an SLP server and gathers the attributes of the service.
248
Enhancements
Eureka
Provides more efficient querying of SMI-S compliant storage devices using CimIQL queries.
249
250
Software
Apache Web Servers
Data Collected by Discovery on Apache Web Servers
Label
Table Name
Field Name
Source
Name
cmdb_ci_web_server name
apcfg
Version
cmdb_ci_web_server version
httpd
JBoss Servers
Data Collected by Discovery on JBoss Servers
Label
Table Name
Field Name
Source
Name
cmdb_ci_web_service
name
jboss-service.xml
App server
cmdb_ci_web_service
app_server
Internal reference
Description
Name
cmdb_ci_web_application name
web.xml
web.xml
App server
web.xml
cmdb_ci_web_application app_server
MySQL Servers
251
MySQL Servers
Data Collected by Discovery on MySQL Servers
Label
Table Name
Version
Field Name
Source
cmdb_ci_db_mysql_instance version
mysqld
my.cnf
Oracle Databases
Data Collected by Discovery on Oracle Databases
Label
Version
Table Name
Field Name
cmdb_ci_db_ora_instance version
Source
lsnrctl
init.ora
SID
cmdb_ci_db_ora_instance sid
lsnrctl
Configuration
cmdb_ci_db_ora_listener
Oracle Home
cmdb_ci_db_ora_listener
oracle_home
Process Classifications
Tomcat Servers
Discoverable Web Applications
Discovery can identify and classify Web applications present in either the CATALINA_BASE or
CATALINA_HOME directories.
Table Name
Field Name
Source
Server port
cmdb_ci_app_server_tomcat server_port
server.xml
Version
cmdb_ci_app_server_tomcat version
server.info
Tomcat
cmdb_ci_tomcat_connector
tomcat
server.xml
Port
cmdb_ci_tomcat_connector
port
server.xml
App server
cmdb_ci_web_service
app_server
Internal reference
Description
cmdb_ci_web_application
short_description web.xml
document_base
web.xml
Tomcat Servers
252
App server
cmdb_ci_web_application
app_server
web.xml
Websphere Servers
Data Collected by Discovery on Websphere Servers
Label
Name
Table Name
cmdb_ci_websphere_cell
Field Name
Source
name
server.xml
app_server
Internal reference
Name
cmdb_ci_web_service
name
server.xml
Name
cmdb_ci_web_application name
serverindex.xml
serverindex.xml
Table Name
Field Name
Source
Version
cmdb_ci_web_server version
Windows registry
Name
cmdb_ci_web_site
name
wmi
Log directory
cmdb_ci_web_site
log_directory
wmi
Description
cmdb_ci_web_site
short_description wmi
Correlation ID cmdb_ci_web_site
correlation_id
Internal
IP address
cmdb_ci_web_site
ip_address
wmi
TCP port
cmdb_ci_web_site
tcp_port
wmi
Note: You must install IIS Management Scripts and Tools on a Microsoft IIS Server in order for Discovery to collect data from it.
253
Table Name
Field Name
Source
Name
cmdb_ci_spkg
name
Various
Version
cmdb_ci_spkg
version
Various
Install count
cmdb_ci_spkg
install_count
Various
License count
cmdb_ci_spkg
license_count Various
msft_sms_id
Various
Installed on
cmdb_software_instance installed_on
Various
Software
cmdb_software_instance software
Various
VMware vCenter
Overview
These options are available for getting VMware vCenter data:
ServiceNow Discovery can run the VMWare - vCenter probe when it identifies a VMware vCenter process
running on a Windows machine.
ServiceNow Orchestration can run the VMWare - vCenter probe from a workflow.
See VMware Component Relationships for a description of the VMware architecture and component relationships.
VMware vCenter
254
The list of vCenter instances appears. ServiceNow sends you an email confirmation when the scan is
complete.
VMware vCenter
255
2.
3.
4.
5.
The Discovery vCenter workflow runs in silent mode for this type of discovery and does not send
notifications.
8. Click Execute Now to run this discovery immediately.
Table Name
Column Name
Source
API version
api_version
Full name
fullname
Instance UUID
instance_uuid
URL
url
Effective CPU
effectivecpu
Effective memory
effectivehosts
Number of hosts
numhosts
Total CPU
totalcpu
Total memory
totalmemory
VMware vCenter
256
host_morid
folder_morid
Accessible
accessible
Capacity (GB)
capacity
freespace
Type
type
URL
url
Full path
fullpath
Accessible
accessible
morid
vcenter_uuid
vCenter Reference
vcenter_ref
Folder
folder
Type
type
Relationships
Discovery automatically creates relationships for vCenter components using data from a key class. Subsequent
Discoveries use the same key class to automatically validate and remove relationships that are no longer valid.
Parent Class
Relationship Type
Child Class
Relationship Key
Class
Child
Connected by::Connects
Parent
Provided by::Provides
Parent
Parent
Used by::Uses
Child
Members::Member of
Child
Parent
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
VMware vCenter
257
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Contains::Contained by
Parent
Enhancements
Eureka
Automatically validates and updates relationships for vCenter CIs. This process also removes stale relationships.
In addition to the new logic to remove stale relationships, code existed in previous versions to perform the
following tasks:
Remove records in the cmdb_ci_vmware_instance table that are no longer associated to a record in the
cmdb_ci_esx_server table, including the corresponding Registered on::Has registered relationship.
Remove records in the cmdb_ci_computer table that are no longer associated to a record in the
cmdb_ci_esx_server table with a Virtualized by::Virtualizes relationship.
Remove duplicate records in the cmdb_ci_vcenter table that have the same instance_uuid or ip_address fields
as the CI that is currently being discovered.
Calgary
An Orchestration workflow Discover vCenter can populate the CMDB with vCenter data without having to
install the Discovery plugin. See Orchestration Configuration and Workflow.
258
Other Stuff
Services/Daemons
Data Collected by Discovery on Services and Daemons
Label
Table Name
Field Name
Source
Name
cmdb_ip_service
name
Various
Port
cmdb_ip_service
port
Various
Various
CI
cmdb_ip_service_ci ci
Internal reference
Service
cmdb_ip_service_ci service
Internal reference
IP Addresses
Data Collected by Discovery on IP Addresses
Label
Table Name
Field Name
Source
IP Address
discovery_ip_address ip_address
Various internal
Hostname
discovery_ip_address host_name
Various internal
Discovered
discovery_ip_address discovered
Various internal
Agent
discovery_ip_address agent
Various internal
Discoverer
discovery_ip_address discoverer
Various internal
In Ranges
discovery_ip_address in_ranges
Various internal
MAC address
discovery_ip_address mac
Various internal
CMDB CI
discovery_ip_address cmdb_ci
Various internal
SSH attempted
discovery_ip_address ssh_attempted
Various internal
IP Networks
259
IP Networks
Data Collected by Discovery on IP Networks
Label
Table Name
Field Name
Source
Discover
cmdb_ci_ip_network discover
Various internal
Subnet
cmdb_ci_ip_network subnet
Various internal
cmdb_ci_ip_network last_discovered
Various internal
MID server
cmdb_ci_ip_network mid_server
Various internal
Router
cmdb_ci_ip_network router
Various internal
State
cmdb_ci_ip_network state
Various internal
Relationships
Data Collected by Discovery on Relationships
Label
Table Name
Field Name
Source
Parent
cmdb_rel_ci
parent
Internal
Child
cmdb_rel_ci
child
Internal
Type
cmdb_rel_ci
type
Internal
Connections
260
Connections
Tables and Fields
Discovery stores information about TCP connections in the following tables and fields.
Label
Absent
Table Name
cmdb_tcp
Computer cmdb_tcp
Field Name
Source
absent
Internal
computer
Internal
IP
cmdb_tcp_connection ip
Internal
PID
cmdb_tcp
pid
Internal
Port
cmdb_tcp
port
Internal
Process
cmdb_tcp
process
Internal
Type
cmdb_tcp
type
Internal
Label
Table Name
Field Name
Source
Application cmdb_tcp_half
application
Internal
Computer
cmdb_tcp_half
computer
Internal
PID
cmdb_tcp_half
pid
Internal
Command
cmdb_tcp_half
command
Internal
From IP
cmdb_tcp_half
from_ip
Internal
From port
cmdb_tcp_half
from_port
Internal
To IP
cmdb_tcp_half
to_ip
Internal
To port
cmdb_tcp_half
to_port
Internal
Type
cmdb_tcp_half
type
Internal
Computer
cmdb_tcp_connection computer
Internal
PID
cmdb_tcp_connection pid
Internal
Command
cmdb_tcp_connection command
Internal
From IP
cmdb_tcp_connection from_ip
Internal
From port
cmdb_tcp_connection from_port
Internal
To IP
cmdb_tcp_connection to_ip
Internal
To port
cmdb_tcp_connection to_port
Internal
State
cmdb_tcp_connection state
Internal
Connections
261
Enhancements
Dublin
The Running Processes [cmdb_running_process] table contains new fields (listening_to and connecting_to) to
track the list of TCP ports a process listens on and connects to.
A new table TCP Connections [cmdb_tcp] replaces the cmdb_tcp_connection and cmdb_tcp_half tables.
The Application Instance [cmdb_ci_appl] table contains new fields to track the classifier that created the instance
record and the running process that matched the classifier.
F5 BIG-IP
Discovery of F5 BIG-IP Load Balancers
Discovery of F5 BIG-IP load balancers is performed by SNMP. VMware images of BIG-IP for testing are available
with free 90-day keys: https://www.f5.com/trial.
Discovery for F5 BIG-IP load balancers is available starting with the Dublin release.
Model
The F5 BIG-IP load balancer model represents a generic load balancer and its components. The abstract class is
Load Balancer (cmdb_ci_lb). The implementation class, extended from Load Balancer, is F5 BIGIP
(cmdb_ci_lb_bigip). The load balancer components are modeled as follows.
Component
Table Name
Description
cmdb_ci_lb_service
A virtual service that the device balances by forwarding requests to members within a
pool.
cmdb_ci_lb_pool
cmdb_ci_lb_vlan
cmdb_ci_lb_interface
A network interface.
Storage Devices
262
Storage Devices
Overview
Discovery uses CIM probes to explore storage systems based on the Common Information Model (CIM) such as
Storage Area Network (SAN) and Network-Attached Storage (NAS) components. The CIM probe uses WBEM
protocols to query a particular CIM server, the CIM Object Manager, for a set of data objects and properties. For
more information, see CIM Discovery.
Table Name
Field Name
sys_id
Source
Sys ID
N/A
File Share ID
CIM probe
Path
CIM probe
disk_space
CIM probe
Pool ID
pool_id
CIM probe
Speed (GFC)
speed
CIM probe
WWPN
wwpn
CIM probe
Device ID
device_id
CIM probe
disk_space
CIM probe
LUN
lun
CIM probe
Storage Relationships
Discovery establishes the correct relationships between Network-Attached Storage (NAS) storage devices and
remotely mounted client servers that consume the storage. Discovery maps NAS file shares by matching the IP or
hostname of a remotely-mounted disk on the client computer to the IP or hostname of the storage server providing
the exported file system.
Storage relationships are available starting with the Eureka release.
Linux CI Relationships
Discovery creates the following relationships for storage CIs running on Linux OS hosts.
Storage Devices
263
Parent Component
Relationship
Child Component
Windows CI Relationships
Discovery creates the following relationships for storage CIs running on Windows OS hosts.
Parent Component
Relationship
Child Component
Relationship
Child Component
264
265
266
267
268