Servicenow Istanbul It Operations Management PDF

06/12/2018
Istanbul ServiceNow IT Operations Management

Istanbul ServiceNow Contents
Contents
IT Operations Management......................................................................................................................... 4
Discovery............................................................................................................................................. 4
Discovery basics....................................................................................................................... 4
Activate Discovery.................................................................................................................. 12
Discovery resource utilization.................................................................................................12
Discovery setup...................................................................................................................... 14
Running discoveries in your network..................................................................................... 22
Discovery configuration...........................................................................................................54
Advanced Discovery configuration....................................................................................... 169
Patterns and horizontal discovery........................................................................................ 209
Discovery probes and sensors............................................................................................. 211
Data collected by Discovery.................................................................................................278
Discovery troubleshooting.....................................................................................................479
Content packs for Discovery................................................................................................ 486
Application Profile Discovery - Legacy.................................................................................486
Service Mapping..............................................................................................................................514
Get started with Service Mapping........................................................................................ 515
Service Mapping setup......................................................................................................... 537
Plan business services......................................................................................................... 614
Business service definition................................................................................................... 628
Business service analysis and maintenance using maps.................................................... 666
Advanced Service Mapping configuration............................................................................ 702
Pattern customization........................................................................................................... 730
Event Management......................................................................................................................... 813
Understanding Event Management...................................................................................... 813
Event Management setup.....................................................................................................819
Administer events................................................................................................................. 854
Manage and monitor alerts.................................................................................................. 944
Service Analytics................................................................................................................ 1012
Operational Metrics.............................................................................................................1030
Cloud Management....................................................................................................................... 1054
Cloud Management product overview................................................................................1055
How Cloud Management works......................................................................................... 1106
Cloud administrator actions................................................................................................ 1111
Cloud operator actions....................................................................................................... 1190
Cloud user actions..............................................................................................................1204
Cloud Management reports................................................................................................ 1244
Advanced topics................................................................................................................. 1252
Errors and Troubleshooting................................................................................................ 1282
Content packs for Cloud Management...............................................................................1289
Index........................................................................................................................................................ 1290
© 2018 ServiceNow. All rights reserved. iii

IT Operations Management
Track and manage IT resources and systems.
Discovery
ServiceNow® Discovery finds applications and devices on your network, and then updates the CMDB with
the information it finds.
Discovery is available as a separate subscription from the rest of the ServiceNow platform. See Activate
Discovery on page 12 for details.
Explore Set up Administer

• Discovery release notes • Activate Discovery on page • Discovery properties on page
• Upgrade to Istanbul 12 55
• Discovery basics on page • MID Server installation • Create a Discovery behavior on
4 • Create credentials for page 191
• Data collected by Discovery Orchestration and Discovery • Create a Discovery CI
on page 278 classification on page 91
• Create a Discovery process
classification on page 96
Use Integrate and develop Troubleshoot and get help

• Schedule discovery on page • Discovery with Software Asset • Discovery troubleshooting on
28 Management Template on page 479
• Run Quick Discovery on page page 369 • Search the HI knowledge base
35 • Activate SCCM Asset for known error articles
• Validate discovery results on Intelligence scheduled imports • Contact ServiceNow Support
page 37 on page 82
• Discovery APIs on the
developer portal
Discovery basics
Discovery finds computers, servers, printers, and a variety of IP-enabled devices, and the applications that
run on them. It can then update the CIs in your CMDB with the data it collects.
Probes, sensors, and patterns
Discovery uses these components to explore computers and devices (which are also known as hosts):
Probes and sensors Probes and sensors are scripts that collect data
on the host, process it, and update the CMDB.
Several probes and sensors are provided out of
box, but you can also customize them and create
custom ones. You can also configure parameters to
control the behavior of a particular probe every time
© 2018 ServiceNow. All rights reserved. 4

it is triggered. A base set of probes and sensors is

always used in the first two stages of Discovery.
If you are not using patterns, additional probes
and sensors are used to identify and explore hosts
and the software that runs on them (see Discovery
phases).
Patterns Patterns are a series of operations that also collect
data on a host, process it, and update the CMDB,
just as probes and sensors do. Patterns differ
from probes and sensors in that they are written
in Neebula Discovery Language (NDL) rather than
JavaScript, and they are called into action during
the last two phases of Discovery. Default patterns
are provided , but you can customize them or create
new ones using the Pattern Designer.
Discovery phases
The four phases of discovery are outlined here. For a more detailed, step-by-step breakdown of the steps
for each phase, see Horizontal discovery process flow on page 8.
Discovery follows these phases:
• Scanning Discovery sends the Shazzam probe to the
network to see if specified ports are open on the
network and if they can respond to queries. For
example, if Shazzam finds a device that responds
on port 135, Discovery knows that it is a Windows
server.
• Classification If Discovery finds devices, it continues to send
probes to find the type of device at each IP
address. For example, Discovery would send
the WMI probe, which is used for Windows
devices, and find out that the Windows operating
system on this server is running Windows 2012.
Classifiers specify which trigger probes to run for
identification and exploration.
• Identification Discovery tries to gather more information about
the device, looks at those attributes, determines
if it has a CI in the CMDB, and reconciles that
information by either updating the CI or creating
a CI. Discovery uses additional probes, sensors,
and identifiers to do this. Identifiers, also known as
identification rules, specify the attributes that the
probes look at when reconciling data with the CIs
in the CMDB. If you are using patterns, Discovery
uses the appropriate identification rule for the CI
type specified in the pattern.
• Exploration The identifier in the previous step (Identification)
launches the exploration probes configured in
the classification record to gather additional
information about the device, like the applications
running on the device, and attributes about the

device, such as memory, network cards, drivers,

etc. Discovery then maps applications to devices
and to other applications. In this phase, Discovery
also uses additional probes and sensors that are
hard-coded to find this additional information.
If you are using a pattern, the operations in the
pattern perform the exploration of the CI.
Horizontal discovery and top-down discovery
There are actually two types of discovery:
Horizontal discovery The Discovery application performs horizontal

discovery, which means that it finds devices
on your network and several attributes about
those devices including the operating system,
software, memory, and so on. It can also establish
relationships between the applications and the
device, and between applications. But it does not
draw relationships between CIs that are part of
specific business services.
Top-down discovery Top-down discovery, which is a technique used by

Service Mapping, finds and maps CIs that are part
of business services in your organization, such as
an email service. Service Mapping actually utilizes
horizontal discovery to find devices in the scanning
and classification phases, and top-down discovery
to map business services.
Note: Both Discovery and Service Mapping can use the same pattern; however, you define steps
in the pattern differently for the two applications.
Discovery and MID Servers
Discovery uses special server processes, called MID Servers. Each MID server is a lightweight Java
process that can run on a Linux, Unix, or Windows server. The job of the MID server during Discovery is
to execute probes and patterns, and then return the results back to the instance for processing. It does not
retain any information.
MID servers communicate with the instance they are associated with by a simple model: They query
the instance for the initial probes to run, and they post the results back to the instance. There, the data
collected by the probes is processed by sensors, which decide how to proceed. Optionally, if you use
patterns, the operations in the patterns 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 uses 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 uses the Simple Network
Management Protocol (SNMP) to gather information from a network switch or a printer.

In addition to the MID Server, you need:

• IP addresses The address or addresses to query on the
network. You configure these on the Discovery
schedule.
• Credentials The access credentials for the devices that you
intend Discovery to collect data on.
IP service affinity
IP Service affinity saves the IP service information that is used to successfully find a device and associates
it with the IP address of the device. Using this information, Discovery can target the device in subsequent
runs with the accurate protocol. Discovery records the IP Service along with the IP address. Discovery can
store the successful IP service information in the IP Service Affinity table [ip_service_affinity].
For example: A network device has both an SSH port and an SNMP port open. By its agentless design,
Discovery tries SSH first. However, network devices should be discovered through SNMP. Discovery tries
the SSH probe and it fails. This triggers the SNMP probe, which succeeds. With the association between
the IP address and the IP service, subsequent discovery runs that target this IP address use SNMP first,
because that is the probe that succeeded.
Discovery communications
Discovery communications cover how your instance talks to the MID Servers and how the MID Servers
talk to your devices. The MID Server is installed on the local internal network. All communications between
the MID Server and the instance are done via SOAP over HTTPS. Since we use the highly secure and
common protocol HTTPS, the MID Server can connect to the instance directly without having to open any
additional ports on the firewall. The MID Server can also be configured to communicate through a proxy
server if certain restrictions apply.
The MID Server is deployed in the internal network, so it can, with proper login credentials, connect directly
to discoverable devices.
Discovery and Help the help desk
Help the Help Desk is a standard feature available through the self-service Help the Help Desk application.
It gathers information, much as Discovery does, about a single Windows computer by running a script on
that computer. Discovery does many things that Help the Help Desk cannot do.

Functionality Discovery Help the Help Desk
Automatic discovery by
schedule
Automatic discovery on user
login
Manually initiated discovery
Windows workstations
Windows servers *
Linux systems
Unix systems (Solaris, AIX, HP-

UX, Mac (OSX))
Network devices (switches,
routers, UPS, etc.)
Printers
Automatic discovery of
computers and devices
Automatic discovery of
relationships between
processes running on servers
*
Returns information about Windows server machines when Discovery is installed.
Horizontal discovery process flow

The horizontal discovery process passes through the four phases of discovery using probes and sensors,
and optionally, operations in patterns.
The process is as follows:
1. A user triggers horizontal discovery by configuring a discovery schedule or by launching an on-
demand discovery with Discover now or Quick Discovery. The schedule specifies one or more IP
addresses or range of IP addresses.
2. The scanning phase begins:
a. Discovery first takes the Shazzam probe (and then port probes) and places it in a request in the
External Communication Channel (ECC) queue.
b. The MID Server checks the ECC queue, retrieves the discovery request, and runs the probes
against the host and discovers open ports.
c. The port probes scan common ports using several protocols, such as WMI, HTTP, SSH, and
SNMP.
d. If one or more ports respond, the Shazzam probe sends information about the port back to the
ECC queue through the MID Server.

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

a. The Discovery application determines which classification probe to send to the newly discovered
device by using information in the record of the port probe that successfully responded.
b. Discovery puts the classification probe into the ECC queue.
c. The MID Server checks the ECC queue, retrieves the discovery request, and runs the
classification probe.
d. The classification probe retrieves additional information, such as which version of the operating
system is running on a machine. This information determines the class of the CI that Discovery
found. There is only one classification probe per discovered device.
e. The classification probe sends information back to the instance ECC queue through the MID
Server.
4. The identification phase begins:

a. Discovery determines which classifier to use based on the class of the CI and the criteria
specified in all CI classifier records. The classifier specifies which probes to use for the next two
phases.
b. Discovery puts the identification trigger probe for the CI classifier into the ECC queue. For
example, a Unix machine running HP-UX would require the HP-UX classifier, which specifies that
the Multi Probe-HP-UX Identity identification trigger probe.
Note: The trigger probe could also be the Horizontal Pattern probe, which tells Discovery
to follow the operations in the specified pattern, rather than sending out additional probes.
The operations in the pattern cover both the identification and exploration phases.
c. The MID Server checks the ECC queue, retrieves the discovery request, and runs the
identification trigger probe.
d. The identification probe accumulates identification data for each device and sends that data back
to the instance via the MID Server.
e. Discovery uses sensors for the identifier probe to process the information.
f. The sensors perform the analysis on the CMDB using CI identifiers. The sensors can update
existing CIs in the CMDB or create new ones.
5. Finally, the Exploration phase begins:

a. Discovery looks at the Triggers Probes related list in the classifier to find exploration probes to
run.
b. Discovery puts the exploration trigger probe into the ECC queue.
c. The MID Server checks the ECC queue, retrieves the discovery request, and runs the exploration
trigger probes.
d. The probes send data back to the instance via the MID Server and sensors make updates to the
CMDB, just as in the identification phase.

Devices and applications that Discovery can discover

In the base instance, Discovery can find and classify these devices and applications.
See Data collected by Discovery on page 278 for table schemas and other information about these
items.
• Windows classifications:
• Windows Server 2008
• Windows Server 2008 R2
• Windows 2012 Server
• Hyper-V Server
• Windows Cluster Virtual IPs
• UNIX classifications:
• AIX
• ESX
• HP-UX
• Mac OS X
• Solaris
• Linux, including:
• Red Hat
• Fedora
• Debian
• SUSE
• CentOS
• Ubuntu
• Network device classifications:

• Load balancers (A10*, ACE*, Alteon*, F5 BIG-IP*, NetScaler*, Radware - AppDirector*, Cisco GSS,
Cisco CSS, HAProxy, Apache mod_jk and mod_proxy)
• DataPower servers*
• Dell Remote Access Controller
• Firewalls
• Netware servers
• Network printers
• Power distribution units
• IP phones
• Wireless access points
• Uninterruptible Power Supplies (UPS)
• Application classifications:
• Web servers:
• Apache Tomcat
• Apache mod_jk module and Apache mod_proxy module
• Microsoft IIS
• Oracle iPlanet
• JBoss

• Email and messaging services:

• IMAP
• Exchange Client Access Server*, Exchange Hub*, Exchange MailBox*
• Tibco Enterprise Message Service*
• Cloud-based technology:
• Amazon Web Services
• Microsoft Azure
• Databases:
• MySQL
• DB2
• Microsoft SQL
• MongoDB
• HBase
• Oracle
• PostgreSQL
• SAP HANA*
• Sybase*
• Storage servers:
• SMI- Storage Server
• SMI- Storage Switch
• Virtualization:
• Docker*
• Kernel-based Virtual Machine
• Solaris Zones
• vCenter
• Others:
• Cisco Unified Computing System (UCS)*
• HP Service Manager application server*
• HP Operations Manager*
• Oracle JavaSpaces
• GlassFish
• SMI- WBEM
• Jrun*
• LDAP service
• MongoDB Shard (MongoS)*
• NGINX
• Puppet
• SAP ASCS*, SAP Business Objects CMS Server*, SAP CI*, SAP DI*, SAP ERS*, SAP SCS*
• Microsoft Sharepoint*
• Microsoft SQL Server Analysis Services*
• Oracle Tuxedo*
• Oracle WebLogic
• IBM WebSphere*, WebSphere Message Broker*, IBM WebSphere MQ*
• Nagios

• Tibco ActiveMatrix BusinessWorks*
Items with an asterisk * have a pattern that Discovery can use to perform horizontal discovery.
Activate Discovery
Discovery is available as a separate subscription from the rest of the platform and requires the Discovery
(com.snc.discovery) plugin.
Role required: None
To purchase a Discovery subscription, contact your ServiceNow account manager or sales representative.
1. In the HI Service Portal, click Service Catalog > Activate Plugin.
2. Fill out the form.
Target Instance Instance on which to activate the plugin.

Plugin Name Name of the plugin to activate.
Specify the date and time you would like this Date and time must be at least 2 business
plugin to be enabled days from the current time.
Note: Plugins are activated in

two batches each business day in
the Pacific timezone, once in the
morning and once in the evening.
If the plugin must be activated at a
specific time, enter the request in
the Reason/Comments.
Reason/Comments Any information that would be helpful for the

ServiceNow personnel activating the plugin
such as if you need the plugin activated at
a specific time instead of during one of the
default activation windows.
3. Click Submit.
Discovery resource utilization

Typical transactions on Windows and Unix generate various amounts of network traffic, depending on what
is being discovered.
This table shows the bandwidth consumption, by operating system, for each data flow segment of a typical
Discovery. Also shown is the bandwidth comparison between an initial Discovery for three-tier applications
and each subsequent Discovery that does not collect hardware data. All measurements are in megabytes.
Note: These measurements were taken with base operating configurations. Your local system
results may vary.


Discovery setup
You can set up Discovery, including a MID Server, by using Guided Setup in your instance. If you do not
want to use Guided Setup, you can set up MID Servers and credentials, and then run discovery from the
Discovery Schedule.
Select your method of setup:
Setup method Description
Guided Setup Use this method if you want to set up everything

within the instance. Help is provided on the
Guided Setup interface to walk you through
everything you need for setup and initial
configuration.
Without Guided Setup Use this method if you want to set up each
component of setup separately. You can
configure MID Servers, credentials, and roles
separately, then configure one of the discovery
types from the Discovery Schedule.
Use guided setup for MID Server and Discovery

Discovery guided setup provides a sequence of tasks that help you configure Discovery on your
ServiceNow® instance.
Role required: admin
You are guided through configuration activities that create, download, and validate a MID Server. When
you have completed those tasks, you can add credentials and create a Discovery schedule. A progress
indicator on each screen allows you to monitor your progress for each task and for the entire process.
Each configuration activity provides the following resources to help you:
• Contextual embedded help.
• Links to comprehensive documentation on the ServiceNow product documentation site.
Important: You must complete MID Server configuration before you can launch the Discovery
guided setup.
1. Navigate to Guided Setup > ITOM Guided Setup.

The ITOM Guided Setup welcome screen appears.

2. Click Get Started.

The ITOM Guided Setup category screen appears, with controls for starting the MID Server and
Discovery guided setup procedures.


3. In the MID Server pane, click Get Started.

The MID Server task list appears with a description of each task.


4. Click Configure to create the MID Server user and follow the instructions in the help pane that
appears on the right edge of the screen.
5. When you have provided the requested information for the MID Server user, click Submit, and then
click Mark as Complete at the bottom of the help pane.
The view returns to the task list. Notice that the circular progress indicator for the category shows 33%
of the MID Server configuration complete. The progress indicator on the left edge of the screen shows
the completion percentage for all the MID Server and Discovery tasks, with each category contributing
50% of the total. In the case of the MID Server, the completed task represents 16% of that category's
50% contribution to the whole.


6. Click Configure to begin the next task, that of downloading and installing the MID Server.
7. Continue working on the configuration tasks until your MID Server is running and has been
successfuly validated.
8. Return to the list of ITOM guided setup categories.
Notice that the Discovery setup procedure is now available, and the progress indicators have been
updated appropriately.
9. Click Get Started in the Discovery pane and complete the configuration tasks in the order prescribed,
using the same general process for completing the procedure as you did for the MID Server.
The progress indicator updates as you complete the Discovery setup tasks.
Set up Discovery manually

If you are not using Guided Setup, you must perform several configuration steps manually to activate the
application, set up the MID Server, and then set up Discovery.
1. Meet prerequisites.
a) 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.
b) Select a MID Server host: Designate a computer to host the MID Server.
c) Gather credentials: Gather the login credentials that the MID server must use to access the
devices it is expected to discover.
d) 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.
2. Enable the Discovery plugin.

For information about purchasing a subscription, see Activate Discovery on page 12.
3. Deploy MID Servers.
Install one or more MID Servers on physical or virtual servers that meet the minimum requirements
and configure them to communicate with the appropriate ServiceNow instance.
Install at least two MID Servers at first and assign them to different schedules and IP ranges to help
complete discoveries quicker. Starting with the Istanbul release, you must make sure that the MID
Server is assigned the Discovery application or the ALL application.
4. Ensure MID Server connectivity. Open the instance and navigate to Discovery > MID Servers.
If the new MID Servers are configured properly, they will appear in the list of MID Servers.
If a MID Server does not appear as a choice in the instance, perform the following checks in the MID
Server:
• Ensure that the URL in the Configuration Parameters related list provided is correct.
• If the MID Server is installed on Windows, make sure the ServiceNow MID Server service is
configured properly with the correct logon credentials and is running.
• Check the MID Server log for errors.
• UI: Navigate to Discovery > MID Servers > [MID Server] > Logs.
• MID Server Host: Navigate to the agent\logs\agent0.log0 directory.
• If Basic Authentication is enabled, a username and password must be provided.

• The MID Server might not have outbound access on port 443 (SSL) or a proxy server might be
preventing TCP communication to the instance.
• Make sure that no firewalls are blocking communication between the MID Server and the instance.
5. 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.
6. Define and run Discovery schedules.
The Discovery Schedule is the control point for running discoveries. The schedule controls when
Discovery runs, defines the MID Server to use, the type of Discovery that should run, and the IP
addresses to query. Create as many schedules as necessary, using different types of discoveries, and
configure them to run at any time. Let Discovery run on its configured schedule or manually execute
Discovery at any time. These schedules can be set up in a variety of ways, including a single schedule
for the entire network or separate schedules for each location or VLAN.
If you do not know the IP address to scan in your network, run a Network Discovery first to discover
the IP networks. Once discovered, you can convert these networks into IP address range sets that you
use in a Discovery Schedule.
Note: For advanced discoveries, such as those requiring load balancing or scanning across
multiple domains, use Discovery Behaviors.
Validate discovery results on page 37
Running discoveries in your network

You can run discoveries from schedules or scripts to create configuration items, define subnets, or to find
resources in AWS and Azure clouds.
MID Server configuration prerequisites
Ensure that your MID Servers are properly configured prior to creating a Discovery schedule.
• Supported applications: The applications that are allowed to use the MID Server. You can use the
ALL application to allow any application to use the MID Server.
• IP ranges: The ranges of IP addresses the MID Server can scan. To find a MID Server match, the IP
range you configure on the Discovery schedule must fall into the ranges that one or more MID Servers
can support. The maximum number of IP addresses that a Discovery schedule can scan is set at
100,000 in the Max range size (glide.discovery.max_range_size) Discovery property. If the number
of IP addresses in a schedule exceeds the value set in this property, the schedule does not run.
• Capabilities: The capabilities that the MID Server supports. You can use the ALL capability to allow
any application to use the MID Server.
Discovery configuration prerequisites
Ensure that your MID Servers can authenticate on the devices they find and classify configuration items
(CI) properly.
• Credentials: The MID Servers with the login credentials query the devices in the network.

• Classifications: The device and process classifications provided in the base platform are sufficient.
Create classifications as needed for the devices, processes, and applications in the network.
Get started running a discovery
1. Use the Discovery Configuration Console to get started with Discovery. The console provides
configuration options which let you choose the types of devices, applications, and software CIs you
want Discovery to find. If you select a CI to exclude from scanning, the instance disables the related
probe or classifier that Discovery uses to identify the CI. See Discovery configuration console on page
23 to get started.
2. Determine what type of discovery to run:
• Run a Configuration item (CI) discovery to find the devices, computers, and applications on
your network. This is the most common type of discovery. Run CI discovery from the Discovery
Schedule, where you to set up a recurring schedule or run a discovery on demand. The Discovery
Schedule also provides configuration options for MID Servers and the Shazzam port probe.
• Run a Network discovery to find the internal IP networks within your organization. If you already
know the IP address ranges in your network, it is not necessary to run Network Discovery. It is
intended for organizations that do not have complete knowledge of the IP addresses available for
Discovery in their networks.
• Run Discovery to find AWS and Azure resources in your organizations cloud.
3. After you run a discovery, monitor the results of the discovery and resolve errors if they occurred:
• Use the Discovery status to see a summary of a Discovery and to access the ECC queue, which
shows probe and sensor activity, as well as the actual XML payload that is sent to or from an
instance.
• Use the Discovery dashboard to monitor ongoing Discovery operations.
Discovery configuration console

Use this console to configure what Discovery data the system allows in the CMDB.
By default, Discovery finds all the information on your network that is specified in probes and patterns. Use
the controls in this console to prevent Discovery from finding data that your organization does not need.
You can control these aspects of Discovery:
• The discovery of entire CI types, such as Windows servers.
• The discovery of specific CI details, such as OS information on Windows servers.
• The discovery of software packages containing keyword terms that you add, such as Hotfix or Security
Update.
Requirements and accessibility
If you use Internet Explorer, you must use version 8 or later. The configuration console supports keyboard
navigation and screen readers.

Console overview
Use the switches in the console to determine if a configuration item (CI) is discovered. The switch turns
gray when an item is excluded. When you configure Discovery to ignore a CI, the instance disables the
probe or classifier that explores that CI.
Note: This action does not deactivate the probe or classifier for general use across the system.
The item remains available for other processes.
The console is divided into these sections:

• Devices: network devices such a printers, storage devices such as storage switches, and Unix and
Windows computers.
• Applications: automation applications such as Puppet, databases such as MSSQL, and web servers
such as Tomcat.
• Software Filter: Unix and Windows applications that include or exclude keywords that you enter.

Figure 1: Discovery configuration console
Device Discovery
You can prevent the discovery of network devices, storage devices, and computers. Blocking device data
at the top level disables the related port probes. For example, blocking Network Devices disables the
SNMP port probe. Blocking devices at the second level of the hierarchy has the following effects:
• Device class categories disable classifiers.
• Device info categories disable probes executed by classifiers.
Data blocked at the second level of the hierarchy effects the nested subclasses. For example, if you block
Windows Servers & Computers data, the system also blocks data from nested subclasses, since those
classes are all dependent on the port probes that are disabled.

Application Discovery
Disabling the discovery of application data affects all host devices on which the application runs. For
example, if you configure Discovery to ignore databases, no information is gathered for either Linux or
Windows databases. Conversely, if you configure the system to ignore a device type, such as a Windows
server, no databases running on that server are explored, even if they are configured to be discovered.
The instance cannot identify the applications running on a server until it first discovers that server.
When you exclude an item from the Applications section, the system disables the relevant process
classifier.
Software Discovery
You can configure which Windows and UNIX software packages identified by Discovery are stored in the
CMDB.
Discovery provides configurable lists of keywords it can use to filter software packages for Windows and
UNIX operating systems. A filtering keyword can be any term that is present in a software package name
that you want to use to filter the results of a Discovery. You can choose to include or exclude packages
with names that contain the keywords defined in these lists.
Keywords for filtering software are stored in the Software Filter Keys [discovery_spkg_keys] table. The
following default keywords are provided for Windows:
• Hotfix
• Language Pack
• Security Update
Note: The system does not provide default filtering keywords for UNIX software.
Affects on Discovery tables
Exclude CIs from Discovery

Use the Discovery configuration console to determine which device configuration items (CI) are added to
the CMDB.
Role required: discovery_admin, admin
1. Navigate to Discovery > Discovery Definition > Configuration Console.
2. If you want to exclude specific devices and device information, expand the category for the device
types.
3. To see what applications can be disabled, hover your cursor over the application type.
4. Click the switch to turn off the CIs you do not want to discover.
The instance creates an update set record for any change you make to the console.
Filter software to discover

Use the Discovery configuration console to filter the software you add to the CMDB.

The instance creates an update set record for any change you make to the console.
1. Navigate to Discovery > Discovery Definition > Configuration Console.
2. In the Software Filter panel, select the tab for the operating system you want, either Unix or Windows.
3. Add or delete keywords for filtering software packages.
a) To add a keyword, enter it in the field provided and click New Key.
b) To delete a keyword, click the red + icon to the right of the keyword.
Discovery looks for software packages containing these terms in the selected operating system and
either includes or excludes them from the CMDB. The system does not provide default keywords for
filtering UNIX software packages, but provides these default keywords for Windows:
• Hotfix
• Language Pack
• Security Update
4. Select whether to Include or Exclude software packages with the keywords in their names.
• Include: Only add software packages that match the keywords.
• Exclude: Add all software packages except those matching the keywords.
5. You can switch off the software filter for either UNIX or Windows.
When the filter is disabled for an operating system, all discovered software packages for that operating
system are added to the CMDB, with no filtering applied.
Discovery configuration console processing

When you use the configuration console to disable Discovery for specific configuration items (CI), the
system disables probes or classifiers and prevents Discovery from adding those CIs to the CMDB.
This table illustrates how the system configures Discovery elements to prevent CIs from being added to the
CMDB.
Table 1: Background processing for configuration console
Category table Example Reference table Field Description
Protocol Category Top level Device Port probes active_discover_cis Turning off this
[discovery_category_protocol]
categories, such [discovery_port_probe] field prevents
as: Discovery from
attempting to
• Network
use that protocol
Devices,
to discover CIs,
• Windows but allows port
Servers & probe to be used
Computers elsewhere for
• Unix Servers & scanning.
Computers

Category table Example Reference table Field Description
Device Everything Classifiers disabled Turning off this

Classification under the label [discovery_classy] field disables
Category Discover by the respective
[discovery_category_device_class]
Device Class, classifier. See
such as the Disabling
classifiers
• Windows 2008
section below the
Servers
table for more
• Linux Servers information.
Device Info Everything Classifier Probes active Turning off

Category under the label [discovery_classifier_probe] this field only
[discovery_category_device_info]
Discover by determines
Device Info, such which probes
as: are triggered
by a certain
• UNIX ADM
classifier and
• Windows does not turn off
Software the actual probe.
The probe is still
available for use
elsewhere, but
is not available
to the classifier
for which it was
disabled.
Application Everything in the Process active Turning off this
Category Applications Classifiers field disables
[discovery_category_appl]
panel [discovery_classy_proc] the respective
classifier.
Disabling classifiers
Disabling Discovery for a specific configuration item does not prevent Discovery from finding the CI, but
prevents the system from classifying and entering the CI into the CMDB. The system stops Discovery
when the disabled classifier is detected. This prevents the system from skipping a higher order of
classification and identifying the CI at a lower level of classification. For example, if you disable Discovery
of Windows 2008 Servers in the console, the system stops Discovery when it detects the disabled server
classifier and does not run the Windows Computer classifier.
Schedule discovery
A schedule determines what horizontal discovery searches for, when it runs, and which MID Servers are
used.
Roles required: admin, discovery_admin
You can use a Discovery schedule to launch horizontal discovery, which uses probes, sensors, and
pattern operations to scan your network for CIs. Use this procedure to create a schedule manually from the
Discovery Schedule form.

Service Mapping also provides a Discovery schedule for top-down discovery. See Create a discovery
schedule for an application CI on page 638 for more information.
Use the Discovery Schedule module in the Discovery application to:
• Configure device identification by IP address or other identifiers.
• Determine if credentials will be used in device probes.
• Name the MID Server to use for a particular type of discovery.
• Create or disable a schedule that controls when the discovery runs in your network.
• Configure the use of multiple Shazzam probes for load balancing.
• Configure the use of multiple MID Servers for load balancing.
• Run a discovery manually.
1. Navigate to Discovery > Discovery Schedules and create a new record.

2. Complete the Discovery Schedule form, using the fields in the table.
3. Right-click in the record's header and select Save from the context menu.
4. To create a range of IP addresses to discover, click Quick Ranges under Related Links.


Table 2: Discovery Schedule Form
Field Description
Name Enter a unique, descriptive name for your schedule.

Discover Select one of the following scan types:
• Configuration items: Configuration item scans use discovery
identifiers to match devices with CIs in the CMDB and update
the CMDB appropriately. You can perform a simple discovery by
selecting a specific MID Server to scan for all protocols (SSH,
WMI, and SNMP), or perform more advanced discoveries with
discovery behaviors. When you select a behavior, the MID Server
field is not available.
• IP addresses: IP addresses scans devices without the use of
credentials. These scans discover all the active IP addresses
in the specified range and create device history records, but
do not update the CMDB. IP address scans also show multiple
IP addresses that are running on a single device. 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 Configure Shazzam probe parameters on
page 244 for details.
• 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.
• Web Service: This scan discovers resources on Amazon Web
Services. Results from this search are used to populate the AWS
Resource table [cmdb_ci_aws_resource]. For EC2 instances, the
information may appear as reference in the AWS Resource table.
• Service: This scan discovers services for the Service Mapping
application. See Create a discovery schedule for an application CI
on page 638 for instructions.

Field Description
MID Server Select the method that Discovery uses to select a MID Server:
selection method
• Auto-Select MID Server: Allow Discovery to select the MID
Server automatically based on the Discovery IP Ranges you
configure. To find a matching MID Server, you must configure MID
Servers to use:
• The Discovery application, or ALL applications. This makes the
MID Server authorized to be accessed by Discovery.
• The IP Range that includes the ranges you configure on the
Discovery Schedule.
• Specific MID Cluster: Use a preconfigured cluster of MID

Servers. You must select the cluster. You no longer need to
specify one member of the cluster. The MID Server cannot be part
of multiple clusters, such as one that supports load balancing and
one that supports failover. You can add any cluster regardless
of the application that the MID Servers are assigned to assigned
to. When you select the cluster, the Discovery application is
automatically added if it does not already exist for the MID Servers
in the cluster.
• Specific MID Server: Use only one MID Server. If that MID Server
is part of a cluster, only that MID Server is used; the cluster is not
used. You can add any MID Server regardless of the application it
is assigned to. The Discovery application is automatically added
if is not already assigned for the MID Server you select. You can
assign a specific MID Server for all types of Discover scans except
Service.
• Use Behavior: Use a behavior when a single schedule requires
the use of multiple MID Servers to perform any of the following:
• Scans requiring multiple Windows credentials.
• A schedule that must execute two or more particular protocols
(SNMP, SSH, or WMI) using more than one MID Server.
• Load balancing for large discoveries where a single MID Server
would be inadequate.
• Scanning multiple domains.
Note: The Discovery schedule enforces domain separation.

The MID Servers that are available for selection are limited to
the same domain of the user who is configuring the schedule.
MID Server Select the MID Server to use for this schedule. This field is available
if MID Server selection method is set to Specific MID Server, or if you
discover IP addresses, networks, or web services.
MID Server Select the MID Server cluster to use for this schedule. This field
Cluster is available if MID Server selection method is set to Specific MID
Cluster.
Behavior Select a behavior configured for the MID Servers in your network.
This field is available only if MID Server selection method is set to
Use Behavior.

Field Description
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.
Location Choose a location to assign to the CIs that are discovered by this
schedule. If this field is blank, then no location is assigned.
Max run time Set a time limit for running this schedule. When the configured
time elapses, the remaining tasks for the discovery are canceled,
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.
Run and related Determines the run schedule of the discovery. Configure the
fields frequency in the Run field and the other fields that appear to specify
an exact time.
Note: The run time always uses the system timezone. If you
add the optional Run as timezone field, it has no effect on the
actual runtime.
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 Enter the number of IP addresses that each Shazzam probe can
size 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 value defined in the
maximum range size property for the Shazzam probe.

Field Description
Shazzam cluster Select the check box to distribute Shazzam processing among
support multiple MID Servers in a cluster and improve performance. Works
with the Shazzam batch size. For example, if the cluster contains
100,000 IP addresses and there are 10 MID Server Schedules, every
MID Server will process 10,000 addresses (100,000 IP Addresses/10
MID Servers). If the Shazzam batch size contains the default 5,000 IP
addresses per probe, a Schedule runs two Shazzam probes per MID
Server (10,000 IP addresses/5,000 per batch). This field is available
starting with the Eureka release.
Use SNMP Use this field to designate the SNMP version to use for this discovery.
Version Valid options are v1/v2c, v3, or All.
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 Create a Quick IP
range for a Discovery schedule on page 67.
Discover now Use this link to immediately start this Discovery.
Discovery IP This related list defines the ranges of IP addresses to scan with this
Ranges schedule. If you are using a simple CI scan (no behaviors), use this
related list to define the IP addresses to discover.
Discovery Range This related list defines each range set in a schedule to be scanned
Sets by one or more Shazzam probes.
Discovery Status This related list displays the results of current and past Discovery
schedule runs.
Table 3: Discovery Schedule run options
Run option Description
Daily Runs every day. Use the Time field to select the time of day this
discovery runs.
Weekly Runs on one designated day of each week. Use the Time field to
select the time of day this discovery runs.
Monthly Runs on one designated day of each month. Use the Day field to
select the day of the month. Use the Time field to select the time of
day this discovery runs. If the designated day does not occur in the
month, the schedule does not run that month. For example, if you
designate day 30, the schedule does not run in February.
Periodically Runs every designated period of time. Use the Repeat Interval
field to define the period of time in days, hours, minutes and
seconds. The first discovery runs at the point in time defined in the
Starting field. The subsequent discoveries run after each Repeat
Interval period passes.
Once Run one time as designated by the date and time defined in the
Starting field.
On Demand Does not run on a schedule. Click the Discover now link to run this
discovery.

Weekdays Runs every Monday, Tuesday, Wednesday, Thursday, and Friday.

Use the Time field to select the time of day.
Weekends Runs every Saturday and Sunday. Use the Time field to select the
time of day.
Month Last Day Run the last day of every month. Use the Time field to select the
time of day.
Calendar Quarter Runs on March 31, June 30, September 30, and December 31.
End Use the Time field to select the time of day. To change these
dates, modify the script include DiscoveryScheduleRunType.
After Discovery Allows you to sequentially stagger the schedule. Use this option to
run this schedule after the Discovery designated in the Run after
field finishes. Check the Even if canceled check box to designate
that this discovery should run even if the Run after Discovery is
canceled before it finishes.
• This option is not valid when the Discovery is started via
DiscoverNow, or when using the Discover CI feature.
• You cannot designate an inactive Discovery schedule.
• You cannot create a loop by designating the run after Discovery
to be the same Discovery.
• This Discovery does not run if the Run after discovery does
not finish, with the exception that the Even if canceled box is
checked and the Discovery is canceled.
If you selected a specific MID Server, go to the MID Server dashboard to verify that the MID Server you
select is up and validated.
Run Quick Discovery

Quick Discovery, or 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,
you can select a MID Server. Use this feature to discover new devices in the network as soon as they are
connected to the network, rather than waiting for a regularly scheduled discovery.
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.
You can run DiscoverNow from a Discovery schedule form or from a script.
1. Navigate to Discovery > Discovery Schedules.
2. Click Quick discovery in the header.
A dialog box appears asking for an IP address and the name of the MID Server to use. Only Up and
Validated MID Servers are available.
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 that you enter
a single IP address only and not an entire network, such as 10.105.37.0/24.

When a MID Server is assigned to the subnet containing the target IP address and currently in
an operational status ofUp, the 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.
Attention: If the selected MID Server is part of a load balanced cluster and becomes
unavailable for any reason, the instance does not assign another MID Server from that cluster
to the quick Discovery. You must select another MID Server from the list of appropriate MID
Servers.
4. If no MID Server is defined for that network, select one from the list of available MID Servers.
Figure 3: Quick Discovery Dialog
5. Click OK to run discovery.

The status record for that discovery appears. The Schedule column is empty because no schedule is
associated with this discovery.
Figure 4: Quick Discovery Status List
Run DiscoverNow from a script

You can run DiscoverNow from a script, such as a background job, a business rule, or web services.
Use the following script:
var d = new Discovery();

var statusID = d.discoveryFromIP(TARGET_IP, TARGET_MIDSERVER);
The discoveryFromIP method takes two arguments, IP and MID Server. The IP argument is
mandatory, but the MID Server argument is optional. To choose the MID Server, supply either the

sys_id or name of the MID Server as the argument. If you do not name a MID Server, the system
attempts to find a valid one automatically. A valid MID Server has a status of Up and is capable of
discovering the given IP address. If the system finds a valid MID Server and runs a discovery, the
discoveryFromIP method returns the sys_id of the discovery status record. If no MID Server is capable
of discovering this IP address, the method returns the value undefined.
If you manually specify the TARGET_MIDSERVER, the system validates the given value and ensures
that the MID Server table contains the specified MID Server record. If the validation passes, the
discoveryFromIP method returns the sys_id of the discovery status record. If the validation fails, the
method return the value undefined.
Validate discovery results

Validate the results of your discovery by accessing the ECC queue, analyzing the XML payload, and
checking the Discovery log.
Role required: discovery_admin
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 probes or pattern operations.
1. To view the actual payload of a probe, click the XML icon in a record in the ECC Queue.


2. To view the actual payload of a probe, click the XML icon in a record in the ECC Queue.
3. 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.
Figure 6: Discovery Log
The Discovery Log provides the following information:
Column Information
Created Displays the timestamp for the probe

launched. Click this link to view the record
for the probe launched in this list.
Level Displays the type of data returned by this
probe. The possible levels are:
• Debug
• Error
• Information
• Warning
Message Message describing the action taken on the

information returned by the probe.
ECC queue input Displays the ECC queue name associated
with the log message.
CI The CI discovered. Click this link to display
the record from the CMDB for this CI.

Column Information
Source Displays the probe name that generated the

log message.
Device Displays the IP address explored by the
probe. Click this link to examine all the
log entries for the action taken on this IP
address by this Discovery.
Note:
If you cancel an active discovery, note the following:
• Existing sensor jobs that have started processing are immediately terminated.
• The existing sensor jobs that are in a Ready state, but have not started processing, are
deleted from the system.
MID Server selection sequence for Discovery

The Discovery application follows this sequence to find a MID Server.
MID Server auto-selection
These steps are followed when you select Auto-Select MID Server for the MID Server selection method
on the Discovery form.
1. Discovery looks for a MID Server with the Discovery application that also has an appropriate IP range
configured.
2. If no MID Servers meet these criteria, it looks for a MID Server that has the ALL application that also
has an appropriate IP range configured.
3. If more than one MID Servers meet the above criteria, Discovery chooses the first MID Server with the
status of Up. If more than one MID Servers are Up, it randomly picks one.
4. If none are Up, it uses the default MID Server specified for the Discovery application, assuming it is
Up.
5. If no default MID Server is specified for the Discovery application, it uses the default MID Server
specified for the ALL application, assuming it is Up.
6. If no default MID Server is specified for the Discovery application, Discovery cycles through the same
steps above, but it looks for MID Servers with the status of Paused or Upgrading.
Note: When a MID Server is paused or upgrading, it does not actually process commands
until it returns to the status of Up.
MID Server clusters
These steps are followed when you select Specific MID Cluster for the MID Server selection method on
the Discovery form, and the cluster is a load balancing cluster:
1. Discovery uses the first MID Server in the cluster that Discovery finds with the status of Up.

2. If more than one MID Servers are Up, Discovery randomly picks one. If it cannot find any MID Servers,
Discovery looks for MID Servers in the cluster with the status of Paused or Upgrading.
These steps are followed if the cluster is a failover cluster:

1. Discovery uses the MID Server with the lowest Order value that also has the status of Up.
2. If no MID Servers are found, Discovery looks for MID Servers in the cluster with the status of Paused
or Upgrading, choosing the one with the lowest Order value.
Note: Discovery ignores the default MID Server for the Discovery and ALL applications when
selecting a MID Server from the cluster.
Port scan (Shazzam) phase
During the port scan phase, Discovery collects all of the target IP addresses and splits them equally
between MID Servers matching the criteria mentioned above (meaning the MID Servers are qualified
to do the port scan work). The Shazzam batch size, which you configured on the Discovery schedule,
determines the number of IP addresses that each Shazzam probe can scan. This helps determine how
much work each MID Server does during the port scan phase.
For example, if there are 16,000 IP addresses to scan among three qualified MID Servers, and you use
the default Shazzam batch size of 5000, two MID Servers each handle 5000 IP address scans (1 Shazzam
probe each), and the other MID Server handles 6000 IP address scans by launching two Shazzam probes.
Network Discovery
Network Discovery discovers the internal IP networks within your organization.
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.
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).
Configure SNMP credentials or (optionally) SSH credentials. Port 161 must be open for SNMP access and
port 22 or SSH access.
Network Discovery properties

The following properties control how Network Discovery works.
The default values are correct for most discoveries. Navigate to Discovery Definitions > Properties to
edit the properties.

Table 4: Network Discovery Properties
Property Description Default
BGP Router Exploration Controls whether Network Yes

Disable Discovery exploration of routers
running the BGP protocol
is disabled. Normally such
exploration is disabled, because
of the huge size of BGP routing
tables, and because such
routers typically operate at the
edge of large networks where
further network discovery would
be irrelevant. The only time this
value should be set to no is
in the unlikely case that your
organization uses BGP routers
as edge routers between
relatively small networks, such
as between buildings on a
single campus.

Maximum Netmask Size for The maximum number of 28

Discoverable Networks (bits) bits in a regular netmask for
networks that are 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.
For example, 255.255.255.0 is
regular, and 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 do not 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 causes 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 are not discovered.

Network Router Selection This property controls the Most Networks

Method method used to decide 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).
Physical Interface Types A comma-separated list of 6,117,9,71,209
interface types that should be
considered physical for the
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 is 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 Interface Types Comma-separated list 7,8,9,26,53,62,69,71,78,115,117,209
of interface types that is
considered. Interface type
numbers 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 are
classified as routers, if they
have routing. A complete list
of the interface type numbers
may be found on the IANA web
site, in the list of ifType-MIB
Definitions.

Stale Network Discovery The number of days until -1

Threshold (Days) discovered information about
network gear is considered
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
launches probes to freshen
the information. Otherwise,
it reuses the information
that has already been
discovered. If this number is
negative, then any previously
discovered information is
always considered stale, and
network discovery always
launches probes to freshen the
information.
Network Discovery Debugging Enables extensive logging (for Yes
debugging purposes) of all
network Discovery activities on
the instance. Normally this is
only set to yes by developers.
Run network Discovery

Configure network Discovery to run using a Discovery schedule.
Configure SNMP credentials or (optionally) SSH credentials. Port 161 must be open for SNMP access and
port 22 or SSH access.
1. Navigate to Discovery > Discovery Schedules.
2. Click New and select Networks from the list in the Discover field.
3. Select a MID Server.
This field is mandatory.
4. Complete the form, including the scheduling fields.
5. Right-click in the header bar and select Save from the pop-up menu.
The Related Links and related lists appear.
6. Click Network Discovery Private IPs in Related Links to view the list of default private IP networks in
the Discovery IP Ranges Related List.
The default IP networks in this list are available to every Network Discovery you conduct and are
sufficient for most discoveries.
7. If your organization has additional private IP addresses, click New to add them.

Figure 7: Private IP addresses
8. Add starting routers to the schedule in the Discovery Range Sets list.
a) Click the Network Discovery Auto Starting Routers link to populate the list with the starting
router for each MID Server in your network.

b) Click Edit to add or delete routers from the list.


9. Run Discovery manually, or through the scheduler.
Convert IP networks into Discovery range sets

After you conduct a network Discovery, you must convert the IP networks that were found into range sets
for use in discovering other devices.
1. Navigate to Discovery > IP Networks.
2. Click New to add an IP network.
3. Ensure that the following field values are provided:
• State: Ready
• Discover: true
• Router: Select a router from the list. This field must not be empty.
If your IP Networks were created through network Discovery, then these fields are 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 manually, you must edit these fields
accordingly.

Figure 9: IP network form
4. Click Update to return to the list.

5. In Related Links, click Create Range Sets.
This converts all the IP networks in the list into range sets.

Figure 10: IP network list
The Discovery Status page appears, displaying the progress of the conversion. The system
increments the Started and Completed count of IP networks, until all the networks are converted.
Discover CIs in Amazon Web Services

Before you can configure the schedule to discover CIs in Amazon Web Services (AWS), you must
configure an AWS administrator account in the instance and provide the necessary credentials.
Note: The Amazon Web Services (com.snc.aws) plugin does not need to be active for Discovery
to run on AWS accounts.
Configure the AWS Admin account for your Amazon Web Service
Create an account record in the instance that matches your admin account in AWS. This account record is
necessary for the instance to reach your cloud resources in AWS.
1. Navigate to AWS Discovery > Accounts.
2. Click New.
3. Use the following information to fill out the AWS Account form:
• Name: Descriptive name for this account.
• Account ID: The 12 digit administrator account ID that you receive from Amazon. The Account ID
can be found on your Billing Management Console in AWS, under the Account field.
4. Click Submit.

Configure the credentials for the AWS account

Configure the AWS credentials on the instance. Use the same credentials that appear on AWS.
The instance stores the AWS credentials for the MID Server.
1. Navigate to AWS Discovery > Accounts.
2. Click the appropriate account.
3. Navigate to the Related Links > AWS Credentialstab.
4. Click New.
These credentials populate the AWS Credentials [aws_credentials] table.
5. Use the following information to fill out the AWS Credentials form:
• Name: Descriptive name for this credential.
• AWS Account: This field is auto-populated with the AWS account that this credential is a member
of.
• Access Key ID: Enter the access key ID for this account. See Get AWS credentials for details on
getting the access key ID.
• Secret Access Key: Enter the secret access key for this account. See Get AWS credentials for
details on getting the secret access key.
6. Click Submit.
Create a Discovery schedule for a web service

Configure a Discovery schedule to find the configuration items in one or more Amazon Web Services
(AWS) accounts.
1. Navigate to AWS Discovery > Discovery Schedules.
2. Click New.
Use the following information to fill out the Discovery Schedule form:
Name: Enter a descriptive name for this schedule.
Discover: Select Web Service.
Note: Do not fill in the MID Server field, as MID servers are not used for AWS discovery.
3. Click Submit.
4. Navigate to AWS Discovery > Discovery Schedules.
5. Click the schedule that was just created for this discovery.
6. Under Related Links, in the Web Service Accounts tab, click Edit.
7. Move the AWS account that is to be discovered from the Collection pane to the Web Service
Accounts List pane.
8. Click Save.
Discover CIs in Microsoft Azure

Configure a Discovery schedule to find the configuration items in your Microsoft Azure subscriptions.

Azure discovery
After you run discovery on Azure resources, check the Azure Resource Type [azure_resource_type] table,
which contains the information on all the Azure Resources. Check the Azure Datasource Type Mapping
[azure_datasource_type_mapping] table to see more attributes of discovered Azure CIs.
Configure an Azure subscription for Discovery

Create an account record in the instance that matches your Azure subscription. This account record is
necessary for the instance to reach your cloud resources in Azure.
1. Navigate to Microsoft Azure Discovery > Accounts (Subscriptions).
2. Click New.
3. Use the following information to fill out the Azure Subscriptions form:
• Name: Descriptive name for this account.
• Subscription ID: The subscription ID that you configured in Azure.
4. Click Submit.
Configure Azure service principals for Discovery

Configure Azure service principals on the instance to allow Discovery to find your Azure resources.
• Role required: admin
• A service principal on the Azure portal.
• The Azure client ID and tenant ID, which you obtain from the Azure portal.
1. Navigate to Microsoft Azure Discovery > Credentials (Service Principals).

2. Click New.
3. Fill in the form fields (see table).
Field Value
Name Enter the name of the service principal to register
with the instance.
Tenant ID and Client ID Paste the values that you obtained from the
Azure portal.
Authentication Method Select Client secret.
Note: Client assertion is not supported.
Secret key Paste the secret key that was generated while
creating the Azure Service Principal.
This field appears when Authentication method
is Client secret.
4. Right-click the form header and click Save.

5. Grant Service Principal permission to the subscriptions that you want to manage as described in the
Azure Resource Manager documentation.
6. Click the Get Subscriptions related link.

The instance discovers your organization's Azure subscriptions. This discovery process discovers
only which subscriptions the Service Principal has access to. The process does not discover other
resources.
Create a Discovery schedule for an Azure subscription

Create a Discovery schedule for an Azure subscription to find the resources that the subscription is allowed
to manage.
• Role required: admin
• A service principal associated with an Azure subscription.
1. Navigate to Microsoft Azure Discovery > Accounts (Subscriptions).

2. Open the subscription for which you want to create a Discovery schedule.
3. Click the Create Discovery Schedule related link.
4. On the Discovery Schedule form, specify the schedule for Discovery.
Field Value
Name Name of the Azure subscription that uses the
Discovery schedule that is defined on this page.
Discover Type of resources to discover.
MID server MID server that will manage the Discovery
process.
Active Check box to activate this schedule.
Max run time Overall time period over which the schedule
applies. For example, enter 365 days if you want
this schedule to be used for one year. Specify a
period less than a day using hh:mm:ss format.
Run How often the schedule runs.
5. Click Submit.
Discovery runs and populates your CMDB (configuration management database) and images that you
can later approve to offer to cloud users in the catalog. The current state of the resource, if applicable, is
updated accordingly (for example, Azure virtual machine instances, Azure virtual networks, Azure subnets,
etc.).
Discovery configuration
Configure the elements that Discovery needs to investigate your network, such as credentials, schedules,
and IP addresses.
Discovery can run on a regular, configurable schedule or can be launched manually. A discovery over
a specified IP address range which tells the Discovery application 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 CI.

Discovery configuration procedures
Use the following links to configure Discovery for your environment. You do not need to perform all these
procedures to run a Discovery. The platform provides many defaults you can use to explore your network
that are suitable for most discoveries. To get started quickly with Discovery, you can use Guided Setup,
which expedites the setup of a basic Discovery.
Table 5: Configuration procedures
Discovery properties on page Discovery and SCCM together Discovery Dashboard on page
55 on page 81 156
Discovery IP address Discovery classifiers on page Discovery customization on
configuration on page 66 84 page 168
Discovery domain separation on Discovery identifiers on page
page 76 114
SNMP support for Discovery on Discovery status on page 138
page 78
Discovery properties
Discovery properties allow you to control several aspects of the horizontal discovery process.
Disco properties
Navigate to Discovery Definition > Properties to edit these properties.
Table 6: Discovery Properties
Field Description
glide.discovery.sensors.fire_ssh_probe Fire SSH probe in case the VIPS not return

as part of the SNMP probe payload. Select
this option to use the SSH port on the load
balancer, rather than just using SNMP.
• Type : true | false
• Default value: true

Field Description
glide.eccprobe.awsrestprobe.max_wait Maximum amount of time, in seconds, that

an AWS REST probe continues to attempt
to reconnect with Amazon Web Services
(AWS) after receiving a rate limit exceeded
error. This is the total amount of time used
by all the probe’s retry attempts (from the
glide.eccprobe.awsrestprobe.max_retries
property). The maximum allowable time is 2046
seconds. Setting negative values is equivalent
to setting the maximum value.
• Type: integer
• Default value: 30
glide.eccprobe.max_queued_probes_per_run Maximum node agent queued probes per run:

Sets the maximum number of probes a node
can pick up during a run.
• Type : integer
glide.eccprobe.node_agent_id Node agent ID. Node agent identification string.

ECC queue entries with "mid.server.${VALUE}"
will be picked up and processed by the nodes.
This must be unique and not the same as any
MID server name.
• Type : string
• Default value: NODE_AGENT
glide.discovery.enforce_unique_ips Enforce unique IP addresses Ignores the

IP address after Discovery encounters
subsequent devices that use the same IP
address. Each time a computer, printer,
or network gear with a valid IP address is
discovered, any other devices with the same IP
address have their IP address field cleared. If
disabled, stores the IP address for each device.
• Default value: false

Field Description
glide.eccprobe.awsrestprobe.max_retries Maximum number of reconnection attempts

an AWS REST probe makes after receiving a
rate limit exceeded error from Amazon Web
Services (AWS). The maximum allowable
number of retries is 10. Setting negative values
is equivalent to setting the maximum value.
Note: Retries use exponential backoff

(2^x). For example, the system waits
1 second before the first retry, 2
seconds until the second retry, 4
seconds until the third retry, and so
on, until the total allowed retry time
limit is exceeded. Make sure you
configure enough total wait time in the
glide.eccprobe.awsrestprobe.max_wait
property to allow the maximum number
of retries.
• Type: integer
glide.discovery.discover_aws_ec2_host_metadata When doing IP-based discovery against a

given host, also run probes that retrieve AWS
EC2 metadata.
glide.discovery.enforce_ip_sync Enforce syncing of IP addresses: Sets the first

IP address. Each time a computer with multiple
NICs is discovered, one of the IP addresses
associated with the NICs is chosen as the IP
Address field of the CI. A value of false collects
all NIC IP addresses.
glide.discovery.hostname.always_update Always update host name. If "yes", discovery

will always update the host name with the most
recently discovered value contingent upon the
source being trusted. Note that this may result
in hand-entered values being overwritten.

Field Description
glide.discovery.hostname.dns_nbt_trusted DNS or NetBIOS is trusted host name source.

If "yes", trust the device name discovered via
DNS or NetBIOS. If checked, CI's host name
found via DNS or NBT will be used.
glide.discovery.hostname.ssh_trusted SSH is trusted host name source. If "yes",

trust the device name discovered via SSH. If
checked, any device name found via SSH will
be used <i>instead of</i> the name found by a
reverse DNS lookup.
glide.discovery.hostname.wmi_trusted WMI is trusted host name source. If "yes",

trust the device name discovered via WMI. If
checked, any device name found via WMI will
reverse DNS lookup.
glide.discovery.hostname.snmp_trusted SNMP is trusted host name source. If "yes",

trust the device name discovered via SNMP. If
checked, any device name found via SNMP will
reverse DNS lookup.
glide.discovery.hostname.include_domain Includes domain name in host name. If "yes",

include the domain name as part of the host
name. For example, "bosco.service-now.com"
instead of "bosco".

Field Description
glide.discovery.hostname.case Host name case. If "Lower case" is selected,

always translate the host name into lower case;
if "Upper case" is selected, always translate
the host name to upper case; if "No change"
is selected, leave the host name intact. This
primarily affects host names discovered with
NETBIOS, though some non-standard DNS
systems may also return some or all of the
name in upper case.
• Type : choice list
• Default value: Lower case
• Additional options: Upper case, No
change
glide.discovery.domain.name.nbt Set OS domain name by NBT or WMI. If

"yes", Windows domain name is set by NBT.
Otherwise it is set by WMI.
glide.discovery.discover_software Discover software packages. Enable the

discovery of software packages.
• Learn More: Data collected by Discovery
on general software packages on page
398
glide.discovery.application_mapping Application mapping. Enable the application

mapping portion of Discovery
Attention: Disabling this property

disables the creation of relationships
between applications but does
not disable the ADM probes and
sensors, nor does it prevent process
classification.

• Learn More: Application Dependency
Mapping (ADM) for Discovery on page
173

Field Description
glide.discovery.active_processes_filter Active Processes Filter: Optimization for

application dependency mapping. Filters the
active processes returned by Discovery to
only those that have a match in the Process
Classification table.
glide.discovery.sensors.save_attachments Save ECC queue attachments: The normal

behavior for discovery sensors is to delete
attachments to ECC queue entries upon
successful sensor processing. Setting this
property to "yes" overrides this behavior, and
forces attachments to be preserved. This
would normally only be useful for debugging
purposes.
glide.discovery.max_range_size Max range size: The maximum number of IP

addresses that a Discovery schedule can scan.
If a schedule exceeds the default number of
100,000 thousand IP addresses, the schedule
does not run.
• Type : integer
• Learn More: Configure Shazzam probe
parameters on page 244
glide.discovery.bgp_router_disable BGP router exploration disable. Controls

whether Network Discovery exploration of
routers running the BGP protocol is 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).

Field Description
glide.discovery.debug.ci_identification CI identification debugging: if true, enables

debug logging (into the CI Identification Log) for
CI Identification.
glide.discovery.network_owner_method 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).
• Type : choice list
• Default value: Most Networks
• Additional options: First Router, Last
Router, Least Networks
glide.discovery.physical_interface_types Physical interface types: A comma-separated

list of interface types that will be considered
"physical" for the 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.
• Type : string
• Default value: 6,117,9,71,209

Field Description
glide.discovery.switch_interface_types Switch interface types. List of interface

types (comma-separated) that will be
considered Interface type numbers 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".
• Type : string
• Default value:
7,8,9,26,53,62,69,71,78,115,117,209
glide.discovery.virtual_interface_types Virtual interface types. List of interface types

(comma-separated) that will be considered
"virtual" for the 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 virtually connected to that
device. The default interface types include the
propVirtual type. Interface type numbers are
defined in the SNMP MIB-2, specifically in OID
1.3.6.1.2.1.2.2.1.3.
• Type : integer
glide.discovery.debug.network_discovery Network discovery debugging: Enables

extensive logging of all Network Discovery
activities on the instance.
• Learn More: Discovery troubleshooting on
page 479

Field Description
glide.discovery.discoverable.network.max.netmask.bits
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.
• Type : integer
glide.discovery.network_discovery.functionality Networks discovery functionality: the

Functionality used to discover networks.
Usually this should be "SNMP only".
• Type : string
• Default value: SNMP only
glide.discovery.log_message_length Log Message Length. Limit the maximum

message length that will be displayed in
Discovery Log table. A value of 0 or any
negative number will disable this limit.
• Type : integer
• Learn More: Discovery logs on page 151

Field Description
glide.discovery.roundingInterval.cpu CPU speed rounding: Enter the number to

round the CPU speed to. The units are in MHz.
• Type : integer
glide.discovery.roundingInterval.ram Memory rounding: Enter the number to round

the computer RAM to. The units are in MB.
• Type : integer
glide.discovery.ip_service_affinity IP service affinity: If "yes", IP service affinity will

be enabled. IP service affinity allows Discovery
to remember the last port of the IP address that
was discovered.
glide.discovery.fqdn.regex DNS Host Name And Domain Name Regex.

The default parsing of FQDN (Fully Qualified
Domain Name) is to pick the first name
separated by dots as the host name and
the rest of the names as the domain name.
For example, "machine1.testlab.service-
now.com" has host name of "machine1" and
domain name of "testlab.service-now.com".
The property allows regex with two capturing
groups with the first group representing the
host name and the second group the domain
name.
• Type : string
• Default value: ^([^.]+)\.((?:[^.]+\.)+[^.]+)$
glide.discovery.use_probe_results_cache Use probe results cache: If set to yes, the

cache will be checked to see if the results of
the probe need to be processed by a sensor.
It will only need to be processed if the results
have changed from the last discovery run.

Field Description
glide.discovery.max_concurrent_invocations_per_schedule
Maximum concurrent invocations per
schedule: Prevents an unbounded number of
invocations from inundating the system when
a schedule takes longer than the time between
invocations. The value is an integer defining
the maximum number of automated invocations
of the same schedule that may proceed at one
time. If the limit has been reached subsequent
scheduled invocations will be cancelled. The
default value is 3. A value of 0 or any negative
number will disable this restriction.
• Type : integer
glide.discovery.warn_minor_version Warn on Minor Version Mismatch. If "yes",

warnings will be logged when minor_version
mismatches are detected during Discovery
sensor processing.
glide.discovery.L3_mapping Map servers and network devices to routers

and layer-3 switches If the "L3 mapping"
property is enabled, it will map servers and
network gears to its associated routers and
layer-3 switches.
• Learn More: Network Discovery on page
41
glide.discovery.software_sccm_managed Windows software is SCCM managed: If

"yes", Discovery will not populate software for
computer CIs also managed by SCCM.
• Learn More: Discovery and SCCM together
on page 81
glide.discovery.use_cmdb_identifiers CMDB Identifiers: If "yes", identification and

reconciliation will be handled by the CMDB
API instead of through the old Discovery
implementation.
• Type: true | false

Discovery IP address configuration

Use one or more of these methods in any combination to define the network or network segment for
Discovery to query.
Note: If you do not know the IP addresses in the network, run Network Discovery on page 41
first to determine the IP networks. Then, convert the IP networks into IP address range sets.
IP address list
Use IP address lists to add individual addresses for Discovery to query. 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 MID Server system.
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. However, Discovery has no way of knowing if the IP range
includes addresses for private networks or broadcast addresses and scans 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. Include only those IP addresses in your range that are 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.
IP address selection properties

You can use system properties to control the selection of IP address for specified CI classes.
Use these properties to determine if the system should replace the IP address returned by Discovery in
a device's CI record if the address does not match that of a network interface (NIC) on the device. This
is important for the discovery of devices with management IP addresses that differ from IP addresses
associated with one or more NICs on the device. Because a device's management IP is used in the
Discovery schedule for that device, this is the address that Discovery returns. Use these properties to
determine which IP address to use for CIs of any class.

Property Description
glide.discovery.enforce_ip_sync Prevents the system from using a discovered

IP address in the CI record if the address
doesn't match that of a NIC on the device. If
this property is true, Discovery checks the IP
address returned to determine if it is associated
with a NIC on the device. If the address is not
associated with a NIC, Discovery uses the IP
address from one of the NICs instead.
glide.discovery.exclude_ip_sync_classes Defines CI classes whose IP addresses should

not be substituted if the address returned by
Discovery does not match one of the devices'
NICs. Use a comma separated list to define
multiple classes. By default, the system uses
the management IP of a load balancer returned
by Discovery in the CI record, rather than
substituting it for the IP address of one of the
load balancer's NICs.
• Type: string
• Default value: cmdb_ci_lb
Create a Quick IP range for a Discovery schedule

Quick ranges allow administrators to define IP addresses to scan in a single comma-delimited string
without creating separate records.
Only MID Servers that are up and validated are used with quick ranges. The MID Servers must specify
the Discovery application (or ALL applications) and have IP ranges configured if you use the auto-select
feature on the Discovery schedule.
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. 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.
1. Click the Quick Ranges related link on the Discovery Schedule form.
2. Enter the 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.

Figure 11: Discovery Quick Ranges
The instance automatically displays the entries in the proper format.

4. To make any changes to IP address ranges, select the IP address records.

Figure 12: Discovery IP Ranges
Import IP ranges into Discovery schedules with import sets

The most efficient method of entering large numbers of IP networks into Discovery schedules is through
the use of import sets.
Common groups of IP addresses, known as ranges can be used in Advanced Discovery schedules.
Use a data source that can be mapped, such as an Excel spreadsheet (network.xls in the following
example).
Figure 13: Sample XLS file
1. Navigate to System Import Sets > Load Data.

2. Identify the file or data source that contains the desired information.
3. Create a new table name, such as ipnetworks.
4. Select Upload an Excel file and browse to the source file.
5. Click Go to import the file.

Figure 14: Data Source
6. Navigate to System Import Sets > Create Transform Map and map the items in the
Excel spreadsheet to the fields of the CMDB in the target table Discovery IP Range
[discovery_range_item] table.
7. Give the Transform Map a unique and descriptive name.
Figure 15: Table Transform Map 1
8. Submit the form, and then click New in the Field Maps Related List.
9. Map the fields from the Excel spreadsheet to the fields in the Discovery IP Range
(discovery_range_item) table using the following field names:
• RangeName to Discovery Range
• IP to Network IP
• mask to Network Mask (or Bits)
• type to Type. Note that the type field is case sensitive.
The display names are different from the actual field names that appear in the Field Maps list.

Figure 16: Table Transform Map 2
10. Click the Mapping Assist Related Link and use the lists that appear to resolve the fields between the
table and the data source (the Excel spreadsheet in this example).

Figure 17: Mapping Assist
This produces the complete map between the data source and the fields to populate in the CMDB.
11. Click Save.
The view returns to the Table Transform Map form.
12. Click Transform in the Related Links to move the data into the proper fields in the Discovery IP Range
(discovery_range_item) table.
The imported IP ranges are available now for use in any advanced Discovery schedule.

Exclude 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.

Figure 18: Exclude IP Address
The Discovery IP Range form appears.

Figure 19: Exclude IP Address 1
2. In the Discovery Range Item Excludes related list, click New.

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

An entry form for the IP addresses to exclude appears.

6. Enter the IP address to exclude, and then click Submit.
The excluded IP address appears in the Discovery Range Item IPs related list for that IP address
Type.
7. Click Update to save the excluded address and return to the Discovery Schedule.
Discovery domain separation

Configuration item (CI) data that Discovery collects can be separated into domains.
How Discovery domain separation works
Discovery implements data domain separation through the MID server by impersonating the MID Server
user during sensor processing. Discovery uses the domain that the MID Server user is in to determine
which domain the discovered data should be put into. Discovery configuration information, including
classifiers, identifiers, probes, and sensors, is not domain separated.

Domain separation for Discovery is available starting with the Helsinki release.
Note: Discovery of Amazon Web Services and Microsoft Azure cloud resources does not support
domain separation because MID Servers are not used.
Domain separation for MID Server files
You can create versions of these specific MID Server policy records that only a MID Server from the
same domain can use. This process separation is supported for records in tables that extend MID Server
Synchronized Files [ecc_agent_sync_file]:
• MID Server MIB File [ecc_agent_mib]
• MID Server JAR File [ecc_agent_jar]
• MID Server Script File [ecc_agent_script_files]
By default, all records in these tables are members of the global domain. A user can override the default
global domain and create a version of these policies for use in the user's own domain.
Note: Attachments on MIB or JAR file records might not appear as they did in a non-domain
separated environment. This occurs because the Attachments [sys_attachment] table is data
separated. When data is separated between domains, a record in a child domain cannot access
records in a parent domain.
Domain separated tables
Records in all tables that extend the Base Configuration Item [cmdb] table can be domain separated. In
addition, records in these tables can also be domain separated:
• Serial Number [cmdb_serial_number]
• TCP Connection [cmdb_tcp]
• Fibre Channel Initiator [cmdb_fc_initiator]
• Fibre Channel Targets [cmdb_fc_target]
• IP Address to DNS Name [cmdb_ip_address_dns_name]
• Service [cmdb_ip_service_ci]
• KVM Virtual Device [cmdb_kvm_device]
• Load Balancer Service VLAN [cmdb_lb_service_vlan]
• Load Balancer VLAN Interface [cmdb_lb_vlan_interface]
• Switch Port [cmdb_switch_port]
Set up domain separation for MID servers

Set up domain separation through the MID server user role and the MID Server configuration file.
Role required: admin, agent_admin
1. Configure a MID Server user within a specified domain with the proper mid_server role.
2. Specify this user within the MID Server config.xml file. When you set the MID Server user
credentials in the config.xml file, make sure they are in the proper domain.
When the MID Server connects to the instance, the MID Server record is created in the proper domain.
If you must change the MID Server domain:
1. Stop the MID Server and delete the ecc_agent record.

2. Update the MID Server config.xml with the new user in the new domain and restart the MID Server
service.
If you need to create versions of specific MID Server files that only MID Servers in your domain can use:
1. Open or create a record in one of these MID Server modules:
• SNMP MIBs
• JAR Files
• Script Files
2. Update an existing domain policy or submit a new record. The system overrides the global domain
configuration with your domain and saves a new copy of the record. The MID Servers in your domain
can only access records in the global domain and records overridden by your specific domain.
Note: Attachments on MIB or JAR file records might not appear as they did in a non-domain
separated environment. This occurs because the Attachments [sys_attachment] table is data
separated. When data is separated between domains, a record in a child domain cannot
access records in a parent domain.
SNMP support for Discovery

Discovery supports SNMP versions 1, 2c, and 3. Discovery uses version 1 and 2c by default. You must
enable support for version 3.
MID Servers support all SNMP protocol versions by default. You can set a MID Server to support only
specific versions of SNMP.
Add an SNMPv3 user credential in Discovery

Set up your credentials so Discovery can access SNMPv3 targets.
A MID Server parameter is also available to control SNMP versions. See MID Server parameters.
1. Navigate to Discovery > Credentials.
2. Click New.
3. Click SNMPv3 Credentials.
4. Use the following table to fill in the form.
This form creates an entry in the SNMPv3 credentials table. The SNMPv3 credentials table stores the
credentials.

Figure 23: SNMPv3 credentials form
Table 7: SNMPv3 credentials form
Field Input Value
Name Unique and descriptive name for this

credential.
Active If the credential can be used. Select this box
to activate the credential.

Field Input Value
User name The user name to authenticate to the

target devices. This selection must match
the name that is set on the devices to
be discovered. 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. A warning appears if the
platform detects leading or trailing spaces in
the user name.
This is the only required field.
Authentication protocol The encryption protocol. This selection must

match the encryption protocol that is set on
the devices to be discovered. Valid options
are:
• None: No encryption is used.
• MD5 (Message Digest version 5)
• SHA (Secure Hash Algorithm)
See the SNMPv3 security options table

below to configure the type of security.
Authentication key The authentication key that is set on the
target devices.
Privacy protocol The encryption standard. This selection
must match the encryption standard that is
set on the devices to be discovered. Valid
options are None, AES128 (standard AES),
AES192, AES256, DES, or 3DES.
Privacy Key The privacy key that is set on the target
devices.
Tag The name of a credential tag.
Applies to The MID servers that use this credential.
You can choose All MID servers, or you
can create a list of Specific MID servers.
Order The order in which the credentials are tried,
if there is more than one credential for a
given type.
Table 8: SNMPv3 security options
Option Fields to configure
noAuthNoPriv security • Authentication protocol: None

• Privacy protocol: None
• Authentication Key: Leave blank
• Privacy Key: Leave blank

Option Fields to configure
authNoPriv security • Authentication protocol: Set

• Privacy protocol: Leave blank
• Authentication Key: Set
• Privacy Key: Leave blank
authPriv • Authentication protocol: Set

• Privacy protocol: Set
• Authentication Key: Set
• Privacy Key: Set
Set SNMP version on the Discovery schedule

You must also add an SNMPv3 credential if you set the SNMP version to v3 or All.
1. Navigate to Discovery > Discovery schedules> your Discovery schedule.
2. In the Use SNMP Version field, select the appropriate version.
Valid options are v1/v2c, v3, or All.
Discovery and SCCM together

Use these guidelines to avoid common issues when you use Discovery and System Center Configuration
Manager (SCCM) together.
You must decided if you will use Asset Intelligence (AI) or non-AI software data sources. Because the
software correlation data is tracked differently for each of these data sources, you should avoid switching
back and forth between the two. If you must switch between data sources, remove all the software
installation records imported by SCCM before the switch occurs. For general information about the SCCM
integration, see Microsoft SCCM integration
When Software Asset Management is not enabled, software installation records are stored in the Software
Instance [cmdb_software_instance] table. When Software Asset Management is enabled, software
installation records are stored in the Software Installation [cmdb_sam_sw_install] table.
Note: If records are not removed before the switch, duplicate records may exist. In the event that
AI and non-AI data becomes mixed, clear the Software Installation table.
Upgrading to another version
The ServiceNow SCCM integrations are self-contained and can exist independently. They each use their
own import set tables, data sources and transform maps. However, all SCCM integrations will transform
data into the same tables within the ServiceNow CMDB. To avoid the data being overwritten by another
source:
• Use one SCCM integration and disable all other SCCM scheduled imports.
• Perform a full import to clear the cmdb_software_instance table, the cmdb_sam_sw_install table, and
other tables of old SCCM data.

Note: It is possible to configure each plugin to integrate with SCCM 2007 or 2012 because the
mechanism of the integration is actually the same, which is to leverage Java Database Connectivity
(JDBC) imports. However, the data sources will need to be modified if a plugin is to be used for an
SCCM version they’re not written for. Starting with Fuji, it is recommended to use the plugin version
that corresponds to the SCCM version it is designed to integrate with.
To change the SCCM integration:

• Disable the current integration by deactivating the SCCM import schedule.
• Activate the new SCCM plugin.
• Reimport all the software records when you are switching to an integration that supports incremental
imports of removed software.
For instructions on disabling the current SCCM import schedule, see Upgrade the SCCM integration
version
Activate SCCM Asset Intelligence scheduled imports

To prevent duplicate software imports, activate either the Asset Intelligence (AI) or the non-AI scheduled
import.
For the best results, limit the software import frequency to be no greater than the frequency of the table
cleanup that tracks deleted software in SCCM.
Asset Intelligence is supported in these SCCM plugins:
• Integration - Microsoft SCCM 2007
• Integration - Microsoft SCCM 2012 v2
Important: To improve the performance of your initial SCCM import, you can prevent the
system from checking against deleted software prior to the import date. Navigate to Integration
- Microsoft SCCM <version> > Data Sources > SCCM <version> Removed Software and
enter the current date in the Last run datetime field. This field is populated automatically for each
subsequent run of the removed software data source.
To activate the AI scheduled imports:

1. Navigate to the System Import Sets > Administration > Scheduled Imports.
2. Set Active to false for these data import schedules:
• SCCM <version> Software
• SCCM <version> Removed Software
3. Set Active to true for these data import schedules:

• SCCM <version> Software (with AI)
• SCCM <version> Removed Software (with AI)


Collect software data with either SCCM or Discovery

When Discovery and SCCM are both enabled on a system, the software records found through both tools
could overwrite each other.
To determine how software data is collected:
1. Navigate to Discovery Definition > Properties.
2. Set the Windows software is SCCM managed property (glide.discovery.software_sccm_managed)
appropriately.
If this property is set to Yes, software for computer CIs is populated in the CMDB by SCCM. An
internal process determines that the computer is managed by SCCM, and Discovery does not
populate the software records for Windows software data. The following information level message is
written to the Discovery log file.
Skipping software population because the CI is managed by SCCM
If the check box is cleared, the property is set to No, and the system manages software data with
Windows.
3. Click Save.
Important: If SCCM Integration is active before Discovery is enabled and the property is
enabled, Discovery ignores the population of software for any CIs that are also imported
through SCCM. If Discovery is enabled before the SCCM Integration, it is possible for software
installation data from both sources to be mixed.
Discovery classifiers
A classifier tells Discovery which probes to trigger for the identification and exploration phases of
discovery. Classifiers can also trigger the Horizontal Pattern probe, which launches a pattern, rather than
additional probes, for identification and exploration.
The classifier essentially starts the identification stage. Discovery uses it after the classification probe
returns important parameters to the instance that tell Discovery what to do next.
In most cases, you do not need to create a classifier or modify a classifier. But if you are having trouble
with Discovery, you might want to check the conditions that determine when a classifier runs based on the
parameters the classification probe returns to the instance. Or if you want to discover a new type of CI that
Discovery does not already find, you can create your own classifier.
Device, process, and IP address classification
Discovery classification can be broken down into three types: device classification, process classification,
and IP address (or IP scan) classification:
Device classification The classification of actual device types, such as

a computer running Windows, a computer running
a flavor or UNIX or LINUX, a router, a switch, or a
load balancer, and so on.
When Discovery identifies a computer CI, it triggers
an active processes probe to explore the computer
CI further. Discovery compares the results of the

active processes probe to the process classification

conditions to determine if there is a match.
Figure 25: Computer CI classification workflow
Process classification The classification of applications based on the

processes that are running.
Discovery classifies processes during the last
phase of discovery: the exploration phase,

after identifying devices in the Computer

[cmdb_ci_computer] table and its extensions. Just
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.
If a process matches the classification criteria,
Discovery determines whether to run the process
handler script. The process handler script modifies
the parameter data to help Discovery identify
whether the process represents an existing or
new application CI. Discovery process handlers
prevent the creation of duplicate CIs by filtering
out parameters known to have inconsistent values
before process classification occurs. Every time
Discovery adds or updates an application CI, it also
determines the application dependency mapping of
the application CI to other CIs in the CMDB.

Figure 26: Process classification workflow
IP address (IP scan) classification IP address discovery is credential-less, meaning

that it attempts to identify devices and software
based on just the open ports and banners it finds
without requiring you to create credentials. 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.
In the default Discovery system, the Linux classifier
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 an IP scan (no
identifiers):


See Classification for IP address discovery on page 102 for more details about the parameters available
to classifiers for this type of discovery.
Classifier criteria
Classifiers also provide criteria that you can use to specify when Discovery should use the classifier under
the conditions that you define. The criteria is based on the parameters that a classify probe returns to
Discovery. Criteria is constructed with the parameter, an operator, and a value.
Classifiers and patterns
Discovery can use patterns, rather than probes, to identify and explore CIs. Discovery triggers patterns
from the Horizontal Discovery probe, which can be specified on a classifier. You can create you own
patterns and add them, via the Horizontal Discovery probe, to a classifier. See Add the Horizontal Pattern
probe to a classifier on page 210 for instructions. You might already be using one of the out-of-box
patterns that are provided with Discovery. You can verify this by looking at the classifier to see if the
Horizontal Pattern Probe is specified.
Logging classification debugging information
To log debugging information about classifications, add the following system property. The resulting log
entries list the name of each classifier that runs, along with all the names and values that are available to
the criteria in the classifier.
System property Description
glide.discovery.debug.classification Enables debugging information for process

classification.
• Default Value: false
• Location: Add to the System Properties
[sys_properties] table
What you can do with Discovery classification
• Create or modify a discovery classifier if you want to classify CIs that Discovery does not already
classify, or trigger other probes that are not already on a classifier. You can modify classifiers that
Discovery uses in standard CI discovery, process classifiers for applications, and classifiers based on
IP address scans.
Before you modify any classifiers, review the parameters that are available for each type of classifier.
• If Windows machines are on your network, you can use the WinRM protocol, rather than WMI, for more
efficient lightweight data transfer and remote command execution. By default, Discovery uses WMI.
For instructions on the classifier modifications you can make to use WinRM, see Use Windows Remote
Management for classification on page 107.
• If you have Windows computers that are acting as servers and you want them to be classified by their
function rather than by the operating system, you can make changes to the criteria of the Windows
classifier. See Reclassify a Windows Workstation machine as a server on page 109 for instructions.

Create a Discovery CI classification

A CI classification allows Discovery to identify and explore servers running most common operating
systems, network devices when a CI Discovery is run. Create or modify CI classifications if you want
classify something new that Discovery does not already find, or to trigger different identification or
exploration probes.
1. Navigate to Discovery Definition > CI Classification.
2. Select the type of classification to create.
Classifier type Description
CIM These classifiers trigger CIM probes that

identify and explore storage servers and
devices.
Process These classifiers trigger probes that identify
and explore a large variety software, such
as web servers and databases. See Create
a Discovery process classification on page
96 for instructions on creating this type of
classifier.
Process Handlers Filters that prevent the creation of duplicate
CIs. See Create a Discovery process
handler on page 101 for instructions on
creating this type of classifier.
Scan Results CI These classifiers trigger probes that identify
and explore various network devices and
computers that other classifiers do not
handle. These include Solaris machines,
printers, IP phones, and AIX servers.
Scan Results Application These classifiers trigger probes that identify
and explore a few generic applications
that other classifiers do not handle. These
include mail server software discovered
through IMAP and Nagios monitoring
software.
SNMP These classifiers trigger probes that identify
and explore network devices, such as
routers and switches.
SNMP System OIDs The OIDs that Discovery uses to identify
devices.
UNIX These classifiers trigger probes that identify
and explore computers running different
flavors of UNIX-based operating systems.
Windows These classifiers trigger probes that identify
and explore computers running different
versions of Windows.
3. Click New in the list of classifications for the type you selected.
4. Fill out the form fields (see table):

Field Input Value
Name Name of the configuration item (CI).

OID SNMP system OID for matching this
device. When the OID value matches that
of an SNMP device, Discovery uses the
information to populate the CMDB with
the specified Manufacturer, Model, and
Classifier.
Operator Operator for determining how to match and
SNMP OID. The choices are Is and Starts
with. This field is available only for SNMP
System OIDs classifiers.
Active Enables or disables this classifier. When
a classifier is disabled, the system stops
classification at this level and does not
launch classifiers of a lower order. For
example, when the classifier for Windows
2008 Server is disabled, the system stops
Discovery at this point and does not launch
the Windows 2012 Server classifier.
Order Order (sequence) in which the platform run
this classifier.
Table Table for this classification. For example, if
this record classifies a Linux server, select
the Linux Server [cmdb_ci_linux_server]
table.
Classifier Classification of an SNMP device, such as
A10 Load Balancer. This field is available
only for SNMP System OIDs classifiers.
Relationship type Type of relationship for this classifier, such
as Runs on::Runs. This field is available
only for application and process classifiers.
Match criteria Criteria that must match to classify this
device. The choices are Any of the
parameters or All of the parameters.
Manufacturer Name of the manufacturer of a network
device. This field is available only for SNMP
and SNMP System OIDs classifiers.
Model Model number of a network device. This
field is available only for SNMP and SNMP
System OIDs classifiers.

Field Input Value
On classification script Script that runs if classification criteria

are met. Use this script to perform any
special tasks after a device is classified. It is
possible to use the g_probe_parameters
hashmap from within a classification script
to set probe parameters for any configured,
triggered probes. For example, this code
sets a 'node_port' parameter to 16001 for all
triggered probes:
(JS),
g_probe_parameters['node_port']
= 16001; //
Related lists
Classification Criteria Criteria 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. See
Discovery classification parameters on page
112 for a list of the parameters you can
use for the criteria.
SNMP OID Classifications Unique fingerprints of all the SNMP devices
that ship with the base Discovery product.
Users can add OIDs for SNMP devices not
in this list. This related list is available only
for SNMP devices.
Triggers probes Probes that Discovery launches to identify
and explore detailed information about
a CI that it has classified in the network.
If you want to use patterns for horizontal
discovery, add the Horizontal Pattern probe
in the Probe column, and then specify your
pattern in the Pattern column.
Warning: Do not specify your

pattern in Probe column. You
must chose the Horizontal Pattern
probe, which launches the specified
pattern.
Versions Lists versions of this classifier. A new

version is created whenever you modify
the classifier record. To revert to a previous
version, open that record and select Revert
to this version under Related Links.
5. Right-click the header and select Save.

6. Optional: Use the Classification Criteria related list to create criteria that determines when the probes
in the Triggers Probes related list are launched.
a) Click New.

b) Type in the appropriate parameter, select an operator, and enter a value to use for this
classification. Operators include:
Table 9: On Classification script objects
Parameter Description
isNode Indicates if this instance is a node.

type Returns the classification windows.
isVIP Indicates if this CI is a virtual machine,
with a virtual IP address.
ip_address Returns the IP address of the device
being discovered.
name Name of the Windows version, such as
Windows 2003 Standard.
regex matches Use this operator to create a regular
expression to conduct a complicated
search on a string.
in IPs Find a single IP address in an IP
address range, network or list.
Possible formats are: 10.10.10.0
- 10.10.10.255; 10.10.10.0/24; or
10.10.10.0, 10.10.10.1, 10.10.10.2.
c) Click Save to return to the Classification form.
This example shows a completed CI classification form with exploration probes defined.
For instruction on creating probes, see Discovery probes and sensors on page 211. The
probes defined here are launched when the device is properly classified, unless Discovery
is configured to stop after classification.


Run a CI type discovery through the Discovery Schedule.
Create a Discovery process classification

A process classification allows Discovery to create a particular CI type from information gathered during
the identification and exploration phases.
When a process matches the classification criteria, Discovery uses the process classification record to
create a CI. You can also have Discovery update existing CIs or ignore certain processes by creating a
process handler.
1. Navigate to Discovery Definition > CI Classification > Process.
2. Click New.
3. Enter the classification fields (see table).
Table 10: Classification fields
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 Server ESX::Server ESX
virtualizes server001.

Field Input value
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.
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.
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 On classification script objects for
Discovery on page 100 for more examples
and for a list of the objects you can use in
this kind of script.

Field Input value
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.
If you want to use patterns for horizontal
discovery, add the Horizontal Pattern probe
in the Probe column, and then specify your
pattern in the Pattern column.
Warning: Do not specify your

pattern in Probe column. You
must chose the Horizontal Pattern
probe, which launches the specified
pattern.
Applications Use this related list to view the application

CIs that match this process classification.
Test results Use this related list to view the how
Discovery classifies processes on the Test
with host and build better classification
conditions.
Parameters Use this related list to view the parameters
associated with this process and build better
classification conditions. See Discovery
classification parameters on page 112 for
a list of the parameters you can use.
Versions Use this related list to view previous
versions of the process classification record.
4. Right-click the header bar and click Save.

5. Enter items from related lists.
6. Click Update.


On classification script objects for Discovery

Use an On classification script in a process classifier to customize an application record. This kind of script
is used in a process classifiers.
Renaming the default application name
By default, application names are in this format: <name of the process classifer>@<the name
of the computer CI where the process resides>;
For example, for a MySQL server running on a computer called machineA, the application is named
mysql@machineA.
You can use the On classification script field in the process classifier record to change the default
application name to match your business needs. For example, the following script changes the default
application name to include a suffix after the process classifier:
var computerName = g_sensor.deviceGR.name;

var processClassiferName = g_classification.name;
current.name = processClassiferName + "999" + "@" + computerName;
In this example, the name of the application record becomes mysql999@machineA.

Another common technique is to set the application name based on the name, command, and parameter
variables. For example, an Eclipse process might have the following values in these variables:
name "eclipse"
command "/glide/eclipse/Eclipse.app/Contents/MacOS/
eclipse"
parameter "-psn_0_1884620"
If an Eclipse application runs on a computer called machineA, ServiceNow names the application
eclipse@machineA. The following script appends the parameter value as part of the application name.
var computerName = g_sensor.deviceGR.name;

var processClassiferName = g_classification.name;
current.name = processClassiferName + parameters + "@" + computerName;
In this example, the name of the application record becomes eclipse-psn_0_1884620@machineA.
Sometimes it is useful to pass values to the triggered probes in the process classification. You can do
this by creating a custom script that defines a name/value pair for the g_probe_parameters object. For
example:
g_probe_parameters['processCommand'] = command;
In this example, when a classification record triggers a probe, the script passes the probe a parameter
called processCommand with the value of the command variable.
Script objects
Use these objects in the script:

Script object Description
current Points to a JavaScript object with its

[property:value] pair to update the application
record. (It is not an actual GlideRecord object of
the application.)
g_sensor Points to the running process sensor class. This
object contains a deviceGR object, which points
to the computer CI record on which the process
resides.
g_classification Points to the process classifier record itself.
name Points to the process name.
command Points to the process command.
parameters Points to the process parameters.
g_probe_parameters A JavaScript object that will allow parameter
passing to the triggered probes.
Create a Discovery process handler

Process handlers prevent the creation of duplicate CIs by filtering out parameters known to have
inconsistent values before process classification occurs. You can create new classifiers or edit existing
ones.
1. Navigate to Discovery Definition > CI Classification > Process Handlers.
2. Click New.
3. Complete the fields on the Process Handler form.
Table 11: Process Handler form
Field Description
Name Enter a unique name for the process

handler record.
Active Select the check box to run the process
handler.
Classify • Select the check box to enable
classification of any Running Process
[cmdb_running_process] record
that matches this Process Handler's
conditions.
• Clear the checkbox to disable
classification of any Running Process
[cmdb_running_process] record
that matches this Process Handler's
conditions.
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.

Field Description
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.
Your instance uses the key_parameters
field, together with the process name, to
determine whether the process is unique on
a specific machine.
See On classification script objects for
Discovery on page 100 for additional
examples.
4. Click Submit.
Classification for IP address discovery

Discovery provides a way to classify devices it finds through IP address discovery, even when no
credentials are available.
When you run a discovery for IP addresses, as opposed to a CI discovery, the Discovery application
makes certain assumptions about devices and the applications running on those devices from the ports
that it finds open. Classification parameters for this type of Discovery are generated differently from scans
in which credentials are available.
The syntax for creating parameters is derived from the fields returned by the Shazzam probe when
conducting a Discovery for IP addresses. Parameters for CIs and applications are formed in the same way.
The Shazzam probe creates an XML file containing the following fields:
• name
• port
• portprobe
• protocol
• result
• service
Note: Optional fields that can be used to form parameters appear as child tags beneath the default
fields. Example of these are the sysDescr and banner_text fields.
Parameters are expressed in the form of <portprobe.service.field>. The value for field can come from any
of the fields or child tags in the XML file. For example, the following parameters classify a device as a UNIX
server and detect an installation of MySQL:
• ssh.ssh.result
• mysql.mysql.result

These parameters were derived from the values in the following XML file generated by a Shazzam probe
conducting an IP Scan. The result field returned a value of open for ports 22 and 3306 on the target device.
The service field indicates the services that normally communicate over those ports.
The sysDescr field can provide additional information about devices, depending upon the manufacturer.
This XML file from the Shazzam probe reveals the following about port 161 on the device at IP
10.10.11.149:
In the classification criteria, we can construct the following parameter with sysDescr that returns an Apple
AirPort wireless router:
snmp.snmp.sysDescr contains Apple AirPort

Modify classifiers for IP address discovery

When you run an IP address type of discovery, port probes scan devices without the use of credentials,
and then Discovery can determine which classifiers to use. You can add port probes and additional
classifiers for IP address discovery.
Although no credentials are required to scan for Windows or UNIX devices with this type of scan,
credentials are still required for SNMP devices. By determining which ports are open on the devices that
it scans, IP address classification can discover such things as the type of device (computer, UPS, etc.),
operating system, running applications, and version numbers.
Note: IP address classification attempts to classify devices when no credentials are available;
however, Discovery will use credentials when they are available, even when IP address
classification is configured.
To use IP address classification, follow these steps:

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

2. Add an IP Service and port probe.

The out-of-box system supplies probes for some of the most common ports, but additional port probes
will be needed for effective IP address scanning.
1. Navigate to Discovery Definition > IP Services and click New.
2. Create a new IP Service record using the port number and service from the Nmap scan. In this
example, we associate the mysql service with port 3306 and add the CI (sanops02) on which the
service runs to the Available on Related List.
3. To use Basic Discovery, navigate to Discovery Definition > Functionality Definition and select
the record for All.
4. Add the new port probes to the list. This tells Discovery which port probes to run for IP address
scans.

Figure 30: Discovery Functionality Def
5. Save the record and navigate to Discovery Definition > Port Probes and click New.
6. Create a port probe using the new IP Service you just defined.
Figure 31: Discovery Port Probe
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.

Figure 32: Discovery Application Classifier
4. Optional: In the Classification Criteria related list, create a criteria filter that determines when this
classifier applies to the discovered devices. See the IP address classification parameters for a list of
the parameters you can use.
Run a IP address discovery through the Discovery Schedule to search for devices.
Use Windows Remote Management for classification

You can configure the discovery of Windows hosts using the Windows Remote Management (WinRM)
protocol.
• Install and configure a Windows MID Server on the local network.
• WinRM service must be enabled on all discoverable Windows hosts.
Roles required: discovery_admin, agent_admin, admin

By default, the system uses the WMI protocol for device classification of Windows hosts. Administrators
can instead use the WinRM protocol for more efficient lightweight data transfer and remote command
execution.
1. Enable the WinRM service on all Windows hosts you want to discover.

2. Navigate to Discovery > MID Servers.

3. Select the MID Server you will use for discovery of Windows hosts.
The system displays the MID Server record.
4. From the Configuration Parameters related list click New.
The system displays a MID Server Configuration Parameter record.
5. In the Parameter name field, select the mid.windows.management_protocol parameter from the
choice list.
6. Enter a value of WinRM.
Figure 33: MID Server configuration parameter
7. Click Submit.
The system displays the MID Server record.
8. Optional: Add other Windows Remote Management protocol parameters as needed.
Table 12: Additional WinRM parameters
Parameter Description Default Requires MID Server

restart
mid.powershell_api.winrm.remote_port
Specifies the 5985 No
communications port
the MID Server uses
to communicate with
the WinRM protocol.
mid.powershell_api.session_pool.target.max_size
Specifies the 2 Yes
maximum number of
sessions allowed in
the pool per target
host.
mid.powershell_api.session_pool.max_size
Specifies the 100 Yes
maximum number of
sessions allowed in
the session pool.

Parameter Description Default Requires MID Server

restart
mid.powershell_api.idle_session_timeout
Specifies the 60 Yes
timeout value of idle
Powershell sessions
in seconds.
Run a discovery from the Discovery schedule to find Windows machines on your network.
Reclassify a Windows Workstation machine as a server

By default, Discovery automatically classifies computers using certain Windows operating systems as
workstations. However, you might want specific computers in your network that are acting as servers to be
classified by their function and not their operating system.
Use the following variables, preceded by cidata, to construct a reclassification condition. For example, to
reclassify based on a machine's IP address, use cidata.ip_address.
• name
• dsn_domain
• os_domain
• ip_address
• serial_number
The following procedure reclassifies any Windows workstation operating system (Windows Vista, XP, or
Windows 7) that is acting as a server.
1. Navigate to Discovery Definition > CI Classification > Windows.
2. Create a new classification record, such as Windows XP Server.
3. Select Windows Server [cmdb_ci_win_server] as the table.
4. Right-click in the header bar and select Save from the context menu.
The Classification Criteria and Triggers Probes Related Lists appear.
5. Configure the following Classification Criteria:

Name Select a variable to use as the classification

criteria from the list above. For example,
to reclassify a machine by name, enter
cidata.name. This works for servers that have
a uniform naming convention, such as SRV001,
SRV002, etc., regardless of operating system.
Operator Select an operator for the classification condition.
In networks containing servers named with a
specific convention, you might select starts with
or contains.
Value Enter the value for the condition. In our example
of a network with a server naming convention,
this value would be the root of that convention,
such as SRV This condition will classify all
computers as servers if their machine name is
SRVXXX.
6. Select the Triggers Probe related list and add the appropriate probes.
a) Copy the list of probes from another Windows server classification, including the Condition
scripts.
b) Ensure that the Windows - Identity probe has a phase of Identification (the default is
Exploration).
The completed form looks like this:

Run a discovery from the Discovery schedule to find Windows machines on your network, and then check
the cmdb_ci_win_server table and related tables to see how data is populated in the CMDB.

Discovery classification parameters

These parameters are available for Discovery classifiers.
Unix parameters
The UNIX parameters define the characteristics of several types of computers, such as Linux, Solaris, and
HP-UX, communicating with SSH protocol, version 2.
output The raw output of the classifier probe (uname -

a).
type Returns the classification UNIX.
IP address Returns the IP address of the device being
discovered.
name Name of the operating system for this UNIX CI.
For example, Linux or HP-UX.
Windows parameters
Windows parameters identify Windows computers communicating with the WMI protocol.
isNode Indicates if this instance is a node.

type Returns the classification windows.
isVIP Indicates if this CI is a virtual machine, with a
virtual IP address.
ip_address Returns the IP address of the device being
discovered.
name Name of the Windows version, such as Windows
2003 Standard.
SNMP parameters
The SNMP parameters can define the characteristics of several types of devices, such as routers,
switches, and printers.
powering A value of true indicates that this device is an

uninterruptible power supply (UPS).
hosting A value of true indicates that this device can host
programs. Hosts are general purpose computers
such as servers.

netware A value of true indicates that this device is

running the Netware operating system.
routing A value of true indicates that this device has
network routing capabilities.
ip_address Returns the IP address through which the device
is being discovered. A device can have multiple
IP addresses.
sysdescr Required descriptive field on any SNMP device
that can contain useful classification data, such
as the operating system and its version.
vlans A value of true indicates that this device can host
a virtual local area network.
hint_router A value of true indicates that Discovery has
determined that this device is a router. This field
only applies to devices that can be used as both
a router and a switch.
block_router_exploration If this parameter is true,Discovery will not launch
exploration probes for routers it detects. This
parameter is used for network Discovery only.
switching A value of true indicates that this device has
network switching capabilities.
mfr_apc A value of true indicates that this device
is an uninterruptible power supply (UPS)
manufactured by American Power Conversion
(APC).
printing A value of true indicates that this device has
printing capabilities.
block_switch_exploration If this parameter is true, Discovery will not launch
exploration probes for switches it detects. This
parameter is used for network Discovery only.
Process parameters
Process parameters identify processes such as those used by LDAP, Apache Server, and JBoss Server.
parameter The parameters used to run the process.

command The command used to run the process.
output The complete output of the current line of the
process probe.
type Indicates the process type (e.g. unix or
windows).

PID The process ID generated by the operating

system of a device to identify a running process.
Generally, this parameter is not a practical
classification criteria, because the value
does not remain static, except in the case of
processes running on an appliance that is never
restarted.
name Name of the process being discovered. In some
cases, this parameter is not reliable, since
several process might be given the same name.
In Windows, for example several processes
return scvhost.exe for this parameter.
Check IP service affinity for Discovery and Orchestration

You can check the IP Services table for a list of IP addresses that are associated with a protocol.
The IP Services table maps a port to a protocol. Several mappings are provided by default for commonly
used port-protocol combinations, such as port 80 for HTTP, port 22 for SSH, and port 161 for SNMP.
Caution: You should not modify IP services unless your organization uses custom ports.
1. Navigate to Discovery > Discovery Definition > IP Services.

2. Filter the list to find the appropriate IP service.
3. Click the name of the service to go to that IP service page.
4. Click the IP Service Affinities tab for the list of IP addresses associated with that service.
Figure 34: IP Service Affinities
Discovery identifiers
After Discovery classifies a CI, it uses identifiers to determine if the device already exists in the CMDB.

Discovery launches special identity probes that accumulate identification data for each device and
feed that data into the identifiers, which determine the action that Discovery must take for each device.
Identifiers accurately determine the identity of the device to prevent the creation of duplicate CIs. This
identification step only takes place for the Configuration item type of discovery, not for the other types of
discovery.
The identity probe in the base Discovery system can be configured to ask the device for information
such as its serial numbers, name, and network identification. The results of this scan are processed
by an identity sensor, which then passes the results to the identifier. The identifier then attempts to
find a matching device in the CMDB. If the identifier finds a matching CI, the identifier either updates
that CI or does nothing. If the identifier cannot find a matching CI, it either creates a new CI or does
nothing. If Discovery is configured to continue, the identifier launches the exploration probes configured
in the classification record to gather additional information about the device. Exploration probes can be
multiprobes or simple probes.
This diagram shows the processing flow for classifying and probing devices with identifiers configured.


CMDB identifier tables
Table Description
Identifier [cmdb_identifier] Stores all identifier rules.

Identifier Entry [cmdb_identifier_entry] Stores all the identifier attributes.
Identifier rules
The default Discovery system contains these identifier rules, each of which is associated with a specific
CI type (the sys_class_name field on the CI record) or the table in the Applies to field and contains the
appropriate attributes for discovering CIs from the specified table. Where necessary to discover all possible
occurrences of an attribute, tables from related lists (Search on tables) are included in the rule. For more
information, see Create or edit a CI identification rule.
Table 13: CMDB identifier rules
Rule Applies to table/attributes Search on table/attributes
ESX Server Rule ESX Server none

[cmdb_ci_esx_server]
• correlation_id
Hardware Rule Hardware [cmdb_ci_hardware] • Serial Number

• serial_number [cmdb_serial_number]
• serial_number_type • serial_number
• name • serial_number_type
• ip_address
• mac_address • Network Adapter
[cmdb_ci_network_adapter]
• ip_address
• mac_address
Storage Server Rule Storage Server • Serial Number

[cmdb_ci_storage_server] [cmdb_serial_number]
• cim_object_path • serial_number
• name • serial_number_type
• serial_number
• serial_number_type • Network Adapter
• mac_address [cmdb_ci_network_adapter]
• ip_address • ip_address
• mac_address

Rule Applies to table/attributes Search on table/attributes
WBEM Service Rule WBEM Service none

[cmdb_ci_wbem_service]
• cim_object_path
Matching strategy for the hardware rule
The sys_class_name cannot be an attribute for independent rules, such as cmdb_ci_hardware. If your
Discovery identification strategy depends on matching a CI with a specific class, you must create a new
rule for each class you want to use for matching and specify that class in the Applies to field of the
Identifier form.
For example, you can create an identifier for a Linux server with different attributes than the Hardware
Rule. You might only want to use the machine name, IP address, and MAC address for identification. Your
new rule would look like this:

Figure 35: Linux identifier rule

Evaluation order for Discovery identifiers
Custom identifiers must have different Order values than those of the default identifiers. Discovery
parses identifiers and attributes in sequence from low order numbers to high. You can create identifiers to
run before or after the default identifiers, or mixed in with the identifiers from the base system. To prevent
any identifier or rule from running, disable it by clearing the Active check box. The evaluation order for
CMDB identifiers is established within each rule and only controls the parsing order of the attributes in that
rule.


Properties for processesing duplicate CIs
You can control how Discovery handles duplicates using properties installed with Identification
and Reconciliation. Use the glide.identification_engine.skip_duplicates and
glide.identification_engine.skip_duplicates.threshold properties.
Properties that control identifier versions
All instances use identifiers from the CMDB Identification and Reconciliation framework. Upgrades from
pre-Geneva versions still preserve the legacy identifiers, but you can switch to the new identifiers using a
property: glide.discovery.use_cmdb_identifiers. If you upgraded from a pre-Geneva version,
you must manually add this property and set it to true to use the new identifiers. If you upgraded from
Geneva or later releases, this property is available in the System Properties [sys_properties] table.
To preserve functionality in custom legacy identifiers, convert them to the new CMDB identifier rules
format before enabling this property. The system does not reconfigure your custom identifiers to the new
framework automatically.
Note: When Service Mapping is active, the new identifiers from the CMDB Identification and
Reconciliation framework are always used regardless of the property value.
Configure Discovery identity probes

Identity probes are multi-probes, which contain one or more simple probes configured to extract specific
information from manageable devices. You can create your own identity multi-probe to identify CIs that
Discovery does not already identify.
Identity probes return such information as device serial numbers (there can be several per device), the
computer name, and network identification (MAC address). For example, the Linux - Identity multiprobe
provided in the system, contains two simple SSH probes configured to return hardware and network
information about the device. After the probe has discovered this information, it passes the data to a
multisensor configured to process identity information.
Note: A multiprobe cannot contain another multiprobe.
1. Navigate to Discovery Definition > Probes.

2. Select a probe from the list whose Class is Multiprobe.
3. Make sure the scope is set to Global.
4. In the Includes Probes Related List, click Edit to select simple probes to include in this multiprobe.
5. Click New to create a new simple probe.


Configure Discovery identity sensors on page 124 that are part of the identify probes.
Configure Discovery identity sensors

If you customize an identify multi-probe, you can also configure a multi-sensor for it.
These multi-sensors pass the data returned by the identity probes to the Discovery identifiers. The
identifiers then search the CMDB for matching CIs. When the identity of a device is resolved, the identifiers
pass the result state for the device to the multi-sensors, which react accordingly, either by launching
exploration probes or stopping Discovery for that device.
1. Navigate to Discovery Definition > Sensors.
2. Select an existing identity multi-sensors from the list.
Note: To avoid confusion, the multi-sensors provided in the instance must have the same
names as their matching multi-probes.
The Responds to Probes related list shows the simple probes which pass their data to this multi-
sensors. These are the same simple probes that appear in the Includes Probes list in the matching
multi-probes record.
3. Click the Script link for each probe in the list to see the script that the multi-sensors runs to process
the data from the probe.


Run a discovery through the Discovery Schedule to search for CIs and verify that they are identified
correctly in the CMDB.
Serial number types for identification

As Discovery finds CIs, their serial numbers are listed in the Serial Number [cmdb_serial_number] table
so they are easy to identify. Serial number types vary depending on the CI, as described in the following
examples.
Linux
In the result of dmidecode | cat, the value on the left side is what Discovery looks for. The value on the
right side is how it is stored in the Serial Number [cmbd_serial_number] table.
Serial Number : system_serial_number
UUID : uuid_serial
Serial Number : baseboard_serial
Serial Number : chassis_serial
Windows
For Win32 WMI classes, the value on the left is the name by which it is stored in the Serial Number
[cmdb_serial_number] table. The value on the right is the WMI value.
('system' : Win32_ComputerSystemProduct.IdentifyingNumber);
('uuid' : Win32_ComputerSystemProduct.UUID);
('chassis' : Win32_SystemEnclosure.SerialNumber);
('bios' : Win32_BIOS.SerialNumber);
('baseboard' : Win32_BaseBoard.SerialNumber);
SNMP
For SNMP, the mapping below is based on the code. Physical types of serial numbers are from all
instances of iso.org.dod.internet.mgmt.mib-2.entityMIB.
'cisco_stack' :
'iso.org.dod.internet.private.enterprises.cisco.workgroup.ciscoStackMIB.chassisGrp.chas
'cisco_chassis' :
'iso.org.dod.internet.private.enterprises.cisco.temporary.chassis.chassisId'
'foundry' :
'iso.org.dod.internet.private.enterprises.foundry.products.switch.snChassis.snChasGen.s
'apc_pdu' :
'iso.org.dod.internet.private.enterprises.apc.products.hardware.masterswitch.sPDUIdent.
'printer' :
'iso.org.dod.internet.mgmt.mib-2.printmib.prtGeneral.prtGeneralEntry'

'standard' :
'iso.org.dod.internet.private.enterprises.apc.products.hardware.ups.upsIdent.upsAdvIden
Legacy Discovery identifiers

The following legacy identifiers are included with Discovery.
Identifier Description Details
Serial Number Table & Class Identify CIs in the CMDB This identifier matches the
Name based on serial number(s) in discovered serial number
the serial number table and against the serial_number
sys_class_name. 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 for
identification on page 126.
Serial Number & Class Name Identify CIs in the CMDB based This identifier matches the
on the serial_number field and discovered serial numbers
matching sys_class_name. 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_numbertable. This
identifier solves the issue of
Discovery finding imported data
in the CMDB.

Name & Class Name Identify CIs in the CMDB based This identifier matches
on name field and matching the discovered name
sys_class_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
Discovery will not identify
CIs that are not in the same
class. For example, a computer
and a printer have the same
name, but since their class
name differs, Discovery will not
identify them as the same CI.
Network Identify CIs in the CMDB based This identifier matches
on IPs and MAC Address(es) in the discovered network
the network adapter table. 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.
Network & Class Name Identify CIs in the CMDB based This identifier matches the
on the mac_address field discovered IP address and
and the ip_address field and MAC address of the base
matching sys_class_name. 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
Discovery will not identify CIs
that are not in the same class.
MAC Address & Class Name Identify CIs in the CMDB based This identifier matches the
on the mac_address field and discovered MAC address of the
matchingsys_class_name. 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

IP Address & Class Name Identify CIs in the CMDB based This identifier matches the
on the ip_address field and the discovered IP address of the
matching sys_class_name. base CI against those in the
IP address and class type
MACAddress Identify CIs in the CMDB based This identifier matches the
on MAC Address(es) in the discovered MAC address of the
network adapter table. base CI against those in the
MAC address and class type
Generic Serial Number Identify CIs in the CMDB based This identifier matches the
on serial_numberfield. 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 Identify CIs in the CMDB based This identifier matches the
on the mac_address field and discovered IP address and
the ip_address field. MAC address of the base
CI against those in the base
CI record. If a discovered IP
address and MAC address
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 Identify CIs in the CMDB based This identifier matches the
on name field. discovered name against
the name field in the base CI
record. If a discovered name
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 Identify CIs in the CMDB based This identifier matches the
on MAC address field. discovered MAC address of the
base CI against those in the
MAC address matches a
CI, then that CI is declared
name is NOT a requirement,
which means that Discovery will
identify CIs that are not in the
same class.
Generic IP Address Identify CIs in the CMDB based This identifier matches the
on IP address field. discovered IP address of the
base CI against those in the
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.
Convert legacy custom Discovery identifiers

Custom identifiers created in a prior release must be converted to CMDB identifier rules after an upgrade
to Geneva to use the new unified framework.
When you upgrade to Geneva, your scheduled discoveries can continue to use the identifiers they were
configured to use, including any custom identifiers you have created. You can use the CMDB identifiers
provided with the Geneva release for new Discoveries or continue to use the legacy identifiers. If you elect
to use the CMDB identifiers and want to use a custom identifier you created in an earlier version, you can
convert that legacy identifier to a new identifier rule manually.
Note: To restrict Discovery to use only the CMDB identifiers, you can add a property to the
sys_properties table and set it to hide legacy identifiers.
This example uses the serial_number and serial_number_type attributes from the hardware identifier.
1. Navigate to Discovery Definition > CI Identification > Identifiers.
2. Open the record for the custom legacy identifier and note the table in the Applies to field.
For example, the identifier might be on the Hardware [cmdb_ci_hardware] table.

3. Determine if the script in the legacy identifier is configured to query another table for matches.
In this example, the Serial Number Table & Class Name identifier is configured to query the Serial
Number [cmdb_ci_serial_number] table for a matching serial number. In CMDB identifier rules, this is
known as the Search on table.
Figure 37: Table queried for matching attributes
4. Locate the attributes the script uses as unique identifiers.

In this example, the serial_number and serial_number_type fields are the unique identifiers on the
Serial Number [cmdb_ci_serial_number] table.

Figure 38: Unique identifiers
5. Identify any filtering conditions the script applies to the attributes.

In this example, serial numbers must be valid and the field cannot be blank.

Figure 39: Attribute conditions
6. Navigate to Configuration > Identification/Reconciliation > CI Identifiers and click New.

7. Enter a descriptive name for the identifier, using the class name.
For example, you might use Linux Server.
8. Select the same table in the Applies to field that your custom legacy identifier specified.
9. Submit the form.
10. Open the new identifier record and click New in the Identifier Entries related list.
11. Complete the form for the attributes from this query table.
Remember to give your new rule a unique priority number to establish its parsing order.

Table 14: Identifier entry fields
Field Description
Criterion attributes Attributes to use as unique identifiers. These

are the values you located in step 4. Click
the lock icon to add one or more attributes
to the list.
Optional condition Filter conditions for the attribute from the
legacy identifier. These are the values you
located in step 5.
Search on table Table to query for the attribute value. This is
the table you identified in step 3.

Figure 40: Identifier entry form
12. Click Submit.

13. Create additional identifier entries for any other attributes from your custom legacy identifier.
Create a Discovery legacy identifier

If your system is configured to use legacy identifiers, you can create new identifiers to examine the
attributes from specific tables that extend tables in the default Discovery rules.

The default identifiers provided with Discovery should be adequate for most discoveries. However, if you
need to discover data from a child table, such as Linux Server [cmdb_ci_linux_server], you can create a
custom legacy identifier and select the exact criteria you want to add to the CMDB.
1. Navigate to Discovery Definition > CI Identification > Identifiers.
2. Click New.
3. Fill out the unique fields provided by the identifier form.
Table 15: Identifier form fields
Field Input Fields
Applies to Select the ServiceNow table of the device

class for this identifier. For example,
if the class is Printer, then the table is
cmdb_ci_printer.
Order Configure the order in which the
identification criteria are evaluated. An
example might be serial number - 910,
network name - 920, and computer name -
930.
Script Create the conditions that determine what
Discovery should do when the results are
returned from a search of the CMDB for
this identifier. For example, you might want
to stop Discovery if two or more CIs in the
CMDB match this identifier. Or you might
want to evaluate additional identifiers even
after a match has been established with
this identifier. Use the scripting methods
described below to tell Discovery how to
respond.
The completed Discovery identifier form looks like this:


Discovery status
The Discovery status provides a summary of a Discovery launched from a schedule. You can also cancel a
Discovery that is in progress from the status form.
To access the Discovery Status form, navigate to Discovery > Status and open the status record
for 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. A status record
contains data that can help you troubleshoot a failed discovery. 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.
• Refresh: Runs the probe again. You can re-run probes when you encounter a failed Discovery or other
unexpected results.
• Discovery timeline: The Discovery timeline is a graphical display of a discovery, including information
about each probe and sensor that was used.
• Discovery log entries: The Discovery Log shows information such as classification failures, CMDB
updates, and authentication failures. A Discovery Log record is created for each action associated with
a discovery status.
• ECC queue entries: Entries in the ECC queue provide you with a connected flow of probe and sensor
activity, as well as the actual XML payload that is sent to or from an instance.
• Device history: The device history provides a summary of all the devices scanned during discovery,
and what action sensors took on the CMDB.
Note: By default, only 30 days of Discovery records are displayed in the status list at a time.
The status record provides the following fields:
Table 16: Discovery status record fields
Field Input value
Number Discovery record ID generated by your

ServiceNow instance.
Description How this Discovery was run. Typically, the
description is Scheduled, but if you ran
Discovery manually from a Schedule, the record
would show Discover Now in the Description
field. If the scan was performed by the Help the
Help Desk application, this value is Help the help
desk.
Schedule The name of the Discovery schedule.
State Indicates the state of this Discovery (Active,
Completed, etc.)

Field Input value
Source Indicates how this Discovery was executed. The

possible options are:
• Schedule Discovery (default)
• Discover now CI
• Discover now schedule
• Quick Discovery
• ServiceWatch
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 the 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.
Cancel a Discovery Status

Discovery can cancel a status.
You can automatically cancel a Discovery status in these ways:
• After the value of the Max run time parameter is exceeded
• After the value of the transaction quota rule is exceeded
To manually cancel a Discovery status:

1. Navigate to Discovery Discovery Status.
2. Click a Number to open the status record.
3. Click Delete.
4. In the Confirm dialog box, click Delete.

When a Discovery status cancels, any associated sensor transactions are immediately terminated and
any scheduled sensor jobs are deleted from the system. After cancellation, the cleanup Status shows the
Completed count and the cancellation is logged in the Discovery log. In the Queue [ecc_queue] table, any
records belonging to sensors exceeding the Transaction Quota Rule will be set to the Error state.
Discovery status timelines

A Discovery Timeline generates a graphical display of the Discovery Status records for a Discovery,
including information about each probe and sensor running.
What timelines display
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
Viewing 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.
View a Discovery timeline
A Discovery Timeline generates a graphical display of the Discovery Status records for a Discovery,
including information about each probe and sensor running.
1. Navigate to Discovery > Status.

2. Select a Discovery from the record list.
3. Click the Show Discovery Timeline Related Link.

Figure 42: Discovery Timeline Related Link
The timeline for the entire Discovery appears, unless the size threshold is exceeded. If the timeline is
too large to display, an error message appears.
4. Clear the warning, and then select the Devices Related List.
5. Click the IP address of a device.
6. In the Device record, click the Show Discovery Timeline Related Link.
The Discovery timeline for that device appears.

Figure 43: Discovery Timeline
7. Use the pink slider at the bottom of the timeline to change the perspective.
a) Move the slider from right to left to view all the tasks on a long timeline.
b) Adjust the end points of the slider to change the magnification. A narrow slider zooms in on the
spans and provides a more detailed view of complex timelines. A wide slider pulls the view out
and makes more of the timeline visible on the screen.
8. Use the selector range at the top of the screen to adjust the visible time frame. To limit the timeline to
the length of the Discovery, click Max.
The time scale adjusts automatically to the length of the Discovery. The available time scale range is
from one day to 1 year.
Tooltips
Discovery timelines display probe and sensor performance data and CI information in tooltips. Hover
the cursor over a span to view this data. Probes are displayed by black spans. The queue time for
a probe is shown as a silver bar within the span, and the processing time is represented by the
remaining space. Sensor spans are red, and the queue time is shown as a green bar. Selected spans
of any type display in yellow.

Figure 44: Discovery Timeline Shazzam Sensor
ECC Queue
Double-click a span to open the ECC Queue record for that probe or sensor.
Figure 45: Discovery Timeline ECC Queue

Discovery device history

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.
Figure 46: Discovery device list
Click 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.

Figure 47: Discovery device
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.
Figure 48: Discovery details
The following information is displayed in this form:
Table 17: Discovery status devices
Field Input value
Source The IP address of the device discovered.

Field Input value
Completed activity Indicates the outcome of Discovery for this

device or the last completed activity for a
Discovery in progress, such as Identified CI.
Successful outcomes are indicated in green.
Current activity The current scanning activity for this device for a
Discovery in progress, such as Updating CI.
CMDB CI The name of this device as it appears in the
CMDB.
Started The number of device-specific probes run. This
number does not include the universal probes,
Shazzam and Ping, that run initially.
Completed The number of sensor records created from the
device-specific probes that were run.
Scan status Shows the final scan count of a
completedDiscovery 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 that can be added by configuring the form:
DNS Names Displays DNS names for each discovered
device.
Address scan data
When Discovery scans for IP addresses only (without credentials or identifiers), no updates are made to
the CMDB. All IP addresses discovered appear on this list, including multiple IPs on the same device. The
results of IP address scans include slightly different information than the results of a CI scan. Since there
is no CMDB activity associated with the IP address scan, the Completed activity column displays only the
classification status.
Possible statuses are:
• Classified
• Unclassified
• Alive, not classified
For Classified devices, Discovery might identify the type of device in the Current activity column. For
example, Network Gear might be classified as Cisco Network Gear, and a Computer might be classified as
a Windows Computer.

Figure 49: Discovery status IPs
The ECC queue for Discovery

The External Communication Channel (ECC) Queue is a connection point between an instance and other
systems that integrate with it, most commonly a MID Server.
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.

Automatic deletion of ECC queue records
If Discovery is running on an instance, the size of this table can grow to several gigabytes. Most of the
accumulated data is unnecessary, but some entries might be important for troubleshooting any problems
with Discovery. For example, if Discovery is not properly capturing the disk drives on a particular Windows
server, look in the ECC Queue at the data returned by the Windows - System Information probe. You
should retain ECC Queue data from Discovery for at least a month.
By default, records in the ECC Queue older than 7 days are deleted automatically. You can set the deletion
schedule by updating the table rotation schedule for the ECC queue. The table rotation names are:
• ecc_queue_event
• ecc_queue
Probe and sensor activity
The ECC Queue provides you with a connected flow of probe and sensor activity. The position of records
in the list is dependent on your sorting criteria and might not represent the processing order of the
Discovery. Activity is recorded (Created date) when the probe is launched or the sensor records the
response in the instance. On a busy system, sensor input might be queued in the instance and delayed
from being recorded. Sensors can launch multiple probes that require different intervals to respond. A
probe record displays the instructions it was given when it was launched, and the sensor record shows the
probe instructions and the results of the probe. All this information is checked into the instance.
To track the processing sequence, use the following methods:
• To track the flow of probes and sensors deeper into the Discovery (toward completion), drill down using
the Queue Related List at the bottom of the ECC Queue record. This list displays the next activity in the
Discovery, by either a probe or a sensor. If the Queue list is empty, then that branch of the Discovery is
complete. Multiple entries means that the sensor in the current record launched multiple probes.
• To track backwards toward the beginning of the Discovery, drill down using the Related Field icon in the
Response to field. This action opens the ECC Queue record for the activity that spawned the current
probe or sensor record.
ECC queue fields
An ECC Queue record provides the following fields:
Table 18: ECC queue fields
Field Input value
Agent The name of the MID Server that initiated the

probe.
Topic Type of probe or sensor that was active (SSH,
WMI, or SNMP).
Name Identifying name of the probe or sensor. For
SSH probes, this is the probe's message. For
all others, the name is an identifying string
generated by the instance.

Field Input value
Source The IP address of the Discovered device. The

Shazzam and Ping probes do not have a source
IP associated with them. These probes are not
directed toward a single device, but exist to scan
all devices in the specified network range.
Response to Displays the name of the probe or sensor in the
Discovery sequence whose activity triggered
this probe or sensor. A single sensor can launch
several probes, but a sensor can only respond to
a single probe.
Queue Designates whether the record is for a probe or
a sensor. Sensors are in the input queue, and
probes are in the output queue.
State Shows where the probe or sensor is in the
process of completing its task (e.g. processed or
processing)
Processed Times that this probe or sensor's task was
finished.
Created Time that this probe or sensor was launched/
activated.
Sequence Internal ID for the execution sequence for this
probe or sensor.
Payload Contents of the probe's instructions or the
response that the sensor reports to the instance.
Click the XML button to display the code in an
XML view.
An ECC Queue record for Discovery looks like this:

Figure 50: Discovery ECC queue
Viewing CMDB records
As you drill down through the probes and sensors that are part of a Discovery, you can view the CMDB
record for the device (CI) that was probed, using either of the following methods:
• Right-click a probe or sensor in the ECC Queue record list and select Go to CMDB item.
• In a ECC Queue record, click the Go to CMDB item Related Link.
Troubleshooting
If you are suspicious of the results of a Discovery (credential failure, for example), you can run individual
probes directly. To run a probe from the ECC Queue list, right-click the probe and select Run Again from
the pop-up menu. To run a probe directly from an ECC Queue record, click the Run Again UI action in
Related Links.

Discovery logs
The Discovery Log and the Horizontal Discovery Log display the activity that takes place during a
discovery. Use the logs to debug failed discoveries.
Discovery Log
The Discovery Log shows information such as classification failures, CMDB updates, and authentication
failures. A Discovery Log record is created for each action associated with a discovery status.
Figure 51: Discovery Log Records
Discovery Pattern and Horizontal Discovery log
The Pattern Discovery log includes Horizontal Discovery log records, which display information about
discoveries that were performed with patterns. A horizontal discovery log record is created for an entire
horizontal discovery run, which includes the results of all the operations specified in the pattern.

Figure 52: The Horizontal Discovery log
Open the Discovery Log

Open the Discovery Log to troubleshoot a discovery.
1. Open a Discovery Status record. Log entries appear in the Discovery Log related list.

Figure 53: Discovery Log Records
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
Short 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.
ECC queue input The related input record from the ECC
queue for this discovery. You can also view
these records from the ECC Queue related
list.
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.
Source Names the particular activity, such as the
Shazzam probe or a UNIX classify probe.

Field Input value
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.
2. Do any of the following:

• Click a link in the CI column to open the record for that CI.
• Click the link in the Created column to view the log record.
• Click the IP address link in the Device column to view the log records for a particular device.
Open the Discovery Pattern log

Open the Discovery Pattern log to troubleshoot a discovery with patterns.
1. Navigate to Pattern Designer > Discovery Pattern Log.
2. Click the link in the Log message column.
3. Click View Log.
The Horizontal Discovery Log window opens.

Figure 54: The Horizontal Discovery log
Discovery Log Item Description
Pre Pattern Execution The actions that were run before the pattern
was launched.
Selecting Pattern for Execution The pattern that was run for discovery.
{Identification Section name} Displays the results of the operations in
the pattern. Expand the name to see each
operation.
Pre Payload Processing Scripts The results of scripts that were run before
the payload was received.

Discovery Log Item Description
Payload Processing Details about the payload and how it was

processed. Look in this section to find errors
that might have been encountered in during
various activities, such as the running of
identification rules, updates to the CMDB,
and so on.
Post Payload Processing Scripts The results of scripts that were run after the
payload was received.
4. Click an item in the left-hand column to see more information about it in the right-hand column.
5. To debug the pattern, click the name of the Identification Section, and then click the Debug button in
the upper-right.
6. To return to the log record, click the X in the upper-right.
Change Discovery log retention time

By default, the Discovery log retains information for of 30 days (2,592,000 in seconds). You can modify this
length of time.
1. Open the Auto Flushes table by typing sys_auto_flush.list in the application filter.
2. Open the discovery_status record.
3. Change the value in the Age in seconds field.
4. For the change to take effect immediately, run the Table Cleaner Job in the Schedule [sys_trigger]
table.
Discovery Dashboard
The Discovery Dashboard is a central place for Discovery users to monitor ongoing Discovery operations.
The dashboard contains reports that query the database and display the results.
Dashboards are the home pages for products on the instance. The Discovery Dashboard provides
summary information about your Discovery status, devices, applications, and timeline. It also displays
Discovery errors and suggested solutions.
Note: All the data on the dashboard is domain separated, and shows only data collected from the
domain specified in the MID Server user account for the Discovery schedule used.
To display the Discovery Dashboard, navigate to Discovery > Dashboard.
Features of the Discovery Dashboard
The Discovery Dashboard displays:

• The current progress of the actively running Discovery schedules.
• Discovered devices, by category and time discovered.
• Errors that occurred during a Discovery schedule that has run.
• Credentials that were either not required or unused by a Discovery schedule.
• Upcoming Discovery schedules in the timeline form.

Discovery Dashboard components

You can customize the reports and reports on the dashboard to display statistics important to your
environment.
Active Discovery Status report
The Active Discovery Status report displays the progress of an actively running Discovery. The information
displayed is pulled from the Discovery Status module. The Progress field of the status record specifies the
percent complete of the Discovery schedule. The percent complete is calculated based on previous runs of
the same Discovery schedule. The progress field is empty in the following cases:
• When you use DiscoverNow
• When you use Discovery from a configuration item (CI).
• During the first run of a Discovery schedule.
Figure 55: Active Discovery Status report
Newly Discovered Devices report
The Newly Discovered Devices report displays the count of the devices that the Discovery application has
identified in the last 7 days, grouped by the class of the device.

Figure 56: Newly Discovered Devices report
Total Discovered Devices report
The Total Discovered Devices report displays the total count of the devices that the Discovery application
has identified in the last 30 days, grouped by the class of the device.

Figure 57: Total Discovered Devices report
Unrefreshed Devices report
The Unrefreshed Devices report displays devices that were discovered up to a year ago, but have not been
identified in the last 30 days, grouped by the class of the device.

Figure 58: Unrefreshed Devices report
Newly Discovered Applications report
The New Applications Discovered report displays the count of new applications that the Discovery
application has identified in the last 7 days, grouped by the class of the application.

Figure 59: Newly Discovered Applications report
Total Discovered Applications report
The Total Discovered Applications report displays the total count of the applications that the Discovery
application has identified in the last 30 days, grouped by the class of the application.

Figure 60: Total Discovered Applications report
Unrefreshed Applications report
The Unrefreshed Applications report displays applications that were discovered up to a year ago, but have
not been identified in the last 30 days, grouped by the class of the application.

Figure 61: Unrefreshed Applications report
Active Discovery Errors report
The Active Discovery Errors report lists the errors that are generated by each active Discovery. The errors
for a specific Discovery are overwritten when that Discovery runs again. This report displays the following
data:
Table 19: Active Discovery Errors report data
Column Description
Created Timestamp of the error message.

Short message Contents of the error message generated during
the Discovery run.
Help Link to a suggestion on how to fix the error. In
some cases, the link will be specific to the error.
In other cases, the link points to a general page
that has the solution to a collection of common
errors.

Column Description
IP IP address of the asset on which the error was

detected.
Discovery status Discovery status number.
Figure 62: Active Discovery Errors report
Unused Credentials report
The Unused Credentials report lists the credentials that are not being used by the Discovery or
Orchestration applications at the current time.
Note: This may include credentials for a Discovery that has been scheduled but not run for the first
time.


Upcoming Discovery Schedules report
The Upcoming Discovery Schedule report is a graphical display of the Discovery schedules that are
scheduled to be executed in the next 30 days. Each row in the timeline is a unique Discovery schedule.
Different spans on the same line show the upcoming Discovery runs of that schedule. Each span
represents the estimated time it will take to complete the run. The blue color inside the timespan is the
actual completion time. The grey color is the maximum run time of that schedule.
You can use the timeline to determine if your scheduled Discovery runs are spread out over time, rather
than all running at once.
The following Discovery scheduled runs do not appear in the timeline.
• When you use a Quick Discovery.
• When you use Discovery from a configuration item (CI).
• When the Discovery Schedule run type is On Demand.

Figure 64: Upcoming Discovery Schedules report
Add a report to the Discovery Dashboard

You can customize the Discovery Dashboard by adding or removing reports.
Role required: admin, discovery_admin
1. Navigate to Discovery > Dashboard.
2. Click the + icon in the upper left corner of the dashboard.

3. Select a report that you want to add to the dashboard.

4. Select a location to place the report using one of the Add here choices.
5. Click the X in the upper right corner of the report box to close the report choices pane.
The default reports are found in the following locations:
Table 20: report locations for Discovery dashboard
report report path
Active Discovery Status Gauges > Discovery Status

Newly Discovered Devices (Last 7 Days) Gauges > Hardware > Newly Discovered
Devices (Last 7 Days)
Total Discovered Devices (Last 30 Days) Gauges > Hardware > Total Discovered
Devices (Last 30 Days)
Unrefreshed Devices (Beyond Last 30 Days) Gauges > Hardware > Unrefreshed Devices
(Beyond Last 30 Days)
Newly Discovered Applications (Last 7 Gauges > Application > Newly Discovered
Days) Applications (Last 7 Days)
Total Discovered Applications (Last 30 Gauges > Application > Total Discovered
Days) Applications (Last 30 Days)
Unrefreshed Applications (Beyond Last 30 Gauges > Application > Unrefreshed
Days) Applications (Beyond Last 30 Days)
Errors Gauges > Discovery Log > Discovery Error
Unused Credentials Gauges > Credentials > Unused Credentials
Timeline Timeline > Upcoming Discovery Schedules
Discovery customization
You can customize how Discovery works in your environment.
Cancel sensor transaction by duration

By default, this rule cancels the sensor transaction if it takes more than 20 minutes to complete.
If the Discovery sensor transaction takes more than 20 minutes to complete, the following actions occur:
• The associated ECC Queue input record is set to the error state.
• The Discovery Status Completed Count is updated.
• An error message is logged, for example:
Sensor error when processing Linux - Storage: Transaction cancelled:

maximum execution time exceeded
• The remainder of the discovery continues to run.
This behavior is provided by the Discovery Sensors Transaction Quota Rule. This rule is active by
default.

You can disable the rule and you can modify the amount of time that has elapsed before the rule takes
effect. Accessing this record requires the admin role.
1. To disable the rule, navigate to System Definition > Quota Rules.

The Transaction Quotas plugin must be active.
2. Search on the name *Discovery to filter the list of rules.
3. In the name column, click Discovery Sensors.
4. To modify the amount of time, edit the Maximum Duration field of the rule.
The value is in seconds.
Turn off collection of port data for SNMP network devices

In some environments you may not want to collect the port data for SNMP network devices.
If the network devices contain an extremely large number of ports and each individual port's information is
not critical to the overall management of the devices, you may not want to collect the port data for SNMP
network devices.
1. Navigate to DiscoveryDiscoveryDefinition Probes.
2. Go to the SNMP - Switching probe.
3. In the SNMP Fields tab, find the field named ports. Double-click the value in the Active column.
Change the value to false.
4. Click the check mark to save the change.
Advanced Discovery configuration

You can configure several additional components of Discovery such as Application Dependency Mapping,
the ECC queue, and extensions for the MID server.
PowerShell for Discovery

PowerShell 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
v2.0 and above. However, PowerShell 3.0 does not support Windows Server 2003.
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.
Installed with PowerShell for Discovery
These elements support PowerShell discoveries.
MID Server parameters
The following parameters are optional.

Note: After changing the setting for any parameter, be sure to restart the MID Server service.
Table 21: MID Server Parameters
Description Name(s) Details
PowerShell credentials mid.powershell.use_credentials 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 PowerShell for mid.use_powershell Enables or disables PowerShell

Discovery for Discovery. You must restart
the MID Server after changing
the value. If PowerShell is
not installed or the version
installed is less than version
2.0, Discovery reverts to using
WMIRunner.
• Default value: true, in the
Fuji release.
• Default value: false, in
releases prior to Fuji.

PowerShell executable path mid.powershell.path Enables an administrator to

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

MID Server credentials mid.powershell.local_mid_service_credential_fallback

Specifies the login credentials
the MID Server uses if all other
credentials fail.
Enable or Disable the mid.powershell.enforce_utf8 Enable this parameter to

enforcement of UTF-8 for force commands on a target
command output 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.
MID Server Script Includes
The following script includes were added for PowerShell discoveries. These scripts run on the MID Server
to generate the scripts that Discovery uses for WMIRunner and PowerShell.
Table 22: MID Server Script Includes
Script Include Description
GenerateWMIScriptJS Generates a Javascript script for the WMIRunner

probe.
GenerateWMIScriptPS1 Generates a PowerShell script for PowerShell
Discovery.
Probe and sensor
When a Windows machine is classified with PowerShell, and an MSSQL instance is detected, a probe
called Windows - MSSQL is launched. The probe returns the SQL database catalogs and version to a
matching sensor.

Probe parameter
A probe parameter called WMI_ActiveConnections.ps1 contains a script that runs netstat.exe on a target
machine for connection information (such as process IDs, ports, IP addresses) when PowerShell is
enabled.
Credentials
Discovery uses Windows PowerShell credentials from the Credentials [discovery_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.
Set up a MID Server to use PowerShell

Discovery can be run with a mix of MID Servers using PowerShell and WMIRunner.
1. Download PowerShell and install it on each MID Server configured to discover Windows computers.
2. Enable PowerShell for Discovery by setting the mid.use_powershell MID Server parameter to true on
all the MID Server machines using PowerShell.
3. Determine which credentials PowerShell should use.
• To discover Windows computers using credentials from the credentials table, set the
mid.powershell.use_credentials parameter to true. This is the default behavior when PowerShell is
enabled.
• To force Discovery to use the credentials of the MID Server service user, set the
mid.powershell.use_credentials parameter to false on the MID Server. The MID Server service
must have domain admin credentials to have access to the Windows machines in the domain.
Application Dependency Mapping (ADM) for Discovery

Application Dependency Mapping (ADM) creates relationships between interdependent applications.
ADM identifies:
• The devices that are communicating with one another.
• The TCP ports these devices are communicating on.
• The processes that are running on these devices.
For example, if a web server application uses a database server application, the web server "depends on"
the database. The web server also "runs on" the host or server cluster. You can use the data from running
processes to determine which devices to drill into to see more application-specific configuration data.
You can disable ADM and use the ADM probes and sensor to collect active connections and active
process information without collecting all the Application Dependency Mapping information.
Discovery ADM probes and sensors
ADM uses the following probes:

Table 23: ADM Probes
Name Probe Type Description Includes Probes
AIX - ADM Multiprobe Queries for information • AIX - Active

about active (running) Connections
AIX processes and • AIX - Active
active connections - the Processes
information required
to perform application
dependency mapping.
HP-UX - ADM Multiprobe Queries for information • UNIX - Active
HP-UX processes and • HP-UX - Active
dependency mapping.
This probe requires
that lsof be installed
and the UNIX - Active
Connections probe
be activated, which is
inactive by default.
Solaris - ADM Multiprobe Queries for information Solaris - Active

about active (running) Processes
Solaris processes and
Solaris - Active
active connections - the
Connections
dependency mapping.
This probe is triggered
by the Solaris Zones
probe. The system
triggers an ADM probe
for each local zone
contained in a global
zone.
This probe requires
that lsof be installed on
the global zone.
UNIX - ADM Multiprobe Queries for information • UNIX - Active

UNIX processes and • UNIX - Active
dependency mapping.

Name Probe Type Description Includes Probes
Windows - ADM Multiprobe Queries for information • Windows - Active

Windows processes • Windows - Active
and active connections Processes
- the information
required to perform
application dependency
mapping.
ADM uses the following sensors:
Table 24: ADM Sensors
Name Sensor Type Description Responds to Probes

Probes
AIX - ADM Javascript Updates the running • UNIX - Active

processes and active Connections
connections, and runs • AIX - Active
application dependency Processes
mapping.
HP-UX - ADM Javascript Updates the running • UNIX - Active

HP-UX processes and Connections
active connections, • HP-UX - Active
and runs application Processes
dependency mapping.
This sensor requires
that lsof be installed.
Solaris - ADM Javascript Updates the running • Solaris - Active
Solaris processes and Processes
active connections, • Solaris - Active
and runs application Connections
dependency mapping.
This sensor requires
that lsof be installed.
UNIX - ADM Javascript Updates the running • UNIX - Active
Unix processes and Connections
active connections, • UNIX - Active
dependency mapping.
Windows - ADM Javascript Updates the running • Windows - Active

Windows processes Connections
and active connections, • Windows - Active
dependency mapping.

Requirements for ADM
Your instance must meet the following requirements to use application dependency mapping:
• The glide.discovery.application_mapping Discovery property is enabled.
• ADM probes are configured.
• Process classifiers are configured.
Relationships and dependencies
In our example relationship, if the virtual server sannnm-01 crashes, the database instances and the web
server upstream are adversely affected. Likewise, if the web server fails, the web site hosted on it goes
down. The CI record for the virtualized Windows server sannnm-01 with its upstream and downstream
relationships is shown below. The downstream relationships show that this server is virtualized by VMware
running on a Windows server named sandb01. Our upstream relationships show a MySQL instance, a
SQL instance, and a web server running on sannnm-01. Farther upstream, a web site is hosted on the web
server.
Figure 65: Upstream and Downstream Relationships

When you delete a CI from the CMDB, ServiceNow also deletes all relationships with that CI.
Deleting a CI affects references to the CI in Incidents, Problems and Changes. In some situation, it might
be preferable to block a CI by setting the install_status or hardware_status attributes to retired, without
deleting the CI.
In the following 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 five Apache
web servers using the local JBoss application.
Figure 66: JBoss application dependency example
Access dependency maps for ADM

Access dependency maps to see application relationships.
1. Navigate to Configuration and select a CI class (such as Servers, Database Servers, or Database
Instances).
2. Select a specific CI from the list.
3. In the CI record, click the map icon in the Related Items header bar.
Figure 67: Related Items Map Icon
4. In the dependency map that appears, right-click the arrow connectors between CIs to display the
relationship type.

Figure 68: Application Dependency Map
Add CI relationships for Discovery ADM

Discovery automatically maps the dependencies between CIs that it finds in the network and assigns the
appropriate type to each relationship.
Administrators can add dependencies manually and to define the appropriate relationship type between
new configuration items based on lists of suggested relationships. When adding application dependencies
to a configuration item, 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.
1. In a CI record, click the + icon in the Related Items toolbar.
Figure 69: Related Items Add Icon
2. Select the appropriate relationship type from the list at the top of the page.

Figure 70: Define Relationships
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.
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.
Figure 71: Application Dependency PeopleSoft Example
vCenter event collector

The vCenter event collector is a MID Server extension that listens for vCenter-related events.
The event collector allows the CMDB to be updated with changes to virtual machines (VMs), in addition
to the updates detected by Discovery. A change to a VM is sent as an event from the vCenter server to
the vCenter event collector. When an event is received, the CMDB is updated accordingly. Full vCenter
Discovery does not need to rerun. For some events, such as powered on and powered off events,
Discovery does not need to run again at all. For most events, Discovery runs only on the necessary
vCenter resource.
For example, if a VM is turned off, the vCenter server sends the event VmPoweredOffEvent. The
vCenter event collector receives and processes the event and the CMDB is updated to reflect that the state
of the corresponding VM is set to off.
Important: With this extension, Discovery can only modify the state of a VM which exists in
the CMDB. When an event with "CreatedEvent" occurs in its name, such as VmCreatedEvent,
Discovery scans that VM and then creates the CI using the data it collects. When a new event
occurs involving that CI, Discovery can update the existing record without launching another scan.
See Discovery for VMware vCenter on page 295 for supported versions of vCenter.
Supported vCenter events
The following events are the only vCenter events handled by the base system when Discovery is activated.
If you have upgraded your instance from an earlier version, you might not have the default events added
with later releases. To use the missing events, manually add them.
Table 25: vCenter events
Event name Description Launches probe
VM events

VmPoweredOnEvent The VM has been powered on None

from the powered off state or
resumed from the suspended
state. This event is sent when
the VM is powered on. It does
not account for the time it may
take to boot the host operating
system.
DrsVmPoweredOnEvent The VM has been powered None
on by a distributed resource
schedule (DRS), which
balances workload between
available resources.
VmRestartedOnAlternateHostEvent
The VM was restarted on None
another host because the
original host failed.
VmPoweredOffEvent The VM has been powered off. None
If the host OS is shut down, this
event is sent after the host OS
shuts down and the VM enters
the powered off state.
VmPowerOffOnIsolationEvent The VM has been powered off None
on an isolated host in an HA
cluster.
VmShutdownOnIsolationEvent The VM has been shut down None
on an isolated host in an HA
cluster.
VmSuspendedEvent The VM is suspended. This None
event is sent after the VM
suspension is complete.
VmRelocatedEvent The VM has been relocated None
while offline (either suspended
or powered off). A VM migration
of the VM to a different host,
or the migration of any storage
used by the VM triggers the
event.
VmMigratedEvent One or both of the following None
occurs:
• The VM has been hot-
migrated, with vMotion, to
another ESX server.
• The storage for the VM has
been hot migrated.
DrsVmMigratedEvent Migration of a VM None

recommended by a DRS.

VmRemovedEvent The VM instance has been None

deleted from vCenter.
VmClonedEvent The VM was cloned VMWare - vCenter VMs
successfully.
VmCreatedEvent The VM was successfully VMWare - vCenter VMs
created.
VmDeployedEvent The VM was deployed VMWare - vCenter VMs
successfully.
VmDiscoveredEvent The vCenter successfully VMWare - vCenter VMs
discovers the VM.
VmRegisteredEvent The VM was successfully VMWare - vCenter VMs
registered.
VmReconfiguredEvent * The VM was reconfigured. VMWare - vCenter VMs
VmInstanceUuidAssignedEvent A new instance UUID was None
* assigned to the VM.
VmRenamedEvent * The VM was successfully None
renamed.
VmUuidAssignedEvent * A new BIOS UUID was None
assigned to the VM.
VmMacAssignedEvent * A new MAC address was VMWare - vCenter VM NICs
assigned to the VM.
VmMacChangedEvent * The MAC address of a VM was VMWare - vCenter VM NICs
changed.
VmGuestShutdownEvent* The guest VM shut-down. None
VmStoppingEvent* The VM stopped. None
VmResettingEvent* The VM reset. None
Cluster events
ClusterCreatedEvent A cluster was created. VMWare - vCenter Clusters
ClusterReconfiguredEvent * A cluster was reconfigured. VMWare - vCenter Clusters
ClusterDestroyedEvent * A cluster was destroyed. None
Datastore events
DatastoreRenamedEvent * A datastore was renamed. None
VMFSDatastoreCreatedEvent * A VM File System (VMFS) VMWare - vCenter Datastores
datastore was created.
DatastoreDiscoveredEvent * A host was added to VMWare - vCenter Datastores
VirtualCenter and datastores
were discovered.
NASDatastoreCreatedEvent * An Network Attached Storage VMWare - vCenter Datastores
(NAS) datastore was created.
LocalDatastoreCreatedEvent * A local datastore was created. VMWare - vCenter Datastores

VMFSDatastoreExpandedEvent A datastore was expanded. VMWare - vCenter Datastores

*
DatastoreDestroyedEvent A datastore was removed from None
VirtualCenter.
Network events
DVPortgroupCreatedEvent * A port group was created. VMWare - vCenter Networks
DVPortgroupRenamedEvent * A port group was renamed. None
DVPortgroupDestroyedEvent * A port group was destroyed. None
Resourcepool events
ResourcePoolDestroyedEvent * A resource pool was destroyed. None
ResourcePoolCreatedEvent * A resource pool was created. VMWare - vCenter Clusters
ResourcePoolMovedEvent * A resource pool was moved. VMWare - vCenter Clusters
ResourcePoolReconfiguredEvent A resource pool was VMWare - vCenter Clusters
* reconfigured.
DVS events
DvsCreatedEvent * A distributed virtual switch was VMWare - vCenter Networks
created.
DvsRenamedEvent * A distributed virtual switch was None
renamed.
DvsDestroyedEvent * A distributed virtual switch was None
destroyed.
Datacenter events
DatacenterCreatedEvent * A datacenter was created. VMWare - vCenter Datacenters
DatacenterRenamedEvent * A datacenter was renamed. None
* New for Jakarta.
How vCenter events are processed
The instance converts the subscribed vCenter events into system events (sysevent) that the system uses
to perform tasks, such as email notification.
The MID Server listens for the vCenter events configured in the vCenter Event Collector form. When one of
these events is returned from vCenter, the instance parses the payload with a business rule that converts
the vCenter event into a system event. The resulting sysevents contain these values:
• Name: Name of the system event created from the vCenter event. This value is always
automation.vcenter.
• Parm1: vCenter event that was returned. This event must be associated with an event collector record.
• Parm2: Event data provided by vCenter, in JSON format.

Figure 72: Log entries for vCenter events
Configure and run the vCenter event collector extension

Configure the vCenter event collector extension in the MID Server module, and then add or remove
supported events.
Before creating an event collector perform these tasks:
• Deploy and start a MID Server.
• Ensure that the MID Server has access to the vCenter.
• Run discovery on the vCenter.
Role required: agent_admin, admin

To configure the vCenter event processor extension:
1. Navigate to MID Server > Extensions > vCenter Event Collectors.
2. Click New or open an existing extension.
3. Fill in the fields, as appropriate from the table.
4. Right-click in the header bar and click Save in the context menu.
The vCenter Event related list appears, containing the default events that the system is configured to
handle.

5. To select a different vCenter event, click Edit in the vCenter Event related list and browse for the
event.
The slushbucket does not display all the available events in the opening list. Use the filter to browse
for events not displayed.
6. Under Related Links click Start to save the events in this collection and start the collector.
The Related Links in this form work as follows:
Table 26: Commands available in the vCenter event processor extension
Related Link Description
Start Starts the collector if it is currently not

running. The extension connects to the
specified vCenter server by enumerating
the VMware credentials in the credential
set until a connection can be made. Next,
the extension tells the vCenter server to
supply the events specified in the Collector
Context.
Stop Stops the running collector on the
configured MID Server. No action is taken if
the extension is not running.
Restart Stops, then starts the collector on the
configured MID Server.
Test Tests the parameters for validity. If the
IP address, hostname, and the set of
events is valid then the test returns a
successful status. If any of the parameters
are incorrect, an error is shown. Running a
test does not affect any extensions that are
currently running.
Update parameters Sends updated parameters to the collector.
Any changes you make to the collector while
the MID Server is running do not take effect
immediately when they are saved. If you
click this control when the collector is not
running, no update is made.
In the case of the vCenter extension, the
collector first tests the parameters for
validity. If the parameters are valid, the
extension disconnects from the vCenter
server and reconnects with the new
parameters.


Field Description
Name A unique name for this vCenter event

collector extension for easy identification.
Short description A description of this collector.
Extension [Read-Only] The collector type is
automatically set to vCenterExtension.
Status This field auto-populates with the status
of the collector. This field is blank until
the collector is started. After issuing a
command to the collector, you see one of
these values:
• Started: The collector is running.
• Stopped: The collector is not running.
• Offline: The MID Server is down.
• Error: The collector failed with an error.
Error Message Message describing any error that causes

a command, such as Start or Stop, to fail.
This field only appears when the value in the
Status field is Error.
Execute on Location for running this collection. The
possible options are Specific MID Server or
Specific MID Server Cluster.
MID Server The name of the designated MID Server
if you selected Specific MID Server in
the Execute on field. The name of the
designated MID Server cluster if you
selected Specific MID Server Cluster. If
you selected the MID Server cluster option,
an algorithm determines which server in the
cluster runs the collector.
vCenter The IP address or hostname of the vCenter
server.
Executing on [Read-Only] The name of the MID Server
on which the collector is running. This field
shows the name of the MID Server even if
the MID Server is down. If the collector is
stopped by the user, this field is empty.
You can add or remove supported events from the vCenter event collector. Multiple MID Servers can listen
to the same vCenter instance, but each MID Server can only have one event collector record associated
with it. Make sure you configure the events on the event collector record that specifies the correct MID
Server.
1. Navigate to the relevant vCenter Event Collector record. This can be the same collector record as the
one containing the supported vCenter events, but only if the same MID Server is used to gather the
events.
2. Click the Edit button in the vCenter Event related list.

3. Select the events from the list and save the selection.
Not every event is supported by the base system event handlers. See Supported vCenter events
for a list of the events you can use without needed to create your own event handlers. If you want to
handle other events, you must create a script action to process the events. For instructions, see Script
actions. As a reference, the instance processes the vCenter events in the base system with a script
action called Discovery: Process vCenter events. Do not edit or delete this script action.
SNMP trap collector extension

The SNMP trap collector is a MID Server extension that listens for SNMP traps from the devices on your
network.
Upon receiving a trap, the MID Server sends the trap to the instance for further processing by Event
Management. If Event Management is not active, traps are not processed and are discarded by the
instance.
For the SNMP trap collector extension to receive traps from network devices, each device must designate
the MID Server that runs the SNMP trap collector extension as a recipient of the trap. See the device
manual for the network device to configure your hardware to do this. Generally, the SNMP trap collector
extension should run on only one MID Server per VLAN. Multiple MID Server recipients on the same VLAN
causes duplicate data in the CMDB.
If network devices are separated by VLANs, multiple MID Servers may have trap collectors installed.
If you want to configure multiple SNMP trap collector extensions, you must configure each in a separate
record, with a unique name and designated MID Server.
Configure the SNMP Trap Collector Extension

For the SNMP trap collector extension to receive traps from network devices, each device must designate
the MID Server that runs the SNMP trap collector extension as a recipient of the trap.
To configure the trap collector extension:
1. Navigate to MID Server > Extensions > MID SNMP Trap Listener
2. Click New or open an existing extension.
3. Fill in the fields from the table, as appropriate.
4. Click Submit or Update.

Field name Description
Name A unique name for this SNMP trap collector

extension for easy identification.
Short description A description of the MID Server extension,
if more description than the Name is
necessary.
Extension [Read-Only] The extension type is
automatically set to TrapExtension.
UDP port The port number that your network hardware
uses when sending a trap to the designated
MID Server. Port numbers 1024 and above
are recommended. Port numbers 1023 and
lower may be system reserved and can
result in access violations for MID Servers
that are not running with administrative
credentials.
Status [Read-Only] The status of the trap collector
extension. This field is blank until the
extension is run. After it is run, the value
may be:
• Started: The extension is running.
• Stopped: The extension is not running.
• Error: The extension failed with an error.

Field name Description
Execute on The location for running this extension: a

Specific MID Server or a Specific MID
Server Cluster. The recommended setting
is Specific MID Server. Network hardware
typically has to be configured to send to a
specific IP address. If the listener moved to
a different MID Server in the cluster, the trap
would not be received.
MID Server The name of the designated MID Server
if you selected Specific MID Server in
the Execute on field. The name of the
designated MID Server cluster if you
selected Specific MID Server Cluster
in the Execute on field. If you selected
Specific MID Server Cluster, a ServiceNow
algorithm determines which server in the
cluster runs the extension.
on which the extension is running. This field
the MID Server is down. If the extension is
stopped by the user, this field is empty.
5. In Related Links, run any of the following actions against the SNMP trap collector extension:
Start Starts the extension if it is currently not

running. The extension is started on the
configured MID Server and port number.
Stop Stops the running extension on the
Restart Stops, then starts the extension on the
configured MID Server and port number.
Test Verifies that the configured MID Server
can run the SNMP trap collector extension
on the specified port. Running a test does
not affect any extensions that are currently
running.
Update parameters If you make changes to the extension
configuration, use this option to update
the parameters of the currently running
extension. First, the parameters are tested
for validity. If the parameters are valid, the
extension disconnects and reconnects with
the new parameters.

Discovery behaviors
Discovery behaviors determine the probes that Shazzam launches, and from which MID Servers these
probes are launched.
Unlike a scan performed by a single MID Server on a designated IP address range, 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.
Behaviors and domain separation
Behaviors also enable the efficient Discovery of SSH and SNMP devices and WMI devices running on
multiple Windows domains, using multiple MID Servers.
For example, an organization has two Windows domains in its network and a variety of UNIX computers
and SNMP devices. The challenge is to discover all the devices efficiently, without duplicating effort. Each
domain contains aWindows MID Server which is used to scan the IP addresses from the two domains
specified in the Discovery Schedule, as well as the SSH and SNMP devices. We need a Behavior that
divides the work appropriately to avoid scanning anything twice. In this example, we assume that both
domains are in the same geographical location, and that a single schedule is sufficient.
Note: The preferred method for running Discovery over multiple Windows domains is to use
PowerShell, which allows a single MID Server to authenticate on machines on different domains
using credentials stored on the instance.
Create a Discovery behavior

Create a Discovery behavior to determine which probes Shazzam launches and which MID Server is used.
1. Navigate to Discovery Definition > Behavior and click New.
2. Enter a name.
3. Right-click the form header and select Save.

4. In the Discovery Functionality related list, click New.

Discovery Functionality defines what each MID Server in this behavior must do, specifically which
protocols to detect.
5. Fill out the form fields:
Field Description
Phase Enter an integer that represents an arbitrary

phase. The phase is used to group one
or more functionalities together. All the
functionalities within a specified 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, such as SSH
and SNMP. In that example, set one phase
for the SSH scan and another phase for the
SNMP scan.
Active Keep this option selected to apply the

discovery functionality.
Functionality definition Click the lookup icon, and then select a pre-
configured functionality that defines the
protocol or list of protocols that each MID
Server scans.

Field Description
Match criteria Define criteria here for Windows MID

Servers.
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.

7. To add criteria that the functionality must meet in order to be triggered, click New in the Functionality
Criteria related list, fill out the form fields, and then click Submit.
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.
Operator Select a logical operator.

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.
Note: 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 process the results of
the probe.

The following graphic shows an example of functionality criteria.
Create a Discovery Schedule of type Configuration Item, and select Use Behavior for the MID Server
selection method.
Set up a load balancing behavior

When multiple MID Servers are configured to scan the same protocol, users can set up a load balancing
behavior to automatically balance the work between the MID Servers.
Behaviors enable load balancing when multiple MID Servers are configured to scan the same protocol.
For example, an organization has fifty remote locations, varying in size from 10 devices to several hundred
devices. All the satellite offices are part of the same Windows domain, which is administered from a central
location. There are three MID Servers installed at this central location: two to scan all the Windows devices
and one to scan the remaining devices. Because some of the remote offices are in different time zones,
different schedules must be created to run Discovery at off-peak hours in each time zone. The same
behavior can be used for each schedule, and the behavior will load-balance the two Windows MID Servers
automatically.
1. Create the behavior record.
a) Create a new Discovery behavior record, and name it something descriptive, such as
LoadBalanced.
b) Right-click in the header bar and select Save from the pop-up menu.
This action saves the record and creates the Discovery Functionality related list in the form.
2. Define the Windows functionality.

a) Click New in the Discovery Functionality related list.
b) Create a new record using the fields described here.
c) Right-click in the header bar and select Save from the pop-up menu.
Field Input Value
Phase Type a phase number of 1 in this field.

Functionality Select Windows only (WMI) from the list.
This functionality defines the protocol that
will be scanned. Because we selected to
scan WMI, we must select Windows MID
Servers for this functionality.

Field Input Value
MID Servers We select the two MID Servers that we

want to share the load for the WMI probes.
By entering multiple MID Servers in this
field, we tell Discovery to balance the load
between these servers automatically. If
we were to create separate functionality
for each server, load balancing would not
occur.
Active Make sure this check box is selected to
enable this behavior.
Match criteria Leave the default criteria of Any.
Figure 73: Discovery Functionality Form
3. Create Functionality Criteria.
Note: All Windows functionality requires criteria to identify the Windows domain and define
any special behavior for the MID Servers named.
a) Click New in the related list.

b) Enter the following values:
Field Input Value
Name We enter win_domain to name the

Windows domain that Discovery will
scan with the MID Servers we have
defined.
Operator Select equals as the operator in this
criteria.
Value This is the name of the Windows
domain that these MID Servers will
scan for devices.

Field Input Value
Active Be sure to enable the criteria by

selecting this check box (true).
The completed criteria appear in the Discovery Functionality form for the Windows MID Servers.
Figure 74: Completed Discovery Functionality Form
4. Define the functionality for the remaining scans.

Create a second record to scan for all the remaining protocols (SSH, SNMP, etc), using the following
settings:
Field Input Value
Phase Type a phase number of 1 in this field. This

phase will be executed at the same time as
the WMI scans and with the same Shazzam
probe. We use the same phase number
for efficiency and because we know that
none of the devices in the target IP ranges
are running multiple protocols (e.g. SSH
and SNMP). If any devices were running
multiple protocols, we would want to specify
a second or even a third phase to discover
the correct protocol first for each device.
Functionality Select All except Windows (no WMI) from
the list. This functionality causes the MID
Server to scan all remaining protocols after
Discovery has run the WMI scans.

Field Input Value
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.
Figure 75: Completed Discovery Behavior Form
5. Define the functionality for the remaining scans.

Create a second record to scan for all the remaining protocols (SSH, SNMP, etc), using the following
settings:
Field Input Value
Phase Type a phase number of 1 in this field. This

phase will be executed at the same time as
the WMI scans and with the same Shazzam
probe. We use the same phase number
for efficiency and because we know that
none of the devices in the target IP ranges
are running multiple protocols (e.g. SSH
and SNMP). If any devices were running
multiple protocols, we would want to specify
a second or even a third phase to discover
the correct protocol first for each device.
Functionality Select All except Windows (no WMI) from
the list. This functionality causes the MID
Server to scan all remaining protocols after
Discovery has run the WMI scans.

Field Input Value
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.
Figure 76: Completed Discovery Behavior Form
6. Create a schedule record for each time zone and name the behavior we just created..
a) Navigate to Discovery > Discovery Schedules and click New in the record list.
b) Select a Discover type of Configuration items.
This action displays the Behavior field.
c) Click the magnifier icon and select the behavior to use. In our example, we select LoadBalanced.
d) Select the appropriate time to run Discovery for this location.
e) Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this location.
f) Save the record.
g) Create additional schedules for each time zone or region in the network and select the same
behavior.


Examples of Discovery behavior functionalities

This example of a Discovery behavior requires three functionalities for the behavior.
We will create three functionalities for this Behavior: one MID Server to scan Domain A for Windows
devices only; a second functionality for the same MID Server to scan for all SSH and SNMP devices; and
a third functionality that names a second MID Server to scan Domain B for Windows devices. The rationale
for this is as follows:
• A Windows MID Server can only discover Windows machines on the Windows domain to which it is
joined. This is entirely due to the way Windows authentication works. For this reason, we need a WMI
functionality for each domain.
• A Windows MID Server, provided with the correct credentials, can discover SSH and SNMP devices
anywhere; however, we cannot combine WMI, SSH, and SNMP functionalities across Windows
domains. This is because the functionality criteria for the WMI scans locks in the Discovery to one
specific domain. For this reason, SSH and SNMP discoveries require a separate functionality.
• We want to scan each machine only once.
Functionality 1: WMI Scanning on Domain A
We configure a MID Server to scan for the WMI protocol on Domain A. WMI scans authenticate on
Windows machines using the domain credentials of the Windows MID Server machine. Windows MID
Servers cannot scan for the WMI protocol outside their own domains.
Create the first functionality using the following values:
Field Input Value
Phase Type a phase number of 1 in this field. All

functionalities in this example use the same
phase number, which launches a single
Shazzam probe for all the functionalities in that
phase. A single phase, when feasible, is the
most efficient use of the Shazzam probe.
Functionality Select Windows, DNS, and WINS from the
list. This functionality defines the WMI protocol
that will be scanned and resolves the domain.
Because we selected to scan for WMI, we
must select a Windows MID Server for this
functionality.
MID Servers We select a Windows MID Server from Domain
A - in this case sandb01-358.
Active Make sure this check box is selected to enable
this behavior.
Match criteria Change the criteria to All.
Create Functionality Criteria
All Windows functionality requires criteria to identify the domain and the MID Server. In our example, we
will create two criteria for this functionality. To create Functionality Criteria, click New in the Related List
and enter the following values for the MID Server doing the WMI scanning on Domain A:

Field Input Value
Name Create the following criteria:

• Enter mid_server to name the MID Server
that will execute the WMI scans on Domain
A.
• Enter win_domain to name the Windows
domain that Discovery will scan with the MID
Server defined.
Operator Select equals as the operator in this criteria.

Value • For the mid_server value, enter the name of
the MID Server that will scan Domain A for
Windows devices.
• For the win_domain value, enter the name of
Domain A that this MID Server will scan for
Windows devices.
Active Be sure to enable the criteria by selecting this

check box (true).
The completed criteria appear in the Discovery Functionality form for this behavior.
Functionality 2: SSH and SNMP
In our network, we want to scan for UNIX computers and netgear, but we don't want to classify these
devices twice. One of our MID Servers will be configured to classify SSH and SNMP using a different
functionality than it does for WMI scans. We do not need to create criteria for non-WMI functionality.
Create the second functionality using the following values:
Field Input Value

Functionality Select All except Windows (no WMI) from the
list. This functionality will scan SSH and SNMP
protocols only.
MID Servers We select the MID Server from Domain A - in
this case sandb01-358.
this behavior.
Match criteria Leave the default criteria of Any. Criteria are not
used for non-WMI functionalities.

Functionality 3: WMI Scanning on Domain B
All that remains is to create a functionality for the WMI scans on Domain B. Because of the Windows
authentication mechanism, we must configure a Windows MID Server to scan Domain B that is a member
of that domain.
Create the third functionality using the following values:
Field Input Value

Functionality Select Windows, DNS, and WINS from the
list. This functionality defines the WMI protocol
that will be scanned and resolves the domain.
Because we selected to scan for WMI, we
must select a Windows MID Server for this
functionality.
MID Servers We select a Windows MID Server from Domain
B - in this case disco-win2003.
this behavior.
Create Functionality Criteria
All Windows functionality requires criteria to identify the Windows domain and the MID Server. In our
example, we will create two criteria for this functionality. To create Functionality Criteria, click New in the
Related List and enter the following values for the MID Server doing the WMI scanning on Domain B:
Field Input Value

• Enter mid_server to name the MID Server
that will execute the WMI scans on Domain
B.
• Enter win_domain to name the Windows
domain that Discovery will scan with the MID
Server defined.
Operator Select equals as the operator in this criteria.

Field Input Value
Value • For the mid_server value, enter the name of

the MID Server that will scan Domain B for
Windows devices.
• For the win_domain value, enter the name of
Domain B that this MID Server will scan for
Windows devices.
Active Be sure to enable the criteria by selecting this

check box (true).
The completed criteria appear in the Discovery Functionality form for this behavior.
Discovery behavior example: access an ACL protected SNMP device

This topic explains how to access an SNMP device protected by an ACL using a Discovery behavior.
A specific type of Access Control List (ACL) on an SNMP device can prevent Discovery from identifying
that device. This list defines host machines by IP addresses that are permitted to run agents on SNMP
devices. In this example, we want to classify, identify, and update all the devices in an IP range, including
the SNMP devices protected by an ACL. To do this, we must install a MID Server with access to the
protected SNMP devices and then create a Behavior that allows us to scan for all protocols without missing
any devices or doing any extra work.
1. Install a MID Server on a host permitted by the ACL.
To scan the SNMP devices in a network protected by an ACL, a MID Server must be installed on a
host machine specified by IP address in the ACL as having access to the SNMP devices. Because this
MID Server is scanning SNMP devices only, it can be installed on any supported operating system.
The other MID Server, configured to discover WMI and SSH, can be installed on any Windows host
that has visibility to the specified IP ranges.
2. Install additional MID Servers if you intend to configure either functionality to load balance.
3. Create the behavior record.
a) Create a new Discovery Behavior record, and name it something descriptive, such as Southwest-
SNMP.
b) Right-click in the header bar and select Save from the pop-up menu.
This action saves the record and creates the Discovery Functionality related list in the form.
c) To complete this behavior (as shown in Figure 1) we must create functionalities using the MID
Servers we installed for that purpose.
For the functionality that scans for the WMI protocol, we must define criteria that specify the
Windows domain and MID Server being used. Because this Discovery is being performed on one
Windows domain, we can configure a functionality for WMI and SSH (All except SNMP) using the
same MID Server.

Figure 78: Completed Discovery Behavior
4. Define the functionalities.

For this behavior, we create two functionalities, one for SNMP on the MID Server installed on the host
specified in the ACL and another for WMI and SSH on a second MID Server.
a) Click New in the Discovery Functionality related list to add functionalities.
b)
Note: We configure the MID Server installed on the privileged host machine to scan for
the SNMP protocol only.
Create the first functionality using the following values:
Field Input Value
Phase Type a phase number of 1 in this field.

Both functionalities in this example
use the same phase number, which
launches a single 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.

Field Input Value
Match criteria Leave the default criteria of Any.

Criteria are not used for SNMP
functionalities.
Figure 79: Scan for SNMP Only
c)
Note: In the second functionality, Discovery will scan our domain for WMI and SSH
protocols. Because WMI is one of the protocols, the MID Server for this functionality must
be installed on a Windows machine and must have criteria.
Create the second functionality using the following values:
Field Input Value
Phase 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.

Field Input Value
Figure 80: Scan for All Except SNMP
d)
Note: Functionalities that scan for WMI require criteria to identify the domain and the MID
Server. In our example, we will create two criteria for this functionality.
To create functionality criteria for a WMI scan, click New in the related list.
e) Enter the following values for the MID Server doing the WMI scanning on our domain:
Field Input Value

• Enter mid_server to name the MID
Server that will execute the WMI
scans.
• Enter win_domain to name the
Windows domain that Discovery will
scan with the MID Server defined.
Operator Select equals as the operator in this

criteria.
Value • For the mid_server value, enter
the name of the MID Server that
will scan our domain for Windows
devices.
• For the win_domain value, enter the
name of our Windows domain.
Active Be sure to enable the criteria by

selecting this check box (true).
The completed criteria appear as follows in the Discovery Functionality form for this behavior.

Figure 81: Functionality Criteria for a WMI Scan
5. Create the schedule.

a) Create a Discovery Schedule record and name the behavior we just created.
b) Navigate to Discovery > Discovery Schedules and click New in the record list.
c) Select a Discover mode of Configuration items. This action displays the Behavior field
d) Click the magnifier icon and select the behavior to use. In our example, we select Southwest-
SNMP.
e) Select the appropriate time to run Discovery for this location.
f) Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this domain.
g) Save the record.

Figure 82: Discovery Schedule Record
Change the Discovery source name

You have the option of changing the source name of discovery results. You might want to do this if you
have another discovery application running on your network and want to have customized identifiers.
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, configure a CI form and add the Sources list. This table is populated
automatically when the Discovery plugin is enabled.

Figure 83: Sources List
To migrate your Discovery Source to ServiceNow:

1. Update the glide.discovery.source_name system property to have a value of ServiceNow.
2. Edit the dictionary entry for the Configuration Item [cmdb_ci] table.
3. Update the choice list for the discovery_source column to only have the value ServiceNow.
4. Open a list for the Configuration Item [cmdb_ci] table and filter on a discovery source field value you
want to change.
5. Use the Update All option to change the value to ServiceNow.
6. Open a list for the Source [sys_object_source] table and filter on a name field value you want to
change.
7. Use the Update All option to change the value to ServiceNow.
Patterns and horizontal discovery

A pattern is a series of operations that tell Discovery which CIs to find on your network, what credentials to
use, and what tables to populate in the CMDB.
It performs the same basic functions as probes and sensors. The main difference between patterns
and probes and sensors is that Discovery uses patterns for the identification and exploration phases of
Discovery only.
When you kick off a discovery, the discovery and classification phases run as they would if you were not
using patterns. After the classification stage ends, Discovery looks at the Triggers Probes related list on
the classifier to see which probe to launch. If the Horizontal Pattern probe is specified, Discovery launches
it, and then launches the pattern specified in it. For more details on the overall Discovery process, see
Horizontal discovery process flow on page 8.
Patterns and upgrades
Patterns are gradually replacing out-of-box probes and sensors, especially for the discovery of
applications. If you are upgrading your instance to a new version and if you customized probes and
sensors or a classifier, the upgrade might not replace these components with the new pattern or the
components necessary for pattern discovery. If you want to manually migrate from probes and sensors that
were not automatically upgraded to patterns, see the instructions in Add the Horizontal Pattern probe to a
classifier on page 210.
Using patterns
Both Discovery and Service Mapping can use the same pattern for horizontal and top-down discovery. But
they are edited differently. See Create a pattern on page 738 for all steps. If you take a pattern that was
exclusively used for top-down discovery and you want to use it for horizontal discovery, you have to make
a few modifications. See Use a pattern for horizontal discovery on page 210 for instructions.

This video provides an example of using patterns for horizontal discovery:
Use a pattern for horizontal discovery

If you want to use a new pattern, or if you already have a pattern that you were using for top-down
discovery, you can use the pattern for horizontal discovery with a few modifications to the relevant
classifier.
1. Verify that Discovery can use the pattern:
a) Navigate to Pattern Designer > Discovery Patterns.
b) Open the pattern. Service Mapping patterns are indicated as type 1-Application.
Two UI actions appear for editing the pattern: Edit for Discovery (for the Discovery application)
and Edit for Mapping (for the Service Mapping application).
c) Click Edit for Discovery. The pattern designer window opens.
d) In the Identification Sections window, verify that there is at least one section that allows for an
entry point type of TCP or All. If not, create one. See the Identification steps for creating a new
pattern.
e) Close the pattern designer.
2. On the instance, create or modify the classification for the CI type you want to discover. Configure the
classifier as follows:
a) Navigate to Discovery Definition > CI Classification > {classification type}.
b) Open the relevant classifier.
c) Configure the classifier as follows:
• Relationship type: Select Runs on::Runs (for process classifiers only)
• Condition: Configure the same condition you defined in the pattern.
• Triggers probes Related list: Add the Horizontal Pattern probe, and then add the pattern you
are using to the Pattern column.
See Create a Discovery CI classification on page 91 for a description of the other fields on the
classifier.
Run the pattern in Debug mode to test it. When you are sure the pattern works, you can run discovery by
setting up a discovery schedule or running an on-demand discovery. See Schedule discovery on page
28 for more information.
Add the Horizontal Pattern probe to a classifier

To use a pattern for the identification and exploration phases of horizontal discovery, you must add the
Horizontal Pattern probe to the classifiers for the CIs are you trying to discover.
Discovery uses the Horizontal Pattern probe to launch patterns for horizontal discovery.
1. Navigate to Discovery Definition > CI Classification > {classifier type}.
2. Open the classifier record.
3. Click the Triggers probe related list.
4. Deactivate the existing identification and exploration probes.

5. Click Edit, and add the Horizontal Pattern probe. The probe appears in the related list.
6. From the related list view, double click the field under the Pattern column and add the pattern you
want to associate with the classification.
7. Remove or deactivate the other probes from the Triggers probe related list.
Note: If you delete a pattern, the Horizontal Pattern probe is not automatically removed from
the classifier. You must select another pattern for the Horizontal Probe, or you can switch back
to using identification and exploration probes specific to the classifier. If you use the Horizontal
Probe without a pattern specified, discovery stops after the classification stage.
Discovery probes and sensors

Discovery probes and sensors perform data collection and update the CMDB.
Note: With each release, patterns are replacing many probes and sensors for Discovery. Consider
creating new patterns or editing existing ones if you want to customize what Discovery can find.
The information on probes and sensors is intended for customers who are not using patterns yet
and for customers who already have customized probes that are retained upon upgrade. See
Patterns and horizontal discovery on page 209 for more information on patterns.
Discovery phases
Discovery always uses probes and sensors during the first two phases of discovery: scanning and
classification. For the last two phases, identification and exploration, Discovery can use probes and
sensors or patterns. This topic refers to probes and sensors only. See Discovery basics on page 4 for
an explanation of these phases. See Patterns and horizontal discovery on page 209 for more information
on patterns.
Probes, sensors, and the ECC queue
The probe collects the information and the sensor processes it. Both get their instructions from the ECC
queue. There is a worker job on the MID Server that monitors the queue for work. The monitor checks for
any entries where the Queue is output and the State is ready.

The MID Server then processes all the output ECC messages, runs the necessary probes, and returns the
probes results to the ECC queue. These results are put in the ECC Queue as input entries.
Figure 84: ECC queue input
After an entry is inserted in the ECC Queue table, a business rule fires (on insert) that takes that
information and runs it through a sensor processor. The sensor processor's job is to take the input data,
find any sensors interested in that data, and pass it along to be processed. Those sensors ultimately
update the CMDB.
How probes and sensors work together
The MID Server launches probes to collect information about a device. The probe sends back information
to the sensor to be processed. If the probe has a post-processing script defined, the post-processing script
does some data processing on the MID Server before data is sent back to the sensor on the ServiceNow
instance. Otherwise the probes sends back all the data collected and the sensor performs this data
processing. In both cases, the sensor updates the CMDB.

A multi-probe is a probe that contains probes. A multi-sensor processes the data from a multi-probe. To
process the data from the multi-probe, the multi-sensor contains individual scripts to process the data
returned by each probe contained in the Multiprobe, as well as a main multi-sensor script. The individual
scripts pass their processed data to the main multi-sensor script.
Probe types
Device Probe Type
Windows computers and servers Remote WMI queries, shell commands

UNIX and Linux servers Shell command (via SSH protocol, version 2).
Discovery supports any Bourne-compatible shell.
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
Discovery probe management

Several discovery probes and their associated sensors are included with Discovery. You rarely need to
modify probes or sensors. But you might need to set parameters to control the behavior of a particular
probe or align versions of customized probes.
Note: With each release, patterns are replacing many probes and sensors for Discovery. Consider
creating new patterns or editing existing ones if you want to customize what Discovery can find.
The information on probes and sensors is intended for customers who are not using patterns yet
and for customers who already have customized probes that are retained upon upgrade. See
Patterns and horizontal discovery on page 209 for more information on patterns.
What you can do
These are the things you can do with probes and sensors:
Review the base system probes Review the List of Discovery probes on page
214 to see the probes that exist in the base
system. Probes need to be active on classifiers for
Discovery to trigger the probes. However, not all
probes are active on classifiers as more patterns
replace probes and sensors.
Create or modify a probe You can create a new probe to discover additional
CIs that Discovery does not find with the base
system probes or patterns, or modify an existing
probe to collect additional information on the type of
CI. After you create or modify a probe, test it. You
can also create multiprobes and multisensors. See
Discovery multiprobes and multisensors on page

Upgrade to the latest version of a probe or If you upgrade your instance, the Discovery
sensor application is also updated, along with components
like probes and sensors. However, if you
customized any probes or sensors, they do not
upgrade. You need to copy your customizations to
a text file, upgrade the probes and sensors, and
reapply your customizations. See Align versions of
customized probes and sensors on page 266 for
more information.
Set probe parameters Probe parameters control several aspects about
how probes function. With each probe provided in
the base system, certain parameters are allowed.
These are specified in the list of Discovery probes.
See Set probe parameters on page 264 for
instructions on how to set a parameter.
Review probe permissions Certain probes need permissions to run on the
target machines or CIs that you are trying to
discover. See Discovery probe permissions on page
List of Discovery probes

A wide variety of probes exist for the Discovery application to detect elements on your network.
These probes are included with the Discovery application.
The PPP script designation in the table indicates whether the probe includes a probe post-processing
(PPP) script that runs on the MID Server. The PPP script transforms probe results into a JSON string and
returns the string to the ServiceNow instance for sensor processing.
To view probes and their descriptions, navigate to Discovery Definition > Probes.
CIM probe
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 instructions on configuring probe parameters, see Set probe parameters on page 264.
The following parameters may be passed to the CIM probe:
Table 27: CIM Probe
Parameter Description Default Value
source [Required] The initial host to None

connect to.
port The port to connect to. If empty, 5988 or 5989
the value is determined by the
"schema" parameter: http =
5988, https = 5989.
schema [Required] The schema to use: http
'"http"' or '"https"'.
namespace [Required] The CIM None
namespace. May be overridden
by a query.

queries [Required] A semicolon- None

delimited list of CIM probe
queries to process and return
results for.
retries The number of times to retry a 2
query if it fails due to network
connectivity issues.
connection_timeout The number of milliseconds 5000
the probe has to connect to a
server.
socket_timeout The number of milliseconds the 5000
probe has to read data.
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 foobarprobe parameter passed to the CIM probe;
likewise for barfoo.
CIMIQL
The CIM Intermediate Query Language (CimIQL) is an intermediate language designed to simplify the
process of querying CIM providers.
CimIQL currently supports the standard Web-Based Enterprise Management (WBEM) protocol stack, but
others, such as Web Services-Management (WS-MAN), may be added in the future. The query language
syntax borrows from elements of Microsoft's WMI query language and UNIX's wbemcli command. The
CimIQL library is a pure Java implementation.
Note: CimIQL is pronounced "simicle".
CimIQL syntax
CimIQL syntax consists of several elements, including a query and different tokens.
Table 28: CimIQL Syntax Element Descriptions
Element Description
Statement The most basic element of CimIQL is a valid . A

statement contains multiple queries delimited by
a period . character.

Element Description
Query A represents a single high-level protocol-

independent request. Each query is comprised
of nested language components and sub-
components known as tokens.
Token A describes a specific lexical aspect of the
CimIQL syntax.
Operation Token The first token of each query must be an , which
represents the overall logical operation to be
performed.
Component Token A is a sub-component of an operation token.
Result Each query is paired with a result, which is
then provided as input to the next query in the
statement. A is comprised of a set of objects
and their properties.
CimIQL operation tokens

The CimIQL probe requires operation tokens.
Each of the following core operations has a counterpart in the CIM Operations over HTTP standard.
Table 29: CimIQL Operation Token Summary
Return Value Details Equivalent CIM Operation over

HTTP
class object Get Object GetInstance
• Retrieves a single object of

a specific class by specifying
all of its unique keys (as key
tokens) and any optional
parameter tokens, separated
by commas.
class object Enumerate Objects EnumerateInstances
• Retrieves objects that match

a set of condition tokens and
parameter tokens.
class object Enumerate Associated Objects Associators
• Retrieves objects associated

with each result from the
preceding query.

Return Value Details Equivalent CIM Operation over

HTTP
statement results Substitution Reference the results of a

named statement
• A no-op token that feeds
the results of a previous
named statement as input
into the next query of its own
statement.
Get Object Token
<classname>{<key token>,<parameter token>,...}

• Retrieves a single object of a specific class by specifying all of its unique keys (as key tokenskey
tokens) and any optional parameter tokens, separated by commas. This token is also known as the .
• The <classname> is the case-sensitive CIM class name of the desired object. By default, objects of the
specified class and of any extended classes are retrieved.
• The key and parameter tokens are enclosed by a single pair of curly brackets { ... }.
• This token must only be used as the first query in a statement.
• Returns: class object
• Example:
CIM_ComputerSystem{CreationClassName='Linux_ComputerSystem',Name='runtime'}.*
Enumerate Objects Token
<classname>{{<condition token>,<parameter token>,...}}<array index token> OR <classname><array

index token>
• Retrieves objects that match a set of condition tokens and parameter tokens. This token is also known
as the .
• The condition tokens and parameter tokens are enclosed by two pairs of curly brackets {{ ... }}. The
curly brackets are optional if there are no conditions or parameters necessary.
• The <classname> is the case-sensitive CIM class name of the desired objects. By default, objects of
the specified class and of any extended classes are retrieved.
• The index token is optional.
• This token must only be used as the first query in a statement.
• Example:
CIM_ComputerSystem{{Name!='runtime'}}.*
Enumerate Associated Objects Token
<association classname>{{<property filter token>,<parameter token>,...}}<array index token> OR

<association classname><array index token>

• Retrieves objects associated with each result from the preceding query.
• The condition tokens and parameter tokens are enclosed by two pairs of curly brackets {{ ... }}. The
curly brackets are optional if there are no properties filters or parameters necessary.
• The <association classname> is the name of the many-to-many or one-to-many class that associates
two objects together. By default, objects of the specified class and of any extended classes are
retrieved.
• The <parameter token>, ResultClass, may be specified to filter results based on the resulting object's
classname.
• The index token is optional.
• This token must not be used as the first query in a statement.
• Example:
CIM_ComputerSystem{{Name='runtime'}}[2].*
Substitution Token
${<statement name>}
• A no-op token that feeds the results of a previous named statement as input into the next query of its
own statement.
• Returns: void
• Example:
$(lastComputer).ElementName
CimIQL component tokens

The CimIQL probe requires component tokens, which are sub-components of operational tokens.
The following tokens are sub-components of operation tokens.
Table 30: CimIQL Component Token Summary
Token Details
Properties token * OR <property name>,<property name>,...

• Specifies which properties are to be returned
for each object of the final result set.
Query Delimiter Token . (Period)

• Separates queries.
Index Token [index]

• Reduces a preceding query's results to a
single object at the specified integer index.
Key Token <key name>='<value>'

• Matches an object property designated as a
key by exact value.

Token Details
Condition Token <property name><conditional

operator><enclosed value>
• Matches a single property of an object based
on the condition specified.
Parameter Token <parameter name>:'<value>'

• Passes a parameter by <parameter name>
to the operation being called. The parameter
may be consumed during CimIQL pre-
processing or by the CIMOM via request,
depending on the parameter.
Properties Token
* OR <property name>,<property name>,...

• Specifies which properties are to be returned for each object of the final result set.
• The wildcard * returns all properties available. Otherwise, each property name desired is provided
within a comma-separated list.
• This token is required at the end of each statement.
• Example:
CIM_ComputerSystem[0].*
Query Delimiter Token
. (Period)
• Separates queries.
• Example:
CIM_ComputerSystem.PrimaryOwnerContact
Index Token
[index]
• Reduces a preceding query's results to a single object at the specified integer index.
• This token is always optional.
• Example:
CIM_ComputerSystem[0].*

Key Token
<key name>='<value>'
• Matches an object property designated as a key by exact value.
• The <key name> is the name of the property used as a key.
• Example:
CIM_ComputerSystem{CreationClassName='Linux_ComputerSystem',Name='runtime'}.*
Condition Token
<property name><conditional operator><enclosed value>

• Matches a single property of an object based on the condition specified.
• The <property name> is the name of the property to match against.
• The <conditional operator> determines how the property's actual value is compared to its expected
value. The operators available are equality (=) and inequality (!=).
• The <enclosed value> should be one of the following:
• Literal value enclosed in single-quotes ' ... '. For example, foo='bar'
• Regular expression, enclosed by a pair of slashes / ... /. For example, foo=/bar.*/
• Example:
CIM_ComputerSystem{{Name!='runtime'}}.*
Parameter Token
<parameter name>:'<value>'
• Passes a parameter by <parameter name> to the operation being called. The parameter may be
consumed during CimIQL pre-processing or by the Common Information Model Object Manager
(CIMOM) via request, depending on the parameter.
• Example:
CIM_ComputerSystem.CIM_RunningOS{{ResultClass:'Win32_ComputerSystem'}}.*
CimIQL tutorial
This is a tutorial by example where each example builds on the previous example.
Table 31: CimIQL Tutorial
Order CimIQL Statement Result
1 CIM_ComputerSystem[0].* Retrieves the first

result of all instances of
CIM_ComputerSystem and
its descendants. Retrieves all
properties.

2 CIM_ComputerSystem.PrimaryOwnerContact
Retrieves all instances of
CIM_ComputerSystem
and their descendants.
Retrieves only one property,
PrimaryOwnerContact.
3 CIM_ComputerSystem{CreationClassName='Linux_ComputerSystem',Name='ru
Retrieves a single
unique instance of
CIM_ComputerSystem and its
descendants. All key tokens
must be specified within the { }
identity token.
4 CIM_ComputerSystem{{Name! Retrieves all instances
='runtime'}}.* and descendants of
CIM_ComputerSystem that do
not have a Name property of
'runtime'.
The filter token {{ }} filters out
instances that do not contain all
of the properties/keys specified.
5 CIM_ComputerSystem{{Name=/ Retrieves all instances

^run.*$/}}.* and descendants of
CIM_ComputerSystem that
have a value matching the
regular expression contained
within the / / characters.
Note: The regular

expression does
not require single
quotations.
The filter token {{ }} filters out

instances that do not contain all
of the properties/keys specified.

6 CIM_ComputerSystem{{Name='runtime'}}
Retrieves the second
[2].* result of all instances of
its descendants where the
instances have a property
Name of 'runtime'.
The order of operations follows
the query syntax.
1. Query server for all
descendants.
2. Filter results based on
Name property.
3. Retrieve the second
instance that passed the
filter.
7 CIM_ComputerSystem.CIM_RunningOS[0].Name
Retrieves the Name
property for the first
CIM_OperatingSystem instance
of each CIM_ComputerSystem
instance.
The middle-token,
CIM_RunningOS, is the name
of the Associator class, not the
end-result.
8 CIM_ComputerSystem.CIM_RunningOS{{Name=/
Retrieves the Name
CentOS/}}[0].Name property for the first
of each CIM_ComputerSystem
instance, where each
has a Name property containing
'CentOS'.
CimIQL results
CIM Probe results are passed to the probe sensor as an XML document embedded within the <output>
element.
The following is a commented example of a CimQuery batch result.


<cimqueryset>

<cimquery>

<query><!CDATA[[>CIM_ComputerSystem[0].PrimaryOwnerContact<! ]]></query>

<result>


<instance>

<_classname>Linux_ComputerSystem</_classname>

<_key>
<CreationClassName><![CDATA[Linux_ComputerSystem]]></
CreationClassName>
<Name><![CDATA[runtime]]></Name>
</_key>

<PrimaryOwnerContact><![CDATA[root@runtime]]></PrimaryOwnerContact>
</instance>
</result>
</cimquery>
</cimqueryset>
Horizontal Pattern probe

Discovery uses the Horizontal Pattern probe to launch patterns for horizontal discovery.
The Horizontal Pattern probe works with the Horizontal Discovery sensor to use patterns for discovery.
When you see messages in the ECC Queue from this probe, they appear with the ECC queue name
Pattern Launcher.
If you create your own device or process classifier and you want to use patterns for discovery, you must
specify this probe in the classifier record. You do not need to modify this probe or the Horizontal Discovery
sensor.
Splitting payload
When Discovery uses patterns to find certain devices like load balancers, large amounts of data could be
sent to the ECC Queue. To better handle large amounts of data, the horizontal pattern probe can split the
payload into chunks, and then create multiple ECC Queue records.
Control how the MID Server splits payloads and handles payloads using properties. See MID Server
properties for more information.
PowerShell probe
The PowerShell Probe executes PowerShell V2 scripts on the MID Server host.
PowerShell scripts are defined as probe parameters with the filename as the parameter name. It is
available as a Probe probe type by specifying PowerShell as the probe's ECC queue topic.
PowerShell probe parameters
Parameter name Description Default
source [Required] The initial host to none

connect to.

<script name>.ps1 [Required] The filename of none

the PowerShell script to run.
Replace <script name> with a
valid filename prefix.
Specifies whether to pass script false

powershell_command_parameter_passing
parameters on the command
line. Regardless of this
parameter's value, ServiceNow
makes all script parameters on
the command line automatically
available to PowerShell scripts
as environment variables.
powershell_param_<script Passes additional parameters none

parameter name> to the PowerShell script to be
executed. Each parameter
will appear to the script as
an environment variable in
the format $env:SNC_<script
parameter name>. Parameters
with this prefix are not
considered encrypted
and are passed through
to the script untouched.
Make sure you select the
appropriate parameter between
powershell_param_<script
parameter name> and
powershell_<script parameter
name>. Using the wrong
prefix results in errors in the
PowerShell execution, which is
passed back to the instance in
the ECC queue input.

powershell_<script parameter Passes additional parameters none

name> to the PowerShell script to be
executed. Each parameter
will appear to the script as
an environment variable in
the format $env:SNC_<script
parameter name>. The
MID Server assumes that
any parameter with this
prefix is encrypted and
attempts to decrypt it.
Make sure you select the
appropriate parameter between
powershell_param_<script
parameter name> and
powershell_<script parameter
name>. Using the wrong
prefix results in errors in the
PowerShell execution, which is
passed back to the instance in
the ECC queue input
debug Enables debug log output false
during the probe.
credentials_debug Displays a <credentials_debug> false

section in the ECC queue,
which can help you troubleshoot
credentials. If you set this
property to true, credential
troubleshooting information is
output to the ECC queue, even
if the credentials succeed.
Scripting requirements
Any custom PowerShell scripts must use environment variables to pass any non-Boolean command line
parameter. Replace non-Boolean parameters in the Param() portion of the script with script variables
of the same name. Define the script variable as part of the environment with an SNC_ prefix. So a string
parameter such as this:
Param([string]$paramName)
Becomes a script variable such as the following:
if(test-path env:\SNC_paramName) {
$paramName = $env:SNC_paramName
}

For example, this parameter definition from the PSScript.ps1 script contains several string parameters that
need to be redefined as script variables:
Param([string]$computer, [string]$script, [string]$user, [string]$password,

[boolean]$useCred, [boolean]$isDiscovery, [boolean]$debug)
Defining the non-Boolean parameters as script variables would result in this type of script:
Param([boolean]$useCred, [boolean]$isDiscovery, [boolean]$debug)
# Copy the environment variables to the params

if(test-path env:\SNC_computer) {
$computer=$env:SNC_computer
}
if(test-path env:\SNC_script) {
$script=$env:SNC_script
}
if(test-path env:\SNC_user) {
$user=$env:SNC_user
$password=$env:SNC_password
}
Create a custom PowerShell probe

You can create your own PowerShell probe and configure probe parameters.
2. Click New.
3. Enter the following values.
• Name: Any unique name
• Probe Type: Probe
• ecc_queue_topic: Powershell

5. From the Probe parameters related list, click New.
6. Create a probe parameter record for each parameter.
7. Click Submit.
SCPRelay probe
The SCP Relay Probe copies a single file or the contents of a directory from one host to another, using the
MID Server as a relay.
The SCP Relay probe uses the same parameters as SSHCommand. The commands may be sent in or out
of the context of a terminal (tty), and with or without sudo (for those commands, such as lsof, that require
being executed in the context of root to cough up the information we need). When commands are sent in
the context of a terminal, the path is automatically widened to include a set of default paths (and this can
be further widened with the path_override parameter). If the target machine is the local machine, SSH is
not used; instead, a local shell is run to execute the command.
The following parameters may be passed to the SCP Relay probe:

Table 32: Parameters
debug Enables debug logging. false

debug_ssh Enables J2SSH debug logging false
(into ssh.log, which can get very
large - be careful!)
timeout Sets the socket connection 60000
timeout, in ms.
path_override Overrides the default paths set none
before executing a command.
keyboard_interactive If true, forces the use of false
keyboard_interactive SSH login
mode.
must_sudo If true, forces the command to false
be executed through sudo.
run_in_terminal If false, disables SSH true
commands from running in an
SSH terminal (this will break
many commands).
long_runner If present, indicates a long- false
running SSH command.
set_path If false, disables setting the true
path environment variable
before running the command.
rm_override If present, overrides the default none
rm command ("/sbin/rm -f") with
the provided value.
source Source host or IP to copy from. required
source_port SSH port on the source required
(defaults to 22).
from_file Name of the file to copy from required
the source.
target Target host or IP to copy to. required
target_port SSH port on the target (defaults required
to 22).
to_file Name of the file to copy to the required
target.
SNMP probe
The SNMP Probe uses the SNMP protocol to query a particular device for a list of OIDs, which are then
traversed and the results passed back to the sensor.
Discovery supports SNMP versions 1, 2c, and 3. Discovery uses version 1 and 2c by default. You must
enable support for version 3.

MID Servers support all SNMP protocol versions by default. You can set a MID Server to only support
specific versions of SNMP.
SNMP probe parameters
This list of parameters may be passed to the SNMP probes.

oid_spec_list A list of OID specifications, one required

per line. Each specification
must be in one of the following
two forms:
• walk {OID}: Walks the OID
and all its children
• table {OID} {OID Children}:
Walks all entries in the
table, returning only the
given children (for example,
"iso.org.dod.internet")
{OID Children} refers to a

comma-delimited list of child
nodes within the entries for
the given table. For example,
"ifEntry.ifIndex,ifEntry.ifDescr,ifEntry.ifType"
are OID children of the table
"iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable".
As a convenience, the
table entry prefix may be
left off. (The preceding
children could be specified as
"ifIndex,ifDescr,ifType".)
Any child may include a filter
qualifier in parentheses.
For example, the child
"entPhysicalContainedIn(=0)"
specifies returning table
entries only if the value of
"entPhysicalContainedIn"
equals 0. The operators
supported in the expression
are:
= equals
!= does not
equal
# contains
If more than one child has a

filter expression, a match on
any one of the children causes
that entry to be read.
Any content including
and after a "//" is ignored
(comments). Any OID that
does not start with "1.3.6.1"
or "iso.org.dod.internet"
automatically prefaces with
"1.3.6.1." as a convenience.

source The IP address or host name of required

the device to query SNMP on.
index The index to apply after the 0
community string, for Cisco-
style community string indexing
(for VLAN interrogation).
credential_id The sys_id of a specific none
credential that is preferred for
1
use above the rest.
credential_tag The credential tag that must be none
2
used.
timeout The timeout value (in 1500
milliseconds) to wait for a
response, instead of the
default. You can use this
parameter to override the
mid.snmp.request.timeout
SNMP MID Server configuration
parameter.
Note: When
use_getbulk is set to
true, the timeout value
is for an individual
GETBULK request.
established_session_timeout The interval (in milliseconds) 500

to wait for a response after at
least one response has been
received. Longer values can be
useful for collecting complete
and accurate data. You can
use this parameter to override
the mid.snmp.session.timeout
SNMP MID Server configuration
parameter.
debug Enables debug logging. Set to false
true for debug mode.
1
This parameter is for internal use only and is not supported.
2
This parameter is for internal use only and is not supported.

request_interval The interval (in milliseconds) 400

between successive requests
for an OID when a response
has not been received. If
this value is smaller than the
timeout value (or established
session timeout value), then
multiple requests are sent
if a device takes too long to
respond. The default value is
250ms, or 0.25 seconds. For
example, suppose that a device
takes 0.9 seconds to respond
to a query. Queries are sent,
four in all, at t + 0, t + 250ms, t
+ 500ms, and t + 750ms. The
device may respond with from
1 and 4 responses. If this value
is set to at least as long as
the timeout value, then only a
single request is sent for any
particular OID.
request_delay The interval (in milliseconds) 0
between the receipt of a
response and the transmission
of the next request. The default
is 0 (no delay). This value may
be set to slow the overall rate of
an SNMP query.
result_format Returns JSON formatted JSON
payloads for the SNMP - F5
BIG-IP - System and SNMP
- Netscaler - System probes.
This parameter returns data
in a more compact format
to prevent sensor failure or
memory problems on a node
when the payload becomes
large. Do not change this value
or delete this parameter.
Caution: Use of this

parameter with any
other probes causes
the sensor to fail.

use_getbulk Enables the use of SNMP false

GETBULK requests to retrieve
tabular data from SNMP
devices instead of using
multiple SNMP GETNEXT
requests. For tabular data,
GETBULK is more efficient.
Regardless of the request type,
certain devices may not return
any results when they are busy
with other tasks.
The
established_session_timeout,
request_interval, and
request_delay parameters are
ignored when use_getbulk
is set to true. Instead, the
retries parameter is available.
The timeout configuration
is the same one used by
use_getscalar.
Note: SNMP
GETBULK is only
available on devices
that support SNMPv2c
or SNMPv3. Requests
to devices configured
to use SNMPv1 only,
automatically revert to
using GETNEXT with
no further configuration
required.
By default, the following probes

use GETBULK requests (the
parameter value is true).
• SNMP - Switch - Vlan
• SNMP - Switch -
BridgePortTable
• SNMP - Switch -
ForwardingTable
• SNMP - Switch -
SpanningTreeTable
• SNMP - Network - ArpTable
• SNMP - Layer 2 Protocol
Caches
• SNMP - F5 BIG IP - System
(only for Service Mapping
customers)
Note: These probes

have a timeout value of
5000.
use_getscalar Enables the use of simplified false

retrieval and handling of scalar
values from SNMP devices.
The
established_session_timeout,
request_interval, and
request_delay parameters are
ignored when use_getscalar
is set to true. Instead, the
retries and timeout parameters
are available. The timeout
configuration is the same one
used by use_getbulk.
retries The number of additional 2

attempts Discovery makes
to complete an individual
GETBULK request (see
use_getbulk) or a GETNEXT
request when the use_getscalar
parameter is set to true.
Load a MIB module

You can load an additional MIB module by creating a new ecc_agent_mib record and attaching the actual
MIB file to the record.
MIBs are only loaded during MID Server startup. When the MID Server starts up, the following
management information base (MIB) modules are loaded:
• Modules that are bundled with the MID Server software. These MIBs are defined industry standards.
• Modules that are included in each instance. These MIBs are provided by manufacturers for Discovery to
extract specific information from a device.
You can view any errors associated with loading a MIB module in the agent log.
1. Navigate to MID Server > SNMP MIBs.
2. Check whether dependencies are met.
If your new MIB has dependencies on another MIB, the MIB that fills the dependency must exist
before you create your new record. Search the existing MIBs to check that the required MIBs are
already loaded. If they are not, use this procedure to also add them to the instance.
3. Click New to create a new record.
The MID Server MIB File form opens to create a new ecc_agent_mib record.
4. Use the following information to fill out the form:
• Name: The name of the MIB.
• Version: The version of the MIB.
• Source: Use this field to note where the MIB was acquired, such as a URL.
• Description: The description that appears in the ecc_agent_mib table.
• Active: This check box denotes whether the MIB module is enabled or disabled in the instance.
5.
Click the Add Attachment icon ( ) in the upper right to attach the actual MIB file to the new record.

The MIB name must begin with an alphabetical character. Remaining characters must be one of the
following: alphanumeric, hyphen ( - ), or underscore ( _ ). The file name must not have an extension.
You can reference the existing MIBs for examples. Use the actual name of the MIB for both the MIB
record name and the attachment name, but it is not required.
Figure 85: MIB form
SNMP probe MIB modules

A management information base module (MIB) is a database that is used to manage elements in a
network.
Your instance includes object definitions from the most common management information base (MIB) files.
Before adding a new object definition, consult this list of MIB modules to ensure that the object definitions
are not already available. The instance includes object definitions from the most common management
information base (MIB) files. The MID Server MIB File [ecc_agent_mib] table is domain separated. You can
create versions of these policies that only a MID Server from the same domain can use.
The following table contains the MIBs that load automatically. The MIBs that are bundled with the MID
Server are not visible in the instance. The MIBs that are in the ecc_agent_mid table are included in the
instance by default and can be viewed in the MID Server > SNMP MIBs module.
Table 33: Management Information Base (MIB) module
Bundled with the MID Server Included in the instance
ATM-MIB A10 AX MIB

BRIDGE-MIB A10 COMMONS MIB
DISMAN-EVENT-MIB CISCO-SMI
ENTITY-MIB CISCO-STACK-MIB

Bundled with the MID Server Included in the instance
EtherLike-MIB CISCO-TC
FRAME-RELAY-DTE-MIB CISCO-VTP-MIB
HOST-RESOURCES-MIB F5-BIGIP-COMMON-MIB
HOST-RESOURCES-TYPES F5-BIGIP-LOCAL-MIB
IANA-ADDRESS-FAMILY-NUMBERS-MIB F5-BIGIP-SYSTEM-MIB
IANAifType-MIB FOUNDRY-SN-AGENT-MIB
IP-MIB FOUNDRY-SN-ROOT-MIB
IP-FORWARD-MIB LanMgr-Mib-II-MIB
IPMROUTE-STD-MIB MSFT-MIB
IPV6-MIB NetWare-Host-Ext-MIB
ISDN-MIB NetWare-Server-MIB
Printer-MIB PowerNet-MIB
RFC-1212 QMS-MIB
RFC-1215
RFC1155-SMI
RFC1213-MIB
RFC1398-MIB
RFC1406-MIB
RMON2-MIB
RSVP-MIB
SNMPv2-SMI
SNMPv2-TC
UPS-MIB
SSHCommand probe
A probe using the ECC queue topic name SSHCommand executes a shell command on the target host,
and returns the resulting output to the sensor.
Discovery supports Bourne Shell (sh) and Bourne-again Shell (bash) commands. Enter shell script
commands in the probe's ECC queue name field. The shell script can use variables and file operations
supported by the target UNIX shell.
• The SSH engine that is active by default on new instances.
• Customers on upgraded instances can manually enable ServiceNow SSH for a particular probe by
setting the use_snc_ssh parameter to true. Alternatively, enable it for all probes on the MID Server by
setting the MID Server parameter mid.ssh.use_snc to true.
Note: To discover network devices, such as routers and switches, use SNMP credentials
credentials, not SSH credentials. If you have Orchestration active,
SSHCommand parameters

Several parameters are available for the SSHCommand probe.

Table 34: Parameters Table
allow_unsupported_shells Allows a probe designer to attempt to run a

command on a device that does not have a
supported shell. With no shell, the following is
true:
• No path information can be provided.
• No scripts can function, because there is no
ability to handle script parameters.
• The text that is specified in the ECC queue
name field of the probe form is the raw
command that is run on the device.
For example, you may design a probe to display

the version of a Cisco switch running NX-OS.
The command that the switch understands
is show version. To accomplish this, put
the show version command in the ECC
queue name field, and add the parameter name
allow_unsupported_shells with a value of
true.
This parameter is only effective for sncssh. It
is not supported with j2ssh. Currently supported
shells are sh, bash, ksh, csh, and tcsh.
• Type: string, true or false
source [Required] Specifies the initial host to connect to.

• Type: string (URL)
• Default value: None
port Specifies the target port to connect to.

• Type: integer (port)

debug Specifies whether to write SSH debug

information to the log file. The parameter usage
depends on whether the ServiceNow SSH client
is enabled.
When the ServiceNow SSH client is enabled,
this parameter functions as follows:
• Type: string
The following string values are valid for the
ServiceNow SSH client:
• true: Enables SSH debug information in
the log file.
• false: Disables SSH debug information in
the log file.
• <IP Addresses>: Specifies which IP
ranges to enable SSH debug information
in the log file. You can enter IP addresses
in the following formats:
• An IP range defined by a slash and
the number of bits in the subnetwork.
For example, the string 10.10.10.0/24
scans 24 bits of IP addresses from
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.
• deferred: Specifies to log SSH debug

information in memory unless an error
or warning occurs. If an error or warning
occurs, the platform publishes the debug
information to the log file. This ensures
that only the part of the log file pertaining
to the error or warning is recorded. If no
error or warning is detected, the platform
deletes the unused log data from memory
when the session closes. Each session
stores up to 1000 log messages. If the
session exceeds 1000 log messages,
the deferred log discards the oldest log
message to make room for the newest log
message.
When the ServiceNow SSH client is disabled,

this parameter enables or disables SSH debug
information in the log file:
• © 2018
Type: true | falseServiceNow. All rights reserved. 237
debug_ssh Specifies whether the legacy SSH client writes

debug information into the agent/logs/
ssh.log log file. This log file can get very large
and should be reviewed frequently.
The ServiceNow SSH client does not use this
parameter.
timeout Sets the socket connection timeout for the

legacy SSH client.
The ServiceNow SSH client does not use this
parameter.
• Type: integer (milliseconds)
• Default value: 60,000
path_override Specifies how to change the default paths set

before executing a command. Type 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:
• append: Appends the override path to the
end of the host’s path. This is the default
behavior.
• replace: Replaces the host path with the
path_overide value.
• prepend: Appends the override path to the
front of the host path.
• Type: string (a colon-separated list of

directories)
• Default value: None
keyboard_interactive Determines whether to enforce

keyboard_interactive SSH login mode.
must_sudo Determines whether SSH commands run

through sudo.

run_in_terminal Determines whether SSH commands run in an

SSH terminal.
• Default value:
• ServiceNow SSH client: false
• Legacy SSH client: true
set_path Determines whether the probe is allowed to alter

the session's PATH variable or not. By default,
during session setup, the PATH variable is set to
/usr/sbin:/usr/bin:/bin:/sbin.
rm_override Overrides the default remove command (/bin/

rm -f) with the provided value.
• Type: string
use_snc_ssh Enables the ServiceNow SSH client. The

ServiceNow SSH client is active by default.
Enabling the ServiceNow SSH client disables
the legacy SSH client.
command_timeout_ms Number of milliseconds an SSH command

is allowed to run before timing out (default is
configurable per MID server).
The legacy SSH client does not use this
parameter.
• Type: integer
• Default value: value of the
mid.ssh.command_timeout_ms MID Server
parameter.
preserve_sudo_environment Specifies whether to use sudo to preserve the

environment for SSH. This parameter is only
effective if the sudo environment on the host
being probed supports the -E switch.
SSHCommand path
The SSHCommand probe computes the default path from the following sources.

• MID Server parameter: mid.ssh.path_override

• SSH Command probe parameter: path_override
• User's default path: Shell configuration file
If you set the MID Server path override parameter, Discovery appends this path to the default path. If
you set the probe path parameter, Discovery uses this path instead of the default path. Discovery always
appends a user's default execution path to the MID Server and probe parameter paths.
Default Path
By default, the MID Server searches for SSH commands in the following paths:
• /usr/sbin
• /usr/bin
• /bin
• /sbin
Shell script options

The SSHCommand probe supports the following scripting options in the ECC queue name field.
Table 35: Shell Scripting Options Table
Summary Syntax Description
Variable ${variable} Replaces the token with the

value of the variable. For
example, ${catalina_home}
specifies the installation
location of a Tomcat server.
Include File ${File:file_name.sh} Treats the contents of the
specified file as a shell script.
For example, ${File:findcat.sh}
runs the findcat shell script.
WMIRunner probe
WMI Runner is a probe type that fetches data from Windows operating systems via the Windows
Management Instrumentation (WMI) interface.
The probe handles multiple user-specified WMI Paths to be queried, using a basic form of native WMI
query. Each field to be probed must be uniquely named (within the domain of the probe). The probe results
returned to the sensor will provide the data found for each field queried, indexed by its name.
When creating a WMI probe, the probe type must be set to WMI Probe and the ECC Queue Topic must be
set to WMIRunner.
The following parameters may be passed to the WMI Probe:
Table 36: WMIRunner probe parameters
Parameter Description Default value
source Host to connect to.

port Port to connect to.

Parameter Description Default value
debug Enables debug logging. false

wmi_timeout Timeout for the actual WMI 300 (seconds)
probe, in seconds. Use this
parameter to change the
timeout interval for individual
Windows probes. This value
overrides the value in the
windows_probe_timeout MID
Server parameter, which sets a
timeout for all probes launched
by a specific MID Server.
Windows - Installed Software
probe is configured with a
timeout value of 15 minutes.
process_timeout Timeout for the process running wmi_timeout + 10 (seconds)
the script, in seconds. This
parameter is for internal use
only and is not supported.
credentials_debug Displays a <credentials_debug> false
section in the ECC queue,
which can help you
troubleshoot credentials. If
you set this property to true,
credential troubleshooting
information is output to the ECC
queue, even if the credentials
succeed. See Credentials
troubleshooting for more
information.
Note: The default timeout for WMI/Powershell is 5 minutes, except for the Windows Installed
Software probe, which has a default timeout value of 15 minutes. Adding wmi_timeout to a probe
parameter can change the default timeout of a Windows probe.
Port probes
Port probes are used in Discovery by the Shazzam probe to detect protocol activity on open ports on
devices it encounters.
When a port probe encounters a protocol in use, the Shazzam sensor checks the port probe record to
determine which classification probe to launch. The common protocols WMI, SSH, and SNMP in the base
system have priority numbers that control the order in which they are launched.
In the base system, the WMI probe is always launched first, and if it is successful on a device, no other
port probes are launched for that device. If the WMI probe is not successful, then the SSH probe is
launched to gather information on the device. If it is not successful, the SNMP probe is launched. This
method allows Discovery to classify a device correctly if the device is running more than one protocol (e.g.
SSH and SNMP).
Port Probe Form
To access the Port Probe form, navigate to Discovery Definition > Port Probes.

The Port Probe form provides the following fields:

Table 37: Port Probes
Field Input Value
Name Simple name for the port probe that reflects its
function (e.g. snmp).
Description Definition of the acronym for the protocol. (e.g.
ssh is Secure Shell Login).
Scanner Shazzam techniques for exploring a port. Some
of these are protocol specific, and others are
generic. For example, a WMI port probe will use
a Scanner value of Generic TCP, and the snmp
port probe uses a value of SNMP.
Active Indicates whether this port probe is enabled or
disabled.
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".
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.
Use classification Names the appropriate classification table,
based on the protocol being explored.
Classification priority Establishes the priority in which this port probe
runs. 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
Supplementary Launches supplementary classifications after

a higher-priority identification succeeds, once
again in order of priority.
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.

Field Input Value
Script Script to run.
Selective port probe scanning
The order in which Port Probes are run is now prioritized by protocol. Prioritization enables the proper
classification of devices that have two protocols running, such as SSH and SNMP, without having to create
a complex Discovery Behavior. Previously (in Basic discoveries), Discovery launched all port probes
at once and attempted to classify devices based on the activity returned for any protocol. The common
protocols WMI, SSH, and SNMP in the out-of-box system now are assigned configurable priority numbers
that control the order in which they are launched. The WMI probe is launched first, and if it is successful
on a device, no other port probes are launched for that device. If the WMI probe is not successful, then the
SSH probe is launched. The SNMP probe is the last to launch, after the other port probes have failed.
The field called Classification priority was added to the Port Probe form. The out-of-box system
prioritizes the use of port probes as follows:
• 1 - WMI
• 2 - SSH
• 3 - SNMP
The WMI port probe runs first and then the WinRM probe. If WMI or WinRM activity is detected on a
device, the Windows - Classify probe is launched (and no other port probes). If no WMI or WinRM activity
is detected, Shazzam runs the SSH probe. If Shazzam successfully detects SSH activity, the UNIX
classifier is launched. The SNMP port probe is launched only if no WMI or SSH activity is detected on a
device. This ensures that the correct classifier probe is launched and the correct device data is returned.
Configure Shazzam probe parameters
When you run Discovery, the Shazzam probe finds your active network devices by scanning specified
ports on specified IP address ranges.
You control the behavior of individual Shazzam probes using basic and advanced parameters.
2. Select Shazzam.
3. Add or edit parameters in the Probe Parameters related list.
4. Configure the basic Shazzam parameter.
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.
Table 38: Basic Shazzam parameters
shazzam_chunk_size Maximum number of IP addresses Shazzam

will scan in parallel. This parameter primarily
controls outbound port consumption.
Default: 100

regulator_max_packets Sets the number of packets that Shazzam

can launch in the time interval specified by
the regulator_period_ms parameter.
Default: 1
regulator_period_ms Sets the interval, in milliseconds, in which

Shazzam can launch packets.
Default: 1
5. Configure the advanced Shazzam parameters.

These parameters are available for fine tuning the Shazzam probe. These values are defined in the
probe record only.
Table 39: Shazzam advanced parameters
report_inactive When true, reports device that are alive

but inactive. For example, a device has no
ports open but refuses at least one port
connection request.
Default: true
shazzam_report_dead When true, reports devices with dead IP

addresses. For example, a device that has
all ports closed.
Default: false
GenericTCP_waitForConnectMS Sets the number of milliseconds the

GenericTCP scanner waits for a connection.
Default: 1000
BannerTCP_waitForConnectMS Sets the number of milliseconds the

BannerTCP scanner waits for a connection
and banner.
Default: 1500
HTTP_waitForConnectMS Sets the number of milliseconds the HTTP

scanner waits for a connection.
Default: 500
HTTP_waitForResponseMS Sets the number of milliseconds the HTTP

scanner waits for a response.
Default: 500
NBT_waitForResponseMS Sets the number of milliseconds the NBT

Default: 500

NBT_alternativePort Defines an alternative port number for the

NBT scanner.
Default: N/A
SNMP_taps Sets the number of taps (requests) the

SNMP scanner attempts.
Default: 2
SNMP_tapIntervalMS Sets the number of milliseconds the SNMP

scanner waits between taps.
Default: 1000
SNMP_waitForResponseMS Sets the number of milliseconds the SNMP

scanner waits for a response after the last
tap.
Default: 1000
SNMP_alternativePort Defines the alternative port number for the

SNMP scanner.
Default: N/A
DNS_waitForResponseMS Sets the number of milliseconds the DNS

Default: 1000
DNS_alternativePort Sets an alternative port number for the DNS

scanner.
Default: N/A
debug Enables debug logging if set to true.

Default: false
scanner_log Enables scanner logging if set to true. This

logging information appears in the Shazzam
probe response.
Default: false
Shazzam probe ports and protocols

Port scanning is the first step in the Discovery process. The Shazzam probe performs port scanning,
regardless of whether you use patterns for horizontal discovery. The following table lists the known ports
and protocols used by Discovery.
Table 40: Discovery ports and protocols
Name Service name Port Details Creates Protocol
afp Apple File 548 TCP

Protocol
BEA Weblogic 7001 cmdb_ci_app_server
TCP

dns Domain Name 53 To resolve the TCP/UDP

Service name of each
IP Address
epmap Microsoft RPC 135 Windows TCP
(WMI, DCOM) Systems
ftp 21 TCP
hp-pdl-datastr Printer PDL 9100 HP Printers TCP
Data Stream
http HyperText 80 Web Servers cmdb_ci_web_server
TCP
Transfer
Protocol
https HyperText 443 Secure Web cmdb_ci_web_server
TCP
Transfer Servers
Protocol over
Secure Socket
IBM DB2 50000 TCP
IBM MQSeries 1414 TCP
IBM 9080 TCP
Websphere
IBM Web 9443 TCP
sphere SSL
IMAPS 993 TCP
pip (Internet IP Phone/ 5060 TCP
Print Protocol) Session
Initiation
Protocol
LDAP 389 TCP
LDAPs 636 TCP
Microsoft 139 TCP
netbios
Microsoft-ds 445 TCP
ms-nb-ns 137 UDP
Microsoft SQL 1433 TCP
server
MySQL 3306 TCP
Nagios NRPE 5666 TCP
nfs 2049 TCP/UDP
Oracle TNS 1521 TCP
POP3 110 TCP
postgresql 5432 cmdb_ci_database
TCP

printer Printer 515 Printers TCP

sip SIP (Session 5060 TCP
Initiation
Protocol)
slp Service 427 TCP/UDP
Location
Protocol (SLP)
smtp TCP 25
smux (SNMP 199
multiplexing)
snmp Simple 161 Network UDP
Network Devices
Management
Protocol
snmptrap 162 UDP
ssh Secure Shell 22 Unix Systems TCP
Service
sunrpc 111 TCP
telnet 23 TCP
TIBCO 7500 TCP
Rendezvous
Tomcat HTTP 8080 TCP
vmapp6_https 9443 TCP
vmapp_https vCenter Server 5480 TCP
Appliance Web
Interface using
https
wbem_https CIM-XML via 5989 CIM TCP
HTTPS(WBEM) Classification
wins Windows 137 NetBIOS UDP
Internet Name Name
Service Resolver
Windows and dynamic ports
Windows machines can have dynamic ports in the following ranges:

• Windows Server 2003: 024-5000 for both TCP and UDP.
• Windows Server 2008 and Vista: 49152-65535 for both TCP and UDP.
Windows probes and permissions

Discovery accesses devices and software by executing commands as a specific user.

Most probes require access to Windows classes, properties, and registry entries. Certain probes also
require additional access to Windows directories and resources. Security policies vary by organization, so
there is no one specific role or right to grant. Ensure that the Windows user has local admin permission
for these Windows components.
Windows Classes
Most Windows probes access Windows classes and properties contained in those classes. Microsoft
provides a list of classes and properties, and information on setting permissions to view these classes.
Some Windows classes do not specify a file namespace path. ServiceNow uses root\cimv2\<Class>
by default if an explicit path is not specified.
Table 41: Windows Classes
Probe Windows Class Property
Hyper-V - Cluster root\MSCluster Dependent

\MSCluster_ClusterToNode
Hyper-V - Cluster root\MSCluster Antecedent
Hyper-V - Cluster root\MSCluster Type
\MSCluster_Resource
Hyper-V - Resource Pools root\virtualization ResourceSubType
\Msvm_ResourcePool
Hyper-V - Resource Pools root\virtualization Name
\Msvm_ResourcePool
Hyper-V - Resource Pools root\virtualization Capacity
\Msvm_ResourcePool
Hyper-V - Resource Pools root\virtualization AllocationUnits
\Msvm_ResourcePool
Hyper-V - Resource Pools root\virtualization InstanceID
\Msvm_ResourcePool
Hyper-V - Virtual Machines root\virtualization VirtualQuantity
\Msvm_MemorySettingData
Hyper-V - Virtual Machines root\virtualization ElementName
\Msvm_ComputerSystem
Hyper-V - Virtual Machines root\virtualization TimeOfLastStateChange
Hyper-V - Virtual Machines root\virtualization NumberOfBlocks
\Msvm_LogicalDisk
Hyper-V - Virtual Machines root\virtualization AllocationUnits
Hyper-V - Virtual Machines root\virtualization ChassisSerialNumber
\Msvm_VirtualSystemSettingData
Hyper-V - Virtual Machines root\virtualization InstanceID
\Msvm_SyntheticEthernetPortSettingData

Hyper-V - Virtual Machines root\virtualization BIOSGUID

Hyper-V - Virtual Machines root\virtualization Description
Hyper-V - Virtual Machines root\virtualization Name
Hyper-V - Virtual Machines root\virtualization BlockSize
\Msvm_LogicalDisk
Hyper-V - Virtual Machines root\virtualization BIOSSerialNumber
Hyper-V - Virtual Machines root\virtualization BaseBoardSerialNumber
Hyper-V - Virtual Machines root\virtualization SystemName
\Msvm_LogicalDisk
Hyper-V - Virtual Machines root\virtualization SystemName
\Msvm_LogicalDisk
Hyper-V - Virtual Machines root\virtualization VirtualQuantity
\Msvm_ProcessorSettingData
\Msvm_ProcessorSettingData
Hyper-V - Virtual Machines root\virtualization EnabledState
\Msvm_SyntheticEthernetPortSettingData
Hyper-V - Virtual Networks root\virtualization Name
\Msvm_VirtualSwitch
Hyper-V - Virtual Networks root\virtualization ElementName
\Msvm_VirtualSwitch
Hyper-V - Virtual Networks root\virtualization Antecedent
\Msvm_ActiveConnection
Hyper-V - Virtual Networks root\virtualization Dependent
\Msvm_ActiveConnection
Windows - Active Processes Win32_Process Description
Windows - Active Processes Win32_Process CreationDate
Windows - Active Processes Win32_Process CommandLine
Windows - Active Processes Win32_Process Caption
Windows - Active Processes Win32_Process Priority

Windows - Active Processes Win32_Process ProcessId

Windows - Active Processes Win32_Process ParentProcessId
Windows - Active Processes Win32_Process Name
Windows - Active Processes Win32_Process ExecutablePath
Windows - Classify root\MSCluster Name
\MSCluster_Node
Windows - Classify Win32_ComputerSystem Domain
\MSCluster_Resource
Windows - Classify root\MSCluster Type
\MSCluster_Resource
Windows - Classify root\MSCluster PrivateProperties
\MSCluster_Resource
Windows - Classify root\virtualization Name
Windows - Classify root\MSCluster Dependent
Windows - Classify root\MSCluster Antecedent
Windows - Classify root\MSCluster PartComponent
\MSCluster_ClusterToResource
Windows - Classify root\MSCluster GroupComponent
Windows - Classify Win32_OperatingSystem Caption
\MSCluster_Cluster
Windows - Classify Win32_ComputerSystem Name
Windows - Cluster root\MSCluster Name
\MSCluster_Cluster
Windows - Cluster root\MSCluster AddressMask
\MSCluster_Network
Windows - Cluster root\MSCluster GroupComponent
Windows - Cluster root\MSCluster Type
\MSCluster_Resource
Windows - Cluster root\MSCluster Characteristics
\MSCluster_Node
\MSCluster_ResourceGroup
Windows - Cluster root\MSCluster PartComponent
\MSCluster_ClusterToQuorumResource


\MSCluster_ResourceGroupToResource
Windows - Cluster root\MSCluster Address
\MSCluster_Network
Windows - Cluster root\MSCluster PrivateProperties
\MSCluster_Resource
Windows - Cluster root\MSCluster Status
\MSCluster_Resource
Windows - Cluster root\MSCluster Flags
\MSCluster_Node
\MSCluster_ClusterToQuorumResource
\MSCluster_ResourceGroupToResource
\MSCluster_NodeToActiveGroup
Windows - Cluster root\MSCluster Description
\MSCluster_Network
\MSCluster_Cluster
Windows - Cluster root\MSCluster Caption
\MSCluster_Resource
Windows - Cluster root\MSCluster State
\MSCluster_Node
Windows - Cluster root\MSCluster Dependent
\MSCluster_ResourceType
\MSCluster_NodeToNetworkInterface
\MSCluster_NodeToActiveGroup
\MSCluster_Network
\MSCluster_Cluster
\MSCluster_ClusterToNetworkInterface
Windows - Cluster root\MSCluster NodeInstanceID
\MSCluster_Node

Windows - Cluster root\MSCluster Antecedent

\MSCluster_NodeToNetworkInterface
\MSCluster_ResourceToPossibleOwner
\MSCluster_Node
Windows - Cluster root\MSCluster Address
\MSCluster_NetworkInterface
\MSCluster_ClusterToNetworkInterface
\MSCluster_Node
\MSCluster_NodeToActiveResource
Windows - Cluster root\MSCluster DisplayName
Windows - Cluster root\MSCluster Type
\MSCluster_Event
\MSCluster_ResourceToPossibleOwner
\MSCluster_Resource
Windows - Cluster root\MSCluster Network
\MSCluster_ClusterToNetwork
\MSCluster_Node
\MSCluster_NodeToActiveResource
\MSCluster_Event
Windows - Cluster root\MSCluster DeviceID
\MSCluster_Resource


\MSCluster_ClusterToNetwork
\MSCluster_Node
Windows - Cluster root\MSCluster Dependent
\MSCluster_ResourceToDependentResource
Windows - Cluster root\MSCluster State
\MSCluster_ClusterToResourceGroup
\MSCluster_ResourceTypeToResource
\MSCluster_Cluster
\MSCluster_Node
Windows - Cluster root\MSCluster Antecedent
\MSCluster_ResourceToDependentResource
\MSCluster_ClusterToResourceGroup
\MSCluster_ResourceTypeToResource
Windows - CPU / Memory Win32_PhysicalMemory DeviceLocator
Windows - CPU / Memory Win32_PhysicalMemory TypeDetail
Windows - CPU / Memory Win32_PhysicalMemory FormFactor
Windows - CPU / Memory Win32_PhysicalMemory MemoryType
Windows - CPU / Memory Win32_PhysicalMemory DataWidth
Windows - CPU / Memory Win32_PhysicalMemory TotalWidth
Windows - CPU / Memory Win32_PhysicalMemory BankLabel
Windows - CPU / Memory Win32_PhysicalMemory Status
Windows - CPU / Memory Win32_Processor Manufacturer
Windows - CPU / Memory Win32_Processor NumberOfCores

Windows - CPU / Memory Win32_PhysicalMemory Speed

Windows - CPU / Memory Win32_Processor MaxClockSpeed
Windows - CPU / Memory Win32_Processor NumberOfLogicalProcessor
Windows - CPU / Memory Win32_PhysicalMemory SerialNumber
Windows - CPU / Memory Win32_Processor Name
Windows - CPU / Memory Win32_PhysicalMemory PartNumber
Windows - CPU / Memory Win32_PhysicalMemory Capacity
Windows - CPU / Memory Win32_PhysicalMemory Manufacturer
Windows - CPU / Memory Win32_PhysicalMemory Tag
Windows - Disks Win32_LogicalDisk Size
Windows - Disks Win32_LogicalDisk FreeSpace
Windows - Disks Win32_LogicalDisk DeviceID
Windows - Disks Win32_LogicalDisk FileSystem
Windows - Disks Win32_LogicalDisk DriveType
Windows - Disks Win32_LogicalDisk Description
Windows - Disks Win32_LogicalDisk VolumeSerialNumber
Windows - Disks Win32_LogicalDisk VolumeName
Windows - Get IIS Information root SecureBindings
\MicrosoftIISv2\IIsWebServerSetting
Windows - Get IIS Information root Name
Windows - Get IIS Information root LogFileDirectory
Windows - Get IIS Information root\MicrosoftIISv2\IIsWebInfo MinorIIsVersionNumber
Windows - Get IIS Information root\MicrosoftIISv2\IIsWebInfo MajorIIsVersionNumber
Windows - Get IIS Information root ServerComment
Windows - Get IIS Information root ServerBindings
Windows - Hardware Win32_ComputerSystemProduct UUID
Information
Windows - Hardware Win32_ComputerSystemProduct IdentifyingNumber
Information
Windows - Hardware Win32_SystemEnclosure ChassisTypes
Information
Windows - Hardware Win32_BIOS SerialNumber
Information

Windows - Hardware Win32_SystemEnclosure SerialNumber

Information
Windows - Hardware Win32_BaseBoard SerialNumber
Information
Windows - Installed Software Win32_OperatingSystem Caption
Windows - Network Win32_NetworkAdapterConfiguration
Index
DHCPEnabled
MACAddress
IPSubnet
IPAddress
Windows - Network Win32_NetworkAdapter Index
Caption
Windows - Network Win32_NetworkAdapter Manufacturer
DefaultIPGateway
Windows - Network Win32_NetworkAdapter NetConnectionID
IPEnabled
Windows - OS Information Win32_OperatingSystem CSDVersion
Windows - OS Information Win32_OperatingSystem Version
Windows - OS Information Win32_ComputerSystem UserName
Windows - OS Information Win32_ComputerSystem Model
Windows - OS Information Win32_ComputerSystem Manufacturer
Windows - OS Information Win32_Processor AddressWidth
Windows - OS Information Win32_OperatingSystem Description
Windows - Printers Win32_Printer Name
Windows - Printers Win32_TCPIPPrinterPort HostAddress
Windows - Printers Win32_TCPIPPrinterPort Name
Windows - Printers Win32_Printer PortName
Windows - Printers Win32_Printer DeviceID
Windows - Services Win32_Service ProcessId
Windows - Services Win32_Service ServiceType
Windows - Services Win32_Service StartName
Windows - Services Win32_Service DisplayName
Windows - Services Win32_Service State
Windows - Services Win32_Service StartMode
Windows - Services Win32_Service PathName

Windows - Services Win32_Service DesktopInteract

Windows - Services Win32_Service Name
Windows - Services Win32_Service AcceptStop
Windows - Services Win32_Service AcceptPause
Windows Registry entries
Several Windows Registry entries are available for Discovery Windows probes.
Probe Windows Registry Entries
Windows - Classify HKEY_LOCAL_MACHINE/SYSTEM/

CurrentControlSet/Services/Tcpip/Parameters/
Hostname
Windows - Classify HKEY_LOCAL_MACHINE/SYSTEM/
CurrentControlSet/Services/Tcpip/Parameters/
Domain
Windows - Find APD File Location HKEY_LOCAL_MACHINE/SOFTWARE/APD/
APD/CONFIGPATH
Windows - Installed Software HKEY_LOCAL_MACHINE/Software/
Wow6432Node/Microsoft/Windows/
CurrentVersion/Installer/UserData/*/Products/*/
InstallProperties/InstallDate
CurrentVersion/Uninstall/*/DisplayVersion
Windows - Installed Software HKEY_LOCAL_MACHINE/Software/Microsoft/
Windows NT/CurrentVersion/ProductId
Windows/CurrentVersion/ProductId
Windows/CurrentVersion/Installer/UserData/*/
Products/*/InstallProperties/InstallDate
CurrentVersion/Uninstall/*/DisplayName
Microsoft/Windows/CurrentVersion/Uninstall/*/
ParentDisplayName
Products/*/InstallProperties/DisplayVersion


UninstallString
InstallProperties/Publisher
Internet Explorer/Version
Products/*/InstallProperties/DisplayName
Windows/CurrentVersion/Uninstall/*/Publisher
InstallProperties/ProductID
Wow6432Node/Microsoft/Office/*/Registration/*/
ProductID
Products/*/InstallProperties/ProductID
DisplayVersion
InstallProperties/DisplayVersion
Wow6432Node/Microsoft/Office/*/Registration/*/
DigitalProductID
Products/*/InstallProperties/Publisher
DisplayName
InstallProperties/DisplayName


CurrentVersion/Uninstall/*/UninstallString
Office/*/Registration/*/DigitalProductID
Internet Explorer/Registration/ProductId
CurrentVersion/Uninstall/*/Publisher
Internet Explorer/svcVersion
Office/*/Registration/*/ProductID
CurrentVersion/Uninstall/*/InstallDate
CurrentVersion/Uninstall/*/ParentDisplayName
Windows/CurrentVersion/Uninstall/*/InstallDate
Windows NT/CurrentVersion/DigitalProductID
Create or modify a probe

Create a new probe to discover additional CIs or modify an existing probe to collect additional information.
After you create or modify a probe, test it.
Important: You need an advanced knowledge of scripting to modify probes or their associated
sensors. Many existing probes provide parameters that you can set, rather than modifying the
probe itself. See Set probe parameters on page 264 for more information.
1. Navigate to Discovery > Discovery Definition > Probes.

2. Click the name of the probe that you want to modify.
3. Modify the form fields (see table).

Field Description
Probe type Select the probe for the operating system of

the device it will query.
• CIM Probe: Select this probe type
to query a CIM server using WBEM
protocols.
• Multiprobe: Select this probe type to
run one or more simple probes of any
type or mix probes of different types.
This type of probe can make several
queries simultaneously that return all the
results at the same time. You cannot add
multiprobes to other multiprobes.
• Probe: Select this generic type to define
a probe class. Specify the name of the
probe class in the ECC queue topic field.
• SNMP Probe: Select this probe type for
network devices, such as routers.
• WMIRunner Probe: Select this probe
type for Windows devices.
ECC queue topic Enter a descriptive term for the function

of the probe. The probe uses this label as
the Topic field for incoming ECC queue
messages. The term does not have to be
unique. For example, all the UNIX probes
might have an ECC queue topic value of
SSHCommand.
By default, probes use the following ECC
queue topics:
• CimProbe
• Multiprobe
• Powershell probe
• SCPRelay
• SSHCommand
• SNMP
• WMIRunner
ECC queue name Enter either a descriptive name for human

use, or the actual command the probe is to
run. For example, if the value in the ECC
queue topic field is SSHCommand, then
enter the actual shell command to run in this
field.

Field Description
Cache results Select this option to cache this probe's

results to improve overall discovery
performance. The probe results cache
should be enabled only for those probes and
sensors whose output is unlikely to change.
For example, the Linux – CPU sensor is
cached because CPU information seldom
changes. The cache is turned on by default
for base system probes and sensors whose
output is unlikely to change.
Warning: Do not turn on the cache

for classification and identification
probes. Furthermore, do not turn
on the cache for probes that trigger
additional probes because this may
prevent them from being triggered.
Classic Mode Select this option to cache this probe's

results in the Starting in Fuji, select this
option to debug the post-processing script
on the ServiceNow instance instead of the
MID Server. This mode is only valid if a
post-processor script exists. Use the Classic
mode to debug post-processing scripts in
the test environment. ServiceNow does not
recommend use of the Classic mode in the
production environment.
Post processor script Define an optional post-processing script
that runs on the MID Server. The script
accepts probe results as an input and
outputs a JSON string that is sent back to
the instance for a sensor to use as input.
Use this type of script to accomplish tasks
like parsing data.

5. Modify these related lists if necessary.
Related list Description
Probe Parameters Parameters that control the functionality of

the probe. See Set probe parameters on
page 264 for instructions.
Sensors that react to this probe or Sensors The sensors that this probe utilizes.
Included by MultiProbe If this probe is included with other probes as
a MultiProbe.
MultiSensor Scripts Scripts that run for multiple sensors.

Related list Description
Versions The version of the probe. If the State is

Current, the probe is the most up to date
with your version of the instance. If not,
you do not have the most current version
and you might need to realign it. See Align
versions of customized probes and sensors
on page 266 for instructions.
6. Click Test probe.

7. On the Test Probe window, enter the IP address of the target and select the MID Server. Only Up and
Validated MID Servers are able to be selected.
8. Click OK.
9. Check the ECC Queue for the MID Server to see the results.
Add the probe to the Triggers Probe related list on the appropriate classifier. See Create a Discovery CI
classification on page 91 for a description of the fields and related lists on the classifier form.
Discovery probe permissions

Several probes require additional permissions to run.
Discovering Active Connections
Discovery uses the Windows - Active Connections probe to access active connection information. The
application dependency mapping feature requires this probe to function.
Table 42: Discovering Active Connections
Probes Additional Permissions
Windows - Active Connections Ability to invoke the \root\CIMV2:Win32_Process

object
Access to the $admin share
Access to the %SystemRoot%\temp directory
Discovering Application Profiles
Discovery uses these probes to access application profile information. The application profile discovery
feature requires these probes to function.

Table 43: Discovering Application Profiles
Windows - Get APD Environment Files Ability to invoke the \root\CIMV2:Win32_Process

object
Windows - Get APD Env File Content
Windows - Get APD Version File Content
Discovering VMware Workstation
Attention: VMware workstation Discovery is deprecated in the Helsinki release. This probe and its
sensor will be removed from the product in a future release.
Discovery uses the Windows - Get VMware Workstation probe to access information about VMware
virtual machines installed on Windows.
Table 44: Discovering VMware Workstation
Windows - Get VMware Workstation Ability to invoke the \root\CIMV2:Win32_Process

object
Configure the PATH variable to include the path
to the vmrun.exe command. This command
is typically found in the VMware Workstation
install directory.
Discovering MSSQL
Discovery uses the Windows - MSSQL probe to access information about Microsoft SQL Server installed
on Windows.

Table 45: Discovering MSSQL
Windows - MSSQL • Access to the Win32_Process object

• Access to the Win32_Service object
• Access to the
Win32_NetworkAdapterConfiguration object
• Access to the
Microsoft.SqlServer.Management.Smo object
• Access to run the nbtstat command
• Access to HKLM\SOFTWARE\Microsoft
\Microsoft SQL Server\InstalledInstances
• Access to HKLM\SOFTWARE\Microsoft
\MSSQLServer\$instanceName
\SuperSocketNetLib\Tcp\TcpPort where
$instanceName is an array of possible
values.
Set probe parameters

Use probe parameters to control the behavior of a particular probe every time it is triggered.
1. Create or select the probe you want to set parameters for.
2. From the Probe Parameters related list, click New.
3. Fill in the fields, as appropriate (see table).
The Probe parameter form has the following fields.
Table 46: Probe Parameter Form Fields
Field Description
Name Enter the parameter name. Each probe type

has its own list of available parameters.
Value Enter the parameter value or script as
required by the parameter.
Value script [Optional] Enter the script you want the
parameter to run if you have not already
specified a script in the Value field.
Probe Displays the probe this parameter relates to.
Discovery sensors
Every probe in Discovery must have a corresponding sensor to process the data returned.
For example, if incoming data is the result of a WMI probe, then the WMI sensor is triggered to process the
payload.

Note: If you create a multiprobe, you must create a multisensor to process the data returned from
this probe. For details, see Multiprobes and Multisensors.
Navigate to Discovery > Discovery Definition > Sensors and edit or create a sensor.
Table 47: Sensor Fields Table
Field Description
Name Enter a unique probe name.

Reacts to probe Select the probe whose payload this sensor
must process.
Sensor Class [sys_class_name] Select the type of sensor to create:
• Import Export Map: This option is not
currently used.
• MultiSensor: Multisensors process the data
returned from multiprobes. Select this type
to create a multisensor that responds to the
simple probes used in a multiprobe.
• Sensor: Select this type if this sensor is a
simple sensor that responds to a simple
probe.
Description Enter an optional description of the sensors

function.
Sensor type [sensor_type] Specify how the results from the probe are
processed.
• Classifier: This field is not currently used.
• Java: This field is not currently used.
• Javascript: Returned data from the probe is
processed in the sensor itself, outside the
application, and is visible to the user. This is
the most common sensor type.
• Multiline Text: This field is not currently used.
• XML: The XML data from the probe is
broken into pieces. Some pieces can be
used to launch other probes that the original
sensor needs to complete all the necessary
information about a device.
Active Select this option to enable or disable the

sensor.
Script Enter a script to run when processing the probe.
You can use the g_probe_parameters hashmap
in a sensor 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;

Field Description
Responds to probes Use this related list to specify the simple

probe within a multiprobe whose payload this
multisensor must process. This list is available
for multisensors only.
Triggers probes Use this related list to specify which probes this
sensor can start for additional exploration.
These fields can be added by configuring the form
Field Description
Agent Enter the ECC queue type to match this sensor
with.
Apply Defaults Select this option to apply default sensor values.
Classification type Select the classification type associated with this
sensor.
Coalesce Enter the field to match against when
determining whether to coalesce.
Condition script Create a predetermined requirement for this
sensor to run.
Data option Select how to treat imported sensor data.
Options include:
• Insert and Update
• Insert Only
• Update Only
External names Enter a name to tag the sensor data.
Align versions of customized probes and sensors

If you customized a probe or sensor and upgraded to a new version of an instance, you need to realign the
versions of the customized probe and sensor to the most current version.
Probes and sensors have a major and a minor version.
Major version A major version change reflects a change in the

expected output of a probe, such as the addition or
subtraction of a targeted attribute, a format change,
such as XML versus JSON, or a probe parameter
script change.
Minor version A minor version change reflects small fixes that do
not impact the result or the processing of the data.
A sensor and its corresponding probe must have the same major version. It is recommended they also
have the same minor version. This version matching ensures that the data sent back from the probe is
understood and properly processed by the sensor. All members of a multi-probes bundle must have the
same major and minor version.

By default, Discovery tracks major version mismatches and displays version mismatch errors in the Active
Discovery Errors section on the Discovery Dashboard and in the Discovery Log. You can control whether
or not Discovery tracks minor versions mismatches by setting the Warn on Minor Version Mismatch
(glide.discovery.warn_minor_version) Discovery property. Minor version mismatches are tracked
in the Discovery log, but are not displayed on the Discovery Dashboard.
Versions for multi-probes and multi-sensors are checked as follows:
• The versions of the individual probes contained in the multi-probes are compared with the Responds to
Probes scripts that process their data.
• The versions of the Responds to Probes scripts and the main multi-sensors script are compared.
If a probe and its corresponding sensor do not have the same major version, a sensor does not process
information during a discovery and sends error messages to the log file. Errors also show up on the
Discovery Dashboard when you run a discovery job. If the major version is the same, but the minor version
is not, a sensor processes information during a discovery.
See the Discovery Probe and Sensor Versioning video for a tutorial on how to resolve version conflicts:
To use the most up-to-date version of a probe that is available:

1. Save the customizations that you made with your probe or sensor into a text file so you can re-apply
them later.
2. Navigate to Discovery > Dashboard.
3. Look for version mismatch errors in the Active Discovery Errors section, and note the probe or
sensor that caused the error.
4. Navigate to Discovery Definition > Probes or Discovery Definition > Sensors and select the probe
or sensor that you want to upgrade.
5. Add the Major version and Minor version fields to the form if you want to display the versions on the
form.
6. In a multi-sensor, you can verify the major version with the versions of the probes that use the sensor
in the Responds to Probes related list.


7. Click the Versions related list.

8. Look for version where the State is Previous and the Source is System upgrades.
9. Click the date link in the Created column for that version to open the version record.
10. Click Revert to this version.
11. Navigate back to the probe or sensor form and verify that the major version is correct.
12. Reapply your customizations to the probe or the sensor.
13. Verify that your customizations are valid with the new version of the probe or sensor by running a
Discovery in your test environment.
Discovery multiprobes and multisensors

Multiprobes contain one or more simple probes configured to extract specific information from manageable
devices by executing multiple queries with a single authentication.
You can schedule multiprobes to run any time in the discovery process to make exploration more efficient.
One common use for multiprobes is as identity probes. Identity probes ask a device for information such as
its name and serial number, and then use the results of those queries to update existing CIs in the CMDB.
To process the data returned from a multiprobe, you must create multisensors, which run scripts that
process the data returned by the multiprobes. Multisensors typically use the same name as their
corresponding multiprobes.
1. Navigate to Discovery > Discovery Definition > Probes.
2. Click New.
3. Complete the form using the following settings:
• Probe type: Multiprobe.
• ECC queue topic: MultiProbe.
4. In the Includes probes related list, add the probes you want to include in the multiprobe.
5. Click Save.
Multiprobes included with Discovery

The following multiprobes are included with the base system.
The corresponding multisensors have the same names.
Table 48: List of Multiprobes
Multiprobe Includes These Probes
AIX - ADM • AIX - Active Processes: Gets active running

processes.
• Unix - Active Connections: Gets active
connections information.
AIX - Identity • AIX - Network: Determines network

interfaces, IPs, and MACs.
• AIX - Serial Number: Gets AIX serial
numbers.

CIM - Identity CIM - Computer System: Gets CIM Computer

Systems per SMI-S.
CIM - Identity - WBEM Service CIM - CIMOM: Probes for the WBEM Service,
CIMOM.
HP-UX - ADM • HP-UX - Active Processes: Gets active
running processes.
connections information.
HP-UX - Identity • HP-UX - Hardware Serial Number: Gets HP-

UX serial numbers.
• HP-UX - Network: Determines network
Linux - Identity • Linux - Hardware Information: Gets DMI

(BIOS) information.
• Linux - Network: Determines network
Mac OS X - Identity • Mac OS X - Network: Determines network

• Mac OS X - CPU/Memory: Gets CPU and
memory information.
SNMP - A10 - Identity • SNMP - A10 - Identity - Serial: Part of the

SNMP - Load Balancer - Identity multiprobe
that is used to identify the A10 load balancer.
• SNMP - Identity Info: Identifies an SNMP
device.
SNMP - ACE - Identity • SNMP - Identity Info: Identifies an SNMP

device.
• SNMP - ACE - Identity - Serial: Part of the
SNMP - Load Balancer - Identity multiprobe,
that is used to identify the ACE load balancer
SNMP - Alteon - Identity • SNMP - Alteon - Identity - Serial: Part of the

SNMP - Load Balancer - Identity multiprobe,
that is used to identify the Alteon load
balancer.
device.

SNMP - AppDirector - Identity • SNMP - AppDirector - Identity - Serial: Part

of the SNMP - Load Balancer - Identity
multiprobe, that is used to identify the
AppDirector load balancer.
device.
SNMP - F5 BIG-IP - Identity • SNMP - F5 BIG-IP - Identity - Serial:

Retrieves the BIG-IP chassis serial number,
which is globally unique for this vendor.
device.
SNMP - Identity • SNMP - Identity Info: Identifies printer CIs
SNMP - Load Balancer - Identity • SNMP - F5 BIG-IP - Identity - Serial: Gets

BIG-IP chassis serial numbers, which are
globally unique for this vendor
• SNMP - Identity Info: Identifies SNMP
devices
SNMP - Netscaler - Identity • SNMP - Netscaler - Identity - Serial:

Retrieves the Netscaler chassis serial
number, which is globally unique for this
vendor.
• SNMP - Identity Info: Identifies SNMP
devices
Solaris - ADM • Solaris - Active Processes: Gets active

running processes
connections information
Solaris - Identity • Solaris - Network: Determines network

interfaces, IPs, and MACs
• Solaris - Serial Number: Gets serial numbers
for Solaris devices †
Unix - ADM • Unix - Active Processes: Gets active running

processes
connections information

UNIX - Classify • ESX - OS: Identifies ESX machines

• UNIX - OS: Runs after the ESX - OS probe
to determine the operating system for SSH
devices not identified as ESX
Windows - ADM • Windows - Active Processes: Gets active

running processes
• Windows - Active Connections: Retrieves
active connections information
Windows - Identity • Windows - Network: Determines network

interfaces, IPs, and MACs
• Windows - OS/Hardware Information: Probes
a Windows machine for WMI information
Windows - Storage 2008 • Windows - Storage 2008 - PS: Retrieves disk

and file system information for Windows 2008
and earlier.
• Windows - Storage 2008 - WMI: Retrieves
disk and file system information for Windows
2008 and earlier.
Windows - Storage 2012 • Windows - Storage 2012 - WMI: Retrieves

disk and file system information for Windows
2012 and later.
• Windows - Storage 2012 - PS: Retrieves disk
and file system information for Windows 2012
and later.
Note: † This probe requires the installation of a command line tool from Oracle called SNEEP. To
download and install this tool, log in to the Oracle website. After this tool is installed, the Solaris
- Serial Number probe runs automatically when Discovery detects a Solaris device. For Fujitsu
PRIMEPOWER devices, you must run this probe with root credentials.
Add a simple probe to a multiprobe

You can add simple probes to your multiprobe in the Includes Probes related list.
You can add simple probes of any type to a multiprobe and mix probe types if necessary.
Warning: Do not add a multiprobe to the Includes Probes related list.
1. Navigate to Discovery Definitions > Probes.

2. Open a multiprobe from the list.
You can see the MultiProbe designation in the ECC queue topic column.


Figure 87: Linux identity multiprobe
3. In the MultiProbe record, click New in the Includes probes related list.
4. Select a simple probe from the collection list in the left column and move it into the included list..
Figure 88: Adding a simple probe to a multiprobe
5. Click Save.
Create Discovery multisensors

Create multi sensors to process data returned from multiprobes.


2. Click New.
• Sensor type: MultiSensor.
• ECC queue topic: MultiSensor.
• Reacts to probe: Select the probe whose payload this sensor must process.
• Sensor type: Select one of these options.
• Javascript: Returned data from the probe is processed in the sensor itself, outside the
application, and is visible to the user. This is the most common sensor type.
• XML: The XML data from the probe is broken into pieces. Some pieces can be used to launch
other probes that the original sensor needs to complete all the necessary information about a
device.
4. Right-click the form header, and click Save.

5. In the Responds to Probes related list, click New.
• Reacts to probe: Select the probe within the multiprobe that this sensor reacts to. The sensor must
be linked to the probe by function, such as network identification or serial number.
• Script: Enter a script to run before the script in the multisensor. This script defines how the data
returned from each probe should be processed.
7. Click Save.
Example custom Discovery probe and sensor: populate a CI with text file
values
This custom Discovery probe helps you if you need to read a text file from a Windows computer and
populate a CI in the CMDB with the values from the file.
In this example the user wanted to read files created by BGinfo.
Note: When you have completed the probe and sensor, place the probe in the appropriate
Windows classifier at Discovery Definition > CI Classification > Windows.
1. Navigate to Discovery Definition > Probes, and then click New.

2. Complete the following fields:
• Name: Unique and descriptive name for the probe
• Probe type: Select Probe.
• Description: Describe the function of this probe.
• Used by Discovery: Select this check box
• ECC queue topic: This is name of the probe the MID server is to run. In this example, we use
WMIRunner.
• ECC queue name: In this example, we use the descriptive name WMI: BGInfo files.
4. Select the Probe Parameters tab in the Probe form, and then click New.
5. Enter WMI_GetFiles.js as the Name of this parameter.
6. Copy the script below into the Script field and edit as needed.
7. Click Submit.

//
// 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);
}
8. Navigate to Discovery Definition > Sensors, and then click New.

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.
9. Click Submit.
new DiscoverySensor({ data: {}, process: function(result) {
this.parseOutput(result.output);
this.update(this.data);
},
parseOutput: function(output) {
var currentFile;
var files = {};
if (output.startsWith("<wmi")) {
var bgout = new XMLHelper(output).toObject();
if (!bgout)
return;
output = bgout.output;
}
var lines = output.split(/\n/);
for(var i = 0; i < lines.length; i++) {

var line = lines[i];
if (line.startsWith("C:\\Information Systems\\BgInfo\\")) {
currentFile = line.substr(30);
files[currentFile] = "";
} else if (currentFile) {
var newLine = line.trim();
if (newLine)

files[currentFile] += (files[currentFile]?
"\n" : "") + newLine;
}
}
this.data['u_jack_id'] = files['JackID.txt'];
this.data['warranty_expiration'] = files['Warranty.txt'];
this.data['po_number'] = files['Ponum.txt'];},
type: "DiscoverySensor"
});
Data collected by Discovery

Discovery collects unique data for each type of device and stores it in dedicated tables, fields, and
relationships.
Computers Computer discovery is based on the machine's

operating system, such as AIX, OS/X, Linux,
Solaris, and Windows.
See Discovering computers on page 278.
Database catalogs Database catalogs list all the catalog objects,

or databases, discovered for an instance of a
database.
See Database catalog discovery on page 369.
Network CIs Discovery can find several types of network-related

CIs, such as IP networks and addresses, and
devices such as load balancers, switches, and
printers.
See Network devices on page 326.
Software Discovery can find many types of software,

including web servers, databases, and applications.
See Software Discovery on page 369.
Storage Discovery collects information on Direct Attached

Storage (DAS), Storage Area Networks (SAN), and
Network Attached Storage (NAS) from specialized
devices.
See Storage discovery on page 436.
Operating system level virtualization (OSLV) OSLV discovery finds image and container
information from OSLV engines, including Docker.
See Operating-system-level virtualization (OSLV)
discovery on page 473.
Discovering computers
Discovery identifies the following computers, clusters, and virtual machines.

Data collected by Discovery on AIX computers

Discovery identifies and classifies information about AIX computers.
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
CPU speed (MHz) cmdb_ci_computer cpu_speed lsdev, lsattr
CPU count cmdb_ci_computer cpu_count lsdev, lsattr
Manufacturer cmdb_ci_aix_server manufacturer lsattr
Model ID cmdb_ci_aix_server model_id lsattr
RAM (MB) cmdb_ci_computer ram lsdev, lsattr
Name cmdb_ci_file_system name df
Capacity (MB) cmdb_ci_file_system capacity df
Available Space (MB) cmdb_ci_file_system 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

Discover HBase Instances

Discovery creates or updates a CMDB record when it detects a running instance of HBase on a UNIX
server.
Discovery creates or updates a CMDB record when it detects a running instance of HBase on a UNIX
server. This feature is available starting in Fuji.
In the following table, the HBase Instance@hostname source may contain the information on whether
the instance is a master or a slave. The name contains Hmaster if the instance is a master instance. The
name contains HRegionServer if the name is a slave instance.
The following data is collected:
Table 49: Data Collected by Discovery on HBase Instances
Name cmdb_ci_db_hbase_instance
name HBase
Instance@hostname
Root Directory cmdb_ci_db_hbase_instance
root_dir hbase-site.xml
TCP port cmdb_ci_db_hbase_instance
tcp_port running process
Site XML cmdb_ci_db_hbase_instance
site_xml hbase-site.xml
Version cmdb_ci_db_hbase_instance
version HBase shell
HBase Home cmdb_ci_db_hbase_instance
hbase_home running process
ZooKeeper Quorum cmdb_ci_db_hbase_instance
zookeeper hbase-site.xml
Data collected by Discovery on HPUX computers

Discovery identifies and classifies information about HPUX computers.
Table 50: Data Collected by Discovery on HPUX Computers
Operating System cmdb_ci_hpux_server os uname

Short description cmdb_ci_hpux_server short_description uname
Name cmdb_ci_hpux_server name DNS, NBT
Hostname cmdb_ci_hpux_server host_name DNS, NBT
DNS domain cmdb_ci_hpux_server dns_domain DNS
Start date cmdb_ci_hpux_server start_date uptime
Manufacturer cmdb_ci_computer manufacturer dmidecode
Serial number cmdb_ci_hpux_server serial_number uname
CPU type cmdb_ci_hpux_server cpu_type cpuinfo
CPU speed (MHz) cmdb_ci_hpux_server cpu_speed adb
CPU count cmdb_ci_hpux_server cpu_count cpuinfo
Model ID cmdb_ci_hpux_server model_id model

RAM (MB) cmdb_ci_hpux_server ram adb

Name cmdb_ci_patches name swlist
name hifconfig
ip_address hifconfig
mac_address hifconfig
netmask hifconfig
JBoss server discovery

JBoss application server is a Java EE application server platform for developing and deploying enterprise
Java applications, web applications, and web portals.
Discovery can detect JBoss application servers running on Linux and Windows systems. Discovery creates
or updates CMDB records about the servers, hosted web applications, and web services.
Requirements
Linux Following are the requirements for JBoss

application servers running on Linux systems.
• Set probe permissions to use these Bourne shell
commands: find, cat, and dirname.
• Enable SSH on the JBoss application server.
The SSH credential must also have read
permissions on the web.xml and jboss-
service.xml files.
Windows For JBoss application servers running on Windows

systems, enable PowerShell on the MID Server.

Probes and sensors
Linux Discovery uses this process to identify Linux JBoss

application servers:
1. The UNIX - Active Processes probe
detects a running process that matches an
org.jboss.main entry point parameter.
2. If there is a match, a record is created
in the JBoss Application Server
[cmdb_ci_app_server_jboss] table. The
following probes are also triggered:
• JBoss - Find web.xml list: The sensor of
this probe populates information in the Web
Application [cmdb_ci_web_application] table
if applicable.
• JBoss - Get jboss-service.xml: The sensor
of this probe populates information in the
Web Service [cmdb_ci_web_service] table.
3. The JBoss - Find web.xml list probe searches

for the web.xml files of JBoss application
server. The probe uses the classpath
parameter in the running process, and then
searches in the related server\default
\deploy directory for the JBoss installation.
4. If associated web applications reside in the
server\default\deploy directory, the
JBoss - Get web.xml probe triggers for each
application. This probe reads the web.xml
file for each web application and the sensor
populates additional information to the Web
Service [cmdb_ci_web_service] table.
5. The Boss - Get jboss-service.xml probe uses
the classpath parameter in the running process
to search for the jboss-service.xml file
in the related server\default\conf\
directory for the JBoss installation.
6. If the probe successfully finds the jboss-
service.xml file in the server\default
\conf\ directory, the sensor reads the
contents of the XML file. It then creates
additional records in the Web Service
[cmdb_ci_web_service] table as necessary.
Windows Discovery uses this process to identify Windows

JBoss application servers:
1. The Windows - Active Processes probe
detects a running process that matches an
org.jboss.main entry point parameter.

2. If there is a match, a record is created

in the JBoss Application Server
[cmdb_ci_app_server_jboss] table. The
following probes are also triggered:
• JBoss - Find web.xml list: The sensor of
this probe populates information in the Web
Application [cmdb_ci_web_application] table
if applicable.
• JBoss - Get jboss-service.xml: The sensor
of this probe populates information in the
Web Service [cmdb_ci_web_service] table.
3. The JBoss - Find web.xml list probe searches

for the web.xml files of JBoss application
server. The probe uses the classpath
parameter in the running process, and then
searches in the related server\default
\deploy directory for the JBoss installation.
4. If associated web applications reside in the
server\default\deploy directory, the
JBoss - Get web.xml probe triggers for each
application. This probe reads the web.xml
file for each web application and the sensor
populates additional information to the Web
Service [cmdb_ci_web_service] table.
5. The Boss - Get jboss-service.xml probe uses
the classpath parameter in the running process
to search for the jboss-service.xml file
in the related server\default\conf\
directory for the JBoss installation.
6. If the probe successfully finds the jboss-
service.xml file in the server\default
\conf\ directory, the sensor reads the
contents of the XML file. It then creates
additional records in the Web Service
[cmdb_ci_web_service] table as necessary.
Data collected
Label Table name Field name Source
Name cmdb_ci_web_service name jboss-service.xml

App server cmdb_ci_web_service app_server Internal reference
Description cmdb_ci_web_applicationshort_description web.xml
Name cmdb_ci_web_applicationname web.xml
Document base cmdb_ci_web_applicationdocument_base web.xml
App server cmdb_ci_web_applicationapp_server web.xml
Servlet Name cmdb_ci_web_applicationservlet_name web.xml

Servlet Class cmdb_ci_web_applicationservlet_class web.xml
Relationships
Table 51: Relationships created
Parent class Relationship Class type
cmdb_ci_web_service Runs on::Runs cmdb_ci_linux_server

cmdb_ci_app_server_jboss Contains::Contained by cmdb_ci_web_application
Data collected by Discovery on Linux computers

Discovery identifies and classifies information about Linux computers.
Table 52: Data collected by Discovery on Linux computers
Operating System cmdb_ci_linux_server os uname

OS Version cmdb_ci_computer os_version uname -a or cat /etc/
*release
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
CPU speed (MHz) cmdb_ci_linux_server cpu_speed /proc/cpuinfo
CPU count cmdb_ci_linux_server cpu_count /proc/cpuinfo
CPU core count cmdb_ci_computer cpu_core_count /proc/cpuinfo
CPU core thread cmdb_ci_computer 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
Disk space (GB) cmdb_ci_linux_server disk_space /proc/ide, /proc/scsi, /
var/log/dmesg

Type cmdb_ci_disk type /proc/ide, /proc/scsi, /

var/log/dmesg
Model ID cmdb_ci_disk model_id /proc/ide, /proc/scsi, /
var/log/dmesg
Disk space (GB) cmdb_ci_disk disk_space /proc/ide, /proc/scsi, /
var/log/dmesg
Name cmdb_ci_disk name /proc/ide, /proc/scsi, /
var/log/dmesg
name ifconfig
ip_address ifconfig
mac_address ifconfig
netmask ifconfig
Default gateway cmdb_ci_hardware default_gateway route
Data collected by Discovery on Linux KVM

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

Discovery uses the following tables to store configuration records for kernel-based virtual machines.

Table 53: Tables used by Discovery on Linux KVM
Table name Extends Description Source
cmdb_ci_kvm cmdb_ci_vm A hypervisor that Process classifier

manages kernel- detects libvirtd running
based virtual machines on Linux servers
(KVMs)
cmdb_ci_kvm_vm_instance
cmdb_ci_vm_instance A virtual machine virsh list -all and
instance on this dumpxml command
hypervisor
cmdb_ci_kvm_object cmdb_ci_vm_object An object connected <network>, <storage
to a virtual machine pool>, and <storage
instance volume> elements from
the dumpxml command
cmdb_kvm_device N/A A device connected <devices> element
to a virtual machine from the dumpxml
instance command
Data Collected by Discovery on Linux KVM
Discovery finds the following information for kernel-based virtual machines.
Table 54: Data collected by Discovery on Linux KVM
Linux Host cmdb_ci_kvm linux_host Reference to the

cmdb_ci_linux_server
that is running this
virtual machine
Details cmdb_ci_kvm details_xml dumpxml
Object ID cmdb_ci_kvm_vm_instance
object_id virsh dumpxml
State cmdb_ci_kvm_vm_instance
state virsh list -all
CPUs cmdb_ci_kvm_vm_instance
cpus virsh dumpxml
Memory cmdb_ci_kvm_vm_instance
memory virsh dumpxml
Disks cmdb_ci_kvm_vm_instance
disks virsh dumpxml
Disks size cmdb_ci_kvm_vm_instance
disks_size virsh domblkinfo
Network adapters cmdb_ci_kvm_vm_instance
nics virsh dumpxml
Name cmdb_ci_kvm_vm_instance
name virsh dumpxml
Short description cmdb_ci_kvm_vm_instance
short_description virsh desc
Details cmdb_ci_kvm_object details_xml XML element from
dumpxml
KVM instance cmdb_kvm_device kvm_instance Reference to
cmdb_ci_kvm_instance

Device cmdb_kvm_device device disk, controller,

interface, etc.
Type cmdb_kvm_device type depends on device
Details cmdb_kvm_device details_xml XML element from
dumpxml
KVM Relationships
Discovery collects the following relationship data.
Table 55: Data collected by Discovery on KVM Relationship
Relationship Parent table Child table
Registered On::Has Registered KVM [cmdb_ci_kvm] KVM Virtual Machine Instance

[cmdb_ci_kvm_vm_instance]
Provided By::Provides KVM [cmdb_ci_kvm] Network
[cmdb_ci_kvm_network]
Defines resource for::Gets KVM [cmdb_ci_kvm] Storage Pool
resources from [cmdb_ci_kvm_storage_pool]
Connected By::Connects KVM Virtual Machine Instance Network
[cmdb_ci_kvm_vm_instance] [cmdb_ci_kvm_network]
Instantiated By::Instantiates KVM Virtual Machine Instance Computer [cmdb_ci_computer]
[cmdb_ci_kvm_vm_instance]
Virtualized By::Virtualizes Computer [cmdb_ci_computer] KVM [cmdb_ci_kvm]
Provides storage for::Stored on Storage Pool KVM Virtual Machine Instance
[cmdb_ci_kvm_storage_pool] [cmdb_ci_kvm_vm_instance]
Data collected by Discovery on OS/X (Mac) computers

Discovery identifies and classifies information about Mac (OS/X) computers.
Tables and Fields

OS Version cmdb_ci_computer os_version system_profiler
OS Service pack cmdb_ci_computer os_service_pack system_profiler
Short description cmdb_ci_computer short_description uname
Name cmdb_ci_computer name DNS, NBT
Hostname cmdb_ci_computer host_name DNS, NBT

DNS domain cmdb_ci_computer dns_domain DNS

Start date cmdb_ci_computer start_date uptime
Manufacturer cmdb_ci_computer manufacturer Assumed to be Apple
Serial number cmdb_ci_computer serial_number system_profiler
CPU type cmdb_ci_computer cpu_type system_profiler
CPU speed (MHz) cmdb_ci_computer cpu_speed system_profiler
CPU count cmdb_ci_computer cpu_count system_profiler
Model ID cmdb_ci_computer model_id system_profiler
RAM (MB) cmdb_ci_computer ram system_profiler
Disk space (GB) cmdb_ci_computer disk_space system_profiler
Volume name cmdb_ci_disk volume_name system_profiler
Volume serial number cmdb_ci_disk volume_serial_number system_profiler
Disk space (GB) cmdb_ci_disk disk_space system_profiler
Name cmdb_ci_disk name system_profiler
Device ID cmdb_ci_disk device_id system_profiler
Free space (GB) cmdb_ci_disk free_space system_profiler
File system cmdb_ci_disk file_system system_profiler
name system_profiler
ip_address system_profiler
mac_address system_profiler
netmask system_profiler
MAC manufacturer cmdb_ci_network_adapter
mac_mfr Assumed to be Apple
DHCP enabled cmdb_ci_network_adapter
dhcp_enabled system_profiler
Data collected by Discovery on Netware

Discovery identifies and classifies information about Netware.
Discovery can identify and classify Netware.

Table 56: Data collected by Discovery on Netware
Name cmdb_ci_netware_servername snmp

Serial number cmdb_ci_netware_serverserial_number snmp
OS Version cmdb_ci_netware_serveros_version snmp
RAM cmdb_ci_netware_serverram snmp
CPU count cmdb_ci_netware_servercpu_count snmp
Data collected by Discovery on Solaris computers

Discovery identifies and classifies information about Solaris computers.
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.
Prerequisites
Discovery stores data in the [cmdb_running_process] table with truncated command line parameters up to
80 characters. This can cause multiple applications to be merged into one CI. To get the full command line
and prevent this issue, run pargs -a and parse the result.
Discovery stores information about Solaris computers in the following tables and fields.
Table 57: Data collected by Discovery on Solaris computers

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
CPU speed (MHz) cmdb_ci_computer cpu_speed kstat
CPU count cmdb_ci_computer cpu_count kstat
CPU core count cmdb_ci_computer cpu_core_count kstat
CPU core thread cmdb_ci_computer 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
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
Volume serial number cmdb_ci_disk volume_serial_number iostat
Disk space (GB) cmdb_ci_disk disk_space iostat
Name cmdb_ci_disk name iostat
Capacity (MB cmdb_ci_file_system capacity df
Name cmdb_ci_patches name showrev
name ifconfig
ip_address ifconfig
mac_address ifconfig
netmask ifconfig
Default gateway cmdb_ci_hardware default_gateway netstat
Data collected by Discovery on Solaris zones

Discovery maps the relationships between global and local Solaris zones upon detection.
3
* To discover Fujitsu PRIMEPOWER devices, you must install Oracle SNEEP, and run Solaris discovery
with root credentials.

Solaris zone topology
In the following example, a Solaris global zone contains two local zones: zone01 and zone02. Each local
zone is represented by a physical Solaris CI record and a Virtual Machine Instance record. Each of the
local zones is tied to a Zone Server, demonstrating how virtualization relates to the global zone (mmp1).


Use cases
The TCP connection and process information for local zone servers must be collected by running
commands on their parent global zone. The relationship path between the local and global zone physical
machines must be established before TCP connection and process information for local zone servers can
be collected.
Case 1: Global zone discovered first.
• The system creates the Solaris server CI for the global zone.
• Discovery detects the local zones, creates a hypervisor zone server record, and creates a virtual
machine instance record for each Solaris device in the local zone.
• Discovery creates the relationship between the hypervisor record and the VM instance record.
Case 2: Local zone discovered first.

• The system creates the Solaris server CI for the local zone.
• Discovery sets the correlation ID, so that it can be reconciled during later global zone discoveries.
Case 3: Global zone discovered after creation of local zone Solaris server CIs.
• Global zone Discovery detects local zones.
• Discovery creates a hypervisor zone server record, and creates a virtual machine instance record for
each Solaris device in the local zone.
• Discovery creates the relationship between the hypervisor record and the VM instance record. In
addition, it creates the relationship between the physical local zone VM and its virtual machine instance
record.
• The global zone runs the Solaris - ADM probe on itself, filtering by the local zone, and updates the
physical local zone VMs with this data.
Case 4: The relationship path between physical local and global zone machines is established.
Subsequent discoveries of the global zone refresh the TCP connection and process information for the
contained local zones.
ECC queue payload
When the system discovers a global zone, the Solaris - Zones & ADM Launcher probe triggers the Solaris
- ADM probe to explore the global zone and each local zone found. Because the Solaris - ADM probe must
run on the global zone to detect TCP connection and process information from its local zones, you might
see multiple ECC queue records that appear identical.

Figure 91: ECC queue entries for a zone Discovery
Upon examining the payload, however, you will see that each probe is actually targeting a different zone CI
to filter on and update.
Figure 92: Local zone payload
Virtual machine data collected for zones
Table 58: Data collected on Solaris zones
Version cmdb_ci_vm_zones version zoneadm, zonename

Correlation ID cmdb_ci_vm_zones correlation_id zoneadm, zonename
Name cmdb_ci_vm_instancename zoneadm, zonename
Parent cmdb_ci_vm_instanceparent Internal
CMDB CI cmdb_ci_vm_instancecmdb_ci Internal

Correlation ID cmdb_ci_vm_instancecorrelation_id zoneadm, zonename
Data collected by Discovery on virtual machines

Discovery identifies and classifies information about virtual machines.
Table 59: Data collected by Discovery on virtual machines
Label Table Name Field Name
CPUs cmdb_ci_vm_instance cpus

Disks cmdb_ci_vm_instance disks
Disks size cmdb_ci_vm_instance disks_size
Memory cmdb_ci_vm_instance memory
Network adapters cmdb_ci_vm_instance nics
State cmdb_ci_vm_instance state
Image path cmdb_ci_vmware_instance image_path
Template cmdb_ci_vmware_instance template
vCenter Reference cmdb_ci_vmware_instance vcenter_ref
vCenter Reference UUID cmdb_ci_vmware_instance vcenter_uuid
Discover a VMware infrastructure

A Discovery schedule can discover VMware vCenter and ESX hosts.
These options are available for getting VMware vCenter data:
• Discovery runs the VMware - vCenter Datacenters probe when it identifies a VMware vCenter process
running on a Windows machine or detects activity with the vmapp port probe.
• Orchestration can run any of the vCenter probes from a workflow
Discovery for VMware vCenter

Discovery can explore the VMware vCenter process running on a Windows or Linux host.
ServiceNow Discovery supports these vCenter versions:
• vCenter versions 6.0 and earlier
• vSphere version 5.5
• vCenter appliance version 6.5 and earlier
Note: If you are discovering SUSE Linux hosts for vCenter appliance version 6.0 and earlier, there
are restrictions when using SSH. Please review VMWare documentation.
See vCenter data collected on page 301 for a description of the VMware architecture and component
relationships.

vCenter event collection
In addition to finding vCenter data through the standard discovery process, Discovery can also update the
CMDB by detecting vCenter events through a MID Server extension called the vCenter event collector.
See vCenter event collector on page 180 for details.
vCenter Discovery on Windows host
Windows credentials are not necessary for vCenter Discovery, when valid VMware credentials are used.
Note:
The VMware credentials must have the read-only role in vCenter.
vCenter probe upgrade

The VMware - vCenter probe that discovered all vCenter objects in previous releases is deprecated in the
Istanbul release and replaced by multiple probes.
Upgrade changes
In upgraded systems, the vCenter process classifier and the vmapp port probe are configured to trigger the
VMware - vCenter Datacenters probe. This probe then triggers the probes that discover individual vCenter
objects such as hosts, storage, and datastores. The legacy probe, VMware - vCenter, is still in the system
but is not triggered to run in the updated instance.
Available vCenter probes and probe parameters
vCenter probe parameters allow you to disable the probes for the objects you are not interested in
discovering. You can also reduce the size of a probe's payload by specifying a page size.
Important: Before disabling a probe, be aware of any dependencies that proble might have. If the
probe you disable triggers another probe, the dependent probe is also disabled, and cannot collect
data.

Figure 93: Relationship of vCenter elements to probe parameters
Consider the following when setting these parameters:

• Disable: You disable a probe by setting the parameter in the triggering probe. For example, if you are
not interested in discovering storage, set the disable_host_storage_probe parameter to true in the
VMWare - vCenter ESX Hosts probe.

• Page size: Page size parameters control the number of CIs to discover with a single probe. Use this
parameter to limit payload size by reducing the number of vCenter elements discovered at a time by
any probe. The page size expressed in parentheses is the default in the base system.
• Debug: Set the debug parameter in the VMWare - vCenter Datacenters probe to allow debugging for all
the vCenter probes. Debugging returns the raw vCenter data in each probe payload.
These parameters are available for vCenter probes.
Table 60: vCenter probe parameters
Probe Parameters
VMWare - vCenter Datacenters • debug (applies to all probes)

• disable_vm_probe
• disable_network_probe
• disable_datastore_probe
• disable_cluster_probe
VMWare - vCenter VMs • disable_vm_nic_probe

• page_size (500)
VMWare - vCenter VM NICs none

VMWare - vCenter Networks page_size (500)
VMWare - vCenter Datastores page_size (500)
VMWare - vCenter Clusters • disable_host_probe
• page_size (1000)
VMWare - vCenter ESX Hosts • disable_host_storage_probe

• page_size (350)
VMWare - vCenter ESX Hosts Storage page_size (175)
Preserving your customizations
If you have customized the VMware - vCenter probe in an earlier version, your changes are not applied,
because this probe is ignored, starting with the Istanbul release. Retain the customized behavior is to
modify the appropriate probe in the upgraded system. If you prefer, you can reconfigure your instance to
launch the legacy probe that contains your customizations.
To revert to the VMware - vCenter probe:
1. Navigate to Discovery Definition > Port Probes and select vmapp.
2. In the vmapp record, select VMware - vCenter in the Triggers probe field, and then click Update.
3. Navigate to Discovery Definition > CI Classification > Process and select vCenter.
4. In the Triggers probes related list, change the condition for VMwareProbe-VMware - vCenter to true
and the condition for VMWareProbe-VMWare - vCenter Datacenters to false.
5. Click Update.

vCenter Discovery and process flow

Discovery classifies the process running on a Windows or Linux machine.
Discovering vCenter CIs
After classifying vCenter, Discovery launches the VMware - vCenter Datacenters probe, which in turn
launches specific probes that return information about ESX machines, virtual machines, and other vCenter
objects.
Note: The vmapp port probe is also configured to launch the VMware - vCenter Datacenters
probe.
If you use a domain account to access vCenter, specify the domain with the user name in the credential
record in one of the supported formats such as Domain\UserName.
Updating the CMDB with vCenter event collector

The vCenter event collector is a MID Server extension that listens for vCenter-related events.
For a list of events handled by default in an instance, see vCenter event collector on page 180. For
instructions on configuring vCenter events, see Configure and run the vCenter event collector extension on
page 184.
CIs removed from vCenter
When a vCenter CI, such as a virtual machine, is removed, the ServiceNow instance marks it as "stale" in
the CMDB, using either of these procedures:
• When Discovery runs, it creates an audit record in the CMDB Health Result [cmdb_health_result] table
for the missing CI and marks the CI "stale".
• If the ServiceNow instance is configured to collect vCenter events, the system can also create
a "stale" audit record for the CI in the CMDB Health Result [cmdb_health_result] table from the
VmRemovedEvent event, without having to run Discovery.
Note: When the Staleness setting is configured, the dependency view (BSM map) grays out stale
CIs in its relationship diagram to indicate that they were removed from vCenter.

Figure 94: vCenter CI marked as "stale"
You have the option of creating a CMDB remediation rule to automatically execute a remediation workflow
that can, for example, delete stale CIs. For more information on stale CIs, see CMDB Health Metrics.
Configure an alternate port for vCenter
You can specify an alternate port for the VMWare - vCenter Datacenters probe.
By default, the VMWare - vCenter Datacenters probe runs on port 443, which is the standard port for the
https protocol. The port probes for vCenter run on these ports:
• vmapp6_https: 9443
• vmapp_https: 5480
To specify an alternate port, use one of these procedures:

1. Hard code the port information.
a) Navigate to Configuration > VMware > vCenter.
b) Select the specific instance from the list of instances.
c) Edit the URL field to include the port.

For example, https://10.0.0.1:444

d) Click Submit.
2. Specify an alternate port number for vCenter in the VMWare - vCenter Datacenters probe.
a) Navigate to Discovery > Probes.
b) Open the VMware - vCenter Datacenters probe record.
c) In the Probe Parameters related list, click New.
d) In the Name field of the Probe parameter record, enter vcenter_port.
e) In the Value field, enter your alternate port number.
f) Click Submit.
vCenter data collected

Discovery identifies and classifies information about VMware vCenter servers.
vCenter data
Discovery uses multiple vCenter probes to collect this data from vCenter.
Table 61: VMware vCenter Instance [cmdb_ci_vcenter]
Field label Column name
Name name
Full name fullname
Instance UUID instance_uuid
URL rul
Effective CPU effectivecpu
Table 62: VMware vCenter Cluster [cmdb_ci_vcenter_cluster]
Effective CPU effectivecpu

Effective memory effectivememory
Number of effective hosts effectivehosts
Number of hosts numhosts
Total CPU totalcpu
Total memory totalmemory
Number of CPU cores numcpucores
Number of CPU threads numcputhreads

Table 63: VMware vCenter Datacenter [cmdb_ci_vcenter_datacenter]
Name name
Managed object reference ID morid
Top level folder for hosts host_morid
Top level folder for VMs folder_morid
Table 64: VMware vCenter Folder [cmdb_ci_vcenter_folder]
Full path fullpath

Object ID object_id
Name name
Object ID object_id
Table 65: VMware vCenter Network [cmdb_ci_vcenter_network]
Accessible accessible
Object ID object_id
Table 66: VMware vCenter Object [cmdb_ci_vcenter_object]

vCenter Instance UUID vcenter_uuid
vCenter Reference vcenter_ref
Table 67: VMware vCenter Server Object [cmdb_ci_vcenter_server_obj]

Table 68: VMware Virtual Machine Instance [cmdb_ci_vmware_instance]

and VMware Virtual Machine Template [cmdb_ci_vmware_template
Name name
CPUs cpus
Disks disks
Disks size (GB) disks_size
Guest ID guest_id
Memory (MB) memory
MAC Address mac_address
BIOS UUID bios_uuid
Correlation ID correlation_id
VM Instance UUID vm_instance_uuid
Image path image_path
State state
vCenter Instance UUID vcenter_instance_uuid
vCenter Reference vcenter_ref
Table 69: ESX Resource Pool [cmdb_ci_esx_resource_pool]
Name name
CPU expandable cpu_expandable
CPU limit (MHz) cpu_limit_mhz
CPU reserved (MHz) cpu_reserved_mhz
CPU shares cpu_shares
Full path fullpath
Memory expandable mem_expandable
Memory limit (MB) mem_limit_mb
Memory reserved (MB) mem_reserved_mb
Memory shares mem_shares
Owner owner
Owner Managed Object Reference ID owner_morid

Table 70: VMware vCenter Datastore [cmdb_ci_vcenter_datastore]
Name name
Accessible accessible
Capacity (GB) capacity
Free space (GB) freespace
Type type
URL url
vCenter 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.
vCenter CIs can be members of folders or clusters, which affect how Discovery creates their relationships.
• If a CI is in a folder, Discovery creates a relationship between that CI and the folder. If that CI is not in a
folder, Discovery creates the relationship between the CI and the datacenter. These vCenter CIs can be
in a folder:
• VM Instance
• VM Template
• vCenter Network
• Datastore
• vCenter Folder
• vCenter Cluster
• If an ESX server is in a cluster, Discovery creates a relationship between the ESX server and the
cluster. If an ESX server is not a member of a cluster, then Discovery creates a relationship to the
datacenter.
• If a resource pool is in a cluster, Discovery creates a relationship between the resource pool and the
cluster. If the resource pool is not a member of a cluster, then Discovery creates a relationship to the
ESX server.
Table 71: vCenter relationships
Parent Class Relationship Type Child Class
Computer [cmdb_ci_computer] Virtualized by::Virtualizes ESX Server

[cmdb_ci_esx_server]
VMware Virtual Registered on::Has registered ESX Server
Machine Instance [cmdb_ci_esx_server]
[cmdb_ci_vmware_instance]
VMware Virtual Connected by::Connects VMware vCenter Network
Machine Instance [cmdb_ci_vcenter_network]

Parent Class Relationship Type Child Class
Virtual Machine Template Connected by::Connects VMware vCenter Network

[cmdb_ci_vmware_template] [cmdb_ci_vcenter_network]
VMware vCenter Network Provided by::Provides ESX Server
[cmdb_ci_vcenter_network] [cmdb_ci_esx_server]
VMware vCenter Datastore Provides storage for::Stored on VMware Virtual
[cmdb_ci_vcenter_datastore] Machine Instance
VMware vCenter Datastore Used by::Uses ESX Server
[cmdb_ci_vcenter_datastore] [cmdb_ci_esx_server]
VMware vCenter Datastore Provides storage for::Stored on Virtual Machine Template
[cmdb_ci_vcenter_datastore] [cmdb_ci_vmware_template]
VMware vCenter Cluster Members::Member of ESX Server
[cmdb_ci_vcenter_cluster] [cmdb_ci_esx_server]
ESX Resource Pool Defines resources for::Get VMware vCenter Cluster
[cmdb_ci_esx_resource_pool] resources from [cmdb_ci_vcenter_cluster]
ESX Resource Pool Defines resources for::Get ESX Server
[cmdb_ci_esx_resource_pool] resources from [cmdb_ci_esx_server]
VMware vCenter Folder Contains::Contained by VMware vCenter Datastore
[cmdb_ci_vcenter_folder] [cmdb_ci_vcenter_datastore]
VMware vCenter Folder Contains::Contained by VMware vCenter Folder
[cmdb_ci_vcenter_folder] [cmdb_ci_vcenter_folder]
VMware vCenter Folder Contains::Contained by Virtual Machine Template
[cmdb_ci_vcenter_folder] [cmdb_ci_vmware_template]
VMware vCenter Folder Contains::Contained by VMware Virtual
[cmdb_ci_vcenter_folder] Machine Instance
VMware vCenter Datacenter Contains::Contained by VMware vCenter Network
[cmdb_ci_vcenter_datacenter] [cmdb_ci_vcenter_network]
VMware vCenter Datacenter Contains::Contained by VMware Virtual
[cmdb_ci_vcenter_datacenter] Machine Instance
VMware vCenter Datacenter Contains::Contained by ESX Server
[cmdb_ci_vcenter_datacenter] [cmdb_ci_esx_server]
VMware vCenter Datacenter Contains::Contained by VMware vCenter Datastore
[cmdb_ci_vcenter_datacenter] [cmdb_ci_vcenter_datastore]
VMware vCenter Datacenter Contains::Contained by VMware vCenter Folder
[cmdb_ci_vcenter_datacenter] [cmdb_ci_vcenter_folder]
VMware vCenter Datacenter Contains::Contained by VMware vCenter Cluster
[cmdb_ci_vcenter_datacenter] [cmdb_ci_vcenter_cluster]
VMware vCenter Datacenter Contains::Contained by Virtual Machine Template
[cmdb_ci_vcenter_datacenter] [cmdb_ci_vmware_template]

Figure 95: VMware relationships with ESX server
Datastore data collected by Discovery

Discovery identifies each datastore in the system and creates the relationships with the virtual machines
and the ESX servers that use these datastores.

Datastores
Discovery uses the VMWare - vCenter Datastores probe to collect this data from datastores.
Field Label Table Name Column Name
Accessible VMware vCenter Datastore accessible

[cmdb_ci_vcenter_datastore]
Capacity (GB) VMware vCenter Datastore capacity
Free space (GB) VMware vCenter Datastore freespace
Type VMware vCenter Datastore type
URL VMware vCenter Datastore url
HostMounts
Discovery uses both the VMWare - vCenter ESX Hosts and VMWare - vCenter Datastores probes to
collect datastore host mount data.
Field label Table Column
Accessible VMware Datastore HostMount accessible

[vcenter_datastore_hostmount]
Access Mode VMware Datastore HostMount access_mode
VMware vCenter Datastore VMware Datastore HostMount datastore
ESX Server VMware Datastore HostMount esx_server
vCenter Reference VMware Datastore HostMount vcenter_ref
ESX server discovery

Discovery identifies and classifies information about ESX servers and ESX resource pools through the
discovery of vCenter and not from the direct discovery of any ESX servers.
Important: ESX server discovery is done through vCenter. Do not specify the IP address of
the ESX server in a Discovery Schedule. Instead, discover the vCenter through the Discovery
Schedule.
For a description of the VMware architecture and component relationships, see vCenter data collected on
page 301.
For a discussion of how Discovery collects information on datastores and establishes the relationships
between the ESX hosts and the storage disks attached to the datastores, see Datastore Discovery on page
313

Required Roles
Users with the itil and asset roles can access ESXii and ESXi configuration item (CI) records. To run
discovery on vCenter servers, users must have the discovery_admin role.
Credentials required
To run a complete Discovery of vCenter/ESX servers, you need vCenter credentials. If the vmapp port
probe is disabled, you must use Windows credentials to access the Windows host on which the vCenter
server runs.
Note: Make sure to select a credential Type of VMware.
ESX server Discovery components
After running the vCenter classifier, Discovery launches the VMware - vCenter Datacenters probe, which
launches the probes that explore the ESX server. For the complete list of vCenter probes, see List of
Discovery probes on page 214.
Table 72: Data discovered
Component Name Description
Classifier vCenter Classifies stand-alone vCenter

servers.
Probe VMWare - vCenter ESX Hosts Creates records for ESX
servers and hostmounts.
Creates relationships between
ESX servers and vCenter
components. Triggers probes
for storage Discovery.
Probe VMWare - vCenter ESX Hosts Creates records for ESX host
Storage hardware: network adapters,
disks, HBAs, FC ports,
iSCSI and FC disks. Creates
relationships between DAS/
iSCSI/FC disks and datastore
disks.
Data collected
Basic server data from ESX hosts is collected by the VMware - vCenter ESX Hosts probe.
Table 73: Data collected by Discovery on ESX hosts
Operating System cmdb_ci_esx_server os

OS Version cmdb_ci_computer os_version

Short description cmdb_ci_esx_server short_description
Name cmdb_ci_esx_server name
DNS domain cmdb_ci_esx_server dns_domain
Start date cmdb_ci_esx_server start_date
Manufacturer cmdb_ci_computer manufacturer
Serial number cmdb_ci_computer serial_number
CPU type cmdb_ci_esx_server cpu_type
CPU speed (MHz) cmdb_ci_esx_server cpu_speed
CPU count cmdb_ci_esx_server cpu_count
CPU core count cmdb_ci_computer cpu_core_count
CPU core thread cmdb_ci_computer cpu_core_thread
CPU manufacturer cmdb_ci_esx_server cpu_manufacturer
Model number cmdb_ci_computer model_number
Model ID cmdb_ci_computer model_id
RAM (MB) cmdb_ci_esx_server ram
Disk space (GB) cmdb_ci_esx_server disk_space
Type cmdb_ci_disk type
Model ID cmdb_ci_disk model_id
Disk space (GB) cmdb_ci_disk disk_space
Name cmdb_ci_disk name
Name cmdb_ci_network_adapter name
IP address cmdb_ci_network_adapter ip_address
MAC address cmdb_ci_network_adapter mac_address
Netmask cmdb_ci_network_adapter netmask
Default gateway cmdb_ci_hardware default_gateway
Managed object reference ID Visualization Server morid
[cmdb_ci_virtualization_server]
Serial Number Serial Number serial_number
[cmdb_serial_number]
Relationships
Discovery collects the following relationship data for ESX servers.

Base Class Relationship Dependent Class
ESX Resource Pool Defines resources for:Gets ESX Server

[cmdb_ci_esx_resource_pool] resources from [cmdb_ci_esx_server]
VM Instance Registered on:Has registered ESX Server
[cmdb_ci_vmware_instance] [cmdb_ci_esx_server]
ESX Server Provides storage for:Stored on VM Template
[cmdb_ci_esx_server] [cmdb_ci_vmware_template]
ESX Server Provided by:Provides Networks
[cmdb_ci_esx_server] [cmdb_ci_vcenter_network]
ESX Server Members of:Members Cluster
[cmdb_ci_esx_server] [cmdb_ci_vcenter_cluster
ESX Server Contains:Contained by Datacenter
[cmdb_ci_esx_server] [cmdb_ci_vcenter_datacenter]
ESX resource pools
Resource pools are configured in vCenter and define the maximum amount of resources that templates
using that pool can consume. An ESX server property enables resource pools to expand when necessary
if the ESX server has additional resources to spare. The Name and Owner fields of each resource pool on
the ESX server must be configured in the ESX Resource Pool [cmdb_ci_esx_resource_pool] table. When
Orchestration for VMware executes its manual provisioning tasks, the provisioner must select the proper
resource pool for the virtual server requested. Discovery finds resource pools on ESX machines and
populates the fields on the ESX Resource Pool form automatically. For more information, see Configure
ESX resource pools on page 311.
ESX resource pools requires the Orchestration - VMware Support plugin.
Note: Ensure that vCenter and the ESX server have been fully configured, including the creation of
the templates and resource pools.
Table 74: Data collected
Label Table Field Name Source
CPU expandable ESX Resource Pool cpu_expendable VMWare - vCenter

[cmdb_ci_esx_resource_pool] Clusters probe
CPU limit (MHz) ESX Resource Pool cpu_limit_mhz VMWare - vCenter
CPU reserved (MHz) ESX Resource Pool cpu_reserved_mhz VMWare - vCenter
CPU shares ESX Resource Pool cpu_shares VMWare - vCenter
Full path ESX Resource Pool fullpath VMWare - vCenter
Memory expandable ESX Resource Pool mem_expandable VMWare - vCenter

Memory limit (MB) ESX Resource Pool mem_limit_mb VMWare - vCenter

Memory reserved (MB) ESX Resource Pool mem_reserved_mb VMWare - vCenter
Memory shares ESX Resource Pool mem_shares VMWare - vCenter
Owner ESX Resource Pool owner VMWare - vCenter
Owner Managed ESX Resource Pool owner_morid VMWare - vCenter
Object Reference ID [cmdb_ci_esx_resource_pool] Clusters probe
URL ESX Resource Pool url VMWare - vCenter
Configure ESX resource pools

The ESX server has a default resource pool called Resources that defines normal resources for a virtual
machine..
These levels are dynamically generated from shares of the total resources allocated to virtual machines on
the ESX server. For details about how these resources are calculated, see the ESX server Administration
Guide. ServiceNow Discovery finds this default resource pool and adds a record to the ESX Resource
Pools module automatically. If Discovery is not running on the ServiceNow instance, create a record for the
Resources pool. Ensure that the Owner field is correct and leave the resource fields blank. If a provisioner
selects the Resources pool when provisioning a virtual server, the ESX server will create a virtual machine
for use under a normal load.
1. Navigate to VMware Cloud > Configuration > ESX Resource Pools.
2. Click New in the list.
3. Create a new record for each resource pool in the ESX server, ensuring that the Name and Owner
fields are correct.
4. Select the CPU expandable and Memory expandable check boxes to allow for expansion of the
CPU and memory limits when needed, if those resources are available on the ESX server.
When granted, these extra resources can be revoked if needed to provision other virtual machines.
The additional fields on the form are for display purposes only.
5. Click Submit.

Figure 96: ESX Resource Pool form
VMware virtual machines

Discovery gathers information about virtual machines generated by the VMware application, installed on
Windows, Linux, or ESX servers.
The Discovery product can extract information from VMware configuration items (CI), including their
relationships. Discovery is configured to work with the Orchestration VMware Support Plugin, which

enables the automatic cloning of virtual machines by an ESX server managed by vCenter. For information
about data collected by Discovery on vCenter, see vCenter data collected on page 301.
VMware on Windows or Linux server without vCenter - Legacy
In the basic VMware system, the VMware application runs on a Windows or Linux host machine.
Attention: The Discovery of VMware Workstation is not supported in the Istanbul release. VMware
workstation probes and sensors are not included in new instances of Istanbul. However, customers
who upgrade to Istanbul from an earlier release can continue to use those probes and sensors to
discover VMware Workstation.
This system can clone instances from templates, but cannot be automated. The relationships between
VMware components for this type of installation are shown in the following diagram:
Figure 97: VMware Workstation component relationships
Component 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

• Instantiated by individual virtual machines
Virtual machines • Instantiates VM instances

• Virtualized by VMware application
Datastore Discovery
A datastore is a storage object for virtual machines that are hosted on an ESX server.

A datastore is a collection of one or more physical disks, such as an iSCSI disk, and can be used by more
than one ESX host. However, a physical disk can only connect to one datastore. Because ESX hosts can
share datastores, it is easy to move virtual machine between hosts that have a common datastore.
Note: From the perspective of a virtual machine attached to a datastore, storage is provided by a
single disk.
The advantages to connecting a datastore to multiple disks are:

• The ability to mirror the disks for failover protection.
• The ease of adding storage to the datastore.
For information about the tables used by Discovery to store the data for physical disks and their
relationship to datastores and ESX hosts, see ESX server discovery on page 307.
In this example configuration, two ESX hosts share a common datastore that uses different types of
storage.
Figure 98: Datastore Discovery with different storage types

Relationships
ServiceNow provides tables that contain the relationships between an ESX host and its datastore and the
specific disks to which the datastore is connected.
ServiceNow Discovery establishes the relationships between a datastore, the disks attached to the
datastore, and the ESX server that hosts the virtual machines using that datastore. From the perspective
of the ESX host, iSCSI and fibre channel disks connected to the datastore are treated as physical disks.
Discovery does not show the direct relationship of the storage disks to the ESX host.
Note: Storage can be hosted on computers that are not discovered by Discovery. ESX hosts are
discovered through vCenter, and storage is discovered separately through CIM. The system can
only establish the relationship between the two when storage is discovered before ESX.
Table 75: Datastore tables
Table Description
cmdb_ci_vcenter_datastore_disk Stores the relationship of the physical disk to the

datastore.
vcenter_datastore_hostmount Stores the relationship between the datastore
and the ESX server to which it is connected.
cmdb_ci_disk Contains the physical disks connected directly
to the datastore. This table also contains a
reference to the ESX host.
cmdb_ci_fc_disk Contains the fibre channel disks in a storage
area network (SAN) connected to the datastore.
This table also contains a reference to the ESX
host.
cmdb_ci_iscsi_disk Contains the iSCSI disks in an IP network
connected to the datastore. This table also
contains a reference to the ESX host.
Windows discovery
Discovery identifies and classifies information about Windows computers.
Supported operating systems

• Windows 2008 Server R2
• Windows 2012 Server R2
• Windows Cluster VIP
Note: For fiber channel discovery on a Windows 2008 host, the Microsoft Fibre Channel
Information Tool (fcinfo.exe) must be installed on that machine. The fcinfo executable
should be available on the environment path. The Microsoft Fibre Channel Information Tool tool is
available for download at http://www.microsoft.com.

The Windows classifier supports the following Windows workstation operating systems:
• Windows 7
• Windows 8
• Windows 8.1
• Windows 10
Configure Windows credentials. The user configured in the credentials must have local admin access to
the Windows machine.
The credential that you configure must have the following:
• Access to the WMI service to the current namespace and sub-namespaces.
• Access to the Powershell service.
• Membership in the Distributed COM Users local security group.
Discovery can identify and classify Windows Computers.
Table 76: Data collected by Discovery on Windows computers
Operating System cmdb_ci_computer os wmi

OS version cmdb_ci_computer os_version wmi
OS service pack cmdb_ci_computer os_service_pack wmi
Name cmdb_ci_win_server name DNS, NBT
Hostname cmdb_ci_win_server host_name DNS, NBT
DNS domain cmdb_ci_win_server dns_domain DNS
OS domain cmdb_ci_computer os_domain NBT
Assigned to cmdb_ci_win_server assigned_to wmi
Department cmdb_ci_win_server department Internal (User)
Short description cmdb_ci_win_server short_description wmi
Manufacturer cmdb_ci_win_server manufacturer wmi
Serial number cmdb_ci_win_server serial_number wmi
CPU name cmdb_ci_computer cpu_name wmi
CPU manufacturer cmdb_ci_computer cpu_manufacturer wmi
CPU speed (MHz) cmdb_ci_computer cpu_speed wmi
CPU count* cmdb_ci_computer cpu_count wmi
CPU core count* cmdb_ci_computer cpu_core_count wmi
CPU core thread* cmdb_ci_computer cpu_core_thread wmi
Model ID cmdb_ci model_id wmi
RAM (MB) cmdb_ci_computer ram wmi
Disk space (GB) cmdb_ci_computer disk_space wmi
Type cmdb_ci_disk type wmi

Description cmdb_ci_disk short_description wmi

Disk space (GB) cmdb_ci_disk disk_space wmi
Name cmdb_ci_disk name wmi
Volume serial number cmdb_ci_disk volume_serial_number wmi
Free space (GB) cmdb_ci_file_system free_space 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 wmi
ip_address wmi
mac_address wmi
netmask wmi
DHCP enabled cmdb_ci_network_adapter
dhcp_enabled wmi
Vendor cmdb_ci_network_adapter
vendor wmi
Default gateway cmdb_ci_hardware default_gateway wmi
* Core counts and threads per core might not be accurate, due to issues with Microsoft reporting.
The Windows registry
Discovery can find software that has been installed on a Windows machine by looking at the Windows
Registry. Discovery can find the following attributes of discovered software:
• Product Name, which is a combination of name and version, such as Windows Imaging Component 3.0.
• Name, which is the name of the product only without the version.
• Version
• Uninstall String, such as C:\Program Files\Notepad++\uninstall.exe
• Part of, which is the update that this a part, such as Windows Internet Explorer 8 - Software U.
• Install Date
• Installed on, which is the name of the asset it is installed on.
Windows server cluster discovery

Discovery establishes the relationships between a Windows server cluster and its nodes.
When a Windows server is found, and Discovery detects that it is part of a cluster, the system launches
the Windows - Cluster probe. Navigate to Discovery Definition > Probes and open the record for the
Windows - Cluster probe to see the specific data Discovery collects.

Note: Discovery collects cluster resources based on the MSCluster_ResourceType WMI class. To
see a list of default cluster resources, see Resource Types. To understand how cluster resources
are related to process classifiers, see Relate the process classifier to Windows cluster resources on
page 396.
Cluster data tables
Discovery creates CIs for clusters in these tables:

• Windows Cluster [cmdb_ci_win_cluster]
• Windows Cluster Resource(s) [cmdb_ci_win_cluster_resource]
• Windows Cluster Node(s) [cmdb_ci_win_cluster_node]
• Cluster Node Resource(s) [cmdb_ci_cluster_node_resource]
• Cluster Virtual IP(s) [cmdb_ci_cluster_vip]
Cluster relationships
Discovery creates a CI Relationship [cmdb_rel_ci] record for each node, using these relationships:
• Cluster of::Cluster: Relationship between the cluster nodes and the cluster. Service Mapping uses this
relationship to map the Windows cluster and it's nodes.
Figure 99: Windows cluster map
• Hosted on::Hosts: Relationship between the cluster nodes and the Windows server.

Figure 100: Windows cluster node relationships
Cluster references
Discovery creates the following cluster references:

• From Windows Cluster Nodes to the associated Windows Cluster.
• From Windows Cluster Resources to the associated Windows Cluster.
• From Cluster Virtual IPs to the associated Windows Cluster.
• From Cluster Node Resources to the associated Windows Cluster Node.
Note: References are maintained in Discovery to provide backward compatibility for systems that
use them.
Hyper-V discovery
Microsoft Hyper-V is a virtualization application that is included with the Windows Server 2008 operating
system.
About Hyper-V
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.
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.

Supported versions
Discovery is supported for these Hyper-V Server versions:

• 2008
• 2012
• 2012 R2 (Helsinki release only)
Support for discovery of Hyper V instances running on Windows 2016 is not supported.
Credentials
Configure Windows credentials with Domain administrator rights. You should also Enable PowerShell for
the MID Server used to discover Hyper-V servers and instances.
Hyper-V architecture
Table Purpose
Hyper-V Server [cmdb_ci_hyper_v_server] Contains data about the physical machine running
the Hyper-V server. This table has a reference
relationship with the existing Windows Server
[cmdb_ci_win_server] table.
Hyper-V Virtual Machine Instance Contains data about Hyper-V instances.

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

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

[cmdb_ci_hyper_v_resource_pool]
Hyper-V Resource Pool Component Contains groups of Hyper-V resource pools.

[cmdb_ci_hyper_v_rpool_comp]
Hyper-V Object [cmdb_ci_hyper_v_object] Base class for all Hyper-V objects.
The ServiceNow ITSA Suite modifies these tables for use with multiple virtualization products:
Table Purpose
Virtualization Server [cmdb_ci_virtualization_server] Contains data on all discovered virtualization

servers.
Virtual Machine Instance [cmdb_ci_vm_instance] Contains data on all discovered virtual machine
instances.

Table Purpose
Virtual Machine Object [cmdb_ci_vm_object] Contains data about various objects associated
with a Hyper-V server, such as partitions, networks,
resource pools, and clusters.

Figure 101: Hyper-V Schema Diagram

Hyper-V data collected by Discovery

When Discovery detects the Hyper-V process running on a host machine, it launches exploration probes
that return the typical Windows server data and the following data on the Hyper-V instances.
Label Field Name Data Description Stored in Table
State state • On cmdb_ci_vm_instance

• Off
• Suspended
• Changing
• Stuck
CPUs cpus Count cmdb_ci_vm_instance

Memory memory Quantity in MB cmdb_ci_vm_instance
Network adapters nics Count cmdb_ci_vm_instance
Disks disks Count * cmdb_ci_vm_instance
Disks size disks_size Capacity in GB * cmdb_ci_vm_instance
Virtual Base Board baseboard_serial Virtual serial number cmdb_ci_hyper_v_instance
Serial Number
BIOS Serial Number bios_serial Virtual serial number cmdb_ci_hyper_v_instance
Chassis Serial Number chassis_serial Virtual serial number cmdb_ci_hyper_v_instance
BIOS GUID bios_guid Globally unique cmdb_ci_hyper_v_instance
identifier (GUID)
* Discovery can only return this information if the virtual machine is running.
Label Field Stored in table
Name name cmdb_ci_hyper_v_server

Chassis type chassis_type cmdb_ci_hyper_v_server
Short description short_description cmdb_ci_hyper_v_server
OS Address Width (bits) os_address_width cmdb_ci_hyper_v_server
Operating System os cmdb_ci_hyper_v_server
Host name hostname cmdb_ci_hyper_v_server
IP Address ip_address cmdb_ci_hyper_v_server
OS Version os_version cmdb_ci_hyper_v_server
OS Service Pack os_service_pack cmdb_ci_hyper_v_server
Is virtual virtual cmdb_ci_hyper_v_server
Name name Name of the virtual cmdb_ci

network

ID object_id Globally unique cmdb_ci_vm_object

identifier (GUID)
ID object_id Globally unique cmdb_ci_vm_object

identifier (GUID)
Capacity capacity Maximum amount cmdb_ci_hyper_v_resource_poo
of the appropriate
allocation unit
Allocation units allocation_units Units of measurement cmdb_ci_hyper_v_resource_poo
used (for example, MB
or GB)
Resource type resource_type Type of resource cmdb_ci_hyper_v_resource_poo
discovered (for
example, memory, or
hard drive space)
Label Field Name Data Description Stored in Table Reference Table
Windows Cluster win_cluster Reference field cmdb_ci_hyper_v_cluster

cmdb_ci_win_cluster
displaying the
Windows Cluster
on which the
Hyper-V cluster
resides.
Clone Hyper-V virtual machines

When importing (cloning) Hyper-V virtual machines, make sure each virtual machine has a unique ID.
Discovery identifies virtual machines with duplicate IDs as the same machine.
1. Export the virtual machine from the Hyper-V server.
2. Import the virtual machine into a different server, making one of the these choices:
• Move or restore the virtual machine: This selection clones the image, using the same ID, and
moves it to another server. The original image remains on the Hyper-V server.
• Copy the virtual machine: This selection copies the virtual machine, using a different ID, and
moves it from the Hyper-V server. This is the best selection and does not require any further action
before you run Discovery.
3. If you import the Hyper-V clone using the Move or restore selection, be sure to delete the original
image from the Hyper-V server.
When Discovery encounters two virtual machines with the same equivalent serial numbers, it creates
only one configuration item (CI).
Help the Help Desk discovery on Windows

Help the Help Desk identifies and classifies information about Windows computers.

Supported Windows Operating Systems
• Windows NT Server
• Windows 2000, 2003, 2008, and 2012 Server
• Windows XP and Vista
• Windows 7, 8, and 10
Data collected
Help the Help Desk stores information about Windows computers in the following tables and fields.
Table 77: Tables and Fields
Field Label Table Name Field Name Source
Operating System cmdb_ci_computer os wmi

OS version cmdb_ci_computer os_version wmi
OS service pack cmdb_ci_computer os_service_pack wmi
Name cmdb_ci_computer name ActiveX
Hostname cmdb_ci_computer host_name ActiveX
OS domain cmdb_ci_computer os_domain wmi
Assigned to cmdb_ci_computer assigned_to wmi
Department cmdb_ci_computer department Internal (User)
Short description cmdb_ci_computer short_description wmi
Manufacturer cmdb_ci_computer manufacturer wmi
Serial number cmdb_ci_computer serial_number wmi
CPU name cmdb_ci_computer cpu_name wmi
CPU manufacturer cmdb_ci_computer cpu_manufacturer wmi
CPU speed (MHz) cmdb_ci_computer cpu_speed wmi
CPU count * cmdb_ci_computer cpu_count wmi
CPU core count * cmdb_ci_computer cpu_core_count wmi
CPU core thread * cmdb_ci_computer cpu_core_thread wmi
Model ID cmdb_ci_computer model_id wmi
RAM (MB) cmdb_ci_computer ram wmi
Disk space (GB) cmdb_ci_computer disk_space wmi
Type cmdb_ci_disk type wmi
Description cmdb_ci_disk short_description wmi
Disk space (GB) cmdb_ci_disk disk_space wmi
Free space (GB) cmdb_ci_disk free_space wmi

Field Label Table Name Field Name Source
Name cmdb_ci_disk name wmi

Volume serial number cmdb_ci_disk volume_serial_number wmi
Name name
cmdb_ci_network_adapter wmi
IP address ip_address
MAC address mac_address
Netmask netmask
DHCP enabled dhcp_enabled
Vendor vendor
Default gateway 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 for details.
Network devices
Discovery identifies the following network devices.
Data collected by Discovery on load balancers

Discovery can collect data about network routers, switches, and applications.
Discovery supports data collection from the following applications and hardware:
• A10
• Apache mod_jk and Apache mod_proxy
• Big-IP F5 Traffic Manager
• Cisco
• Citrix NetScaler
• HAProxy
• NGINX
• Alteon
• ACE
• Radware
Important: Discovery treats hardware load balancers as network devices and attempts to discover
them primarily using SNMP. If a load balancer in your system running on a Linux host has SNMP
and SSH ports open, Discovery might classify it based on the SSH port, which has classification
priority over SNMP. To ensure that Discovery properly classifies your hardware load balancers,
create a Discovery behavior for load balancers that includes SNMP but not SSH. Software load
balancers are treated as applications.
Load balancer specific tables

Discovery stores information about load balancers in dedicated, load balancer specific tables.

Table 78: Tables storing load balancer data
Table Extends table Description
A10 Load Balancer Load Balancer [cmdb_ci_lb] A load balancer categorized as

[cmdb_ci_lb_a10] an A10.
ACE [cmdb_ci_lb_ace] Load Balancer [cmdb_ci_lb] A load balancer categorized as
an ACE.
Alteon [cmdb_ci_lb_alteon] Load Balancer [cmdb_ci_lb] A load balancer categorized as
an Alteon.
Cisco CSM Load Balancer [cmdb_ci_lb] A load balancer categorized as
[cmdb_ci_lb_cisco_csm] a Cisco CSM.
Cisco CSS Load Balancer [cmdb_ci_lb] A load balancer categorized as
[cmdb_ci_lb_cisco_css] a Cisco CSS.
Cisco GSS Load Balancer [cmdb_ci_lb] A load balancer categorized as
[cmdb_ci_lb_cisco_gss] a Cisco GSS.
Citrix Netscalers Load Balancer [cmdb_ci_lb] A load balancer categorized as
[cmdb_ci_lb_netscaler] a Citrix Netscaler.
F5 BIG-IP [cmdb_ci_lb_bigip] Load Balancer [cmdb_ci_lb] A load balancer categorized as
an F5 BIG-IP.
F5BigIP GTM Load Balancer [cmdb_ci_lb] A load balancer categorized as
[cmdb_ci_lb_f5_gtm] an F5 BigIP GTM.
F5BigIP LTM Load Balancer [cmdb_ci_lb] A load balancer categorized as
[cmdb_ci_lb_f5_ltm] an F5 BigIP LTM.
HAProxy Load Balancer Load Balancer Application A load balancer application
[cmdb_ci_lb_haproxy] [cmdb_ci_lb_appl] categorized as HAProxy.
ISA Server [cmdb_ci_lb_isa] Load Balancer [cmdb_ci_lb] A load balancer categorized as
an ISA Server
Load Balancer [cmdb_ci_lb] Server [cmdb_ci_server] A device identified as a load
balancer.
Load Balancer Application Application [cmdb_ci_appl] An application that provides
[cmdb_ci_lb_appl] load balancing functionality.
Load Balancer Interface Configuration Item [cmdb_ci] A network interface.
[cmdb_ci_lb_interface]
Load Balancer Pool Configuration Item [cmdb_ci] A collection of host-to-port
[cmdb_ci_lb_pool] mappings to be balanced.
Load Balancer Pool Member Configuration Item [cmdb_ci] A host-to-port mapping of a
[cmdb_ci_lb_pool_member] request to be balanced.
Load Balancer Service Configuration Item [cmdb_ci] A virtual service that the
[cmdb_ci_lb_service] device balances by forwarding
requests to members within a
pool.
Load Balancer Service VLAN A virtual LAN related to services
[cmdb_lb_service_vlan]

Table Extends table Description
Load Balancer VLAN Configuration Item [cmdb_ci] A virtual LAN segment.

[cmdb_ci_lb_vlan]
Load Balancer VLAN Interface Interfaces related to virtual
[cmdb_lb_vlan_interface] LANs
Modjk Load Balancer Load Balancer Application A load balancer application
[cmdb_ci_lb_modjk] [cmdb_ci_lb_appl] categorized as Mod_jk.
ModProxy Load Balancer Load Balancer Application A load balancer application
[cmdb_ci_lb_modproxy] [cmdb_ci_lb_appl] categorized as ModProxy.
Network Load Balancer [cmdb Load Balancer [cmdb_ci_lb] A load balancer categorized as
_ci_lb_network] a Network.
Nginx Load Balancer Load Balancer Application A load balancer application
[cmdb_ci_lb_nginx] [cmdb_ci_lb_appl] categorized as NGINX.
Radware Load Balancer Load Balancer [cmdb_ci_lb] A load balancer categorized as
[cmdb_ci_lb_radware] a Radware.
Probes for load balancers
Several probes are available to discover load balancers, applications, interfaces, and pools. See Load
balancer fields and probes on page 328 for more information.
Load balancer fields and probes
Discovery stores load balancer information in the following fields.
Note: By default, the system uses the discovered IP address of a load balancer for the CI record.
This can be the management IP created for the device that is used in the Discovery schedule. For
instructions on how to force Discovery to use the IP address of the load balancer's NIC rather than
that of a management IP, see IP address selection properties on page 66.
Table 79: Fields on the Citrix Netscalers [cmdb_ci_lb_netscaler] table
Field label and name Probes that gather data
Serial Number [serial_number] SNMP - Netscaler - Identity - Serial

Asset tag [asset_tag] SNMP - Netscaler - Identity
Model ID [model_id] SNMP - Netscaler - Identity
Table 80: Fields on the Cisco GSS [cmdb_ci_lb_cisco_gss] table
Serial Number [serial_number] Cisco GSS - Serial Number

Model ID [model_id] Cisco GSS - Identity
IP Address [ip_address] Cisco GSS - Network
Manufacturer [manufacturer] Cisco GSS - Identity

Table 81: Fields on the Cisco CSS [cmdb_ci_lb_cisco_css] table
Serial Number [serial_number] SNMP - Load Balancer – Identity

Model ID [model_id]
IP Address [ip_address]
Manufacturer [manufacturer]
Table 82: Fields on the F5 BIG-IP [cmdb_ci_lb_bigip] table
Active modules [active_modules]* SNMP - F5 BIG-IP - System

Asset tag [asset_tag]
Model ID [model_id]
Failover mode [failover_mode]*
Failover peer [failover_peer]*
Serial Number [serial_number] Cisco GSS - Serial Number
*not visible on the form by default. Customize the form to add this field.
Table 83: Fields on the Load Balancer [cmdb_ci_lb] table
Operational status [operational_status] • Apache - Get JK Module

Name [name] • Apache - Get Proxy Module
• HAProxy - Get Configuration
• SNMP - F5 BIG-IP - System
• SNMP - Netscaler - System
• SNMP - Load Balancer - Identity
Table 84: Fields on the Load Balancer Application [cmdb_ci_lb_appl] table
Configuration file [config_file]* Nginx - Get Configuration

Name [name] • Apache - Get JK Module
IP Address [ip_address]* • Apache - Get Proxy Module
Most recent discovery [last_discovered]*
• Nginx - Get Configuration

Version [version] • Apache - Version

• HAProxy - Version
• Nginx - Version
Table 85: Fields on the Load Balancer Interface [cmdb_ci_lb_interface] table
Status [install_status]* • Apache - Get JK Module

Load Balancer [load_balancer] • Apache - Get Proxy Module
Name [name]
Table 86: Fields on the Load Balancer Pool [cmdb_ci_lb_pool] table
Load Balancing Method [load_balance_method] • Apache - Get JK Module

Load Balancer [load_balancer] • Apache - Get Proxy Module
Most recent discovery [last_discovered]*
Name [name] • SNMP - Netscaler - System
Table 87: Fields for Load Balancer Pool Member [cmdb_ci_lb_pool_member] data
Fully qualified domain name [fqdn]* • HAProxy - Get Configuration


IP Address [ip_address] • Apache - Get JK Module

Load balancer [load_balancer] • Apache - Get Proxy Module
Most recent discovery [last_discovery]*
• Nginx- Get Configuration
Name [name] • SNMP - F5 BIG-IP - System
Pool [pool]*
Service Port [service_port]
Table 88: Fields for Load Balancer Service [cmdb_ci_lb_service] data
Input URL [input_url] • Apache - Get JK Module

• Apache - Get Proxy Module
IP Address [ip_address] • Apache - Get JK Module

• Apache - Get Proxy Module
• Cisco GSS - Identity
Last port [last_port]* HAProxy - Get Configuration

Load Balancer [load_balancer] • Apache - Get JK Module
Most recent discovery [last_discovery]* • Apache - Get Proxy Module
• Cisco GSS - Identity
Service Port [service_port]*

Table 89: Fields for Load Balancer VLAN [cmdb_ci_lb_vlan] data
Load Balancer [load_balancer] • Apache - Get JK Module

Name [name] • Apache - Get Proxy Module
Tag [tag] • SNMP - F5 BIG-IP - System

Apache web server data
Discovery also collects data on Apache web serer load balancing modules using SSH. See Apache mod_jk
and mod_proxy discovery on page 335 for more information on probes for Apache web server data. For
information on the tables, fields, and data sources that discovery populates for Apache web servers, see
Data collected by Discovery on Apache web servers on page 375.
Load Balancer: A10
Discovery identifies and classifies information about A10 load balancers. The discovery of the A10 load
balancer is supported by SNMP.
Data sources
Discovery uses the following SNMP MIBs to collect data for A10 load balancers:
• A10 COMMONS MIB file for common data
• A10 AX MIB file for extras
Data collected
The A10 load balancer follows the generic model of a load balancer and its components. The abstract
class is Load Balancer [cmdb_ci_lb], and the implementation class, extended from cmdb_ci_lb, is
A10 [cmdb_ci_lb_a10]. The load balancer components are modeled as follows:

Table 90: A10 load balancer components
Component Table Description
Load Balancer Interface cmdb_ci_lb_interface Network interface.

Load Balancer Group cmdb_ci_lb_pool Collection of host-to-port
mappings to be balanced.
Load Balancer Group Member cmdb_ci_lb_pool_member Host-to-port mapping of a
request to be balanced.
Load Balancer Service cmdb_ci_lb_service Virtual service that the device
balances by forwarding
requests to members within a
pool.
Load Balancer VLAN cmdb_ci_lb_vlan Virtual LAN segment. Currently
not supported.
Relationships created
An A10 Discovery creates relationships between the application and the load balance service if the
application CI exists.
In this example from the ServiceNow dependency view (BSM map), an A10 load balancer is represented
by these elements:
• Vip1: Virtual IP address that is the entry point for all business services attempting to contact the load
balancer.
• vthunder: Actual A10 load balancer CI created by Discovery.
• webApp-group1: Group containing the web server pool members IBM web01 and IBM web02.

Figure 102: A10 load balancer dependency view (BSM map)
Discovery creates these relationships from the perspective of the load balancer group:

Figure 103: A10 load balancer relationships
ServiceWatch maps an A10 load balancer like this:
Figure 104: A10 load balancer ServiceWatch map
Apache mod_jk and mod_proxy discovery

Discovery uses SSH to find Apache connectors mod_jk and mod_proxy.
Discovery uses the Unix - Active Processes probe to identify an Apache web server process by matching
one of the following criteria: the name of the process is:
• httpd, or
• apache, or
• httpd2, or
• httpd2-prefork
If there is a match on one of these criteria, a record is created in the Web Server [cmdb_ci_web_server]
table if one does not already exist for that running process.
The following probes are triggered after classification:

Table 91: Apache web server probes
Probe Description Commands
Apache – Version The sensor of this probe httpd

populates the Apache version
information in the Web Server
record.
Apache – Get Configuration This probe contains a Bourne echo, sed, httpd, cut, grep,
shell script and an argument egrep (within the Borne shell
that determines the path of the script)
Apache configuration file. The
sensor of this probe populates
some additional information in
the Web Server record.
The sensor processing of the Apache – Get Configuration probe identifies whether either the mod_jk or
mod_proxy modules are present and triggers the appropriate probe.
Table 92: Apache module probes
Apache – Get JK Module If the mod_jk module is running echo, sed, httpd, cut, grep,
as a load balancer on the egrep (within the Borne shell
server, the sensor of this probe script)
populates the information in
the Load Balancer Service
[cmdb_ci_lb_service],
Load Balancer Pool
[cmdb_ci_lb_pool] and Load
Balancer Pool Member
[cmdb_ci_lb_pool_member]
tables.
Apache – Get Proxy Module If the mod_proxy module is grep, egrep (within the Borne
running as a load balancer on shell script)
the server, the sensor of this
probe populates the information
in the Load Balancer Service
Load Balancer Pool
[cmdb_ci_lb_pool] and Load
[cmdb_ci_lb_pool_member]
tables.
In addition to data population, the following relationships are created in the CI Relationship [cmdb_rel_ci]
table:
• The records in the cmdb_ci_lb_appl table run on the cmdb_ci_web_server table records.
• The records in the cmdb_ci_lb_service table use the cmdb_ci_lb_pool table records.
• The records in the cmdb_ci_pool table are used by the cmdb_ci_service table record.
• The records in the cmdb_ci_pool table are members of the cmdb_ci_pool_member table.

• The records in the cmdb_ci_pool_member table are members of the cmdb_ci_pool table.
Load balancer: Citrix Netscaler

Discovery of Citrix Netscaler load balancers is performed by SNMP.
Requirements
Consider the following requirements for discovering Citrix Netscaler load balancers:
• The Citrix Netscaler device is installed and running on the network.
• The Citrix Netscaler probes require SNMP credentials to run commands.
Probes
The SNMP - Classify probe detects Citrix Netscaler load balancers with the following SNMP MIB: NS-
ROOT-MIB
Table 93: Citrix Netscaler probes
Probe Description
SNMP - Netscaler – Identity MultiProbe that queries for the serial number and
other identifying information.
SNMP - Netscaler – Identity - Serial Retrieves the Netscaler chassis serial number,
which is globally unique for this vendor.
SNMP - Netscaler - System Collects information on the Netscaler, including
pools, services, and VLANs.
The Citrix Netscaler load balancer model represents a generic load balancer and its components. The
abstract class is stored in the Load Balancer [cmdb_ci_lb] table. The implementation class, extended from
Load Balancer, is stored in the Citrix Netscalers [cmdb_ci_lb_netscaler] table.
Note: See Load balancer fields and probes on page 328 for a list of the fields that are populated
by these probes.
Note:
Discovery does not gather the load balancer interface information that is necessary to map the
network path in Service Mapping. Service maps might not appear correct.

CI relationships
A Citrix Netscaler discovery creates relationships between the application and the load balance service
as well as groups and group members if the application CI exists. However, if the application CI was not
discovered, the SNMP - Netscaler - System sensor will map between the computer and the load balance
service instead.
In this example from the ServiceNow dependency view (BSM map), a Netscaler load balancer is
represented by these elements:
• netscaler: Actual Netscaler load balancer CI created by Discovery.
• VIP1: Virtual IP address that is the entry point for all business services attempting to contact the load
balancer.
• New_Service_Group: Group containing the web server pool members.

Figure 105: Sample Citrix Netscaler load balancer configuration
Load balancer: F5 BIG-IP discovery

Discovery of F5 BIG-IP load balancers is performed via SNMP.

Consider the following requirements for discovering F5 BIG-IP load balancers:

• The F5 BIG-IP device is installed and running on the network.
• The F5 BIG-IP probes require SNMP credentials to run commands.
Note: You can download VMware images of BIG-IP with a free 90-day key from https://
www.f5.com/trial.
Components
MIBs The SNMP - Classify probe detects F5 BIG-IP load

balancers with the following SNMP MIBs:
• F5-BIGIP-COMMON-MIB
• F5-BIGIP-LOCAL-MIB
• F5-BIGIP-SYSTEM-MIB
• F5- BIGIP-GLOBAL-MIB
Probes The following probes are triggered after

classification:
Table 94: F5 BIG-IP probes
Probe Description
SNMP - F5 BIG-IP - MultiProbe that

Identity queries for identifying
information.
SNMP - F5 BIG-IP - Retrieves the BIG-IP
Identity - Serial chassis serial number,
which is globally unique
for this vendor. This is
included in the Identity
probe.
SNMP - F5 BIG-IP - Collects information
System on the F5 BIG-IP,
including pools,
services, and VLANs.
DNS names For F5 Global Traffic Manager (GTM) load

balancers, Discovery can resolve the DNS name of
the F5 GTM hardware as well as the DNS names
of all the servers associated with the load balancer
that receive distributed traffic. To view this data,

navigate to Configuration > Load Balancers > LB

Hardware and open the F5 load balancer record.
Then select the DNS Names for CIs related list.
This data is used by Service Mapping on page
514 to map F5 relationships.
Relationship mapping The abstract class is stored in the Load Balancer

[cmdb_ci_lb] table. The implementation class, which
is extended from Load Balancer, is stored in the F5
BIG-IP [cmdb_ci_lb_bigip] table.
An F5 discovery creates relationships between
the application and the load balance service if the
application CI exists. However, if the application
CI was not discovered, the SNMP - F5 BIG-IP -
System sensor maps between the computer and
the load balance service instead.
In this example, load balancer lba-001a has
multiple services. The vip_repo_sea1-http service
distributes the Apache Server on Port 80. Because
there are three services (vip_ns_internal.sea1,
vip_ldaps.sea1, vip_ldap.sea1) where the sensor
could not locate the application, relationships to the
Linux server ops01 are created instead.

Figure 106: F5 Network with a load balancer
Load balancer: HAProxy

Discovery of HAProxy load balancers is performed by SSH.

HAProxy is an open-source load balancer that can manage any TCP service. It is particularly suited for
HTTP load balancing because it supports session persistence and Layer 7 processing. Discovery supports
HAProxy for HTTP load balancing. TCP load-balancing is not supported.
Consider the following requirements for discovering the HAProxy:
• The HAProxy software is installed and running on a Linux server.
• The MID Server is deployed to explore the server and the MID Server has access to the server
HAProxy configuration file.
• The configuration probe checks for the haproxy.cfg file using one of the following methods:
• Using the f parameter for the HAProxy process output.
• Using the default /etc/haproxy/haproxy.cfg path.
• The HAProxy probes require credentials and execute privileges to run commands.
Discovery uses the Unix - Active Processes probe to identify an HAProxy load balancer when the name
of the process is haproxy. If this criterion matches, a record is created in the HAProxy Load Balancers
[cmdb_ci_lb_haproxy] table if one does not already exist for that running process.
Table 95: HAProxy probes
HAProxy – Version The sensor of this probe haproxy

populates the HAProxy version
in the HAProxy Load Balancers
[cmdb_ci_lb_haproxy] table.
HAProxy – Get Configuration The sensor of this probe echo, sed, cut, grep, egrep
populates additional information (within the Borne shell script)
in the HAProxy Load Balancers
[cmdb_ci_lb_haproxy]
table. The probe also
populates information in
the Load Balancer Service
Load Balancer Pool
[cmdb_ci_lb_pool], Load
[cmdb_ci_lb_pool_member],
Load Balancer Interface
[cmdb_ci_lb_interface], and
Load Balancer Application
[cmdb_ci_lb_apple] tables.
In addition to populating the data, the following relationships records are created in CI Relationships
[cmdb_rel_ci] table:
• The records in the cmdb_ci_pool table are used by the cmdb_ci_service table records.
• The records in the cmdb_ci_pool table are members of the cmdb_ci_pool_member table records.
• The records in the cmdb_ci_pool_member table are members of the cmdb_ci_pool table records.

Load balancer: NGINX

Discovery of NGINX load balancers is performed by SSH.
NGINX is an open source web server with a load balancer. Discovery identifies the web server and
information related to the load balancer.
Consider the following requirements for discovering NGINIX servers:
• Ensure that the NGINX software is installed and running on the server.
• Grant the MID Server has access to the NGINX configuration file, which is /etc/nginx/nginx.conf
by default.
• Enable secure shell (SSH) commands.
• The NGINX probes require credentials and execute privileges to run commands.
The Nginx Process Classifier detects a running process that matches the following criteria during the
exploration of a UNIX server:
• The name of the process starts with nginx.
• The name of the process contains master.
Both of these conditions must match:

• A record is created in the Web Server [cmdb_ci_web_server] table.
• A Runs on relationship is created in the CI Relationship [cmdb_rel_ci] table for the Linux Server
[cmdb_ci_linux_server] table and the Web Server [cmdb_ci_web_server] table.
Table 96: NGINX probes
Nginx – Version This probe contains a Bourne nginx

shell script. It determines
the version of NGINX and
populates the Web Server
[cmdb_ci_web_server] table.
Nginx – Get Configuration This probe contains a Bourne echo, sed, cut, grep, egrep
shell script and an argument (within the Borne shell script)
that determines the path of the
NGINX configuration file. The
probe identifies configuration
parameters based on keywords
within the configuration file
and returns them as a single
payload result.
In addition to populating the data, the following relationships records are created in CI Relationships
[cmdb_rel_ci] table:
• The records in the cmdb_ci_web_server table run on the cmdb_ci_linux_server table records.
• The records in the cmdb_ci_pool table are members of the cmdb_ci_pool_member table records.
• The records in the cmdb_ci_pool_member table are members of the cmdb_ci_pool table records.

Load balancer: Cisco GSS

Discovery of Cisco GSS load balancers is performed by both SNMP and SSH.
Classifiers
Discovery uses the Cisco GSS Load Balancer classifier, which contains the condition: sysdescr contains
Global Site Selector to classify the device.
Probes
Discovery uses several probes, including an SNMP probe to discover the specific GSS device and a Serial
Number probe to identify the serial number of the device. See the table below for the list of related probes.
Warning: You must have SNMP and SSH credentials configured correctly for the GSS load
balancers on your network.

Probe Description Type
Cisco GSS - Identity A multiprobe that identifies the MultiProbe

GSS device and serial number.
Cisco GSS - Network This is included in the Cisco Java- SNMP
GSS - Identify probe.
Cisco GSS - Serial Number This is included in the Cisco JavaScript
GSS - Identify probe.
Cisco GSS - Get Domains A probe that discovers global JavaScript
domain names corresponding
to the device.
Tables
Discovery creates a record for each GSS device in the Cisco GSS [cmdb_ci_lb_cisco_gss] table. Domains
are populated in the DNS Names [cmdb_ci_dns_name] table. Host names and IP addresses are stored in
the IP Address to DNS Name [cmdb_ip_address_dns_name] table. Service Mapping uses this information.
You can see the DNS name information on the DNS Names for CIs related list of the Load Balancer form.
Note: The Cisco GSS pattern is available by default to use with the Pattern Designer.
Load balancer: Cisco CSS

Discovery of Cisco CSS load balancers is performed by SNMP.
Classifiers
Discovery uses the Cisco CSS Load Balancer classifier, which contains the OID Classification:
1.3.6.141.9.9.368.4.5: .

Probes
The following probes are triggered:

Probe Description Type
SNMP - Load Balancer - A multiprobe that identifies load Java-SNMP

Identity balancers.
Cisco CSS - Get Services A Java probe that includes the Java-SNMP
Cisco CSS sensor to identify
services defined on the load
balancer in the Load Balancer
Services [cmdb_ci_lb_service]
table. For every service,
Discovery populates Name,
ip_address and port.
Tables
Discovery creates a record for each CSS device in the Cisco CSS [cmdb_ci_lb_cisco_css] table, which
includes the device's Name, Model, Serial Number, Manufacture, and NIC (ip_address). It also creates a
record for each service in the Load Balancer Services [cmdb_ci_lb_service] table.
.
Layer 2 Discovery
Discovery can detect the physical connections, known as Layer 2, between network devices.
Layer 2 discovery process
Discovery uses multiple probes to gather information about network adapters and their Layer 2
connections.
For example, if Discovery finds a switch in a network, it triggers the SNMP - Switch - Vlan probe and the
SNMP - Network - ARPTable probe. For every Vlan Discovery finds, it triggers various switch probes. If
a switch has routing capabilities, Discovery triggers the SNMP - Routing probe to collect network adapter
information in the Network Adapter [cmdb_ci_network_adapter] table. If Discovery finds a server, it triggers
the appropriate Address Resolution Protocol (ARP) probe for that operating system. Discovery also
supports the use of patterns, such as the Network Switch and Network Router patterns, which are available
by default in Discovery. See Router and switch discovery on page 353 for more information.
During the discovery of a network device, Discovery creates records in the Router Interface
[dscy_router_interface] table and the Switchport [dscy_switchport] table. This information contains network
adapter information for that device. For SNMP-enabled devices, Discovery gathers the information from a
routing probe during the exploration phase. The Layer 2 protocol cache probe runs next to collect neighbor
data from the device.
As Discovery gathers network information from the probes on a device, it populates the Device Neighbors
[discovery_device_neighbors] table. In some cases, the neighbors of this device might not yet be known to
the instance. The neighbor's interface cannot be resolved to a record until Discovery eventually finds the
neighbor's side of the relationship. When Discovery runs on the neighboring device, Discovery completes
the information for the neighbor's interface for the original reporting device.

Retrieving neighbor data
Discovery can retrieve neighbor data from these caches on a network device:
• Cisco Discovery Protocol (CDP) : Cache on Cisco devices that contains device neighbor information in
the form of a protocol specific neighbor ID.
• Link Layer Discovery Protocol (LLDP): Generic cache that contains device neighbor information in the
form of a protocol specific neighbor ID.
• Address Resolution Protocol (ARP): Cache that contains the IP and MAC addresses of all connecting
devices and servers.
Layer 2 connectivity
Discovery can create Connects to:Connected by relationships between connected layer 2 devices and
between the interfaces and adapters of host servers and layer two devices. Service Mapping must be
active in addition to Discovery.
In the following example, Discovery found a server running AIX, and was also able to find two IP switches
on the network. These relationships were created:
• An IP Connection relationship between the AIX Server and the two IP switches A and B.
• A reference between the AIX server and its own network adapter.
• A Connects to relationship between the adapters on the two IP switches (not shown in image below).
• A Connects to relationship between the network adapter of the AIX server and the switch port of IP
switch A (highlighted in red). This kind of relationship requires Service Mapping to be active.
To view these relationships, open the dependency view for the server. To view the relationship between
the two IP switches, open the dependency view from one of the switches and select the Physical Network
Connections option for the Dependency Type in the map settings.
Address Resolution Protocol (ARP) in Layer 2 Discovery

The Discovery probes for Address Resolution Protocol (ARP) map the IP address of a computer or network
device to a MAC address. These probes retrieve the IP address and MAC address for a CI from the

Network Infrastructure Item [dscy_net_base] table. Devices that support SNMP, such as Linux computers
and network devices, cache two types of address information:
• Static: Manually added address resolutions.
• Dynamic: Hardware name and IP address pairs added to the cache by previous, successful ARP
resolutions.
When the ARP table Discovery completes, the system collects all static and dynamic table entries
from devices via SNMP. If a new ARP entry is available, it is added to the Network ARP Table
[discovery_net_arp_table]. If any previously discovered ARP entries are no longer cached in the device’s
ARP table, the system removes the corresponding records from the CMDB using the reconciliation
process.
Note: If new ARP entries are created after Discovery runs, they are not discovered until the next
Discovery schedule. If ARP entries are removed from the device after Discovery runs, the CMDB
ARP table is not updated until Discovery runs again.
ARP probes
Discovery provides these probes for extracting IP and MAC address resolution information:
Probe ECC queue topic Command Description
Linux - Network ARP SSHCommand arp -n SSH command probe

Tables that retrieves the
network information
from the ARP table on
a Linux server.
Solaris - Network ARP SSHCommand arp -an SSH command probe
Tables that retrieves the
network information
a Solaris server.
Windows - Network Powershell arp -a Powershell probe
ARP Table that retrieves the
network information
a Windows server.
SNMP - Network - SNMP Table SNMP probe that
ArpTable collects information
The SNMP probe
uses this OID first:
a switch or router.
iso.org.dod.internet.mgmt.mib-2.ip.ipNetToMedia
ipNetToMediaPhysAddress,ipNetToMediaNetAddress
If the probe fails
to return results,
it uses this OID:
iso.org.dod.internet.mgmt.mib-2.ip.ipNetToPhys
ipNetToPhysicalNetAddress,ipNetToPhysicalPhysA

SNMP switch probes
These probes return bridging information from VLANs connected across network switches, including port
selection, forwarding tables, and the use of the spanning tree protocol.
SNMP - Switch - BridgePortTable This probe returns all the ports from a switch that
are used to create a bridge between network
segments.
Table 97: Bridging data returned
Table Switch Bridge

Port Table
[discovery_switch_bridge_port_table]
OID iso.org.dod.internet.mgmt.mib-2.dot1dB
dot1dBasePort,dot1dBasePortIfIndex
Fields populated • cmdb_ci
• port
• interface_index
SNMP - Switch - SpanningTreeTable This probe returns the active path between any two
network nodes bridged by a switch.
Table 98: Spanning tree data returned
Table Switch Spanning

Tree Table
[discovery_switch_spanning_tree_table
OID iso.org.dod.internet.mgmt.mib-2.dot1dB
dot1dStpPort,dot1dStpPortState,dot1dS
• port
• port_state
• port_enable
• designated_root
• designated_bridge_mac
SNMP - Switch - ForwardingTable This probe returns information from a switch's

forwarding table.
Table 99: Forwarding table data returned
Table Switch
Forwarding Table
[discovery_switch_fwd_table]

OIDs These OIDs are built

as needed by the
DiscoveryVlanSwitchProcessor
script include.
• Non-Cisco:
• Q-BRIDGE MIB:
oid_spec_list
= 'table
iso.org.dod.internet.mg
dot1qTpFdbAddress.'
+
vlanIndex +
',dot1qTpFdbPort.'
+
vlanIndex +
',dot1qTpFdbStatus.'
+
vlanIndex;
• BRIDGE MIB:
oid_spec_list
= 'table
iso.org.dod.internet.mgmt.mib-2.
dot1dTpFdbAddress,dot1dTpFdb
• Cisco
BRIDGE MIB:
oid_spec_list
= 'table
iso.org.dod.internet.mgmt.
dot1dTpFdbAddress,dot1dTpF
Additional probe called Switch - MAC

Table called by
DiscoveryVlanSwitchProcessor
script include, if
needed.
Command show mac address-
table

• vlan_id
• port
• status
• mac_address (from
the cmdb_ci field
in the Network
Infrastructure Item
[discovery_net_base]
table)
SNMP - Switch - Vlan This probe returns VLAN IDs from a network switch.

Table 100: VLAN data returned
OIDs • iso.org.dod.internet.private.enterpris
• iso.org.dod.internet.private.enterpris
• iso.org.dod.internet.private.enterpris
• iso.org.dod.internet.mgmt.mib-2.sys
Note:
Other switch
types are not
supported.
Data collected by Discovery on TCP connections

Discovery identifies and classifies information about TCP connections.
Table 101: Data collected by Discovery on TCP connections
Absent cmdb_tcp absent Internal

Computer cmdb_tcp 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
Data collected by Discovery on an IP address

Discovery identifies and classifies information about IP addresses.
Table 102: Data Collected by Discovery on IP Addresses
IP Address discovery_ip_address ip_address Various internal

Hostname discovery_ip_address host_name Various internal
Discovered discovery_ip_address discovered Various internal
Agent discovery_ip_address agent Various internal
Discoverer discovery_ip_address discoverer Various internal
In Ranges discovery_ip_address in_ranges Various internal
MAC Address discovery_ip_address mac Various internal

CMDB CI discovery_ip_address cmdb_ci Various internal

SSH attempted discovery_ip_address ssh_attempted Various internal
SNMP attempted discovery_ip_address snmp_attempted Various internal
Data collected by Discovery on IP networks

Discovery identifies and classifies information about IP networks.
Table 103: Data collected by Discovery on IP networks
Discover cmdb_ci_ip_network discover Various internal

Subnet cmdb_ci_ip_network subnet Various internal
Network discovery cmdb_ci_ip_network network_discovery Various internal
Last discovered cmdb_ci_ip_network last_discovered Various internal
MID server cmdb_ci_ip_network mid_server Various internal
Router cmdb_ci_ip_network router Various internal
State cmdb_ci_ip_network state Various internal
Data collected by Discovery on network printers

Discovery identifies and classifies information about network printers.
Discovery can identify and classify Network Printers.
Table 104: Data collected by Discovery on network printers
Serial number cmdb_ci serial_number SNMP, various MIBs

Start date cmdb_ci start_date SNMP, RFC1213 MIB
Manufacturer cmdb_ci manufacturer SNMP, RFC1213 MIB
Model ID cmdb_ci model_id SNMP, RFC1213 MIB
ip_address SNMP, IP MIB
mac_address SNMP, IF MIB
Printer type cmdb_ci_printer print_type SNMP, PRINT MIB
Use count cmdb_ci_printer use_count SNMP, PRINT MIB
Use count units cmdb_ci_printer use_units SNMP, PRINT MIB
Colors cmdb_ci_printer colors SNMP, PRINT MIB
Horizontal resolution cmdb_ci_printer horizontal_resolution SNMP, PRINT MIB
Vertical resolution cmdb_ci_printer vertical_resolution SNMP, PRINT MIB

Resolution units cmdb_ci_printer resolution_units SNMP, PRINT MIB

Description discovery_printer_supplies
description SNMP, PRINT MIB
Supply type discovery_printer_supplies
supply_type SNMP, PRINT MIB
Supply class discovery_printer_supplies
supply_class SNMP, PRINT MIB
Current level discovery_printer_supplies
current_level SNMP, PRINT MIB
Max capacity discovery_printer_supplies
max_capacity SNMP, PRINT MIB
Router and switch discovery

Discovery identifies and classifies information about network routers and switches.
Network routers and switches often have very similar capabilities. It is very common for some switches
known as Layer 3 switches to have IP routing. Larger routers with optional modules might 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. For
details on how Discovery collects data about connections between network devices and other components,
see Layer 2 Discovery on page 346.
Table 105: Data collected by Discovery on network routers and switches

Start date (only when cmdb_ci start_date SNMP, RFC1213 MIB
target is a host)
Can route IP cmdb_ci_netgear can_route SNMP, IP MIB, BGP
MIB
Can switch IP cmdb_ci_netgear can_switch SNMP, dot1dBridge
MIB
Can partition VLANs cmdb_ci_netgear can_partitionvlans SNMP, dot1dBridge
MIB
Can hub cmdb_ci_netgear can_hub SNMP, IP MIB
Neighbor Address discovery_device_neighbors
neighbor_address ciscoCdpMIB, lldpMIB
Neighbor ID discovery_device_neighbors
neighbor_id ciscoCdpMIB, lldpMIB
Neighbor Interface discovery_device_neighbors
neighbor_interface ciscoCdpMIB, lldpMIB
Neighbor Source discovery_device_neighbors
neighbor_source ciscoCdpMIB, lldpMIB
Origin Interface discovery_device_neighbors
origin_interface ciscoCdpMIB, lldpMIB
IP Address discovery_net_arp_table ip_address SNMP, IP MIB

MAC Address discovery_net_arp_table mac_address 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 next_hop_ip_address SNMP, IP MIB
Interface Index discovery_switch_bridge_port_table
interface_index SNMP, dot1dBridge
MIB
Port discovery_switch_bridge_port_table
port SNMP, dot1dBridge
MIB
MAC Address discovery_switch_fwd_table
mac_address SNMP, dot1dBridge
MIB
Port discovery_switch_fwd_table
MIB
Status discovery_switch_fwd_table
status SNMP, dot1dBridge
MIB
VLAN Id discovery_switch_fwd_table
vlan_id SNMP, dot1dBridge
MIB
Designatged Bridge discovery_switch_spanning_tree_table
designated_bridge_mac SNMP, dot1dBridge
MAC MIB
Designated Root discovery_switch_spanning_tree_table
designated_root SNMP, dot1dBridge
MIB
Port discovery_switch_spanning_tree_table
MIB
Port Enable discovery_switch_spanning_tree_table
port_enable SNMP, dot1dBridge
MIB
Port State discovery_switch_spanning_tree_table
port_state SNMP, dot1dBridge
MIB
Base IP address dscy_swtch_partition base_ip_address SNMP, dot1dBridge
MIB
Base MAC address dscy_swtch_partition base_mac_address SNMP, dot1dBridge
MIB
Base netmask dscy_swtch_partition base_netmask SNMP, dot1dBridge
MIB

Type dscy_swtch_partition type SNMP, dot1dBridge

MIB
Transparent dscy_swtch_partition transparent SNMP, dot1dBridge
MIB
Sourceroute dscy_swtch_partition sourceroute SNMP, dot1dBridge
MIB
Name dscy_swtch_partition name SNMP, dot1dBridge
MIB
Status dscy_swtch_partition status SNMP, dot1dBridge
MIB
Interface number dscy_swtch_partition interface_number SNMP, dot1dBridge
MIB
Type dscy_switchport type SNMP, dot1dBridge
MIB
Status dscy_switchport status SNMP, dot1dBridge
MIB
MAC address dscy_switchport mac_address SNMP, dot1dBridge
MIB
Port number dscy_switchport port_number SNMP, dot1dBridge
MIB
Interface name dscy_switchport interface_name SNMP, dot1dBridge
MIB
Interface number dscy_switchport interface_number SNMP, dot1dBridge
MIB
MAC address dscy_swtch_fwd_rule mac_address SNMP, dot1dBridge
MIB
MAC manufacturer dscy_swtch_fwd_rule mac_mfr SNMP, dot1dBridge
MIB
Status dscy_swtch_fwd_rule status SNMP, dot1dBridge
MIB
IP address dscy_swtch_fwd_rule ip_address SNMP, dot1dBridge
MIB
Netmask dscy_swtch_fwd_rule netmask SNMP, dot1dBridge
MIB
Required credentials
Discovery explores many kinds of devices, such as switches, routers, and printers, using the SNMP
protocol. Credentials for SNMP do not include a user name, just a password, which is 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.

Important: SSH is not supported.
Table 106: Data collected by Discovery on network routers and switches

Start date (only when cmdb_ci start_date SNMP, RFC1213 MIB
target is a host)
Can route IP cmdb_ci_netgear can_route SNMP, IP MIB, BGP
MIB
Can switch IP cmdb_ci_netgear can_switch SNMP, dot1dBridge
MIB
Can partition VLANs cmdb_ci_netgear can_partitionvlans SNMP, dot1dBridge
MIB
Can hub cmdb_ci_netgear can_hub SNMP, IP MIB
Neighbor Address discovery_device_neighbors
neighbor_address ciscoCdpMIB, lldpMIB
Neighbor ID discovery_device_neighbors
neighbor_id ciscoCdpMIB, lldpMIB
Neighbor Interface discovery_device_neighbors
neighbor_interface ciscoCdpMIB, lldpMIB
Neighbor Source discovery_device_neighbors
neighbor_source ciscoCdpMIB, lldpMIB
Origin Interface discovery_device_neighbors
origin_interface ciscoCdpMIB, lldpMIB
IP Address discovery_net_arp_table ip_address SNMP, IP MIB
MAC Address discovery_net_arp_table mac_address 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 next_hop_ip_address SNMP, IP MIB
Interface Index discovery_switch_bridge_port_table
interface_index SNMP, dot1dBridge
MIB

Port discovery_switch_bridge_port_table
MIB
MAC Address discovery_switch_fwd_table
mac_address SNMP, dot1dBridge
MIB
Port discovery_switch_fwd_table
MIB
Status discovery_switch_fwd_table
status SNMP, dot1dBridge
MIB
VLAN Id discovery_switch_fwd_table
vlan_id SNMP, dot1dBridge
MIB
Designatged Bridge discovery_switch_spanning_tree_table
designated_bridge_mac SNMP, dot1dBridge
MAC MIB
Designated Root discovery_switch_spanning_tree_table
designated_root SNMP, dot1dBridge
MIB
Port discovery_switch_spanning_tree_table
MIB
Port Enable discovery_switch_spanning_tree_table
port_enable SNMP, dot1dBridge
MIB
Port State discovery_switch_spanning_tree_table
port_state SNMP, dot1dBridge
MIB
Base IP address dscy_swtch_partition base_ip_address SNMP, dot1dBridge
MIB
Base MAC address dscy_swtch_partition base_mac_address SNMP, dot1dBridge
MIB
Base netmask dscy_swtch_partition base_netmask SNMP, dot1dBridge
MIB
Type dscy_swtch_partition type SNMP, dot1dBridge
MIB
Transparent dscy_swtch_partition transparent SNMP, dot1dBridge
MIB
Sourceroute dscy_swtch_partition sourceroute SNMP, dot1dBridge
MIB
Name dscy_swtch_partition name SNMP, dot1dBridge
MIB
Status dscy_swtch_partition status SNMP, dot1dBridge
MIB
Interface number dscy_swtch_partition interface_number SNMP, dot1dBridge
MIB
Type dscy_switchport type SNMP, dot1dBridge
MIB
Status dscy_switchport status SNMP, dot1dBridge
MIB

MAC address dscy_switchport mac_address SNMP, dot1dBridge

MIB
Port number dscy_switchport port_number SNMP, dot1dBridge
MIB
Interface name dscy_switchport interface_name SNMP, dot1dBridge
MIB
Interface number dscy_switchport interface_number SNMP, dot1dBridge
MIB
MAC address dscy_swtch_fwd_rule mac_address SNMP, dot1dBridge
MIB
MAC manufacturer dscy_swtch_fwd_rule mac_mfr SNMP, dot1dBridge
MIB
Status dscy_swtch_fwd_rule status SNMP, dot1dBridge
MIB
IP address dscy_swtch_fwd_rule ip_address SNMP, dot1dBridge
MIB
Netmask dscy_swtch_fwd_rule netmask SNMP, dot1dBridge
MIB
Load Balancer Data
Discovery uses the following SNMP MIBs to collect data for load balancers.
• F5-BIGIP-COMMON-MIB
• F5-BIGIP-LOCAL-MIB
• F5-BIGIP-SYSTEM-MIB
Discovery uses the following tables to store configuration records for load balancers.
Table 107: Tables used by Discovery for load balancers
Table Name Label Extends
cmdb_ci_lb Load Balancer Server [cmdb_ci_server]

cmdb_ci_lb_bigip F5 BIG-IP Load Balancer [cmdb_ci_lb]
cmdb_ci_lb_interface Load Balancer Interface Configuration Item [cmdb_ci]
cmdb_ci_lb_pool Load Balancer Pool Configuration Item [cmdb_ci]
cmdb_ci_lb_pool_member Load Balancer Pool Member Configuration Item [cmdb_ci]
cmdb_ci_lb_service Load Balancer Service Configuration Item [cmdb_ci]
cmdb_ci_lb_vlan Load Balancer VLAN Configuration Item [cmdb_ci]
cmdb_lb_service_vlan Load Balancer Service VLAN N/A
cmdb_lb_vlan_interface Load Balancer VLAN Interface N/A

Data Collected by Discovery on Load Balancers
Discovery collects the following information for load balancers.
Table 108: Data Collected by Discovery for load balancers
Table Name Field Name Label
cmdb_ci_lb operational_status Operational status

cmdb_ci_lb name Name
cmdb_ci_lb_bigip failover_mode Failover Mode
cmdb_ci_lb_bigip failover_peer Failover Peer
cmdb_ci_lb_bigip serial_number Serial Number
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 load_balance_method Load Balancing Method
cmdb_ci_lb_pool name Name
cmdb_ci_lb_pool_member ip_address IP Address
cmdb_ci_lb_pool_member pool Pool
cmdb_ci_lb_pool_member service_port Service Port
cmdb_ci_lb_service ip_address IP Address
cmdb_ci_lb_service load_balancer Load Balancer
cmdb_ci_lb_service port Port
cmdb_ci_lb_vlan load_balancer Load Balancer
cmdb_ci_lb_vlan tag Tag
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
Data collected by Discovery on relationships

Discovery identifies and classifies information about relationships between configuration items.

Relationships
Table 109: Data Collected by Discovery on Relationships
Parent cmdb_rel_ci parent Internal

Child cmdb_rel_ci child Internal
Type cmdb_rel_ci type Internal
Discovery for servers and network devices
Starting in Fuji, the Layer 3 BSM Discovery feature will map Layer 3 relationships between a server and
other network devices. The relationship begins at the router or switch and shows relationship and IP
address information for associated servers and network devices.
The system property glide.discovery.L3_mapping toggles the Layer 3 BSM discovery of these devices.
When glide.discovery.L3_mapping is true, the relationship created is of type IP Connection::IP Connection.
In this example, the BSM resulting from the discovery of Linux Server db14242 shows that it has an IP
Connection::IP Connection relationship to switch cor-001a.
Figure 107: BSM relationship between db14242 and MySQL servers
Prerequisites
• The server or network device needs to have IP Address information.

• The system property glide.discovery.L3_mapping is set to true to discover routers and switches.
• The router or Layer 3 switch that provides the IP Address needs to have been successfully discovered
with populated Exit Interface Routing Rules.

System Properties
Table 110: System Properties for logical mapping for the TCP/IP layer
glide.discovery.L3_mapping Starting in Fuji, provides a logical mapping of the

TCP/IP layer for network gears. This is not Layer
2 mapping.
• Type: string
• Default value:true
• Location: The System Property
Data collected by Discovery on services and daemons

Discovery identifies and classifies information about services and daemons.
Table 111: Data Collected by Discovery on Services and Daemons
Name cmdb_ip_service name Various

Port cmdb_ip_service port Various
Description cmdb_ip_service_ci description Various
CI cmdb_ip_service_ci ci Internal reference
Service cmdb_ip_service_ci service Internal reference
Data collected by Discovery on an uninterruptible power supply (UPS)

Discovery identifies and classifies information about an uninterruptible power supply (UPS).
Discovery can identify and classify uninterruptible power supplies.
Table 112: Data collected by Discovery on uninterruptible power supplies

Start date cmdb_ci start_date SNMP, RFC1213 MIB
UPS software version cmdb_ci_ups ups_software_version SNMP, UPS MIB
Agent software version cmdb_ci_ups agent_software_version SNMP, UPS MIB
Attached devices cmdb_ci_ups attached_devices SNMP, UPS MIB

Battery status cmdb_ci_ups battery_status SNMP, UPS MIB

Seconds remaining on cmdb_ci_ups seconds_on_battery SNMP, UPS MIB
battery
Estimated minutes cmdb_ci_ups est_mins_remaining SNMP, UPS MIB
remaining on battery
Estimated charge % cmdb_ci_ups est_charge_remaining SNMP, UPS MIB
remaining
Battery voltage cmdb_ci_ups battery_voltage SNMP, UPS MIB
Battery current cmdb_ci_ups battery_current SNMP, UPS MIB
Battery temperature (C) cmdb_ci_ups battery_temperature SNMP, UPS MIB
Input line bads cmdb_ci_ups input_line_bads SNMP, UPS MIB
Output source cmdb_ci_ups output_source SNMP, UPS MIB
Output frequency cmdb_ci_ups output_freq SNMP, UPS MIB
Bypass frequency cmdb_ci_ups bypass_freq SNMP, UPS MIB
Nominal input voltage cmdb_ci_ups nom_input_volt SNMP, UPS MIB
Nominal input cmdb_ci_ups nom_input_freq SNMP, UPS MIB
frequency
Nominal output voltage cmdb_ci_ups nom_output_volt SNMP, UPS MIB
Nominal output cmdb_ci_ups nom_output_freq SNMP, UPS MIB
frequency
Rated output VA cmdb_ci_ups rated_output_va SNMP, UPS MIB
Rated output power cmdb_ci_ups rated_output_power SNMP, UPS MIB
Low battery threshold cmdb_ci_ups low_battery_threshold_mins
SNMP, UPS MIB
minutes
Audible alarm status cmdb_ci_ups audible_alarm_status SNMP, UPS MIB
Low voltage transfer cmdb_ci_ups low_voltage_transfer_point
SNMP, UPS MIB
point
High voltage transfer cmdb_ci_ups high_voltage_transfer_point
SNMP, UPS MIB
point
Input index cmdb_ci_ups_input input_index SNMP, UPS MIB
Input frequency (Hz) cmdb_ci_ups_input input_freq SNMP, UPS MIB
Input voltage (RMS cmdb_ci_ups_input input_volt SNMP, UPS MIB
VAC)
Input current (RMS cmdb_ci_ups_input input_current SNMP, UPS MIB
AAC)
Input power (Watts) cmdb_ci_ups_input input_power SNMP, UPS MIB
Output index cmdb_ci_ups_output output_index SNMP, UPS MIB
Output load (%) cmdb_ci_ups_output output_load SNMP, UPS MIB

Output voltage (RMS cmdb_ci_ups_output output_volt SNMP, UPS MIB

VAC)
Output current (RMS cmdb_ci_ups_output output_current SNMP, UPS MIB
AAC)
Output power (Watts) cmdb_ci_ups_output output_power SNMP, UPS MIB
Bypass index cmdb_ci_ups_bypass bypass_index SNMP, UPS MIB
Bypass voltage (RMS cmdb_ci_ups_bypass bypass_volt SNMP, UPS MIB
VAC)
Bypass current (RMS cmdb_ci_ups_bypass bypass_current SNMP, UPS MIB
AAC)
Bypass power (Watts) cmdb_ci_ups_bypass bypass_power SNMP, UPS MIB
Alarm index cmdb_ci_ups_alarm alarm_index SNMP, UPS MIB
Alarm type cmdb_ci_ups_alarm alarm_type SNMP, UPS MIB
Alarm time cmdb_ci_ups_alarm alarm_time SNMP, UPS MIB
Dell Remote Assistant Card discovery

TM
The Dell Remote Assistant Card (DRAC) provides users with tools and functionality to monitor,
troubleshoot, and repair servers.
To identify the DRAC, Discovery uses the SNMP – DRAC probe. This probe uses SNMPv1 and SMNPv2c.
Data collected
Table 113: Data collected by Discovery for Dell DRAC
Firmware version cmdb_ci_outofband_device

firmware_version SNMP walk:
drsFirmwareVersion
(racFirmwareVersion
for iDRAC7)
1
Host cmdb_ci_outofband_device
host SNMP walk:
drsSystemServiceTag
(systemServiceTag for
iDRAC7) *
IP Address cmdb_ci_outofband_device
ip_address DNS probe
Name cmdb_ci_outofband_device
name SNMP - Identity probe
Product version cmdb_ci_outofband_device
product_version SNMP walk:
drsProductVersion
(racVersion for
iDRAC7)
Type cmdb_ci_outofband_device
type SNMP walk:
drsProductType
(racType for iDRAC7)

URL cmdb_ci_outofband_device
url SNMP walk:
drsProductURL
(racURL for iDRAC7)
Note: 1 Host is a reference to the cmdb_ci_computer table via the serial number. Therefore, in
order for the cmdb_ci_outofband_device.host field to be populated correctly, the host machine
needs to be discoverable or exist within the CMDB with the appropriate serial number.
IBM WebSphere DataPower device discovery

Discovery identifies and classifies information about DataPower devices.
Pattern
By default, Discovery uses the following pattern to perform the discovery: DataPower Server.
Credentials
Configure both SNMP credentials and Applicative credentials.
Classifier and OIDs
The DataPower Server classifier uses these OIDs:

OID Manufacturer Model Table
1.3.6.1.4.1.14685.1.3 IBM Data Power

Hosting Server
[cmdb_ci_datapower_server]
1.3.6.1.4.1.14685.1.8 IBM Data Power
Hosting Server
1.3.6.1.4.1.14685.1.4 IBM DataPower XB62 Data Power
Hosting Server
The classifier kicks off the Horizontal Pattern probe on page 223 to perform identification and exploration
of the device.
Data collected
The following data is collected on the Data Power Hosting Server [cmdb_ci_datapower_server]
table.
Label Field Name
Model name model_name

Host name host_name

Label Field Name
Serial number serial_number
The following data is collected on the Network Adapters [cmdb_ci_network_adapter] table.

Label Field Name
MAC address mac_address

Name name
Cisco Unified Computing System (UCS)-HD device discovery

Discovery identifies and classifies information about Cisco UCS equipment, including chassis and blades.
Cisco UCS pattern
By default, Discovery uses the following pattern to perform the discovery: UCS - HD.
Credentials for the Cisco UCS pattern
Configure both SNMP credentials and Applicative credentials.
SNMP classification and OIDs
Use the UCS classifier, or add an SNMP classifier and specify the Cisco UCS Equipment
[cmdb_ci_ucs_equipment] table. Then create these SNMP OIDs on the classifier:
OID Manufacturer Model Table
1.3.6.1.4.1.9.12.3.1.3.847Unified Computing 1.4(3u)(NX-OS) 5.0 Cisco UCS Equipment

Cisco UCS 6120XP Aggregation Switch
20-Port Fabric
Interconnect
1.3.6.1.4.1.9.12.3.1.3.899Unified Computing 1.4(3u)(NX-OS) 5.0 Cisco UCS Equipment
Cisco UCS 6140XP Aggregation Switch
40-Port Fabric
Interconnect
1.3.6.1.4.1.9.12.3.1.3.1062
Unified Computing 2.0(1t)(NX-OS) 5.0.2 Cisco UCS Equipment
Cisco UCS 6248UP Aggregation Switch
48-Port Fabric
Interconnect
1.3.6.1.4.1.9.12.3.1.3.1063
Unified Computing 2.0(1t)(NX-OS) 5.0.2 Cisco UCS Equipment
Cisco UCS 6296UP Aggregation Switch
96-Port Fabric
Interconnect

Data collected for Cisco UCS
Only B-series and C-series devices are discovered. The UCS - HD pattern does not find S or E series
devices. The following data is collected on the Cisco UCS Equipment [cmdb_ci_ucs_equipment]
table.
Label Field Name
Name name
Model model_id
Distinguished name dn
The following data is collected on the Cisco UCS Chassis [cmdb_ci_ucs_chassis] table.
Label Field Name
Name name
Model number model_number
Chassis ID chassis_id
Operational status operational_status
Operability operability
The following data is collected on the Cisco UCS Blade [cmdb_ci_ucs_blade] table.
Label Field Name
Name name
Model number model_number
CPU count cpu_count
CPU core count cpu_core_count
Ram ram
Number of Adapters number_of_adapters
Chassis ID chassis_id
Slot ID slot_id
Service ID server_id
Description short_description
The following data is collected on the Cisco UCS Rack Mount Units [cmdb_ci_ucs_rack_unit] table.

Label Field Name
Name name
Vendor vendor
Server ID server_id
Availability availability
UUID uuid
Rack serial rack_serial
Number of CPUs num_of_cpus
Number of cores num_of_cores
Number of adapters num_of_cpus
Model ID model_id
Total Memory total_memory
State state
Relationships
The following example shows the relationships between a Cisco UCS device, chassis, and blades:

Figure 108: Cisco UCS
Table 114:
CI Relationshp CI
cmdb_ci_ucs_chassis Contains::Contained by cmdb_ci_ucs_blade

cmdb_ci_ucs_equipment Contains::Contained by cmdb_ci_ucs_rack_unit
cmdb_ci_ucs_equipment Contains::Contained by cmdb_ci_ucs_chassis

Software Discovery
Discovery identifies several types of software.
Database catalog discovery

The database catalog lists all the catalog objects, or databases, discovered for an instance of a database.
Different database manufacturers use the term catalog differently. For example, MySQL uses database to
mean catalog.
Database catalogs can be imported into your instance from a third-party discovery tool, entered into the
platform manually, or found by Discovery.
Important: Discovery does not support Oracle or MySQL database catalog discovery in the base
system. You must create probes and sensors to find these.
To view a database catalog, navigate to Configuration > Database Catalogs and select a database.
Discovery with Software Asset Management Template

The table structure for managing software installations behaves differently when the Software Asset
Management Template application is activated.
The presence of this application affects the way Discovery stores the software installation data it returns
from a scan and require additional configuration within configuration item (CI) records.
The following tables are created when the Software Asset Management template plugin is activated:
• Software Discovery Model [cmdb_sam_sw_discovery_model]
• Software Model [cmdb_software_product_model]
• Software Installation [cmdb_sam_sw_install]
Note: The original schema used by previous versions is not affected when the Software Asset
Management plugin is not activated.
When it runs, Discovery populates the Software Installation [cmdb_sam_sw_install] table. The
appropriate configuration item (CI) references the software data. A business rule on this table runs,
searching for a matching record on the Software Discovery Model [cmdb_sam_sw_discovery_model]
table. If a record exists in the Software Discovery Model table, then the Software Installation table
updates the record. If no record exists in the Software Discovery Model table, then one is created. Data
from this table is then passed to the Software [cmdb_ci_spkg] table to preserve backward compatibility.
The Software Model [cmdb_software_product_model] table is not populated or used by Discovery.
Important: When SAM is installed, the Software Installation [cmdb_sam_sw_install] table is the
appropriate source for all current software data. This means you need to update any related lists
or customized reference fields you added to CI records.

Figure 109: Discovery and the Software Asset Management Template Table schema
Configure a CI to display Software Asset Management Template data

After you activate the Software Asset Management template plugin, configure the form for any computer CI
that you want to discover to show data from the Software Installation [cmdb_sam_sw_install] table.
1. Open any computer CI record.
2. Configure the form to add the Software Installation related list and remove the Software Installed
related list.
Discovery Application Mapping for UNIX

To perform the mapping that establishes application relationships, Discovery must be able to detect TCP
connections.
The best way to accomplish this is to run the lsof command on target machines. However, this command
is not available by default on Solaris and AIX machines. To return TCP connection information on these
machines, Discovery uses custom shell scripts. For Solaris, the shell script runs the pfiles command to
query each process. The pfiles command causes momentary pauses in the processes it queries on
Solaris target machines. These pauses can last from a few milliseconds to a few seconds, during which

no other processing can occur. To avoid pausing process threads, the ServiceNow ITSA Suite disables
active connection probes for Solaris machines in the base system, but can be configured to use these if
the pauses are not an issue. For AIX machines, Discovery is configured to use the active connection probe
for AIX targets. However, the user that executes the shell script on AIX machines might require additional
privileges to execute commands, such as kdb, employed in the script.
On Linux machines, Discovery uses the lsof command (installed by default on Linux) to detect TCP
connections. The Linux classification probe triggers the Linux - Active Connections probe, which uses
lsof to discover application relationships and does not produce any pauses. The lsof command is the
recommended method of returning active TCP connections and can be installed on Solaris and AIX target
machines to eliminate any issues produced by the shell script.
Note: Discovery of active connections on HP-UX is not supported.
Using the ServiceNow Shell Script

This procedure causes Discovery to run a shell script that uses the pfiles command to query processes
on a Solaris machine for active connection information. This procedure does not use the lsof command
to perform application mapping.
1. Navigate to Discovery Definition > CI Classification > UNIX.
2. Select Solaris from the list.
3. In the UNIX Classification form for Solaris, select the Triggers probes related list, and then click Edit.
4. Move Solaris - Active Connections from the Collections list to the Triggers probe List.

Figure 110: Solaris Active Connections
5. Click Save.

Using the lsof Command

Use the ls of command to return active TCP connections and can be installed on Solaris and AIX target
machines.
1. Install lsof on the Solaris and AIX machines on which you want to gather application relationship
data.
2. In the instance, navigate to Discovery Definition > CI Classification > UNIX.
3. Select Solaris from the list.
4. In the UNIX Classification form for Solaris, select the Triggers probes related list, and then click Edit.
5. Move Linux - Active Connections from the Collections list to the Triggers probe List.
This probe is configured to use lsof.

Figure 111: Solaris Active Connections lsof
6. Click Save.
7. Repeat this procedure for the AIX classification probe.

Data collected by Discovery on Apache web servers

Discovery identifies and classifies information about Apache web servers.
Starting in Fuji, Discovery can find information about Apache Web Servers. The Unix - Active Processes
probe captures the following information for Apache web servers. When the Apache web server process is
detected during discovery, if the mod_jk module or the Apache mod_proxy module is running on the target
Apache web server, additional probes trigger for each module. The probes gather configuration parameters
from each module configuration for additional sensor processing.
Table 115: Data Collected by Discovery on Apache Web Servers
Label Table Name Field Name Source Probe
Name cmdb_ci_apache_web_server
name apcfg Apache – Get
Configuration
Version cmdb_ci_apache_web_server
version httpd Apache – Version
Description cmdb_ci_apache_web_server httpd
short_description Apache – Get
Configuration
Add sudo access for the Unix - Active Processes Probe

For an Apache web server the Unix - Active Processes probe requires sudo privileges.
You can configure the Unix - Active Processes probe to elevate privileges.
1. Navigate to Discovery > Probes.
2. In the Search field, search for Unix - Active Processes.
3. Click field, search for Unix - Active Processes probe.
4. In the Probe Parameters related list, clickNew
5. Click New
6. Use the following information to fill out the form:
Probe Commands
Name must_sudo
Value true
7. Click Submit
Data collected by Mod_jk module

The Apache mod_jk module forwards requests from the Apache web server to a Servlet container, such as
Tomcat.
Additional mod_jk directives can also manage load balancing. Discovery populates the CMDB when it
detects an Apache Server. When the Apache Web Server process is detected, if the mod_jk module is
running on the web server as a load balancer, the related information populates to the CMDB.
• The MID Server user account to explore the target server must have access to the httpd.conf
configuration file in the /etc/httpd/conf/ folder.
• Discovery uses secure shell (SSH) commands to identify the following associated elements:
• Apache Get Configuration
• Apache Version

• Apache Get JK Module
• The following probes require execute privileges to run commands:
Table 116: Probes that require execute privileges
Probe Command
Apache – Get Configuration echo, sed, httpd, cut, grep, egrep (within the
Borne shell script)
Apache – Version httpd
Apache – Get JK Module echo, sed, httpd, cut, grep, egrep (within the
Borne shell script)
Probes and sensors
Discovery uses the Unix - Active Processes probe to identify an Apache server that contains the mod_jk
module:
1. The Unix - Active Processes probe detects a running process that matches one of the following
criteria:
• The name of the process is httpd.
• The name of the process is apache.
2. If there is a match on one of these criteria, a record is created in the Web Server table
[cmdb_ci_web_server] if one does not already exist for that running process. The following probes are
also triggered:
• Apache – Version: the sensor of this probe populates the Apache version information in the Web
Server record.
• Apache – Get Configuration: this probe contains a Bourne shell script and an argument that
determines the path of the Apache configuration file. The sensor of this probe populates some
additional information in the Web Server record.
3. The sensor processing of Apache – Get configuration probe results triggers the following probes if the
mod_jk module is running on the web server:
• Apache – JK Module: if the mod_jk module is running as a load balancer on the
server, the sensor of this probe populates the information in the Load Balancer Service
[cmdb_ci_lb_service], Load Balancer Pool [cmdb_ci_lb_pool] and Load Balancer Pool Member
[cmdb_ci_lb_pool_member] tables.
Data Collected
For the mod_jk module with no load balancer, the following data is collected by default:

Table 117: Default Data Collected by Discovery
Table Name Field and Label Name Probe
cmdb_ci_web_server Name [name] Apache – Get Configuration

cmdb_ci_web_server Version [version] Apache – Version
cmdb_ci_web_server Description [short_description] Apache – Version
If the mod_jk module is enabled for load balancing, Discovery connects the following data:
Table 118: Data Collected by Discovery When the

mod_jk Module is Identified as a Load Balancer
cmdb_ci_lb_appl Name [name] Apache – Apache - Get JK

Module
cmdb_ci_lb_appl IP Address [ip_address] Apache – Apache - Get JK
Module
cmdb_ci_lb_appl Last Discovered Apache – Apache - Get JK
[last_discovered] Module
cmdb_ci_lb_pool_member Name [name] Apache – Apache - Get JK
Module
cmdb_ci_lb_pool_member Last Discovered Apache – Apache - Get JK
cmdb_ci_lb_pool_member IP Address [ip_address] Apache – Apache - Get JK
Module
cmdb_ci_lb_pool_member Load Balancer [load_balancer] Apache – Apache - Get JK
Module
cmdb_ci_lb_pool_member Port [port] Apache – Apache - Get JK
Module
cmdb_ci_lb_service Input URL [Input_url] Apache – Apache - Get JK
Module
cmdb_ci_lb_service Last Discovered Apache – Apache - Get JK
cmdb_ci_lb_service IP Address [ip_address] Apache – Apache - Get JK
Module
cmdb_ci_lb_service Name [name] Apache – Apache - Get JK
Module
cmdb_ci_lb_service Load Balancer [load_balancer] Apache – Apache - Get JK
Module
cmdb_ci_lb_service Port [port] Apache – Apache - Get JK
Module
cmdb_ci_lb_pool Last Discovered Apache – Apache - Get JK

cmdb_ci_lb_pool Load balancing Method Apache – Apache - Get JK

[load_balancing_method] Module
cmdb_ci_lb_pool Load Balancer [load_balancer] Apache – Apache - Get JK
Module
cmdb_ci_lb_pool Name [name] Apache – Apache - Get JK
Module
Relationships
table:
• The records in the cmdb_ci_pool table are used by the cmdb_ci_service table record.
• The records in the cmdb_ci_pool_member table are members of the cmdb_ci_pool table.
Data collected by Mod_proxy module

The Apache mod_proxy module implements a proxy, gateway, or cache for the Apache web server.
An additional mod_proxy_balancer can also manage load balancing. Discovery populates the CMDB when
it detects an Apache server. When the Apache Web Server process is detected, if the mod_proxy module
is running on the web server as a load balancer the related information populates to the CMDB.
Consider the following requirements for discovering an Apache server that contains the mod_proxy
module:
• The MID Server user account to explore the target server must have access to the httpd.conf
configuration file in the /etc/httpd/conf/ folder.
• Discovery uses secure shell (SSH) commands to identify the following associated elements:
• Apache Get Configuration
• Apache Version
• Apache Get Proxy Module
• The following probes require execute privileges to run commands:
Table 119: Data collected from the mod_jk module
Probe Commands
Apache – Get Configuration echo, sed, httpd, cut, grep, egrep (within the
Borne shell script)
Apache – Get Proxy Module grep, egrep (within the Borne shell script)
Apache – Version httpd

Probes and sensors
Discovery uses the Unix - Active Processes probe to identify an Apache server that contains the
mod_proxy module. The probes and sensors operate in the following manner:
1. The Unix - Active Processes probe detects a running process that matches one of the following
criteria:
• The name of the process is httpd.
• The name of the process is apache2.
2. If there is a match on one of these criteria, a record is created in the Web Server table
[cmdb_ci_web_server] if one does not already exist for that running process. The following probes are
also triggered:
• Apache – Version: the sensor of this probe populates the Apache version information in the Web
server [cmdb_ci_web_server] record.
• Apache – Get Configuration: this probe contains a Bourne shell script and an argument that
determines the path of the Apache configuration file. The sensor of this probe populates some
additional information in the Web server [cmdb_ci_web_server] record.
3. The sensor processing of the Apache – Get configuration probe results triggers the following probes if
the mod_proxy module is running on the web server:
• Apache - Get Proxy Module: if the mod_proxy module is running as a load balancer on
the server, the sensor of this probe populates the information in the Load Balancer Service
[cmdb_ci_lb_service], Load Balancer Pool [cmdb_ci_lb_pool] and Load Balancer Pool Member
[cmdb_ci_lb_pool_member] tables.
Data Collected
For the mod_proxy module with no load balancer, the following data is collected by default:
Table 120: Data collected by Discovery by default
cmdb_ci_web_server Name [name] Apache – Get Configuration

cmdb_ci_web_server Version [version] Apache – Version
cmdb_ci_web_server Description [short_description] Apache – Version
If the mod_proxy module is enabled for load balancing, Discovery connects the following data:
Table 121: Data collected by Discovery if the

mod_proxy module is identified as a load balancer
cmdb_ci_lb_appl IP Address [ip_address] Apache - Get Proxy Module

cmdb_ci_lb_appl Last Discovered Apache - Get Proxy Module
[last_discovered]

cmdb_ci_lb_pool_member Name [name] Apache - Get Proxy Module

cmdb_ci_lb_pool_member Last Discovered Apache - Get Proxy Module
[last_discovered]
cmdb_ci_lb_pool_member IP Address [ip_address] Apache - Get Proxy Module
cmdb_ci_lb_pool_member Load Balancer [load_balancer[ Apache - Get Proxy Module
cmdb_ci_lb_pool_member Port [port] Apache - Get Proxy Module
cmdb_ci_lb_service Input URL [Input_url] Apache - Get Proxy Module
cmdb_ci_lb_service Last Discovered Apache - Get Proxy Module
[last_discovered]
cmdb_ci_lb_service IP Address [ip_address] Apache - Get Proxy Module
cmdb_ci_lb_service Name [name] Apache - Get Proxy Module
cmdb_ci_lb_service Load Balancer [load_balancer] Apache - Get Proxy Module
cmdb_ci_lb_service Port [port] Apache - Get Proxy Module
cmdb_ci_lb_pool Last Discovered Apache - Get Proxy Module
[last_discovered]
cmdb_ci_lb_pool Load balancing Method Apache - Get Proxy Module
[load_balancing_method]
cmdb_ci_lb_pool Load Balancer [load_balancer] Apache - Get Proxy Module
cmdb_ci_lb_pool Name [name] Apache - Get Proxy Module
Relationships
table:
• The records in the cmdb_ci_pool are members of the cmdb_ci_pool_member table records.
• The records in the cmdb_ci_pool_member is a member of the cmdb_ci_pool table records.
Discover an Amazon Web Services (AWS) cloud

A Discovery schedule can discover one or more AWS accounts.
The discovery of Amazon Web Services cloud is based on account information rather than an IP range.
MID Servers are not used in this type of discovery.
In AWS, a web service account is a master account that has many subscriptions, where each subscription
is a set of login credentials. Each subscription has views into the resources available in the master account
to that subscription. To discover the entire web service account, you must have the credentials for each
subscription.
To perform host-based discovery of the virtual hosts contained within an AWS Virtual Private Cloud (VPC):
• A MID server must be installed and configured on a node within the VPC.

• Each VPC that is discovered must have a separate discovery schedule for the IP addresses in that
VPC.
The account used for the AWS discovery scan needs the ReadOnlyAccess permissions policy applied to
it.
View the data collected
Navigate to AWS Discovery > Accounts> your AWS account.

The following tabs hold AWS information:
• EC2 Virtual Machine Instances
• AWS VPCs
• AWS Subnets
• AWS Elastic Load Balancers
• AWS EBS Volumes
• AWS Elastic Block Store Snapshots
Relationship between an EC2 instance and its host servers
When Discovery finds a Linux or Windows host, it determines if that host is running on an Amazon
Web Services (AWS) EC2 instance and then attempts to create a relationship between an
cmdb_ci_ec2_instance and the cmdb_ci_server CI.
Discovery gets EC2 instance information, such as instance ID, region, and account ID, from a host server
running on an EC2 instance when the host is discovered. Discovery then checks for a CI in the EC2 Virtual
Machine Instance [cmdb_ci_ec2_instance] table with matching information. If a match is found, Discovery
creates the Virtualized by::Virtualized relationship between that instance CI and the host CI.
Discovery launches these probes to establish the relationship:
• Linux - AWS Relationship: Discovery launches this probe for any Linux server discovered.
• Windows – AWS Relationship: Discovery launches this PowerShell probe for any Windows server
classified as 2008, or 2012.
Note: You can disable the collection of EC2 metadata by setting the
glide.discovery.discover_aws_ec2_host_metadata property to false. To access this property,
navigate to Discovery Definition > Properties and locate the property labeled When doing IP-
based discovery against a given host, also run probes that retrieve AWS EC2 metadata.
AWS Auto Scaling Group table
Table 122: Data Collected by Discovery for AWS Auto Scaling Group table
Account ID AWS Auto account_id AWS ASG -

Scaling Group DescribeAutoScalingGroups
[cmdb_ci_aws_asgrp]

Auto Scaling group AWS Auto resource_name AWS ASG -

ARN Scaling Group DescribeAutoScalingGroups
[cmdb_ci_aws_asgrp]
Correlation ID AWS Auto correlation_id AWS ASG -
[cmdb_ci_aws_asgrp]
Created time AWS Auto created_time AWS ASG -
[cmdb_ci_aws_asgrp]
Default cooldown AWS Auto default_cooldown AWS ASG -
[cmdb_ci_aws_asgrp]
Desired capacity AWS Auto desired_capacity AWS ASG -
[cmdb_ci_aws_asgrp]
Enabled metrics AWS Auto enabled_metrics AWS ASG -
[cmdb_ci_aws_asgrp]
Health check grace AWS Auto health_check_grace_period
AWS ASG -
period Scaling Group DescribeAutoScalingGroups
[cmdb_ci_aws_asgrp]
Health check type AWS Auto health_check_type AWS ASG -
[cmdb_ci_aws_asgrp]
Launch configuration AWS Auto launch_config AWS ASG -
[cmdb_ci_aws_asgrp]
Load balancers AWS Auto load_balancers AWS ASG -
[cmdb_ci_aws_asgrp]
Max size AWS Auto max_size AWS ASG -
[cmdb_ci_aws_asgrp]
Min size AWS Auto min_size AWS ASG -
[cmdb_ci_aws_asgrp]
Name AWS Auto name AWS ASG -
[cmdb_ci_aws_asgrp]
Region AWS Auto region AWS ASG -
[cmdb_ci_aws_asgrp]
Termination policies AWS Auto termination_policies AWS ASG -
[cmdb_ci_aws_asgrp]

VPC zone identifier AWS Auto Scaling vpc_zone_identifiers AWS ASG -

Group Launch Config DescribeAutoScalingGroups
[aws_asgrp_launch_cfg]
AWS Auto Scaling Group Launch Config table
Table 123: Data Collected by Discovery for AWS Auto Scaling Group Launch Config table
Account ID AWS Auto Scaling account_id AWS ASG -

Group Launch Config DescribeLaunchConfigurations
Associate Public IP AWS Auto Scaling associate_public_ip_addrAWS ASG -
Address Group Launch Config DescribeLaunchConfigurations
Block Device Mappings AWS Auto Scaling block_device_mappings AWS ASG -
Created time AWS Auto Scaling created_time AWS ASG -
EBS Optimized AWS Auto Scaling ebs_optimized AWS ASG -
Image ID AWS Auto Scaling image_id AWS ASG -
Instance Monitoring AWS Auto Scaling instance_monitoring AWS ASG -
Instance Type AWS Auto Scaling instance_type AWS ASG -
Kernel ID AWS Auto Scaling kernel_id AWS ASG -
Key Name AWS Auto Scaling key_name AWS ASG -
Launch Configuration AWS Auto Scaling resource_name AWS ASG -
ARN Group Launch Config DescribeLaunchConfigurations

Launch Configuration AWS Auto Scaling name AWS ASG -

Name Group Launch Config DescribeLaunchConfigurations
Ramdisk ID AWS Auto Scaling ramdisk_id AWS ASG -
Security Groups AWS Auto Scaling security_groups AWS ASG -
User data AWS Auto Scaling user_data AWS ASG -
AWS Availability Zone table
Table 124: Data Collected by Discovery for AWS Availability Zone table
Account ID AWS Availability Zone account_id AWS EC2 -

[aws_availability_zone] DescribeAvailabilityZones
Message AWS Availability Zone message AWS EC2 -
Region AWS Availability Zone region AWS EC2 -
Zone name AWS Availability Zone zone_name AWS EC2 -
Zone state AWS Availability Zone state AWS EC2 -
AWS EBS Volume table
Table 125: Data Collected by Discovery for AWS EBS Volume table
Account ID AWS EBS Volume account_id AWS EC2 -

[cmdb_ci_aws_ebs_volume] DescribeVolumes
Assigned to AWS EBS Volume assigned_to AWS EC2 -
Assignment group AWS EBS Volume assignment_group AWS EC2 -

Attachment status AWS EBS Volume attachment_status AWS EC2 -

Availability zone AWS EBS Volume availability_zone AWS EC2 -
Correlation ID AWS EBS Volume correlation_id AWS EC2 -
Delete On Termination AWS EBS Volume delete_on_termination AWS EC2 -
Device Name AWS EBS Volume device_name AWS EC2 -
Instance AWS EBS Volume instance AWS EC2 -
Name AWS EBS Volume name AWS EC2 -
Region AWS EBS Volume region AWS EC2 -
Snapshot AWS EBS Volume snapshot AWS EC2 -
Volume ID AWS EBS Volume volume_id AWS EC2 -
Volume IOPs AWS EBS Volume volume_iops AWS EC2 -
Volume size (GiBs) AWS EBS Volume volume_size AWS EC2 -
Volume status AWS EBS Volume volume_status AWS EC2 -
Volume type AWS EBS Volume volume_type AWS EC2 -
AWS Elastic Block Store Snapshot table
Table 126: Data collected by Discovery on an AWS Elastic Block Store Snapshot table
Account ID AWS Elastic Block account_id AWS EC2 -

Store Snapshot DescribeSnapshots
[aws_ebs_snapshot]
Name AWS Elastic Block name AWS EC2 -
[aws_ebs_snapshot]

Owner ID AWS Elastic Block owner_id AWS EC2 -

[aws_ebs_snapshot]
Progress AWS Elastic Block progress AWS EC2 -
[aws_ebs_snapshot]
Region AWS Elastic Block region AWS EC2 -
[aws_ebs_snapshot]
Short description AWS Elastic Block short_description AWS EC2 -
[aws_ebs_snapshot]
Snapshot ID AWS Elastic Block snapshot_id AWS EC2 -
[aws_ebs_snapshot]
Snapshot size (GB) AWS Elastic Block snapshot_size AWS EC2 -
[aws_ebs_snapshot]
Start time AWS Elastic Block start_time AWS EC2 -
[aws_ebs_snapshot]
State AWS Elastic Block state AWS EC2 -
[aws_ebs_snapshot]
Volume ID AWS Elastic Block volume_id AWS EC2 -
[aws_ebs_snapshot]
AWS Elastic Load Balancer table
Table 127: Data Collected by Discovery on AWS Elastic Load Balancer table
Account ID AWS Elastic account_id AWS ELB -

Load Balancer DescribeLoadBalancers
[cmdb_ci_aws_elb]
Canonical hosted zone AWS Elastic canonical_hosted_zone_name
AWS ELB -
name Load Balancer DescribeLoadBalancers
[cmdb_ci_aws_elb]
Canonical hosted zone AWS Elastic canonical_hosted_zone_name_id
AWS ELB -
name ID Load Balancer DescribeLoadBalancers
[cmdb_ci_aws_elb]

Comments AWS Elastic comments AWS ELB -

[cmdb_ci_aws_elb]
Correlation ID AWS Elastic correlation_id AWS ELB -
[cmdb_ci_aws_elb]
Created time AWS Elastic created_time AWS ELB -
[cmdb_ci_aws_elb]
DNS Domain AWS Elastic dns_domain AWS ELB -
[cmdb_ci_aws_elb]
DNS name AWS Elastic dns_name AWS ELB -
[cmdb_ci_aws_elb]
Instances AWS Elastic instance AWS ELB -
[cmdb_ci_aws_elb]
Name AWS Elastic name AWS ELB -
[cmdb_ci_aws_elb]
Region AWS Elastic region AWS ELB -
[cmdb_ci_aws_elb]
Scheme AWS Elastic scheme AWS ELB -
[cmdb_ci_aws_elb]
Security groups AWS Elastic security_groups AWS ELB -
[cmdb_ci_aws_elb]
Source security groups AWS Elastic source_security_group AWS ELB -
[cmdb_ci_aws_elb]
Subnets AWS Elastic subnet AWS ELB -
[cmdb_ci_aws_elb]
VPC AWS Elastic vpc AWS ELB -
[cmdb_ci_aws_elb]

AWS Resource table
Table 128: Data Collected by Discovery for AWS Resource table
Account ID AWS Resource account_id AWS CF -

[cmdb_ci_aws_resource] ListStackResources
Logical ID AWS Resource logical_id AWS CF -
Name AWS Resource name AWS CF -
Region AWS Resource region AWS CF -
Resource ID AWS Resource resource_id AWS CF -
AWS Subnet table
Table 129: Data Collected by Discovery for AWS Subnet table
Account ID AWS Subnet account_id AWS EC2 -

[cmdb_ci_aws_subnet] DescribeSubnets
Availability zone AWS Subnet availability_zone AWS EC2 -
Available IP address AWS Subnet available_ip_address_count
AWS EC2 -
count [cmdb_ci_aws_subnet] DescribeSubnets
CIDR block AWS Subnet cidr_block AWS EC2 -
Correlation ID AWS Subnet correlation_id AWS EC2 -
Default for region AWS Subnet default_for_az AWS EC2 -
Map public IP on AWS Subnet map_public_ip_on_launchAWS EC2 -
launch [cmdb_ci_aws_subnet] DescribeSubnets
Name AWS Subnet name AWS EC2 -
Region AWS Subnet region AWS EC2 -
Subnet ID AWS Subnet subnet_id AWS EC2 -

Subnet state AWS Subnet state AWS EC2 -

VPC AWS Subnet vpc_id AWS EC2 -
AWS VPCs table
Table 130: Data Collected by Discovery for AWS VPCs table
Account ID AWS VPCs account_id AWS EC2 -

[cmdb_ci_aws_vpc] DescribeVpcs
CIDR block AWS VPCs cidr_block AWS EC2 -
Correlation ID AWS VPCs correlation_id AWS EC2 -
Default AWS VPCs is_default AWS EC2 -
DHCP options ID AWS VPCs dhcp_options_id AWS EC2 -
Instance tenancy AWS VPCs instance_tenancy AWS EC2 -
Name AWS VPCs name AWS EC2 -
Region AWS VPCs region AWS EC2 -
VPC ID AWS VPCs vpc_id AWS EC2 -
VPC state AWS VPCs state AWS EC2 -
AWS VPC Security Group table
Table 131: Data Collected by Discovery for AWS VPC Security Group table
Account ID AWS VPC account_id AWS EC2 -

Security Group DescribeSecurityGroups
[aws_vpc_security_group]

Correlation ID AWS VPC correlation_id AWS EC2 -

Description AWS VPC description AWS EC2 -
Group ID AWS VPC group_id AWS EC2 -
Group name AWS VPC group_name AWS EC2 -
Name AWS VPC name AWS EC2 -
Region AWS VPC region AWS EC2 -
VPC AWS VPC vpc AWS EC2 -
EC2 Image table
Table 132: Data Collected by Discovery for EC2 Image table
Account ID EC2 Image account_id AWS EC2 -

[ec2_image] DescribeImages
Architecture EC2 Image architecture AWS EC2 -
Description EC2 Image description AWS EC2 -
Image ID EC2 Image image_id AWS EC2 -
Image location EC2 Image image_location AWS EC2 -
Kernel ID EC2 Image kernel_id AWS EC2 -
Location EC2 Image location AWS EC2 -
Manufacturer EC2 Image manufacturer AWS EC2 -

Name EC2 Image name AWS EC2 -

Platform EC2 Image platform AWS EC2 -
Public EC2 Image is_public AWS EC2 -
Ramdisk ID EC2 Image ramdisk_id AWS EC2 -
Region EC2 Image region AWS EC2 -
Root device type EC2 Image root_device_type AWS EC2 -
State EC2 Image state AWS EC2 -
Virtualization EC2 Image virtualization AWS EC2 -
EC2 Key Pairs table
Table 133: Data Collected by Discovery for EC2 Key Pairs table
Account ID EC2 Key Pairs account_id AWS EC2 -

[ec2_keypairs] DescribeKeyPairs
Finger print EC2 Key Pairs finger_print AWS EC2 -
Name EC2 Key Pairs name AWS EC2 -
Region EC2 Key Pairs region AWS EC2 -
EC2 Virtual Machine Instance table
When Discovery determines that a Linux or Windows host is running on an AWS EC2 instance, Discovery
creates a Virtualized by::Virtualized relationship between the cmdb_ci_ec2_instance record and the host.
Table 134: Data Collected by Discovery for EC2 Virtual Machine Instance table
Account ID EC2 Virtual account_id AWS EC2 -

Machine Instance DescribeInstances
[cmdb_ci_ec2_instance]

Availability zone EC2 Virtual availability_zone AWS EC2 -

Category EC2 Virtual category AWS EC2 -
Correlation ID EC2 Virtual correlation_id AWS EC2 -
DNS Domain EC2 Virtual dns_domain AWS EC2 -
IP Address EC2 Virtual ip_address AWS EC2 -
Key pair EC2 Virtual key_pair AWS EC2 -
Manufacturer EC2 Virtual manufacturer AWS EC2 -
Name EC2 Virtual name AWS EC2 -
Region EC2 Virtual region AWS EC2 -
Root Device Name EC2 Virtual root_device_name AWS EC2 -
Root Device Type EC2 Virtual root_device_type AWS EC2 -
State EC2 Virtual state AWS EC2 -
Subnet ID EC2 Virtual subnet_id AWS EC2 -
VPC ID EC2 Virtual vpc_id AWS EC2 -

Clustered application discovery on Windows

A process and its corresponding resource information can be used to determine whether the process is a
clustered process.
The Microsoft SQL Server process classifier that comes with your instance identifies clustered SQL
Servers. You can leverage the same technique to detect other clustered applications on Windows using
Discovery.
To detect Windows clustered applications with Discovery, you create a process classifier that detects
whether a process is a clustered process. Perform the following steps:
Create a classifier for clustered processes
To detect Windows clustered applications, create a process classifier for that CI type.
1. Navigate to Discovery Definition > CI Classification > Processes.
2. Click New.
3. Fill out the form using the fields from the table.
4. Click Submit.


Table 135: Process classification form
Field Description
Name A unique name for the process classifier.

Table Select Application.
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.
• Cluster of::Cluster: Defines the
relationship of a cluster node to
the cluster to which it belongs. This
relationship is expressed from the
perspective of the cluster node and of
the cluster.
• Hosted on::Hosts: Defines the
relationship of a cluster node and the
Windows host. This relationship is
expressed from the perspective of the
cluster node and of the Windows host.
Active Select this box to activate the process

classification. Deselect to deactivate it.

Field Description
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 the 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.
Condition Configure the appropriate condition. The
example screenshot triggers this process
classification when the process command
contains the string MSFT SQL Server 2000.
Relate the process classifier to Windows cluster resources

In the second step, relate the process classifier to the information that is in the Windows Cluster resources
table.
The Windows Cluster resources table is cmdb_ci_win_cluster_resource. This relationship is built through
JavaScript.
1. Navigate back to the process classification you just made.
2. Click the Parameters tab.
3. Click New.
4. Fill out the fields on the form as appropriate (see table).
5. Click Submit.
Figure 113: Classifier parameter
form

Table 136: Classifier parameter form
Field Description
Name Select a unique name.

Application Select Global.
Type Enter Cluster.
Value This field defines two JavaScript objects,
called resourceType and isMatch. For
more information, see Populate the Value
field on the Classifier Parameter form on
page 397.
Populate the Value field on the Classifier Parameter form

The value field defines two JavaScript objects, called resourceType and isMatch.
The resourceType value refers to the Resource Type column in the Windows Cluster Resources table
[cmdb_ci_win_cluster_resource]. The resourceType value can not be empty or null.
1. Navigate to a Windows cluster page to access the Windows Cluster Resources table.
2. Click the Windows Cluster Resources tab.
The isMatch value evaluates whether the process is a clustered process.

• An evaluation that returns true indicates the process is a clustered application, and the
process is classified as a clustered application in the cluster.
• An evaluation that returns false classifies the process as a regular application running
on the cluster node.
The isMatch value is a function that contains two input variables, process and resource:
• process: Process is the GlideRecord of the process application. It is determined by
the Table field in the classifier. In this example, it is the GlideRecord entry of the
Application table (cmdb_ci_app) for the process that is being classified. You have
access to any field values for the CI type such as name or version.
• resource: Resource is the GlideRecord entry in the Windows Cluster Resource
table after the resourceType condition has been applied. In the example, it is the
GlideRecord entry of the sixth row.
Examples of JavaScript for the Value field

In the following example code: resourceType: "SQL Server" the query filters the Windows
Cluster Resources table entry for the Resource Type field that has a value that is equal to
SQL Server. In the following example table, the sixth record would be returned.
The following script indicates that if there is a resource of type SQL Server, the process is
classified as a clustered application.
resourceType: "SQL Server"

isMatch: function(process, resource) {
return true;
}

The following script indicates that if if there is a resource of type SQL Server, and the
application name is equal to the resource name, then the process is classified as a
clustered application.
resourceType: "SQL Server"

if (process.name == resource.name)
return true;
}
If there are multiple matches to the resourceType condition, the matching function is
called multiple times. For the following resourceType example, the matching function is
called twice because there are two entries that have Physical Disk in the Resource Type
column in the sample Windows Cluster Resources table.
resourceType: "Physical Disk"
Figure 114: Windows Cluster Resources
tab
Data collected by Discovery on general software packages

Discovery identifies and classifies information about general software packages.
Table 137: Data collected by Discovery on General Software Packages
Name cmdb_ci_spkg name Various

Version cmdb_ci_spkg version Various

Install count cmdb_ci_spkg install_count Various

License count cmdb_ci_spkg license_count Various
Microsoft SMS ID cmdb_ci_spkg msft_sms_id Various
Installed on cmdb_software_instance installed_on Various
Software cmdb_software_instance software Various
Microsoft IIS server discovery

Discovery identifies and classifies information about Microsoft IIS servers.
Table 138: Data collected by Discovery on Microsoft IIS servers
Version cmdb_ci_microsoft_iis_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.
Microsoft SQL server discovery

Discovery uses the SQL SMO object to get information about all Microsoft SQL Server instances running
on the same system.
Requirements
The Microsoft SQL Server probe is triggered by a running process that has a command that contains
sqlservr.exe.
MID Server Host
• Install .Net 3.5 and 4 from Microsoft

• Install the latest version of the Microsoft SQL Server management library (SMO).
Note: The SMO requires the Common Language Runtime (CLR) library to be installed first.
Both libraries can be downloaded from the Microsoft website.
• Install PowerShell v2.0 and above.

Microsoft SQL Server Host
• Install the Remote Registry Service on target computers running Microsoft SQL Server.
Credentials
• Add valid Windows credentials (type=Windows) to the Discovery Credentials table.

• Ensure credentials have the public access level to the following:
• The target Windows host.
• The Microsoft SQL Server instance on the target Windows host. You must add the user to the SQL
Server configuration.
• The MID Server host. The SMO libraries locally impersonate the credentials for the target system
prior to connecting to the Microsoft SQL Server. This behavior is enforced by Active Directory.
Authentication only succeeds if the domain requirements specified here are met.
• Role: On MS SQL 2014, the sysadmin role must be assigned to the user to obtain the instance
version. The public role does not have permission to retrieve the instance version.
Note: If there are no matching discovery credentials, probes may attempt to connect using the MID
Server service credentials. The MID Server service credentials are only valid if the MID Server host
is on same domain as the Microsoft SQL Server host.
Domains
• Install the MID Server host and the Microsoft SQL Server host on the same domain or, if they are on
different domains, enable a trust relationship between the domains such that users in the Microsoft SQL
Server host domain are trusted by the MID Server host domain.
• If a domain trust relationship is in place, do not install the MID Server on a domain controller.
Process classifiers
For Powershell version 2 or later, the MID Server must be within the same domain that it is trying to
discover.
Discovery collects data from the following versions:
Table 139:
Edition Version name
Microsoft SQL Server • 2000

• 2005
• 2008
• 2012

Edition Version name
Microsoft SQL Express • 2005

• 2008
• 2012
Dictionary entries
The running processes of the database (the actual SQL server) is referred to as the database instance.
Discovery writes the following information to the MSFT SQL instance [cmdb_ci_db_mssql_instance] table.
Table 140: Dictionary entries
Label Field name
Name Name
Instance instance_name
TCP port tcp_port
Portdynamic port_dynamic
Version name version_name
Edition edition
Version version
Engine edition engine_edition
For SQL2000 servers, Discovery can match instance names to their process ID. The database is referred
to as the catalog. The following data is collected in the MSFT SQL Catalog [cmdb_ci_db_mssql_catalog]
table:
Label Field name
Name name
Status status
Note: You can find the data for the actual server on which the MSSQL instance and catalogs
resides in the Windows computer [cmdb_ci_win_server].
Microsoft SQL Server cluster Discovery

Discovery identifies Microsoft SQL Server instances that are part of a cluster in the CMDB by the cluster
name rather than as individual configuration items (CI).
An SQL Server instance that is part of a cluster is listed as a related item in the CI record for the server that
hosts the instance with a Runs::Runs on relationship.


Viewing discovered 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:
1. Add the Cluster Nodes related list to the form. This list displays the name of the node and the parent
cluster.


2. Click the cluster name 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 host name with the @ symbol. In this example,
MSSQLCLUSTER is the SQL Server instance name, and cluster-node2 is the name of the Windows
host (not the Windows cluster).


3. Click the name of the SQL Server instance in the Related Items list to open the record for that CI.
The instance name is expressed in the format instance@host name and displays the relationship
hierarchy to the configured number of levels, including the system databases that the instance uses,
the cluster on which the instance runs, and the server on which the cluster runs.


Figure 117: SQL instance CI record
Defining a clusterable process
1. Open the desired process classifier (Discovery Definition > CI Classification > Process).
2. Add the Parameters related list (if not visible).
3. Click New in the Parameters related list and add a new parameter, using the following values:
• Name: Unique name of your choosing.
• Type: Enter Cluster.
• Value: Enter the following statement.
resourceType: "Resource Type",

//javascript function that returns true if a resource matches the
classified process
}
Table 141: Defining Clusterable Processes
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.

Figure 118: SQL Cluster Parameter
MySQL discovery
Discovery creates or updates a CMDB record when it detects a running instance of MySQL on UNIX or
Windows systems.
Discovery searches for the MySQL configuration file location from the following areas:
• UNIX: Discovery searches for the MySQL configuration file location from the Mysqld process, or port
3306.
• Windows: Discovery searches for the MySQL configuration file location from the Mysqld.exe process, or
port 3306.
For each process, the following process parameters are explored in the following order:
--defaults-extra-file
--defaults-file
If the MYSQL configuration file location is not found from that search, then the following occurs:
• UNIX: The configuration file location defaults to /etc/my.cnf.

• Windows: No default configuration file location exists, and the probe to read the configuration file
location is skipped.
Table 142: Data collected by Discovery on MySQL servers
MySQL configuration cmdb_ci_db_mysql_instance

myconf my.cnf
TCP port(s) cmdb_ci_db_mysql_instance
tcp_port running_process
Version cmdb_ci_db_mysql_instance
version mysqld
Discover MongoDB instances

Discovery creates or updates a CMDB record when it detects a running instance of MongoDB.
Table 143: Data Collected by Discovery on MongoDB instances
Version cmdb_ci_db_mongodb_instance
version mongod (UNIX) or
mongod.exe (Windows)
Mongo configuration cmdb_ci_db_mongodb_instance
mongodb_conf mongod.conf
TCP port(s) cmdb_ci_db_mongodb_instance
tcp_port Process Classification
or mongod.conf
PostgreSQL discovery
Discovery creates or updates a CMDB record when it detects a running instance of PostgreSQL on UNIX
systems.
Credentials and other prerequisites
These credentials are required:

• SSH credentials
The user must have root-level access to the database to access the postgresql.conf file.
Classifiers, patterns, and probes
Classifier Trigger probes
PostgreSQL Instance • PostgreSQL - Configuration (add the must_sudo

parameter to this probe)
• PostgreSQL - Version

Data collected
Table 144: Data Collected by Discovery on PostgreSQL instances
Name cmdb_ci_db_postgresql_instance
name PostgreSQL
Instance@hostname
Data Directory cmdb_ci_db_postgresql_instance
data_dir running process
TCP port cmdb_ci_db_postgresql_instance
SQL Configuration cmdb_ci_db_postgresql_instance
postgres_conf data_directory/
postgresql.conf
Version cmdb_ci_db_postgresql_instance
version postmaster/postgres
NGINX web server discovery

NGINX is an open source web server with a load balancer. Discovery identifies the web server and
information related to the load balancer.
Discovery identifies NGINX server software using the following process:
1. The NGINX Process Classifier detects a running process that matches the following criteria during the
exploration of a Linux server:
• Name starts with nginx
• Name contains master
2. If there is a match:
• A record is created in the NGINX Web Server [cmdb_ci_nginx_web_server] table.
• A Runs on relationship is created in the CI Relationship [cmdb_rel_ci] table for a Linux server
(Linux Server [cmdb_ci_linux_server]) and for an NGINX web server (NGINX Web Server
[cmdb_ci_nginx_web_server]) .
The following two probes are triggered:
• NGINX – Version: This probe contains a Bourne shell script. It determines the version of NGINX and
populates the NGINX Web Server [cmdb_ci_nginx_web_server] table.
• NGINX – Get Configuration: This probe contains a Bourne shell script and an argument that
determines the path of the NGINX configuration file. The probe identifies configuration parameters
based on keywords within the configuration file and returns them as a single payload result.
The sensor on the ServiceNow instance parses the payload result and populates the CMDB.
You must have the following requirements to discover an NGINX webserver:

• NGINX is installed and running on the server.
• The MID Server has access to the NGINX configuration file, which is /etc/nginx/nginx.conf by
default.
Requirements
For NGINIX servers:

• Ensure that the NGINX software is installed and running on the server.
• Grant the MID Server has access to the NGINX configuration file, which is /etc/nginx/nginx.conf
by default.
• Enable secure shell (SSH) commands to identify the following associated elements:
• NGINX Version
• NGINX Get Configuration
The following probes require execute privileges to run commands:
Table 145: Commands
Probe Commands
Nginx – Version nginx

Nginx – Get Configuration echo, sed, httpd, cut, grep, egrep (within the
Bourne shell script)
Probes and Sensors
Discovery identifies NGINX server software using the following process:

1. The Nginx Process Classifier detects a running process that matches the following criteria during the
exploration of a UNIX server:
• The name of the process starts with nginx.
• The name of the process contains master.
2. If there is a match:
• A record is created in the Web Server [cmdb_ci_web_server] table.
• A Runs on relationship is created in the CI Relationship [cmdb_rel_ci] table for the Linux Server
[cmdb_ci_linux_server] table and the Web Server [cmdb_ci_web_server] table.
3. The following two probes are triggered:

• Nginx – Version: this probe contains a Bourne shell script. It determines the version of NGINX and
populates the Web Server [cmdb_ci_web_server] table.
• Nginx – Get Configuration: this probe contains a Bourne shell script and an argument that
determines the path of the NGINX configuration file. The probe identifies configuration parameters
based on keywords within the configuration file and returns them as a single payload result.
4. The sensor on the ServiceNow instance processes the payload and populates the CMDB.
Data Collected
Discovery creates or updates CMDB records when it detects a running NGINX process. The following data
is collected.

Table 146: Data Collected by Discovery for NGINX
Name cmdb_ci_lb_appl [name] Nginx– Get Configuration

IP Address cmdb_ci_lb_appl [ip_address] Nginx– Get Configuration
Last Discovered cmdb_ci_lb_appl Nginx– Get Configuration
[last_discovered]
Version cmdb_ci_lb_appl [version] Nginx– Version
Name cmdb_ci_lb_pool_member Nginx– Get Configuration
[name]
Last Discovered cmdb_ci_lb_pool_member Nginx– Get Configuration
[last_discovered]
IP Address cmdb_ci_lb_pool_member Nginx– Get Configuration
[ip_address]
Load Balancer cmdb_ci_lb_pool_member Nginx– Get Configuration
[load_balancer]
Fully Qualified Domain Name cmdb_ci_lb_pool_member Nginx– Get Configuration
[fqdn]
Port cmdb_ci_lb_pool_member Nginx– Get Configuration
[port]
Last Discovered cmdb_ci_lb_service Nginx– Get Configuration
[last_discovered]
IP Address cmdb_ci_lb_service Nginx– Get Configuration
[ip_address]
Name cmdb_ci_lb_service [name] Nginx– Get Configuration
Load Balancer cmdb_ci_lb_service Nginx– Get Configuration
[load_balancer]
Input URL cmdb_ci_lb_service [input_url] NGINX – Get Configuration
Relationships
In the table [cmdb_rel_ci] the following relationships are populated:

• The records in the cmdb_ci_pool_member table are members of cmdb_ci_pool table.
Oracle database discovery

Discovery can identify an Oracle database instance that is running on UNIX or Windows operating
systems.

UNIX operating system requirements
In the UNIX operating system

• Discovery requires credentials that allow read permission to the oratab file.
• Discovery requires credentials that allow read permission to the System Parameter file.
• Discovery identifies a running instance of an Oracle database from the process that starts with
ora_pmon_. Ensure this process is running in the IP range you designate.
Windows operating system requirements
In the Windows operating system

• Discovery requires credentials that allow read permission to the System Parameter file.
• Discovery identifies a running instance of an Oracle database from the oracle.exe process. Ensure this
process is running in the IP range you designate.
UNIX operating system
The following data is collected by Discovery for an Oracle database instance running on the UNIX
operating system.
SID (UNIX) cmdb_ci_db_ora_instancesid Extracts SID from

the name of the
process that starts with
ora_pmon_
Version cmdb_ci_db_ora_instanceversion Tries to extract the
version in this order
• From the output of
the ORA_HOME/
bin/sqlplus /
NOLOG command
• From the output of
the ORA_HOME/
bin/lsnrctl
status command
• From the path of
ORA_HOME
Oracle Home cmdb_ci_db_ora_listeneroracle_home From the ORATAB file

System Parameter File cmdb_ci_db_ora_instancespfile The following locations

(SPfile) are explored for the
location of the System
Parameter File. If this
file does not exist in
one of the explored
locations, Discovery
does not find the file
and reports an error.
• oracle_home/dbs/
spfileSID.ora
spfile.ora
initSID.ora
Windows operating system
The following data is collected by Discovery for an Oracle database instance running on the Windows
operating system.
SID (Windows) cmdb_ci_db_ora_instancesid Extracts SID from the

process parameter
that is passed to the
oracle.exe process
Version cmdb_ci_db_ora_instanceversion From the output of
the ORA_HOME/bin/
sqlplus.exe -V
command
Oracle Home cmdb_ci_db_ora_listeneroracle_home Parsed from the path of
oracle.exe

System Parameter File cmdb_ci_db_ora_instancespfile The following locations

(SPfile) are explored for the
location of the System
Parameter File. If this
file does not exist in
one of the explored
locations, Discovery
does not find the file
and reports an error.
• oracle_home\database
\spfileSID.ora
\spfile.ora
\initSID.ora
Puppet automation software discovery

Discovery identifies Puppet Masters running on UNIX servers.
Discovery uses secure shell (SSH) commands to collect information.
To access Puppet Master records, navigate to Configuration > Automation Servers > Puppet Masters.
You can view the resources in the related list of the Puppet Master record.
How the Puppet Master probe works
Discovery identifies the Puppet Master using the following process:

1. The UNIX - Active Processes probe detects a running process that matches one of the following
criteria:
• The name of the process is pe-httpd.
• The name of the process is ruby and the parameters of the process contain puppet master.
2. If there is a match on one of these criteria:

• A record is created in the Puppet Master table [cmdb_ci_puppet_master] if one does not already
exist for that running process.
• The Puppet - Master Info probe is triggered. The sensor of this probe populates additional
information in the Puppet Master [cmdb_ci_puppet_master] record.
3. With the activation of the Puppet Configuration Management plugin, the sensor processing of
Puppet - Master Info triggers the following simultaneously:
• Puppet – Certificate Requests: The sensor of this probe populates the Puppet Certificate Request
[puppet_certificate_request table] with open requests. Open requests are requests that are not
already signed or rejected.
• MultiProbe Puppet – Resources: This probe contains the following probes:
• Puppet – Module: The sensor of this probe populates records within the Puppet Module
[puppet_module] table.

• Puppet – Manifests: The sensor of this probe populates records within the Puppet Manifest
[puppet_manifest], Puppet Class [puppet_class], and Puppet Parameter [puppet_parameter]
tables.
Requirements to discover a Puppet master
By default, Discovery identifies Puppet Masters running on UNIX servers. Discovery uses secure shell
(SSH) commands to collect information.
With the addition of the Puppet Configuration Management plugin, Discovery identifies the following
associated elements:
• Puppet Certification Requests
• Puppet Manifests
• Puppet Modules
The credentials used to discover the UNIX server must have privileges to execute the following commands.
The use of sudo is supported, but you must add the must_sudo parameter to the probe.
Probe Commands
Puppet – Master Info puppet, echo, hostname (within the Borne shell
script)
Puppet – Certificate Requests puppet
Puppet – Manifests echo, sed, find (within the Bourne shell script)
Puppet – Modules puppet
Data collected
Table 147: Data collected by Discovery for Puppet automation software, by default
Name Puppet Master name Puppet - Master Info

[cmdb_ci_puppet_master]
Configuration directory Puppet Master config_directory Puppet - Master Info
Manifest directory Puppet Master manifestdir Puppet - Master Info
Module path Puppet Master modulepath Puppet - Master Info
Fully qualified domain Puppet Master fqdn Puppet - Master Info
name [cmdb_ci_puppet_master]
IP Address Puppet Master ip_address Puppet - Master Info

Version Puppet Master version Puppet - Master Info

Table 148: Data collected by Discovery for Puppet automation

software, with the Puppet Configuration Management plugin
Name Module name Puppet - Modules

[puppet_module]
Path Module path Puppet - Modules
[puppet_module]
Name Manifest name Puppet - Manifests
[puppet_manifest]
Path Manifest path Puppet - Manifests
[puppet_manifest]
Content Manifest content Puppet - Manifests
[puppet_manifest]
Name Class [puppet_class] name Puppet - Manifests
Inherits class Class [puppet_class] inherits Puppet - Manifests
Selectable Class [puppet_class] selectable Puppet - Manifests
Name Parameter name Puppet - Manifests
[puppet_parameter]
Default value Parameter default_value Puppet - Manifests
[puppet_parameter]
Name Certificate Request name Puppet - Certificate
[puppet_certificate_request] Requests
Node request Certificate Request node_request Puppet - Certificate
[puppet_certificate_request] Requests
Add the must_sudo parameter to the Puppet probe

To use the Puppet probe with sudo, you must add the must_sudo parameter to each probe that requires it.
You add the must_sudo parameter for each Puppet probe.
1. Navigate to Discovery > Probes.
2. In the Search field, search on the name Puppet.
3. Click the name of the probe.
For example, Puppet Master - Info.
4. In the Related Links pane, select the Probe parameters tab.
5. Click New.
6. In the Name field, enter must_sudo
7. In the Value field, enter true.
8. Click Submit.

Tomcat server discovery

Discovery identifies and classifies information about Tomcat servers and Web applications.
Discovery can identify and classify Web applications present in either the CATALINA_BASE directory or the
CATALINA_HOME directory.
Data collected
The classifier that finds Tomcat server processes uses the condition: Parameters contains
org.apache.catalina.startup.Bootstrap.
Table 149: Data collected by Discovery on Tomcat servers
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
Description cmdb_ci_web_applicationshort_description web.xml
Document base cmdb_ci_web_applicationdocument_base web.xml
App server cmdb_ci_web_applicationapp_server web.xml
Table 150: Relationships created
Parent class Relationship Child class
cmdb_ci_app_server_tomcat Contains::Contained by cmdb_ci_web_application
WebLogic discovery
Discovery creates or updates a CMDB record when it detects an instance of an Oracle or BEA Weblogic
application server running on a Windows or Linux system.
Requirements
• The Linux - Weblogic - Find config.xml probe requires the use of these Bourne shell commands: find,
cat, and dirname. The SSH credential must also have read permissions on the config.xml file.
• WebLogic administration server instances started via NodeManager must have the -
Dweblogic.RootDirectory=<path> parameter defined and visible through the Linux ps process stat
command (for each AdminServer) for the rest of the Linux WebLogic application server and web
application information to be populated in the CMDB.
• PowerShell must be enabled on the MID Server for the WebLogic probes to gather full server and web
application information.

• The WebLogic Administration Server instances that start via WebLogic NodeManager must have the -
Dweblogic.RootDirectory=<path> parameter defined upon server startup. The Windows credential must
also have read permissions on the config.xml file.
Probes and sensors
Discovery uses this process to identify Linux WebLogic application servers:

1. The Unix - Active Processes probe detects a running process that matches one of the follow criteria:
• The parameters of the process contain weblogic.Server.
• The parameters of the process contain -Dweblogic.name.
2. If there is a match on one of the criteria:

• A record is created in the BEA Weblogic [cmdb_ci_app_server_weblogic] table. The record is
populated with the server name and TCP port, which is gathered from the running process.
• The Linux - Weblogic - Find config.xml probe triggers. The sensor of this probe populates
additional information in the BEA Weblogic [cmdb_ci_app_server_weblogic] record and the Web
Application [cmdb_ci_web_application] record if applicable.
3. The Linux - Weblogic - Find config.xml probe attempts to find the related config.xml file for the
server by either:
• Using the -Dweblogic.RootDirectory=<path> parameter defined in the running process.
• Searching for the parent process that started the WebLogic server (only viable if the weblogic jvm
was started via the startWeblogic.sh or related custom script and not the init process).
Discovery uses this process to identify Windows WebLogic application servers:

1. The Windows - Active Processes probe detects a running process that matches one of the follow
criteria:
• The parameters of the process contain weblogic.Server.
• The parameters of the process contain -Dweblogic.name.
2. If there is a match on one of the criteria:

• A record is created in the BEA Weblogic [cmdb_ci_app_server_weblogic] table. The record is
populated with the server name and TCP port, which is gathered from the running process.
• The Windows - Weblogic - Find config.xml probe triggers. The sensor of this probe populates
additional information in the BEA Weblogic [cmdb_ci_app_server_weblogic] record and the Web
Application [cmdb_ci_web_application] record if applicable.
3. The Windows - Weblogic - Find config.xml probe attempts to find the related config.xml file for the
server by:
• Using the -Dweblogic.RootDirectory=<path> parameter defined in the running process.
• Searching for config.xml files under the –Dplatform.home=<path> parameter defined in the
running process (not as efficient using the parameters of the process).
4. If there are associated web applications found in the WebLogic config.xml file, the Windows –
Weblogic find web.xml probe triggers for each application. This probe reads the WebLogic web.xml
file for each web application and the sensor, and then populates additional information.

Data collected
Table 151: Default data collected for Linux
Table Field Source
cmdb_ci_app_server_weblogi Name (name) running process

cmdb_ci_app_server_weblogic TCP port (tcp_port) running process
Table 152: Data collected from the config.xml file for Windows
Table Name Field Source
cmdb_ci_app_server_weblogic Version (version) config.xml

cmdb_ci_app_server_weblogic Weblogic domain config.xml
(weblogic_domain)
cmdb_ci_web_application Name (name) config.xml
cmdb_ci_web_application Context path (context_path) config.xml
cmdb_ci_web_application App server (app_server) config.xml
Table 153: Default data collected on Windows
Name cmdb_ci_app_server_weblogic
name running process
TCP port cmdb_ci_app_server_weblogic
Table 154: Data collected from configuration files for Windows
Version cmdb_ci_app_server_weblogic
version config.xml
Weblogic domain cmdb_ci_app_server_weblogic
weblogic_domain config.xml
Name cmdb_ci_web_applicationname config.xml
Document base cmdb_ci_web_applicationdocument_base config.xml
Description cmdb_ci_web_applicationdescription web.xml
Servlet class cmdb_ci_web_applicationservlet_class web.xml
Servlet name cmdb_ci_web_applicationservlet_name web.xml
App server cmdb_ci_web_applicationapp_server config.xml
TCP port cmdb_ci_app_server_weblogic
tcp_port web.xml

Relationships
Table 155: Relationships
Parent class Relationship type Child class
cmdb_ci_app_server_weblogic Runs on::Runs cmdb_ci_linux_server

cmdb_ci_app_server_weblogic Contains::Contained by cmdb_ci_web_application
cmdb_ci_app_server_weblogic Depends on::Used by cmdb_ci_app_server_weblogic
This relationship is made
between an AdminServer
and any managed servers it
encapsulates.
cmdb_ci_app_server_weblogic Runs on::Runs cmdb_ci_windows_server
Add sudo access for the Weblogic - Find config.xml probe

For a WebLogic application server on Linux, the Weblogic - Find config.xml probe requires sudo privileges.
2. Search for and select the Linux - Weblogic - Find config.xml probe.
3. In the Probe Parameters related list, clickNew
4. Use the following information to complete the form
Probe Commands
Name must_sudo
Value true
5. Click Submit
WebSphere server discovery

The IBM WebSphere application server is a software framework with middleware that hosts Java-
based web applications. Discovery creates or updates a CMDB record when it detects an instance of
aWebSphere application server running on a Windows or Linux system.
Websphere discovery on Windows
Requirements for discovery:

For WebSphere application servers running on Windows systems, enable PowerShell on the MID Server.
Linux discovery on Windows
Requirements for discovery:

• Enable SSH on the WebSphere Application Server.
• Set execute privileges to enable the following probes to run commands:

• WebSphere - Get serverindex.xml: cat/read permissions on the serverindex.xml file

• WebSphere - Get cell.xml: cat/read permissions on the cell.xml file
• WebSphere - Get server.xml: cat/read permissions on the server.xml file
• The following comfiguration must be set on the sudorers file:

User ALL=(root) NOPASSWD: /bin/sh *
User is the user name on the SSH credential that you create for this discovery.
• This command must be able to be run:
/bin/sh /tmp/snc-*-findcat.sh * *"
Do not make any changes to findcat.sh.
• The Linux - Weblogic - Find config.xml probe must specify this parameter and value: must_sudo =
true
Probes and sensors
Discovery uses this process to identify Linux WebSphere application servers:

1. The Unix - Active Processes probe detects a running process that matches the
com.ibm.ws.runtime.WsServer. For example, the ...com.ibm.ws.bootstrap.WSLauncher
com.ibm.ws.runtime.WsServer process output has a parameter of /opt/IBM/WPS/profiles/ccmdb/config
localhostNode01Cell ccmdb01 server1. The values are:
• last parameter = server_name = server1
• last parameter - 1 = node_name = ccmdb01
• last parameter - 2 = cell_name = localhostNode01Cell
• last parameter - 3 = config_path = ‘/opt/IBM/WPS/profiles/ccmdb/config’
2. If there is a match, a record is created in the IBM Websphere [cmdb_ci_app_server_websphere] table.

• WebSphere - Cell
• WebSphere - Web Applications
• WebSphere –Web Services
3. The WebSphere - Cell probe searches for the cell.xml file for the instance by using the parameters
in the running process, and then searching in the related <config_path>\cells\<cell_name>\
directory.
4. If the probe successfully finds the cell.xml file, the sensor reads its contents and populates
additional Websphere Cell [cmdb_ci_websphere_cell] table records as necessary.
5. If the probe successfully finds the serverindex.xml file, the sensor reads its contents and
populates additional Web Application [cmdb_ci_web_application] table records as necessary.
6. If the probe successfully finds the server.xml file, the sensor reads its contents and populates
additional Web Service [cmdb_ci_web_service] table records as necessary.
Discovery uses this process to identify Windows WebSphere application servers:

1. The Windows - Active Processes probe detects a running process that matches the
com.ibm.ws.runtime.WsServer. For example, the ...com.ibm.ws.bootstrap.WSLauncher
com.ibm.ws.runtime.WsServer process output has a parameter of /opt/IBM/WPS/profiles/ccmdb/config
localhostNode01Cell ccmdb01 server1. The values are:

• last parameter = server_name = server1

• last parameter - 1 = node_name = ccmdb01
• last parameter - 2 = cell_name = localhostNode01Cell
• last parameter - 3 = config_path = ‘/opt/IBM/WPS/profiles/ccmdb/config’
2. If there is a match, a record is created in the IBM Websphere [cmdb_ci_app_server_websphere] table.

• Windows - WebSphere - Cell
• Windows - WebSphere - Web Applications
• Windows - WebSphere –Web Services
3. The Windows - WebSphere - Cell probe searches for the cell.xml file for the instance by using
the parameters in the running process, and then searching in the related <config_path>\cells
\<cell_name>\ directory.
4. If the probe successfully finds the cell.xml file, the sensor reads its contents and populates
additional Websphere Cell [cmdb_ci_websphere_cell] table records as necessary.
5. The Windows - WebSphere - Web Applications probe searches the serverindex.xml file for
the instance by using the parameters in the running process, and then searching in the related
<config_path>\cells\<cell_name>\nodes\<node_name> directory.
6. If the probe successfully finds the serverindex.xml file, the sensor reads its contents and
populates additional Web Application [cmdb_ci_web_application] table records as necessary.
7. The Windows WebSphere - Web Services probe searches for the server.xml file for the instance
by using the parameters in the running process, and then searching in the related <config_path>
\cells\<cell_name>\nodes\<node_name>\servers\<server_name> directory.
8. If the probe successfully finds the server.xml file, the sensor reads its contents and populates
additional Web Service [cmdb_ci_web_service] table records as necessary.
Data collected
Table 156: Data collected on Windows Websphere servers
Table Field Source
cmdb_ci_app_server_websphere Name (name) Running process

cmdb_ci_websphere_cell Name (name) cell.xml
cmdb_ci_websphere_cell Cell ID (cell_id) cell.xml
cmdb_ci_websphere_cell Cell type (cell_type) cell.xml
cmdb_ci_websphere_cell Cell discovery protocol cell.xml
(cell_discovery_protocol)
cmdb_ci_web_service Name (name) server.xml
cmdb_ci_web_service Service ID (service_id) server.xml
cmdb_ci_web_application Name (name) serverindex.xml

Table 157: Data collected on Linux Websphere servers
Name cmdb_ci_websphere_cellname server.xml

Name cmdb_ci_web_service name server.xml
Name cmdb_ci_web_applicationname serverindex.xml
App server cmdb_ci_web_applicationapp_server serverindex.xml
Relationships
These relationships are created in the CI Relationship [cmdb_rel_ci] table.
Table 158: Relationships
Parent class Relationship type Child class
cmdb_ci_app_server_websphere Runs on::Runs cmdb_ci_linux_server

cmdb_ci_win_server Runs on::Runs cmdb_ci_win_server
cmdb_ci_app_server_websphere Contains::Contained by cmdb_ci_web_application
cmdb_ci_web_service Runs on::Runs cmdb_ci_app_server_websphere
cmdb_ci_websphere_cell Contains::Contained by cmdb_ci_app_server_websphere
Adobe JRun
Discovery creates or updates a CMDB record when it detects a running instance of Adobe JRun.
By default, Discovery uses the following patterns to perform the discovery: Jrun.
The following data is collected in the Jrun [cmdb_ci_app_server_jrun] table:
Label Field Name
Name name
Version version
Installation directory install_directory
Configuration directory config_directory
Configuration file config_file
Sybase
Discovery creates or updates a CMDB record when it detects an instance of Sybase.
By default, Discovery uses the following pattern to perform the discovery: Sybase.
The following data is collected in the Sybase Instance [cmdb_ci_db_syb_instance] table:

Label Field Name
Name name
Version version
Instance instance
Exchange Hub Transport Servers

Discovery creates or updates a CMDB record when it detects a running instance of Exchange Hub.
By default, Discovery uses the following pattern to perform the discovery: Hub Transport Server On
Windows Pattern.
The following data is collected on the Exchange Hub Transport Servers
[cmdb_ci_exchange_hub_transport_server] table:
Label Field Name
Name name
Version version
Class sys_class_name
Fully qualified domain name fqdn
IP Address ip_address
Type type
HP Service Manager
Discovery creates or updates a CMDB record when it detects a running instance of HP Service Manager.
By default, Discovery uses the following pattern to perform the discovery: HP Service Manager Application
Server.
The following data is collected on the HP Service Manager [cmdb_ci_appl_hp_service] table.
Label Field Name
Name name
Vendor vendor
HP Operations Manager discovery

Discovery creates or updates a CMDB record when it detects a running instance of HP Operations
Manager.
By default, Discovery uses the following pattern to perform the discovery: HP Operations Manager for
Windows.
The following data is collected in the HP Operations Manager [cmdb_ci_appl_hp_operations] table:

Label Field Name
Name name
SQL Server Analysis Services (SSAS)

Discovery creates or updates a CMDB record when it detects a running instance of SQL Server Analysis
Services.
By default, Discovery uses the following pattern to perform the discovery: SSAS pattern.
The following data is collected in the SQL Server Analysis Services [cmdb_ci_db_mssql_analysis]
table:
Label Field Name
Name name
Version version
Type type
Instance Name instance
Model ID model_id
Tibco ActiveMatrix BusinessWorks

Discovery creates or updates a CMDB record when it detects a running instance of Tibco ActiveMatrix
BusinessWorks.
By default, Discovery uses the following patterns to perform the discovery: ActiveMatrix Business Works
and ActiveMatrix Business Works Process.
The following data is collected in the ActiveMatrix Business Works [cmdb_ci_appl_tibco_matrix]
table.
Label Field Name
Name name
Version version
TCP port(s) tcp_port

Label Field Name
Project project
Tibco Enterprise Message Service

Discovery creates or updates a CMDB record when it detects a running instance of Tibco Enterprise
Message Service.
By default, Discovery uses the following pattern to perform the discovery: Enterprise Message Service.
The following data is collected in the Tibco Enterprise Message Services
[cmdb_ci_appl_tibco_message] table.
Label Field Name
Name name
Version version
Project project
Active Directory Domain Controller

Discovery creates or updates a CMDB record when it detects a running instance of Active Directory
Domain Controller on Windows machines.
By default, Discovery uses the following pattern to perform the discovery: Active Directory Domain
Controller On Windows Pattern.
The following data is collected on the Active Directory Domain Controllers [cmdb_ci_ad_controller]
table:
Label Field Name
Name name
Version version
Type type

IBM WebSphere Message Broker (WMB) and WMB HTTP Listener discovery
Discovery creates or updates a CMDB record when it detects a running instance of IBM WMB and the
WMB HTTP listener for both Linux and Windows.
By default, Discovery uses the following patterns to perform the discovery:
• WMB On Unix Pattern
• WMB On Windows Pattern
• WMB HTTP Listener On Unix Pattern
• WMB HTTP Listener On Windows Pattern
The following data is collected in the IBM Web Sphere Message Brokers [cmdb_ci_appl_ibm_wmb]
table and the IBM WMB Http Listener [cmdb_ci_appl_ibm_wmb_listener] table:
Label Field Name
Name name
Version version
IBM Websphere WMQ

Discovery creates or updates a CMDB record when it detects a running instance of IBM Websphere WMQ
for Unix and Windows.
By default, Discovery uses the following patterns to perform the discovery: WMQ On Unix Pattern and
WMQ On Windows Pattern.
The following data is collected in the IBM WebSphere MQ [cmdb_ci_appl_ibm_wmq] table.
Label Field Name
Name name
Version version
Fully qualified domain name (Windows only) fqdn
Exchange MailBox
Discovery creates or updates a CMDB record when it detects a running instance of Exchange Mailbox.
Prerequisites
The Microsoft.Exchange.Management.PowerShell module must be installed on the server that you

want to discover.

The service winRM must be running on the host machine. Run the following command in the Powershell
window to verify: New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
"http://$hostname/PowerShell/" -Authentication Kerberos
Pattern
By default, Discovery uses the following pattern to perform the discovery: MailBox On Windows Pattern.
Credentials
Configure these credentials:

Credential type Additional notes
Applicative credentials The user must be able to run Powershell commands against the
Exchange hosts.
Use Exchange Mailbox as the CI type for the applicative credential.
Attention: Do not use the Exchange Mailbox server CI

type.
Windows credentials The OS user must be a domain user, not a local user for the server.
Data collected
The following data is collected on the Exchange Mailboxes [cmdb_ci_exchange_mailbox] table:
Label Field Name
Name name
Version version
Type type
Exchange Client Access Server (CAS)

Discovery creates or updates a CMDB record when it detects a running instance of Exchange Client
Access Server.
By default, Discovery uses the following pattern to perform the discovery: CAS On Windows Pattern.
The following data is collected on the Exchange Client Access Server [cmdb_ci_exchange_cas] table:
Label Field Name
Name name

Label Field Name
Version version
Type type
GlassFish Server discovery

Discovery creates or updates a CMDB record when it detects a running instance of GlassFish Server.
By default, Discovery uses the following patterns to perform the discovery: GlassFish Server and
GlassFish WAR.
The following data is collected in the GlassFishes [cmdb_ci_appl_glassfish] and GlassFish Wars
[cmdb_ci_appl_glassfish_war] tables:
Label Field Name
Name name
Version version
Port port
Oracle Tuxedo discovery

Discovery creates or updates a CMDB record when it detects a running instance of Oracle Tuxedo.
By default, Discovery uses the following pattern to perform the discovery: Tuxedo.
The following data is collected the Tuxedo [cmdb_ci_appl_tuxedo] table:
Label Field Name
Name name

Microsoft SharePoint
Discovery creates or updates a CMDB record when it detects a running instance of Microsoft SharePoint.
By default, Discovery uses the following pattern to perform the discovery: SharePoint.
The following data is collected in the SharePoints [cmdb_ci_appl_sharepoint] table:
Label Field Name
Name name
Version version
Category category
Type type
SAP Central Services

Discovery creates or updates a CMDB record when it detects a running instance of SAP Central Services
(SAS).
By default, Discovery uses the following pattern to perform the discovery: SAP SCS Application.
The following data is collected in the SAP SCS Application [cmdb_ci_appl_sap_scs] table:
Label Field Name
Name name
Version version
Instance name instance_name
Instance number instance_number
System ID sid
System directory system_directory
System type system_type
Transport domain transport_domain
SAP Convergent Invoicing (CI)

Discovery creates or updates a CMDB record when it detects an instance of SAP CI.
By default, Discovery uses the following pattern to perform the discovery: SAP CI Application.
The following data is collected in the SAP CI Application [cmdb_ci_appl_sap_ci] table:

Label Field Name
Name name
Version version
System ID sid
SAP Development Infrastructure (DI)

Discovery creates or updates a CMDB record when it detects a running instance of SAP DI.
By default, Discovery uses the following pattern to perform the discovery: SAP DI Application.
The following data is collected in the SAP DI Applications [cmdb_ci_appl_sap_di] table:
Label Field Name
Name name
Version version
System ID sid
SAP Evaluated Receipt Settlement (ERS)

Discovery creates or updates a CMDB record when it detects a running instance of SAP ERS.
By default, Discovery uses the following pattern to perform the discovery: SAP ERS Application.
The following data is collected in the SAP ERS Application [cmdb_ci_appl_sap_ers] table:
Label Field Name
Name name

Label Field Name
Version version
System ID sid
SAP HANA Database

Discovery creates or updates a CMDB record when it detects a running instance of SAP HANA database.
By default, Discovery uses the following pattern to perform the discovery: SAP HANA DB.
The following data is collected in the HANA Database [cmdb_ci_appl_sap_hana_db] table:
Label Field Name
Name name
Type type
Version version
SAP Business Objects CMS Server

Discovery creates or updates a CMDB record when it detects a running instance of SAP Business Objects
CMS Server.
By default, Discovery uses the following pattern to perform the discovery: SAP Business Objects CMS
Server on Windows.
The following data is collected on the SAP Business Objects CMS server [cmdb_ci_appl_sap_bo]
table:
Label Field Name
Name name
Server Name server_name
Version version

Label Field Name
SAP ABAP SAP Central Services (ASCS)

Discovery creates or updates a CMDB record when it detects a running instance of SAP ASCS.
By default, Discovery uses the following pattern to perform the discovery: SAP ASCS Application.
The following data is collected in the SAP ASCS [cmdb_ci_appl_sap_ascs] table:
Label Field Name
Name name
Version version
System ID sid
Sun Java Enterprise System (JES)

Discovery creates or updates a CMDB record when it detects a running instance of Sun JES.
By default, Discovery uses the following pattern to perform the discovery: Sun JES pattern.
The following data is collected in the JES [cmdb_ci_email_server_jes] table:
Label Field Name
Name name
Storage discovery
Discovery collects information on Direct Attached Storage (DAS), Storage Area Networks (SAN), and
Network Attached Storage (NAS).
Storage can be located on specialized devices, such as Storage Arrays, Fibre Channel Switches, iSCSI
disks, or on host operating systems, including Windows, Linux, and Solaris.
Discovery finds and maps dependencies for the following types of storage:

• Direct-attached storage (DAS), network-attached storage (NAS), or storage area network (SAN).
• NAS or SAN storage that is discovered via a Storage Management Initiative Specification (SMI-S) and
Common Information Model (CIM).
• Virtual storage for VMware EXS servers and Linux Kernel-based Virtual Machines (KVM). Discovery
maps this storage to the underlying physical storage.
Discovery of storage via a host reconciles data and creates relationships between the host's file systems
and associated local storage devices. The local storage devices represent the storage available to the
host, whether it's directly attached or provided by Fibre Channel or iSCSI. This reconciliation assumes that
the storage server has been discovered first.
Discovery collects and creates CIs in the CMDB for the following information:
• File systems (local and NAS).
• Disks (both SAN disks and DAS drives).
• Fibre Channel (FC) HBAs and ports.
• Linux Volume Manager (LVM) volumes. LVM volume data resides in the Storage Pool
[cmdb_ci_storage_pool] table.
• Veritas Volume Manager disks, subdisks, disk groups, plexes, and volumes.
Note: For details about the discovery of direct attached or multipath block storage provisioned on a
Linux host, see KB0622583.
This diagram shows the relationship of SAN storage devices to a host computer. Storage accessible to
the Linux host consists of two physical fibre channel (FC) disks, mpatha and mpathb, connected to the
host via a multipath FC SAN. The two HBAs on the host interface are connected with two fibre cables each
to separate FC switches for failover capability. The FC fabric switches are connected to two FC storage
controllers. In this example, each FC Controller is configured to exclusively manage only one physical disk.

Figure 119: Multipath SAN storage
Probes, sensors, and patterns
• KVM - Storage Pools: identifies storage attached to KVM virtual machines.

• Linux - Storage: identifies storage attached to systems running the Linux operating system.
• Solaris - Storage: identifies storage attached to systems running the Solaris operating system.
• Windows - Storage 2008: identifies storage attached to systems running Windows 2008.
• Windows - Storage 2008 - PS: identifies storage attached to systems running Windows 2008, using
the PowerShell.

• Windows - Storage 2008 - WMI: identifies storage attached to systems running Windows 2008,
using WMI Runner.
• Windows - Storage 2012: identifies storage attached to systems running Windows 2012 and later.
• Windows - Storage 2012 - PS: identifies storage attached to Windows systems, using PowerShell.
• Windows - Storage 2012 - WMI: identifies storage attached to Windows systems, using WMI
Runner.
• VMWare - vCenter ESX Hosts Storage: collects information about ESX servers and creates
relationships from datastores to underlying disks.
Requirements
Windows • For Windows, use one of the following supported

host configurations:
• Windows Server 2012, DAS or NAS with
Fibre Channel (FC) or Internet Small
Computer System Interface (iSCSI).
• Windows Server 2008, DAS or NAS with FC
or iSCSI.
• Install the fcinfo.exe tool on Windows 2008

and 2012 servers that attach to storage via FC.
• Install Windows Management Instrumentation
(WMI).
• Enable Powershell on the MID Server host
server.
• Provide the instance with the necessary
credentials to the host server.
• Put the MID Server and the target machine in
the same domain or add the target machine to
the trusted host list on the MID Server machine.
• Optionally, install Windows Remote
Management (WinRM) on the host server to
discover Fibre Channel information. WinRM is
on by default for Windows 2012 and Windows
2016 machines, but not for Windows 2008.
Linux • For Linux, use one of the following supported

host configurations:
• Solaris, DAS, NAS, or SAN with iSCSI
• CentOS, DAS, NAS, or SAN with FC or iSCSI
• Ubuntu Server, DAS, NAS, or SAN with
iSCSI
• Provide the device with SSH credentials that

have root or sudo access.
• Provide the MID Server with the necessary
credentials to the host server.

Relationships
Discovery creates the following relationships for storage CIs:

Parent Component Relationship Child Component
Storage Export Exports to::Imports from Storage Device

[cmdb_ci_storage_export] [cmdb_ci_storage_device]
Fibre Channel Disk Provides::Provided by File System
[cmdb_ci_fc_disk] [cmdb_ci_file_system]
iSCSI Disk [cmdb_ci_iscsi_disk] Provides::Provided by File System
[cmdb_ci_file_system]
NAS File System Allocated from::Allocated to Storage File Share
[cmdb_ci_nas_file_system] [cmdb_ci_storage_fileshare]
Direct attached storage example

Discovery creates configuration items (CI) and CI relationships for dedicated storage servers, in addition to
physical and logical storage components attached directly to application and database servers.
In this example of direct attached storage (DAS), a SCSI drive with two partitions, /dev/sda1 and /dev/
sda2, is attached to a Linux host. The /dev/sda1 partition is bootable and supports the system software.
The /dev/sda2 partition contains a logical volume configured as a storage pool and mounted to the Linux
root file system by Logical Volume Management (LVM). The storage pool uses only 1.5GB of the partition,
leaving 13GB of storage available for additional logical volumes.

Figure 120: Direct attached storage (DAS) example

CIs and relationships created for direct attached storage (DAS)
Configuration item Description Tables Key reference and

Relationships
/dev/sda SCSI physical storage • [cmdb_ci_disk] [cmdb_rel_ci]

device • [cmdb_ci_storage_device]
• Provides: /dev/sda
• [cmdb_rel_ci] • Provided by:/dev/
sda1
[cmdb_rel_ci]
• Provided by:/
dev/mapper/lvm-
root-333-0
/dev/sda1 Partition 1 on the SCSI • [cmdb_ci_partition] [cmdb_ci_file_system]

storage device • [cmdb_ci_storage_volume]
• Mount point: /boot
• [cmdb_ci_file_system]• File system: Ext4
• [cmdb_rel_ci]
[cmdb_rel_ci]
• Provided by:/dev/
sda1
/dev/sda2 Partition 2 on the SCSI • [cmdb_ci_partition] [cmdb_ci_storage_pool_member]

storage device • [cmdb_ci_storage_pool_member]
• Pool: /dev/mapper/
lvm-root-333-0
• Storage: /dev/sda2
/dev/mapper/lvm- Linux logical volume, • [cmdb_ci_file_system]

[cmdb_ci_storage_device]
root-333-0 mapped with LVM to a • [cmdb_ci_storage_volume]
• Mount point: /
physical disk storage
• [cmdb_ci_file_system]• File system: Ext4
partition.
• [cmdb_ci_storage_pool
• [cmdb_ci_storage_pool_member]
[cmdb_rel_ci]
• [cmdb_ci_lvm_pool]
• [cmdb_ci_lvm_pool_member]
[cmdb_rel_ci] • Provided by:/
dev/mapper/lvm-
root-333-0
[cmdb_ci_storage_pool_member]
• Pool: /dev/mapper/
lvm-root-333-0
• Storage: /dev/sda2

Multipath fibre channel storage example

Discovery creates configuration items (CI) and CI relationships for multipath physical and logical storage
components attached to application and database servers by fibre channel switched fabric.
In this example of a fibre channel storage area network (SAN), two physical storage devices, mpatha
and mpathb, are attached to a Linux host through fibre switches, which provide failover capabilities.
The mpatha drive contains two partitions, mpatha1 and mpatha2. The first partition is mounted directly
to /boot on the Linux host. Three logical volumes are mapped to the mpatha2 partition and to the
physical device mpathb. The logical volumes are mounted as Ext4 file systems in folders on the Linux
root structure. This example shows the CIs that Discovery manages for each component and the mounting
points for the logical volumes on the Linux host.

Figure 121: Multipath fibre channel storage example
Switched fibre fabric details
Discovery creates CIs for the logical sub-components in NAS and SAN environments, such as fibre
channel disks and pool components, as well as for host bus adapters (HBA) and physical block storage. In

multipath environments, Discovery creates CI relationships within the switched fibre fabrics that connects
the Linux host to the physical storage devices. In this diagram, the fibre fabrics have redundant paths that
the SAN environment can use for failover if connections fail.


Configure Discovery for UNIX or Linux hosts with attached storage

Discovery can find information about a UNIX or Linux host and attached storage.
Role required: admin or discovery_admin
You can configure Discovery for UNIX or Linux hosts Windows.
1. Optional: On the host, assign elevated privileges to the account that Discovery will use.
2. On the instance, add credentials to the Discovery Credentials table.
3. Create a Discovery Schedule for each host IP address..
4. Optional: Create a behavior that uses a functionality definition with a wbem port probe to make the
initial port-scanning phase (Shazzam) more efficient.
5. Run network discovery.
Note: If the host also connects to a NAS or SAN storage array, set up the SMI-S Provider and
CIM credentials.
Configure Discovery for Windows hosts

Discovery can find information about a Windows host and attached storage.
You can configure Discovery for Windows hosts with attached storage.
1. For Windows 2008 servers that attach to storage via FC. For servers that are using newer operating
systems, similar functionality is present with the operating system; this step is not required:
a) Download and install the Microsoft Fibre Channel Information Tool from http://www.microsoft.com.
Search the website for Microsoft Fibre Channel Information Tool.
b) Set the environment path for the fcinfo executable and run the fcinfo.exe file.
2. For all Windows hosts including Windows 2008, add Windows credentials to the Discovery Credentials
table.
3. On the ServiceNow instance, create a Discovery Schedule for each host IP address.
4. Optional: Create a behavior that uses a functionality definition with a wbem port probe to make the
initial port-scanning phase (Shazzam) more efficient.
Note: If the host also connects to a NAS or SAN storage array, set up the SMI-S Provider and
CIM credentials.
Discovery data collected for storage via a host

Discovery uses these tables and probes to gather information about storage units that connect to a host via
a local I/O port or Host Bus Adapter (HBA).
Discovery on Solaris supports HBAs manufactured by:
• Emulex
• QLogic

Table 159: Data collected for storage from a host
Table Probes
Disk [cmdb_ci_disk] • KVM

• Linux - Storage
• Solaris - Storage
• Windows - Storage 2008
Disk Partition [cmdb_ci_disk_partition] • KVM

• Linux - Storage
Fibre Channel Disk [cmdb_ci_fc_disk] • Linux - Storage

Fibre Channel Port [cmdb_ci_fc_port] • Linux - Storage

File System [cmdb_ci_file_system] • KVM

• Linux - Storage
iSCSI Disk [cmdb_ci_iscsi_disk] • KVM

• Linux - Storage
NAS File System [cmdb_ci_nas_file_system] • KVM

• Linux - Storage
Storage HBA [cmdb_ci_storage_hba] • Linux - Storage

Storage Pool [cmdb_ci_storage_pool] Linux - Storage

Table Probes
Storage Pool Member Linux - Storage

VMware vCenter Datastore VMware - vCenter Datastores
Storage references discovered via a host

Discovery maps these references for storage units that connect to a host via a local I/O port or Host Bus
Adapter (HBA).
Table 160: References discovered for storage from a host
Table and column Reference Target data element
cmdb_ci_storage_device.computer
refers to the cmdb_ci_computer
cmdb_ci_storage_device.provided_by
refers to the cmdb_ci_fc_port (for FC only)
cmdb_ci_disk_partition.disk is a partition of cmdb_ci_disk
cmdb_ci_storage_hba.computer is the cmdb_ci_computer
cmdb_ci_fc_port.controller contains the cmdb_ci_storage_hba
cmdb_ci_fc_port.computer is the same cmdb_ci_computer as
cmdb_ci_storage_hba.computer
cmdb_ci_storage_volume.computer
is the cmdb_ci_computer
cmdb_ci_storage_volume.provided_by
is the cmdb_ci_storage_pool or
cmdb_ci_storage_pool or
cmdb_ci_storage_device
(providing storage)
cmdb_ci_storage_pool.hosted_byis the cmdb_ci_computer
cmdb_ci_computer the pool is on cmdb_ci_storage_pool.container
cmdb_ci_storage_pool.container is the cmdb_ci_storage_pool or
cmdb_ci_storage_pool_member
containing the pool (if the pool
is present)
cmdb_ci_storage_pool_member.pool
is the cmdb_ci_storage_pool
cmdb_ci_storge_pool_member.storage
is the cmdb_ci_storage_pool,
cmdb_ci_disk_partition or
cmdb_ci_storage_device
providing storage
Data collected for HBAs on Linux and ESX servers

Discovery collects information on host bus adapters (HBA) for fiber channel enabled devices connected to
Linux and ESX servers.
Discovery on Linux supports HBAs manufactured by Emulex and QLogic.

Table 161: HBA tables and fields
Label Table Field name Source
Name Storage HBA name • VMWare - vCenter

[cmdb_ci_storage_hba] ESX Hosts Storage
probe
• Linux - Storage
WWNN Storage HBA wwnn • VMWare - vCenter

probe
• Linux - Storage
Model ID Storage HBA model_id • VMWare - vCenter

probe
• Linux - Storage
Computer Storage HBA computer • VMWare - vCenter

probe
• Linux - Storage
Table 162: Fibre Channel ports
WWPN Fibre Channel Port wwpn VMWare - vCenter

[cmdb_ci_fc_port] ESX Hosts Storage
• probe
• Linux - Storage
WWNN Fibre Channel Port wwnn • VMWare - vCenter

probe
• Linux - Storage
Port type Fibre Channel Port port_type • VMWare - vCenter

probe
• Linux - Storage
Speed Fibre Channel Port speed • VMWare - vCenter

probe
• Linux - Storage

Controller Fibre Channel Port controller • VMWare - vCenter

probe
• Linux - Storage
Computer Fibre Channel Port computer • VMWare - vCenter

probe
• Linux - Storage
Table 163: Fibre Channel targets
FC Disk Fibre Channel Targets fc_disk • Linux - Storage

[cmdb_fc_target] • Solaris - Storage
• Windows - Storage
2008
2012
Created by Fibre Channel Targets sys_created_by • Linux - Storage

2008
2012
Created Fibre Channel Targets sys_created_on • Linux - Storage

2008
2012
SysID Fibre Channel Targets sys_id • Linux - Storage

2008
2012

Updates Fibre Channel Targets sys_mod_count • Linux - Storage

2008
2012
Updated by Fibre Channel Targets sys_updated_by • Linux - Storage

2008
2012
Updated Fibre Channel Targets sys_updated_on • Linux - Storage

2008
2012
WWNN Fibre Channel Targets wwnn • Linux - Storage

2008
2012
WWPN Fibre Channel Targets wwpn • Linux - Storage

2008
2012
Data collected for HBAs on Solaris servers

Discovery collects information on host bus adapters (HBA) for Fibre Channel (FC) enabled devices
connected to Solaris servers.
HBA fields
Discovery populates these fields in the Storage HBA [cmdb_ci_storage_hba] table, using the Solaris -
Storage probe and sensor. Discovery on Solaris supports HBAs manufactured by Emulex and QLogic.

Label Field name
Name name
Computer computer
Device ID device_id
Manufacturer manufacturer
Model ID model_id
Fibre channel port fields
Discovery populates these fields in the Fibre Channel Port [cmdb_ci_fc_port] table, using the Solaris -
Storage probe and sensor.
Table 165: Fibre channel ports
Label Field name
Name name
Computer computer
Controller controller
WWPN wwpn
WWNN wwnn
Port type port_type
Speed speed
Operational status operational_status
Fibre channel disk fields
Discovery populates these fields in the Fibre Channel Disk [cmdb_ci_fc_disk] table, using the Solaris -
Table 166: Fibre channel disk fields
Label Name
Name name
Storage type storage_type
Device interface device_interface
Device LUN device_lun

Fibre channel targets
Discovery populates these fields in the Fibre Channel Targets [cmdb_fc_target] table, using the Solaris -
Table 167: Fibre channel target fields
Label Name
FC Disk fc_disk
WWNN wwnn
WWPN wwpn
Data collected for HBAs on Windows servers

Discovery collects information on host bus adapters (HBA) for Fibre Channel enabled devices connected to
Windows servers.
Discovery on Windows supports HBAs on any OS.
Name Storage HBA name • VMWare - vCenter

probe
2008
2012
WWNN Storage HBA wwnn • VMWare - vCenter

probe
2008
2012
Model ID Storage HBA model_id • VMWare - vCenter

probe
2008
2012

Computer Storage HBA computer • VMWare - vCenter

probe
2008
2012
Table 169: Fibre Channel ports
WWPN Fibre Channel Port wwpn • VMWare - vCenter

probe
2008
2012
WWNN Fibre Channel Port wwnn • VMWare - vCenter

probe
2008
2012
Port type Fibre Channel Port port_type • VMWare - vCenter

probe
2008
2012
Speed Fibre Channel Port speed • VMWare - vCenter

probe
2008
2012

Controller Fibre Channel Port controller • VMWare - vCenter

probe
2008
2012
Computer Fibre Channel Port computer • VMWare - vCenter

probe
2008
2012
Data collected for Veritas Volume Manager on Linux

Discovery collects disk and volume information for Veritas Volume Manager (VxVM) on Linux hosts and
maps file systems mounted on Veritas volumes to the upstream storage provider.
Note: Ensure that VxVM is correctly installed and configured. If you are using 3rd party drivers,
you must configure sudo permission for vxdmpadm.
Table schema
Table 170: VxVM tables
Table Extends table
Veritas Disk [cmdb_ci_veritas_disk] Storage Pool [cmdb_ci_storage_pool]

Veritas Disk Group Configuration Item [cmdb_ci]
[cmdb_ci_veritas_disk_group]
Veritas Plex [cmdb_ci_veritas_plex] Storage Pool [cmdb_ci_storage_pool]
Veritas Subdisk [cmdb_ci_veritas_subdisk] Storage Pool Member
Veritas Volume [cmdb_ci_veritas_volume] Storage Pool [cmdb_ci_storage_pool]

Data collected
Table 171: VxVM data collected
Table Fields Relationship
Veritas Disk • name Provided by::Provides

[cmdb_ci_veritas_disk] • size_bytes relationship to the physical disk.
• disk_group
Veritas Disk Group name Contains::Contained by

[cmdb_ci_veritas_disk_group] relationship to Veritas Disks in
the group.
Veritas Plex • name
[cmdb_ci_veritas_plex] • size_bytes
• layout (CONCAT, STRIPE,
RAID)
Veritas Subdisk • partition_number

[cmdb_ci_veritas_subdisk] • 4
source_start_offset:
• source_end_offset
5
• start_offset
6
• end_offset
7
• size_bytes
Veritas Volume name Stored on::Provides storage for

[cmdb_ci_veritas_volume] relationship to Veritas Disks on
which the volume is stored.
Displaying data
VxVM Discovery maps file systems to the disks that supply storage. By default this is the only information
displayed in the UI. The file system to disk relationship is shown as an upstream Stored on relationship on
the File System form. To see the remainder of the information that Discovery captures for VxVM, you must
add the appropriate related list to the Linux Server form. The available lists are:
• Veritas Disk Group
• Veritas Disk
• Veritas Plex
• Veritas Subdisk (Computer)
• Veritas Subdisk (Storage)
• Veritas Volume
4
Offset in the disk from which this subdisk is partitioned.
5
Offset in the disk from which this subdisk is partitioned.
6
Offset of this subdisk in the plex that is using it.
7
Offset of this subdisk in the plex that is using it.

Storage Discovery via SMI-S and CIM

Discovery can explore storage devices that contain a Storage Management Initiative Specification (SMI-S)
provider that is a specialized Common Information Model (CIM) server.
To see the current list of vendors and products conforming to SMI-S as tested by SNIA, see the SNIA
website.
Other types of storage, such as storage that is attached via a host, VM storage that is available on VMware
ESX servers, and storage for Kernel VM (KVM), use a separate set of probes and sensors.
Discovery collects information about storage area networks (SAN) and network-attached storage (NAS)
from specialized devices, such as storage arrays and Fibre Channel (FC) switches. Discovery collects and
creates CIs in the CMDB for the following information items:
• Array disks, pools, and volumes
• Fibre Channel HBAs, ports, and controllers
• FC exports
• Fabrics, including endpoints, zoning, and switches
• Dependencies between storage sub-components
Requirements
• A CIM server using SMI-S 1.5 or later.

• NAS and SAN systems from major vendors such as EMC, Hitachi, HP, and NetApp. SAN storage
devices must use FC.
• FC switches from major vendors such as Brocade and Cisco.
• The CIM credentials must be available for SMI-S configuration. The CIM credentials can be different
than the credentials for the system hosting the CIM server.
• The CIM user requires the administrator role.
Note: Because the SMI-S Provider caches storage device information, the Discovery query to the
provider does not affect storage device performance.
ServiceNow SAN schema
This diagram shows the tables in the SAN schema and the default references defined between them.


SMI-S Discovery architecture
CIM architecture
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.
The following components are part of CIM:
• Common Information Model (CIM): CIM 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 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. ServiceNowsupports SMI-S version

1.5 or higher.
Figure 123: CIM SMI-S Standard Diagram
• Web-Based Enterprise Management (WBEM): WBEM defines a particular implementation of CIM,

including protocols for discovering and accessing each CIM implementation.
• Service Location Protocol (SLP): SLP is an ad hoc protocol for retrieving and associating configuration
information about CIM servers, such as default paths, capabilities, and the exact interop namespace.
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.
Note: The mid.cim.interop.namespace system property defines four default storage

namespaces:
• interop
• root/interop
• root/pg_interop
• pg_interop
If you are using multiple storage vendors with custom namespaces not specified as one of the
defaults, add the new namespaces to the comma-separated list in this property. If you intend to
continue using any of the default namespaces, make sure to include them in the property.

Figure 124: CIM Agents Diagram
SLP and WBEM support
SLP is required for CIM Discovery as it is part of the Storage Management Initiative Specification (SMI-S)
stack. Some storage devices may support the WBEM protocol, but may not support SLP.
You can manually register the WBEM services on SLP using a common Linux tool like slptool. This tool
has a command line interface that you can use to make SLPv2 User Agent (UA) requests, which usually
come with the SLP daemon package. To register a service, provide a URL and list of attributes. An
example can be extracted from a working SLP server by using the same tool.
Storage Discovery table schema
This diagram displays the disk hierarchical schema for storage Discovery.

Figure 125: Disk hierarchical schema
Tables and probes
Discovery uses the following tables and probes to gather information about storage devices that are
managed by a SMI-S provider.
Table 172: Data Collected
Table Probe
Disk [cmdb_ci_disk] SMI - Storage Server

Fibre Channel Export [cmdb_ci_fc_export] SMI - Storage Server
Fibre Channel Port [cmdb_ci_fc_port] SMI - Storage Server
SAN Export [cmdb_ci_san_export] SMI - Storage Server
Storage Controller [cmdb_ci_storage_controller] SMI - Storage Server

Table Probe
Storage Export [cmdb_ci_storage_export] SMI - Storage Server

Storage File Share [cmdb_ci_storage_fileshare] SMI - Array - File Shares
Storage Pool [cmdb_ci_storage_pool] SMI - Storage Server
Storage Server [cmdb_ci_storage_server] CIM - Identity
Storage Switch [cmdb_ci_storage_switch] CIM - Identity
Storage Volume [cmdb_ci_storage_volume] SMI - Storage Server
Storage Device [cmdb_ci_storage_device] SMI - Storage Server
Storage Area Network [cmdb_ci_san] SMI - Fabric
SAN Connection [cmdb_ci_san_connection] SMI - Fabric
SAN Endpoint [cmdb_ci_san_endpoint] SMI - Fabric
SAN Fabric [cmdb_ci_san_fabric] SMI - Fabric
SAN Zone [cmdb_ci_san_zone] SMI - Fabric
SAN Zone Alias [cmdb_ci_san_zone_alias] SMI - Fabric
SAN Zone Alias Member SMI - Fabric
[cmdb_ci_san_zone_alias_member]
SAN Zone Member SMI - Fabric
[cmdb_ci_san_zone_member]
SAN Zone Set [cmdb_ci_san_zone_set] SMI - Fabric
How CIM Discovery works

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

Figure 126: CIM Shazzam Processing Diagram
The wbem port Probe
The wbem probe stores the data it retrieves in the CIM Classification [discovery_classy_cim] table.
To view the wbem port probe, navigate to Discovery Definition > Port Probes.


SLP query
The SLP query detects the wbem service (service:wbem) on an SLP server and gathers the attributes of
the service. To view the SLP Query record, open the wbem port probe record and select SLP Query from
the Service Registry Queries related list.
Figure 128: SLP Query record
CIM - Classify probe
The wbem port probe appends the SLP data it carries, including namespaces, to the CIM - Classify probe
before launching it. The CIM classification probe extracts VMware ESX serial numbers and connector
relationships between the SAN and NAS components from CIM Servers in the network.
To access the CIM classification probe, navigate to Discovery Definition > Probes and select CIM -
Classify from the list of probes.

Note: The mid.cim.interop.namespace system property defines four default storage

namespaces:
• interop
• root/interop
• root/pg_interop
• pg_interop
If you are using multiple storage vendors with custom namespaces not specified as one of the
defaults, add the new namespaces to the comma-separated list in this property. If you intend to
continue using any of the default namespaces, make sure to include them in the property.


SMI-S and CIM probes and sensors
Probe/Sensor Description
CIM - Identity Identifies a system via CIM per SMI-S.

SMI - Array - Controllers Retrieves controller information.
SMI - Array - Disks Retrieves storage disk information.
SMI - Array - File Shares Enumerates NAS file shares from a storage
server.
SMI - Array - Pools Retrieves storage pools.
SMI - Array - Ports Retrieves storage ports.
SMI - Array - Volumes Retrieves storage volumes.
SMI - Fabric Retrieves SANs, fabrics, zone sets, zones, zone
aliases, endpoints, and connections.
SMI - Fibre Channel Switch Retrieves FC switches.
SMI - NAS Head - Component Systems Retrieves all virtual file servers in a NAS head
profile.
SMI - NAS Head - File Server IPs Retrieves IP addresses for each NAS file server.
SMI - NAS Head - File Servers Retrieves NAS file servers such as Common
Internet File System (CIFS) and Network File
System (NFS).
SMI - NAS Head - File Shares Retrieves file shares for each NAS file server.
SMI - Storage Server Retrieves SAN and NAS arrays and servers.
SMI - WBEM Service Retrieves WBEM Service information such as
profiles and SMI-S version.
Configure Discovery for a standalone storage device

Use this procedure for configuring a standalone storage device with the required SMI-S Provider for
Discovery.
1. On the storage device, if the SMI-S Provider is not present, install the SMI-S Provider software.
The SMI-S Provider software is often part of the device management software. For more information,
download the SMI-S Provider instructions from the storage provider manufacture. For example, if the
SAN contains an EMC storage device, click here for more information.
2. For NetApp storage devices, install the SMI-S agent on the storage device host.
3. Start the SMI-S Provider service.
4. In the SMI-S Provider or agent, configure the Discovery Interval with a synchronization rate that
allows the webm probe to receives the most current information during discovery.
For example, for EMC storage, set the Discovery Interval.

Figure 130: EMC provider example
5. On the ServiceNow instance, set up CIM credentials.

6. Create a Discovery Schedule with the IP addresses of each SMI-S Provider.
7. Optionally, create a Discovery behavior that uses a functionality definition with a wbem port probe to
make the initial port-scanning phase (Shazzam) more efficient.
Data collected by Discovery on storage devices

Discovery identifies and classifies information about storage devices.
Table 173: Data collected by Discovery on storage devices
Sys ID Storage Disk sys_id N/A

[cmdb_ci_storage_disk]
File Share ID Storage File Share fileshare_id CIM probe
[cmdb_ci_storage_fileshare]
Path Storage File Share path CIM probe
[cmdb_ci_storage_fileshare]
Disk space (GB) Storage Pool disk_space CIM probe
[cmdb_ci_storage_pool]

Pool ID Storage Pool pool_id CIM probe

[cmdb_ci_storage_pool]
Speed (GFC) Storage Port speed CIM probe
[cmdb_ci_storage_port]
WWPN Storage Port wwpn CIM probe
[cmdb_ci_storage_port]
Device ID Storage HBA device_id CIM probe
[cmdb_ci_storage_hba]
Firmware version Storage Server firmware_version CIM probe
[cmdb_ci_storage_server]
Disk Space (GB) Storage Volume disk_space CIM probe
[cmdb_ci_storage_volume]
LUN Storage Volume 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.
Discovery creates the following relationships for storage CIs running on Storage Area Networks.
Table 174: SAN CI relationships
Storage Volume Exports to::Imports from Fibre Channel Disk

[cmdb_ci_storage_volume] [cmdb_ci_fc_disk]
Storage Volume Exports to::Imports from iSCSI [cmdb_ci_iscsi_disk]
Discovery maps NAS file shares by resolving the hostname of a remotely mounted disk on the client
computer to an IP address and then matching it to the IP address of the storage server that provides the
exported file system. Discovery extracts the hostname or IP address from the NAS path to determine
the identify of the storage server. If the hostname is an actual hostname, the system immediately
resolves that value into an IP address and stores it in the nas_ip_address field of the NAS File System
[cmdb_ci_nas_file_system] table.
Discovery creates the following relationships for storage CIs running on Network Attached Storage (NAS).
These relationships are the same between Linux and Windows operating system hosts.

Table 175: NAS CI relationships
NAS File System Allocated from::Allocated to Storage File Share

[cmdb_ci_nas_file_system] [cmdb_ci_storage_fileshare]
Operating-system-level virtualization (OSLV) discovery

Discovery can collect image and container information from OSLV engines.
Discovery can determine container status and size and identify images and their tags provided by
operating-system-level virtualization.
Note: Currently, the ServiceNow® platform supports the discovery of Docker virtualization
containers only.
Table schema
Table Description
cmdb_ci_oslv_engine Base table for all OSLV engines.

cmdb_ci_oslv_image Base table for globally unique OSLV images.
cmdb_ci_oslv_local_image Base table for local instances of OSLV images.
cmdb_ci_oslv_image_tag Base table for tags on OSLV images.
cmdb_ci_oslv_container Base table to store containers found on the host.
Data collected
Table Fields
Operating System Level Virtualization Engine Server [server]

[cmdb_ci_oslv_engine]
Operating System Level Virtualization Image • Image ID [image_id]
[cmdb_ci_oslv_image] • Image digest [image_digest]
• Image created [image_created_at]
• Size (bytes) [size_bytes]
Operating System Level Virtualization Local Image ID [image_id]

Image [cmdb_ci_oslv_local_image]
Operating System Level Virtualization Image • Image ID [image_id]
Tag [cmdb_ci_oslv_image_tag] • Repository [repository]
• Tag [tag]

Table Fields
Operating System Level Virtualization Container • Container ID [container_id]

[cmdb_ci_oslv_container] • Status [status]
• Size (bytes) [size_bytes]
• Image ID [image_id]
Docker virtualization
Discovery can collect data about specific objects in a Docker engine, running on a Linux host.
The ServiceNow® platform supports the discovery of Docker release 1.11.0 or later.
Docker configuration items
Discovery creates configuration items (CI) for these Docker objects:

• Engine: Software that runs on the Linux host to create the operating environment for distributed
applications.
• Images: Images on the Docker engine separated into these entities:
• Global images.
• Locally stored instances of the images.
• Tags associated with the locally stored instances of the images.
• Containers: Virtual wrappers, found on the Docker engine, which contain running instances of images.
Docker restrictions and considerations
When using Docker virtualization, consider the following:

• The initial Discovery process scan can identify an application in a container and classify it correctly.
However, subsequent probes launched to explore that application cannot see inside the container and
cannot return details about the application.
• Discovery scans all containers it finds, including inactive containers, which can slow down Discovery.
You should delete containers that are not running.
• Only one Docker engine is permitted per computer (on either a physical or virtual machine).
User privileges
The user whose credentials are used to perform Docker Discovery must have privileges defined by one of
these methods:
• The user is the root user, since the Docker daemon runs as the root user.
• Assigned to a group named docker, which has special privileges for running Docker commands. For
instructions on setting up a group, see Create a Docker group.

Table schema and relationships
The Docker tables are installed with the Discovery plugin and extend tables used to store data on the
operating-system-level virtualization (OSLV) engine.
Table 176: Docker tables
Table Description
Docker Engine [cmdb_ci_docker_engine] Stores instances of the Docker engine.

Docker Image [cmdb_ci_docker_image] Stores the globally unique representation of
Docker images.
Docker Local Image Stores local instances of Docker images.
[cmdb_ci_docker_local_image]
Docker Image Tag [cmdb_ci_docker_image_tag] Stores tags from local Docker images.
Docker Container [cmdb_ci_docker_container] Stores Docker containers found on the host.
Discovery stores these relationships in the CI Relationship [cmdb_rel_ci] table.

• cmdb_ci_server Runs::RunsOn cmdb_ci_docker_engine
• cmdb_ci_docker_engine Manages::ManagedBy cmdb_ci_docker_container
• cmdb_ci_docker_engine Manages::ManagedBy cmdb_ci_docker_local_image
• cmdb_ci_docker_container Instantiates::InstantiatedBy cmdb_ci_docker_local_image
• cmdb_ci_docker_image_tag RegisteredOn::HasRegistered cmdb_ci_docker_local_image
• cmdb_ci_docker_local_image Instantiates::InstantiatedBy cmdb_ci_docker_image

Figure 131: Parent and child relationships for the OSLV and Docker dependent tables

Identification, containment, and hosting rules
Discovery uses an application rule identifiers to find the Docker engine and then applies other rules to
identify specific Docker objects.
Application rule identifier The system creates the cmdb_ci_docker_engine

configuration item (CI) during process classification.
Based on this, Discovery uses the Application Rule
identifier, on the Application [cmdb_ci_appl] table to
identify the particular Docker engine encountered.
After establishing this identity, Discovery uses the
relationships defined in the containment and hosting
rules to accurately create and update the individual
Docker component CIs related to that engine.
Identifiers
Name Table Attributes
Docker Docker container_id

Container Container
[cmdb_ci_docker_container]
Docker Global Docker Image image_id
Image [cmdb_ci_docker_image]
Docker Local Docker image_id
Image Local Image
[cmdb_ci_docker_local_image]
Docker Image Docker repository, tag
Tag Image Tag
[cmdb_ci_docker_image_tag]
Containment and hosting rules Docker Discovery uses these containment and
hosting rules to create configuration items (CI)
from the data retured by the Docker Pattern.
After Discovery identifies the Docker engine by
its relationship to the Application [cmdb_ci_appl]
table, it uses these rules to identify the specific CIs
connected to that engine from their relationships to
one another. By connecting the components to one
another in this fashion, from the application down,
starting with the engine, Discovery avoids creating
duplicate CIs for components from other Docker
engines that use the same name or image_id.
Table 177: Containment rule
Parent Child Relationship
Docker Local Docker Image Has registered

Image Tag

Table 178: Hosting rules
Parent Child Relationship
Docker Docker Engine Managed by

Container
Docker Local Docker Engine Managed by
Image
Pattern
To view the pattern for discovering the docker engine (cmdb_ci_docker_engine) and its components,
navigate to Pattern Designer > Discovery Patterns and open Docker Pattern. For more information
about Discovery patterns, see Pattern customization on page 730.
Discovery runs the Docker Engine process classifier in the network. If the classifier identifies the dockerd
or docker daemon process, the classifier triggers the Horizontal Pattern (HorizontalDiscoveryProbe)
probe, which launches the Docker Pattern and begins collecting data from Docker components.
The pattern collects data for the main CI type, cmdb_ci_docker_engine, and for these related CI types:
• cmdb_ci_docker_image
• cmdb_ci_docker_local_image
• cmdb_ci_docker_image_tag
• cmdb_ci_docker_container
Data collected
These attributes are discovered, in addition to the attributes derived from the parent OSLV tables.
Table Fields
Docker Engine [cmdb_ci_docker_engine] • Version [version]

• Go version [go_version]
• Git commit [git_commit]
• Build date [build_date]
• OS/Arch [os_arch]
• API version [api_version]
Docker Image [cmdb_ci_docker_image] No additional attributes are discovered for this

child table.
Docker Local Image No additional attributes are discovered for this
[cmdb_ci_docker_local_image] child table.
Docker Image Tag [cmdb_ci_docker_image_tag] No additional attributes are discovered for this
child table.

Table Fields
Docker Container [cmdb_ci_docker_container] • Image ID [image_id]

• Command [command]
• Container created [container_created_at]
Discovery troubleshooting
The Knowledge Base on Hi contains several articles to help you troubleshoot discovery issues. There are
also a number of error messages that can help you figure out what went wrong with a failed discovery.
Discovery Troubleshooting Guide
KB0535181
Start here if you are experiencing symptoms, such as the inability for Discovery to
classify a discovered host, or the Shazzam probe not finding certain types of devices.
Discovery Error Messages
Discovery error messages on page 479

Start here for a list of error messages and possible solutions.
Discovery error messages

Error messages and warnings in the system are documented to allow users to recognize the issues they
are having and to take steps to resolve their problems.
Common error messages
Input/output errors • CONNECTION_FAILED

• CONNECTION_TIMEOUT
• CONNECTION_REFUSED
• CONNECTION_CIPHER_UNSUPPORTED
• CONNECTION_PROTOCOL_UNSUPPORTED
• CONNECTION_LOST
• INVALID_CONNECTION_PARAMETER
• FILE_NOT_FOUND
• IO_ERROR
Authentication errors • NO_CREDENTIALS

• AUTHENTICATION_FAILED
• INVALID_CREDENTIALS_TYPE
SSH errors • SSH_SHELL_UNSUPPORTED

• SSH_SCRIPT_TRANSFER_FAILED

• SSH_INVALID_SESSION
Windows errors • POWER_SHELL_VERSION_UNSUPPORTED
Command errors • COMMAND_TIMEOUT

• INVALID_COMMAND
• COMMAND_FILTER_ERROR
• COMMAND_PARSER_ERROR
• COMMAND_KEY_MAPPER_ERROR
• COMMAND_VALUE_NORMALIZER_ERROR
• TERMINAL_SESSION_LOST_ERROR
• TERMINAL_SESSION_ENVIRONMENT_MODIFICATION_ER
Generic component errors • INVALID_COMPONENT

• INVALID_COMPONENT_PARAMETER
• INVALID_OPERATION
General error messages
Message: org.xml.sax.SAXParseException: The A version of this message occurs if you have used
entity name must immediately follow the '&' in special characters in a password that is saved in an
the entity reference XML file.
Message: Identified, ignored extra IP This message can appear during the identification
phase of Discovery if a targeted IP address belongs
to a device that is being discovered at the same
time.
For example, a Windows server has two NIC
cards with two IP addresses. Discovery targets
both IP addresses within the same Discovery
schedule. This message is generated to note that
that second IP address is ignored because we don't
want to update the same CI twice within the same
Discovery run.
This message is a warning and is expected. No
action is needed.
Message: Authentication failures The discovery process could not discover the
CI because the discovery application could not
authenticate. To resolve, add the credentials of that
machine in to the discovery credentials table.
Message: Identified, not updating CI, now No match on any of the CI Identifiers.
finished
Message: The impersonation of user failed This message originates in the Powershell. Check
that the domain is specified along with the user
name in the credentials.
Message: Connection failed to WMI service. This message originates in WMI. Check that the
Error: Permission denied MIS Server service is running with the correct
credentials and has access to the target device.

To check this, run the following command from the

command prompt on the MID server host:
wmic /node:target /user:user /

password:password path
win32_operatingsystem
target = IP address of target device
user = user account used by the mid
server service
password = password used by the mid
server service
Message: Connection failed to WMI service. This message originates in WMI. Check that the
Error: The remote server machine does not exist MID Server service account has access to the
or is unavailable targeted machine. Check if a domain admin account
is used as the MID server service account? Check
if any existing firewalls are open to the connection.
To check this, run the following command from the
command prompt on the MIS Server host.
Execute for runner_type=WMI:
wmic /node:"<target>" /
user:"<user>" /password:"<password>"
path win32_operatingsystem
From within a Powershell console on
the mid server host, execute for
runner_type=Powershell:
gwmi win32_operatingsystem -computer
<ip> -credential '<username>'
Message: Provider is not capable of the WMI repository was corrupted. After following
attempted operation this article the problem was corrected: http://
blogs.technet.com/b/askperf/archive/2009/04/13/
wmi-rebuilding-the-wmi-repository.aspx
Message: The result file can't be fetched PRB581515 - Powershell does not work when
because it doesn't exist customer has locked down write rights to admin
share.
Message: Please run sneep as root to ensure The Oracle Sneep command line tool must be
correct serial number from fserial data source installed for the Solaris - Serial Number probe to
work correctly. There is a known limitation with
Fujitsu PRIMEPOWER devices. To work around
this limitation, run the Solaris discovery with root
credentials.
Discovery sensor error messages
Message: The multisensor will not process

because its major version = X while
probe_name responding script's major version
=Y
Message: The multisensor will not process
because its responding script's major version =
X while its referenced probe probe_name major
version = Y

Message: sensor_name sensor's major version The above error messages indicate that there is a
= X while its related probe's major version = Y major version mismatch in the probe and sensor
versions and the sensor will stop processing until
this condition is resolved.
Message:sensor_name multisensor's minor
version = X while probe_name responding
script's minor version = Y
Message: sensor_name multisensor's
responding script's minor version = X while its
referenced probe probe_name minor version =
Y
Message: sensor_name sensor's minor version The above error messages indicate that there is a
= X while its related probe's minor version = Y minor version mismatch in the probe and sensor
versions. Processing will continue, but you may
want to resolve this condition
Message: Message: Sensor error when Every active probe looks for a corresponding sensor
processing . . . : No sensors defined to process the data that is collected by the probe.
The No sensors defined message indicates that the
corresponding sensor for the probe is missing or
inactive.
Message: Message: Sensor error when This type error message occurs to indicate the
processing . . . : typeError: . . . sensor has one of the core error constructors in
JavaScript
Message: Message: Sensor error when This XML parsing error occurs when the discovery
processing ...: Exception while processing sensor fails to parse the input ECC queue payload.
sensor: XML Parse Problem: ![CDATA] The payload is not formatted according to XML
specifications. Possible solutions include:
• Escape problematic characters. For example,
change < to &lt and & to &amp.
• Escape entire blocks of text with CDATA
sections, or put encoding declarations at the
start of the text.
• Remove any whitespace characters (space,
tabs, newlines) before the XML declarations.
Message: Message: Sensor error when The system displays the No XML data error when
processing Linux - Network ARP Tables: the XML sensor processor fails to #nd the expected
Exception while running probe post processing XML data in the probe output. During sensor
script: No XML data processing, Discovery attempts to retrieve the
probe results but finds the probe output empty.
Verify that the probe returns the correct output for
the sensor to process.
Message: Message: Sensor error when The Probe not found error occurs when the
processing Shazzam: Exception while running sensor processor fails to #nd the probe record
probe post processing script: Probe not found: supposedly associated with the sensor. During
null sensor processing, Discovery gets the probe
record from the probe cache and stores it for later
reference. The "Probe not found" error occurs either
when the sys_id of the probe cannot be found or
there is an issue with the probe cache.

See Find the cause of a "Probe not found" error on

page 485 for more information.
Find the cause of a sensor error message

Use this procedure to identify a Discovery sensor error.
This process requires that you identify the following:
• The error.
• The name of the sensor where the error occurred.
• The datestamp of the error.
• The associated stack trace of the error.
1. Navigate to Discovery > Discovery Log.

2. To find the error, filter on the Level name of Error.
You can also view the error and the date stamp in the Error Report on the Discovery dashboard.
3. Note the Created field of the error record.
This timestamp is used to find the proper stack trace.
4. Note the Short Message field of the error record.
This field shows the name of the sensor where the error has occurred. In this example, a generic
sensor error occurred in the SMI – Fiber Channel Switch sensor at 4:03 on 10-24-2014.
Figure 132: Error message in fiber channel switch sensor
In this example, a sensor TypeError occurred in the Windows – Installed Software sensor.
Figure 133: Error message in installed software sensor for Windows
5. To find the stack trace, navigate to System Logs > Errors.

6. Search for the date and time that matches the value in the Created field of the error record in the
discovery log.
7. The Message field of that entry contains the full stack trace of the error.
The stack trace contains the error message, the sys_id of the script, and the line number where the
error occurred. This stack trace shows the following errors:
• Line 1 and 2: There was a JavaScript evaluation error on new DiscoverySmiFcSwitchSensor().
• Line 3: The Ci.controller variable is undefined.

• Line 4: This script_includes line indicates the sysid 7780111 ... d768 and the error occurred at
approximately line 26 of the JavaScript file.
Figure 134: Stack trace
8. After determining the error details, you can fix the JavaScript file.
Identify cause of No Sensor Defined error message

Every active probe looks for a corresponding sensor to process the data that is collected by the probe. The
No Sensors Defined message indicates that the corresponding sensor for the probe is missing or inactive.
To find the cause of this error, identify the Short Message field of the error record. This field shows the
name of the probe for which the sensor is missing.
1. Navigate to Discovery > Discovery Log.
2. Filter on the Level name of Error.
You can also view the Error Report on the Discovery dashboard.
3. Note the Short Message field of the error record
This field shows the name of the sensor. In this example, the sensor error occurred when the
Shazzam probe checked for the existence of the Shazzam sensor.
Figure 135: Stack trace for No Sensor Defined error

Fix the cause of a sensor error message

To fix a Discovery sensor error message, you must fix the JavaScript file containing the code that
generated the error.
To fix the JavaScript file:
1. Navigate to the module in Discovery in which the error occurred.
In this example, navigate to Discovery Definition > Script Includes.
2. Fix the error.
a) In this example, search for DiscoverySmiFcSwitchSensor in the Name field.
Figure 136: Discovery script includes
b) Click on the link to go to the details page for that script include.
c) Modify the JavaScript script on that page to fix the error indicated.
d) Click Update.
Find the cause of a "Probe not found" error

Verify the correct sys_id of the probe associated with the probe parameter in the payload of the ECC
Queue input record.
1. Record the sys_id of the probe as it appears in the ECC Queue payload.

Figure 137: ECC Queue payload sample
2. Navigate to Discovery Definition > Probes and open the record for the probe you want to inspect.
3. Right-click in the record's header bar.
4. Select Copy sys_id from the context menu. Follow browser instructions to copy the sys_id if browser
security measures restrict this function.
5. Compare this value with the sys_id of the probe from the payload.
If the sys_id of the probe record does not match the value in the payload, try to determine the cause of
the incorrect value.
Content packs for Discovery

Performance Analytics Solutions contain preconfigured dashboards. These dashboards contain actionable
data visualizations that help you improve your business processes and practices.
Note: You can activate Performance Analytics content packs and in-form analytics on instances
that have not licensed Performance Analytics Premium to evaluate the functionality. However, to
start collecting data you must license Performance Analytics Premium.
Content packs
The Performance Analytics widgets on the dashboard visualize data over time. These visualizations allow
you to analyze your business processes and identify areas of improvement. With content packs, you can
get value from Performance Analytics for your application right away, with minimal setup.
Note: Content packs include some dashboards that are inactive by default. You can activate these
dashboards to make them visible to end users according to your business needs.
To enable the content pack plugin for Discovery, an admin can navigate to System Definitions > Plugins
and activate the Performance Analytics - Content Pack - Discovery plugin.
Application Profile Discovery - Legacy

Application Profile Discovery (APD) is deprecated in the Helsinki release. Instances upgraded from a
previous release can continue to use APD, but the feature is not available for new instances.
Application Profile Discovery (APD) enables Discovery to identify custom applications or applications that
contain multiple processes and determine their dependencies by using pre-populated data.
The information that Discovery uses to do this appears in an XML file, created by an administrator, and
installed in your environment. The administrator saves this environment file to a location on a managed

system (host, node, server, platform, or other device that is present in the CMDB) where probes launched
by the MID Server are configured to look for it. Discovery uses the data in this file to establish the
relationships between the application and the business services it supports. In addition to the environment
file, the administrator creates a version file containing general information about the application and the
version that Discovery uses to describe the application.
The diagram shows a hypothetical relationship between the SAP application and another application
created by a common business service. APD is able to discover both SAP and the dependencies created
by the shared business service by using information contained in an environment file called sap.xml
installed on the managed system. Version information is contained in the sap_version.xml file which is
installed in a different location on the same managed system or proxy server.
Figure 138: Application Discovery Instrumentation Diagram Rev
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
Included with Application Profile Discovery - Legacy

This is a list of elements included with Application Profile Discovery.
Application Profile Discovery supports the use of MID Servers configured for PowerShell to discover
applications on Windows machines.
Name Description
Table

Name Description
Application Classification Stores the results of application discoveries.

[discovery_classy_appl] Access application CIs in this table by navigating
to Discovery Definition > CI Classification >
Application.
Environments [cmdb_ci_environment] Stores the Environment details.
Environments [cmdb_environment_to_ci] Stores many-to-many record that link the
environment record to the CI.
Category
DiscoveryAPDVersionSensor Processes the APD version file
DiscoveryAPDSensor Parses the application files
DiscoveryAPDEnvSensor Processes the APD environment file
Normalizing business service names - Legacy

The name of a business service used in an Application Profile Discovery environment or version file might
not be an exact match for an existing business service name in the ServiceNowServiceNow CMDB.
For example, the creator of the environment file might define a business service as Management tools,
but in the CMDB, that business service appears as Management tool (singular). This can occur if the
administrators who manage profile Discovery and the CMDB fail to standardize the names. Discovery
assumes that these are two separate business services and creates separate records, one for each
version of the name. To eliminate duplication, normalize all business service names after running a new
Application Profile Discovery.
Environment file - Legacy

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.
Environment File Template
Use the following XML template for your environment file.
<?xml version="1.0" encoding="UTF-8"?>

<apd>
<config version="1.0" application="(optional) application-name"
type="environment" system=" (optional, if not local system) managed system
name">
<environment>
<label> environment-name </label>
<description> environment description </description>
<ownership> (optional) environment ownership information </ownership>
<business_service> (optional) business service name </business_service>
<application_version_path path="path to version file including filename…

"/>

<subservices>
<subservices_provided>
<subservice> … label … </subservice>
</subservices_provided>
<subservices_consumed>
</subservices_consumed>
</subservices>
</environment>
</config>
</apd>
Environment file fields - Legacy

Provide attribute and tag information in the environment configuration file.
Detail Requirement Description
Attributes
version Mandatory Version of this application.
application Optional. Discovery uses the Name of this application.
application name from the
version file to populate the
CMDB.
system Mandatory if this environment The system name represents
configuration file is installed on the managed system’s name,
a proxy server (the managed unique to a given system,
system cannot store custom to which this environment
files or is accessible to the MID configuration file belongs.
Server).
Tags
<label> Mandatory This label has information
important to the organization,
such as Production, UAT, QA,
or Development. The label and
description appear only in the
Environment related list in the
application record. You must
personalize the form to add the
Environment related list.
<description> Optional This is a short description of the
application.

<ownership> Optional If ownership is not specified

here, then it must be configured
in the version file. This
value is typically a group-
level ownership label that
may be mapped to an
existing group in the Group
[sys_user_group] table.
This value appears in the
Support group field in the
ServiceNowServiceNow
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.
<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.
Environment configuration file location - Legacy

Environment files are stored on and collected directly from systems that support a general purpose file
system.
The MID Server searches for environment files on every machine it discovers, using the location
preferences described in this section. To provide flexibility in different environments, an administrator has
several options for installing environment files in a file system. The MID Server checks specific locations
on the managed systems it discovers in a particular order. When the MID Server finds a base environment
file, the MID Server quits searching on that device.
Note: Never place the version file in the same directory as the environment file. Discovery treats
all files found in that location as environment files and cannot parse the version file correctly.
UNIX
Place the environment files in one of the following locations. Discovery searches for the file in the order
shown.
1. Environment variable: Put the environment configuration file in a path such as /usr/local/APD
and set the variable, $APDCONF, to describe the location of the file. How this environment variable is
maintained is left to the administrators of the local environment.
2. Discovery property: Navigate to Discovery Definition > Properties and set the file
path in the Application Profile Discovery location for UNIX based systems property
(glide.discovery.application_discovery.unix_location). The default path is /etc/
opt/APD/.
Windows
Place the environment configuration file in one of the following locations on a Windows OS version that
supports a local machine registry.

1. Registry key: Before the MID Server retrieves a file from a managed Windows system, it checks the
HKEY_LOCAL_MACHINE (HKLM) hive, in the key HKLM\SOFTWARE\APD\APD\CONFIGPATH for
a REG_EXPAND_SZ or REG_SZ type registry value. The key value can require expansion for terms
such as %CommonAppDataFolder%. See Microsoft’s CSIDL documentation for further details.
Figure 139: APD Win Registry
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" >

APD Version file - Legacy

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.
Version File Template
Use the following XML template for the version file.
<?xml version="1.0" encoding="UTF-8"?>

<apd>
<config version="1.0" application="application-name" type="version">
<version>
<label>version-name-label</label>
<description>version description</description>
<ownership>software package ownership information</ownership>
<subservices>
<subservices_provided>
</subservices_provided>
<subservices_consumed>
</subservices_consumed>
</subservices>
</version>
</config>
</apd>
Version File Configuration
The version configuration file contains the following information:

• Application details
Application Details
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 Name of this application.

the application name from the
version file to populate the
CMDB.
Tags
<label> Optional This label has information
important to the organization,
such as Production, UAT, QA,
or Development. The label and
description appear only in the
Environment related list in the
application record. You must
personalize the form to add the
Environment related list.
<description> Optional This is a short description of the
application.
<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 ServiceNowServiceNow
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.
Application Profile Discovery example in Linux environments - Legacy

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

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

After you create the ADP directories, enable ADP through a property and specify the ADP directory you
created for the ResourceNow environment file.
1. Navigate to Discovery Definition > Properties.

2. In the Application Profile Discovery field , select Yes.

This field maps to the glide.discovery.application_profile_discovery property.
3. Use the appropriate Application Profile Discovery location field (for UNIX or Windows) to name the
path to the /APD directory you just created for the ResourceNow environment file.
In this example, the file system is UNIX-based, so define the /APD path in the Application
discovery location for UNIX based systems property. This field maps to the
glide.discovery.application_discovery.unix_location property.
Figure 140: Application Discovery Properties
4. Click Save.
Create the APD environment file - Legacy

After creating the APD folder, create the environment file.
1. In an XML editor, open the environment file template and complete it for the ResourceNow application
using the following values:
Option Description
Version: Enter 2.0.

Application: Name the application ResourceNow.
Label: Configure Development as the name for this
environment.
Description: Enter Development environment for this
example.
Ownership: Add the name of an existing group from the
Group [sys_user_group] table that is
responsible for managing this environment. For
this example, add Software.
Version path: Enter the path and the name of the
version you will create in the next task.
For this example, enter /APD_version/
ResourceNow_version.xml, where
ResourceNow_version.xml is the name of the
version file.
Sub-services provided: Name this sub-service Benefits.

Option Description
Sub-services consumed: Name this sub-service Management tool.
Figure 141: Environment File Template
2. Give the environment file a logical name, such as the name of the application (ResourceNow.xml) and
save it to the /APD directory.
Create the APD version file - Legacy

After creating the environment file, create the ADP version file.
Note: Do not save the version file in the same directory as the environment file. Discovery cannot
process version data found in the environment directory.
1. In an XML editor, open the version file template and complete it for the ResourceNow application
Option Description
Version: Enter the version number for this application. For

this example, enter 2.0.

Option Description
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.
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.
Figure 142: Version file example
3. Save the file in the /APD_version directory created in Create the APD Directories.
Classify the custom application for APD - Legacy

For Discovery to classify the custom application, you must create a classification record in the CMDB.


You can create a classification record in CMDB to classify a custom application.
1. Navigate to Discovery Definition > CI Classification > Application and click New.
2. Complete the Application Classification record, using the following values:
Option Description
Name: Enter the application name that should

appear in the CMDB. For this example, enter
ResourceNow.
Table: Select Application [cmdb_ci_appl] from the list
of tables.
Relation type: Select the relationship of the application to the
host on which it runs. For this example, select
Runs on::Runs.
4. Go to the Classification Criteria related list, click New.
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:
Option Description
Operator: Select contains.

Value: Enter ResourceNow.

Figure 143: Application Classification Record
8. Click Update.

Run Discovery for APD - Legacy

When Discovery runs, the MID Server checks for environment files in the directory specified in the location
property (/APD/ in this example).
The MID Server parses the ResourceNow.xml environment file and finds the path to the
ResourceNow_version.xml file. The contents of both files are used to construct the relationships of the
application to its configured business services and to the computer on which it runs.
You can see these relationships in the following records:
• CI record for the computer host
• Application CI record
• Dependency view (BSM map)
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.

Figure 144: Host Computer CI Record

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.
Figure 145: Application CI Record
For more information, view the environmental details.

Dependency view (BSM map)
To see a graphical representation of the relationship between this application, its business services, and
the computer on which it runs, open the CI record for the computer host. Then, click the dependency view
(BSM map) icon in the header bar of the CI Relations Formatter. The map shows all the business
services and applications associated with the computer host, as well as the installed hardware.
Figure 146: Dependency view (BSM map) example

Application Profile Discovery example in Windows environments - Legacy

about the application for all the systems on which it is installed.
Use a property for Windows systems to set the path location for the environment file. The default path
is %ALLUSERSPROFILE%\Application Data\APD, where %ALLUSERSPROFILE% is the environment
variable for any Windows system. This variable points to different paths on different versions of Windows.
For example, on Windows 7, %ALLUSERSPROFILE% opens C:\ProgramData, and on Windows 2003
server it opens C:\Documents and Settings\All Users.
Complete the following tasks:
Create the APD Folder on a Windows 2003 server - Legacy

The first step in this example is creating the ADP folder on a Windows 2003 server.
1. Open Windows Explorer and enter %ALLUSERSPROFILE% in the address bar, then press Enter.
The complete path defined by that variable appears in the address bar.
Figure 147: Windows Explorer 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 Create the Environment File and copy the completed environment file
from that task into the APD folder you created.
Create the APD environment file - Legacy

After creating the APD folder, create the environment file.
1. In an XML editor, open the environment file template and complete it for the ResourceNow application
Option Description
Version: Enter 2.0.

Application: Name the application ResourceNow.
Label: Configure Development as the name for this
environment.
Description: Enter Development environment for this
example.
Group [sys_user_group] table that is
responsible for managing this environment. For
this example, add Software.
Version path: Enter the path and the name of the
version you will create in the next task.
For this example, enter /APD_version/
ResourceNow_version.xml, where
ResourceNow_version.xml is the name of the
version file.
Sub-services provided: Name this sub-service Benefits.
Sub-services consumed: Name this sub-service Management tool.

Figure 148: Environment File Template
2. Give the environment file a logical name, such as the name of the application (ResourceNow.xml) and
save it to the /APD directory.
Create the APD version file - Legacy

After creating the environment file, create the ADP version file.
Note: Do not save the version file in the same directory as the environment file. Discovery cannot
process version data found in the environment directory.
1. In an XML editor, open the version file template and complete it for the ResourceNow application
Option Description
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.

Option Description
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.
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.
Figure 149: Version file example
3. Save the file in the /APD_version directory created in Create the APD Directories.
Application Profile Discovery example with proxy servers - Legacy


about the application for all the systems on which it is installed.
Some devices that you want to discover might be inaccessible to the MID Server. Examples
of this are mainframe computers, a server whose credentials are not in the Credentials
[discovery_credentials] table, and a switch that does not have a file system for storing XML files.
For such devices, create an environment file that identifies the inaccessible device, and then put that file on
a proxy server where the file is visible to the MID Server. Place the version file on the same proxy server,
but in a different directory than the environment file. The MID Server locates the environment file in one of
the expected locations on the proxy server and reads the path to the version file. The MID Server includes
the environment and version data in the sensor package, without exploring the hidden system.
Complete the following tasks in the order in which they are listed:
Create APD files for an SAP application on a server - Legacy

The first step in this example is to create APD files for an SAP application on a server (any OS) for which
no credentials are available.
1. Navigate to Discovery Definition > Properties and find the property for the proxy server's operating
system.
In this example, use the Application discovery location for UNIX-based systems property
(glide.discovery.application_discovery.unix_location) for a Linux proxy server. This example uses the
default path of /etc/opt/apd/, although it could use any path.
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.
Option Description
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.

Figure 150: SAP Environment File Template
4. Save the environment file to the /etc/opt/apd/ directory.

5. Create the version file directory using the path specified in the environment file.
For this example, create a directory called apd_version on the same level as the apd directory.
Remember that the version file cannot be in the same directory as the environment file.
6. Use the template to create a version file called sap_version.xml and save it to the /etc/opt/
apd_version directory.
7. Continue the process at Classify the Application.
View the environmental details - Legacy

After you classify an application, you can view the environment details from an application CI record.
1. Configure the form to display the Environment related list.

Figure 151: Environment Related List
2. Click Development in the related list to see the environment details.

The value in the Support group field is the ownership value from the ResourceNow.xml environment
file.
Figure 152: Environment Details
Application Profile Discovery customization - Legacy

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.

Legacy APD customization example: Customize the APD environment file

This example adds a value to the environment file that populates the comments field of the ResourceNow
application record.
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.
This example adds a value to the environment file that populates the comments field of the ResourceNow
application record.
1. Open the existing environment file in an XML editor.
2. Add a new XML tag within the <environment> tags, at the end of the last subservices section.
Figure 153: Custom Environment Record
The tag name is arbitrary. This example uses <custom>, but the tag could also be named <notes>.

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.
Legacy APD customization example: Customize the APD version File

This example adds a value to the version file that populates the asset_tag field of the ResourceNow
application record.
This example adds a value to the version file that populates the asset_tag field of the ResourceNow
application record.
1. Open the existing environment file in an XML editor.
2. Add a new XML tag within the <version> tags, at the end of the default subservices section.
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.
Legacy APD customization example: Update the APD classification script

After you customize the version file, you must update the classification script.
1. Navigate to Discovery Definition > CI Classification > Application and open the Application
Classification record for your application.
2. In the On classification script field, configure the classifier to return the data from the environment
and version files.
This example uses the following script:
var appdata = ciData.getData();

appdata.<asset_tag> =
versionResult.config.version.custom.<asset_tag>;
appdata.<comments> =
envResult.config.environment.custom.<comments>;
This script uses the appdata parameter to identify the field tags in each file. The remainder
of the statement shows the position in each XML file in which the data appears.

Legacy APD customization example: Personalize the APD application form

To display the information that Discovery returns from APD in this example, you must personalize the
Application form to display the necessary fields.
1. Navigate to Configuration > Applications.
2. Select the application from the list.
For this example, select ResourceNow.
3. Right-click the header bar of the Application record and select Personalize > Form Layout from the
context menu.
4. Add the Asset tag and Comments fields.
5. Save the changes.
Legacy APD customization example: Run Discovery to add APD data to the
CMDB
Finally, run Discovery.
Run Discovery to add the custom Application Profile Discovery data to the CMDB. The values you
specified in the XML files appear in fields on the Application record.
Service Mapping
The ServiceNow® Service Mapping application discovers all business services in your organization and
builds a comprehensive map of all devices, applications, and configuration profiles used in these business
services. Service Mapping maps dependencies, based on a connection between devices and applications.
This method is referred to as top-down mapping. The top-down mapping helps you immediately see the
impact of a problematic object on the rest of the business service operation.
Service Mapping is available as a separate subscription and requires activation by ServiceNow personnel.

• Service Mapping release notes • Service Mapping setup on • Plan business services on
• Upgrade to Istanbul page 537 page 614
• Get started with Service • Request Service Mapping on • Video: Service Map Planner
Mapping on page 515 page 538 • Business service definition on
• Applications supported by • MID Server configuration for page 628
Service Mapping on page Service Mapping in upgraded
523 deployments on page 705
• Advanced Service Mapping
configuration on page 702
• Video: Advanced Service
Mapping features
Use Develop Troubleshoot and get help

• Business service analysis and • Developer training • Video: Troubleshooting
maintenance using maps on • Developer documentation Service Mapping
page 666 • Pattern customization on page • Troubleshoot maps in Service
• Video: Service Mapping basics 730 Mapping on page 657

• Ask or answer questions in the

ITOM community
• Search the HI knowledge base
for known error articles
• Contact ServiceNow Support
Get started with Service Mapping

ServiceNow® Service Mapping discovers all business services in your organization and builds a
comprehensive map of all devices, applications, and configuration profiles used in these business services.
A business service is a set of interconnected applications and hosts which are configured to offer a service
to the organization. Business service can be internal, like organization email system or customer-facing,
like an organization web site. For example, creating financial reports through a web-based application
requires a computer, web server, application server, databases, middleware, and network infrastructure.
These applications and hosts are all configured to offer the service of financial reporting.
Typically, IT departments create and maintain an inventory that treats devices and applications as
standalone, independent objects. Connections between the devices and applications are not included. This
is usually referred to as horizontal discovery. This method does not address the biggest challenge for IT
departments, which is understanding the connection and dependencies between each object.
Service Mapping maps dependencies, based on a connection between devices and applications. This
method is referred to as top-down mapping. The top-down mapping helps you immediately see the impact
of a problematic object on the rest of the business service operation.
Figure 154: Comparison of horizontal and top-down mapping results

Business service maps show infrastructure objects and semantic connections between them. Service
Mapping regenerates business service maps regularly, to keep them updated and relevant. Any faulty
objects are shown along with the devices and applications they affect, providing a visual clue of the state of
the business service.
Data collected and organized by Service Mapping is visible in Event Management and Dependency Views.
With Event Management, you can view events to take actions for recovering your organization business
services. Dependency Views shows relationships between devices and applications in the context of
business services they belong to.
Service Mapping supports domain separation. If your ServiceNow platform uses domain separation,
administrators and users can only see and manage business services belonging to their own domain.
Business services
to the organization. Business service can be internal, for example organization email system, customer-
facing, or an organization web site.
ServiceNow applications, including Service Mapping, refer to devices, applications, and connections that
comprise a business service as configuration items (CIs). Service Mapping creates a map of a business
service by communicating with its individual CIs belonging to this business service, identifying the CI
connections, and mapping the CIs.
To reflect the importance or impact of each business service on the operations of your organization, you
can select a criticality level for them. For example, you might select a high level for a business service
that supports sales functionality using the organization web site. You might then select a lower level for a
business service that provides internal printing for the organization employees.
Criticality assigned in Service Mapping defines the prominence of a business service on the Event
Management dashboard. You can also use a criticality value to define recovery strategies.

Figure 155: Example of a business service criticality on the Event Management dashboard
You can control user access to business services.
Pattern-based discovery flow in Service Mapping

Service Mapping collects data about devices and applications used in business services in your
organization. It then creates a map of business services and stores the collected data in the CMDB.
In Service Mapping and Discovery, devices and applications are referred to as configuration items (CIs).
The main method of Service Mapping discovering and mapping CIs is using patterns as discussed below.
Service Mapping can also discover CIs by following traffic connections between CIs. This method is
referred to as traffic-based discovery.
Service Mapping uses patterns to discover and map CIs. A pattern is a sequence of operations whose
purpose is to establish attributes of a CI and its outbound connections. A typical Service Mapping pattern
consists of two types of algorithms for:
• identifying CIs
• finding CI connections
The starting point of any discovery process is an entry point. An entry point is a property of a connection
to a configuration item (CI). For example, to map your electronic mailing business service, define an email
address. The discovery and mapping process begins from Discovery performing the horizontal discovery
to identify the host. Once the host discovery is complete, Service Mapping starts the top-down discovery to
find and map applications running on this host.
Service Mapping uses MID Servers to communicate with CIs in your organization. MID Servers are located
inside your organization network and Service Mapping can communicate with them without traversing
firewalls.

The discovery and mapping process consists of the following interactions:

1. A user defines an entry point for an application CI.
2. The device hosting the application is identified:
a. Service Mapping checks if the device hosting this application CI exists in CMDB.
b. If not, Service Mapping triggers Discovery to perform host detection.
c. Discovery creates the first set of probes for port discovery (Shazzam) and places them as a
discovery request in the External Communication Channel (ECC) queue.
d. The MID Server checks the ECC queue and retrieves the discovery request assigned to it.
e. The MID Server runs the probes against the host and discovers open ports.

f. The MID Server passes information on the host ports to the ECC queue.
g. Discovery checks the ECC queue and receives information on the host ports.

h. These steps are repeated for other types of probes: classification, identification, and exploration.
i. Discovery adds the host to CMDB.
j. During the host discovery using probes, Service Mapping checks the ECC queue if this process is
complete. When the host discovery is complete, Service Mapping checks whether this host exists
in CMDB.
3. Once the host is found in CMDB, Service Mapping discovers the application running on this host:
a. Service Mapping creates an application discovery request for the IP address of the entry point. It
then writes the request in the ECC queue and assigns a MID Server to the request.
b. The MID Server checks the ECC queue and retrieves the discovery request assigned to it.
c. The MID Server starts running identification sections of the pattern to find the match for the entry
point. When the identification section matches the entry point, the pattern discovers a CI.

d. The MID Server starts running connectivity sections of the pattern to find outgoing connections of
the newly discovered CI.
e. The MID Server passes information on the discovered CI, its attributes, and connections to the
ECC queue.
f. Service Mapping checks the ECC queue and receives information on the newly discovered CI.
g. Service Mapping writes the information into the CMDB and adds this CI to the business service
map.

h. Service Mapping creates the discovery requests for all applications to which the newly discovered
CI connects. Mapping is complete after Service Mapping maps a CI that does not have any
outbound connections or is marked as a boundary.
Traffic-based discovery in Service Mapping

Service Mapping uses traffic connections to collect network statistics and perform traffic-based mapping.
The major way of Service Mapping collecting data is by using patterns. However, Service Mapping can
also discover CIs by following traffic connections between CIs. This method is referred to as traffic-based
discovery.
Using traffic-based discovery is like casting a finer net, allowing Service Mapping to find even those CIs
that it failed to discover using patterns. The advantage is discovering more CIs, at the same time this
method may clutter a business service with irrelevant CIs. Typically, you use traffic-based discovery at the
initial stages of discovering a business service and disable it once you completed discovery and fine-tuned
Service Mapping detects inbound and outbound connections using the netstat and lsof commands as well
as the Netflow protocol. The Netflow-based discovery is not enabled by default and must be configured.
Service Mapping detects inbound and outbound connections using the netstat and lsof commands.
You can enable traffic-based discovery at different levels listed here from the most global to the most
specific:
• Product level
In the base system, traffic-based discovery in Service Mapping is enabled. If necessary, you can fine-
tune or disable traffic-based discovery at the product as described in Properties installed with Service
Mapping under Installed with Service Mapping on page 526.
• Business service level
As part of defining a business service, you can enable traffic-based discovery for it. In this case, Service
Mapping uses this method for all CIs making up this business service, unless traffic-based discovery is
disabled for some CI types or specific CIs.
• CI type level
You can create a discovery rule to include or exclude a CI type from traffic-based discovery. This rule
prevails over the setting you choose for a business service.
• Specific CI level
You can create a discovery rule to include or exclude a specific CI from traffic-based discovery. This
rule prevails over the setting you choose for a business service.
Rules for specific CIs take precedence over rules for CI types. For example, if you do not want to use
traffic-based discovery on any Tomcat servers, you can define a CI type rule disabling the traffic-based
discovery on the Tomcat table. At the same time, you can create a discovery rule enabling the traffic-
based discovery for a specific Tomcat server. In that case, Service Mapping uses the traffic-based
discovery only for this specific Tomcat server out of all Tomcat servers.

While using traffic-based discovery creates a more inclusive map, it may also result in mapping many
redundant CIs that do not influence the business service operation. You can choose to hide CIs discovered
using this method from a business service map. In that case, these CIs are still part of the business
service, but they are not on its map.
Applications supported by Service Mapping

In a base system, Service Mapping supports a wide range of operating systems and applications.
If your organization uses applications, which are not in this list, you can configure Service Mapping to
support it as described in Pattern customization on page 730.
Operating systems
• AIX
• HP-UX
• Linux
• Solaris

• Windows
Applications
• ABAP SAP Central Services (ASCS)

• Active Directory Domain Controller
• Apache Tomcat
• Apache Tomcat WAR
• Apache Web Server
• App TNS Service
• BIG-IP Global Traffic Manager (GTM) F5
• BIG-IP Local Traffic Manager (LTM ) F5
• BMC CTRL-M Enterprise Manager
• BMC CTRL-M Gateway
• BMC IT Asset Management (ITAM)
• CA Identity Manager Provisioning Server
• Cisco ACE Command Line Interface (on Cisco CSM)
• Cisco Global Site Selector (GSS)
• Citrix Delivery Controller
• Citrix Netscaler
• Connect-IT Service
• DataPower
• EMC Documentum Docbase
• FormEngine
• Generic application
• GlassFish Server
• HAProxy
• HP Service Manager Application Server
• HP Service Manager Index
• HP Service Manager Knowledge Base
• IBM WebSphere Message Broker
• IBM CTRL-M Server
• IBM CICS Transaction Gateway CTG
• IBM Customer Information Control System (CICS)
• IBM DB2
• IBM J2EE EAR
• IBM J2EE EAR
• IBM Websphere Application Server
• IBM WebSphere Message Broker Flow
• IBM WebSphere Message Broker
• IBM WebSphere MQ
• IBM WebSphere MQ Queue
• IBM WebSphere Portal
• Jboss
• Jboss Module
• JRun
• JRun WAR Inc
• Microsoft BizTalk Orchestration
• Microsoft BizTalk Server

• Microsoft Dynamic CRM

• Microsoft Exchange BackEnd Server
• Microsoft Exchange CAS
• Microsoft Exchange FrontEnd Server
• Microsoft FAST Search Server
• Microsoft Exchange Hub Transport Server
• Microsoft Exchange Mailbox
• Microsoft Internet Information Services (IIS)
• Microsoft Internet Information Services (IIS) Virtual Directory
• Microsoft Message Queuing (MSMQ)
• Microsoft .NET Framework
• Microsoft SharePoint
• Microsoft SQL Database
• MySQL Cluster MGM Node
• MySQL Server
• Nginx
• Oracle Advanced Queue Queue
• Oracle Concurrent Server
• Oracle Database
• Oracle Discoverer Engine
• Oracle Discoverer UI
• Oracle E-Business Suite
• Oracle Form UI
• Oracle Fulfillment Server
• Oracle HTTP Server
• Oracle iAS Web Module
• Oracle Metric Client
• Oracle Metric Server
• Oracle Net Listener
• Oracle OACORE Server
• Oracle OAFM Server
• Oracle Process Manager
• Oracle Report Server
• Oracle Tnslsnr Engine
• Oracle Tuxedo
• Oracle Tuxedo Portal
• Oracle WebLogic Module
• Oracle WebLogic Server (version 10.3)
• Oracle WebLogic On-demand Router Load Balancer
• PostgreSQL Database
• RabbitMQ
• SAP BO BOXI ScheduleRouter
• SAP Business Objects CMS Server
• SAP Central Instance
• SAP Central Services (SCS)
• SAP Evaluated Receipt Settlement (ERS)
• SAP HANA Database
• SAP Java Cluster
• SAP NetWeaver Dialog Instance
• SQL Server Analysis Services (SSAS)

• SQL Server Integration Services (SSIS) Job

• SQL Server Integration Services (SSIS)
• Sun iPlanet Web Server
• Sun Directory
• Sun JES
• Sybase
• Symantec Enterprise Vault
• Tibco ActiveMatrix BusinessWorks
• Tibco ActiveMatrix BusinessWorks Process
• Tibco EMS Queue
• Tibco Enterprise Message Service (EMS)
Installed with Service Mapping

Several types of components are installed with Service Mapping.
Tables installed with Service Mapping
Service Mapping adds the following tables.

Table Description
Applicative Credentials This table contains credentials used when

running application-specific commands on
[sa_applicative_credentials]
servers.
BaseLines This table contains storing points in the time
defined as baselines for business services.
[sa_baselines]
Business Service User preferences This table contains user preferences associated
with a specific business service.
[sa_business_service_user_prefs]
Service Mapping CI attributes This table contains CI attributes relevant only for
discovery process.
[sa_ci_attr]
Related CI Types This table assigns CI types to patterns (relevant

only for the horizontal discovery performed by
[sa_ci_to_pattern]
Discovery).
Label This table maps CI types to icons which
represent CI types in the business service map.
[sa_ci_type_icon]
Menu Action This table contains data on configurable menu

options for CIs in the business service map.
[sa_context_menu]
Custom Operations This table contains data on planned

enhancements in the Pattern Designer. Not in
[sa_custom_operation]
use in this release.
Custom Operation Parameters This table contains data on planned
[sa_custom_operation_param]

Table Description
Custom Parsing Strategies This table contains data on planned

[sa_custom_parsing_strategy]
Pattern Debugger Session This internal table is used for the Pattern
Designer components.
[sa_debug_session]
Pattern Debugger Session Status for UI This internal table is used for the Pattern
Designer components.
[sa_debug_session_status]
Sa Deferred Service Discovery This internal table is used for Service Mapping
components.
[sa_deferred_service_discovery]
Service Discovery Log This table contains discovery logs collected by

Service Mapping.
[sa_discovery_log]
Service Discovery Messages This table contains messages created by

Service Mapping during service discovery.
[sa_discovery_message]
Planned Business Service This table contains data on planned services

created in Service Map Planner.
[sa_dw_business_service]
Components This table contains data on planned components

created in Service Map Planner.
[sa_dw_components]
Check Connectivity Result This table contains data on results of

connectivity test performed in Service Map
[sa_dw_connectivity_result]
Planner.
Connectivity Test This table contains data on connectivity tests
performed in Service Map Planner.
[sa_dw_connectivity_test]
Planned Custom Entry Point This table contains data on planned custom
entry points in Service Map Planner.
[sa_dw_custom_entry_point]
Planned Entry Point This table contains planned entry points used in
Service Map Planner.
[sa_dw_entry_point]
Planned Endpoint Attributes This table contains attributes of planned entry

point used in Service Map Planner.
[sa_dw_ep_attrs]
Import Errors This table contains import errors appearing in

[sa_dw_import_errors]
Phase This table contains planned phases in Service

Map Planner.
[sa_dw_phase]
Validation errors This table contains validation errors appearing in

[sw_dw_validation_errors]

Table Description
Sa Endpoint Status This table contains discovery status for

endpoints in Service Mapping.
[sa_endpoint_status]
nfdump file This internal table contains information used for

Netflow-based discovery.
[sa_flcon_file_nfdump]
nfdump install This internal table contains information used for

[sa_flcon_local_nfdump]
AWS VPC flow logs This internal table contains information used for
[sa_flcon_vpc_flow_log]
Flow Connection This internal table contains information used for

[sa_flow_connection]
Flow Connector This internal table contains information used for

[sa_flow_connector]
Flow Server Communication This internal table contains information used for
[sa_flow_server_comm]
Flow Services IP/Port and Statistics This internal table contains information used for
[sa_flow_service]
Hash This internal Service Mapping internal table

contains temporary statuses.
[sa_hash]
Host Class to Capability This table maps server type to capabilities

required by Service Mapping.
[sa_host_class_to_capability]
Infra Path To Elements This table contains data on components which

are part of a network path.
[sa_infra_path_assoc]
Boundary endpoints This table maps boundary endpoints to business

service. Not relevant in Istanbul.
[sa_m2m_boundary_ep_service]
Entry Point This table maps entry points to business service.

[sa_m2m_service_entry_point]
Manual Connections This table contains data on manual connections

created by user. Not relevant in Istanbul.
[sa_manual_connections]
Mapping External Discovery Commands This table contains data on customized

commands created by user.
[sa_mapping_ext_commands]
Network Paths This table contains data on network paths

discovered by Service Mapping.
[sa_network_paths]

Table Description
Discovered Service Notification This internal table contains data on notifications

between different parts of the software.
[sa_notification]
Horizontal Discovered Paged Payloads Service Mapping uses data in this table for
splitting payload sent from the MID Server.
[sa_paged_payload]
Discovery Patterns This table contains preconfigured and

customized patterns that Service Mapping uses
[sa_pattern]
for discovery.
Service Mapping Draft Pattern This table contains non-activated discovery
patterns.
[sa_pattern_draft]
Service Mapping Relation attributes This table contains relation attributes used
during service discovery process.
[sa_rel_attr]
Rel to Infra Path This table maps relations to network or storage

paths.
[sa_rel_to_infra_path]
Service Mapping Server Usage This table contains count of servers used by
Service Mapping.
[sa_server_usage]
Service Group Members This table maps service group to its business
service members.
[sa_service_group_member]
File System To Storage Path This table contains data on storage paths
discovered by Service Mapping.
[sa_storage_paths]
Storage Path Connectivity Map This table maps file system to storage volume.
[sa_storage_path_connectivity_map]
Business Service Group Responsibilities This table contains data on users having access
to business service groups.
[sa_svc_group_responsibilities]
Traffic Based Discovery Rules This table contains data on configuration of

traffic-based discovery.
[sa_traffic_based_rules]
Uploaded File This table contains data on files uploaded to the

MID Server and used by Service Mapping.
[sa_uploaded_file]
Properties installed with Service Mapping
Service Mapping adds the following properties.
Note: To open the System Property [sys_properties] table, enter sys_properties.list in

the navigation filter.

sa.storage_path_calculation.active Enable storage path calculation.

• Type: true/false
• Other possible values: false
• Location: Service Mapping >
Administration > Properties.
sa.update_paths_in_service_model.active Update network and storage paths in Service

Model.
sa.network_path_calculation.active Enable network path calculation.

sa.discovery_task_timeout_min Maximum time for a Service Mapping task

in minutes (including waiting for execution in
internal queues and ECC queue).
• Type: string
• Other possible values: any number higher
than 30
sa.debugger.max_timeout Maximum timeout (in seconds) since the last

server activity during a Pattern Debugger run.
• Type: integer
than 60

sa.max_concurrent_connections The maximum number of concurrent tasks sent

to an individual host.
• Type: integer
than 1
sa.rediscovery.batch_size Number of discovery tasks executed in a single

batch.
• Type: integer
than 10
sa.traffic_based_discovery.active Traffic-based discovery

sa.traffic_based_discovery.conn_aging_time Time period in hours for a Traffic Based

Connection to remain active since last
discovered.
• Type: integer
than 24

sa.traffic_based_discovery.ignored_ports Ports to ignore when found by traffic-based

discovery.
This property is available in the System Property
[sys_properties] table.
Change this property to define ports that Service
Mapping ignores while performing traffic-based
discovery. It makes discovery more efficient
since resources are not wasted on discovering
irrelevant connections.
• Type: string
• Default value: 445, 139, 111, 2049, 860,
3260, 135, 53
• Other possible values: any relevant port
numbers
• Location: System Property [sys_properties]
table
sa.traffic_based_discovery.max_connections Maximum number of traffic-based connections

from a single CI.
This property is available in the System Property
[sys_properties] table.
This property helps to keep the map size
reasonable by limiting the number of possible CI
connections.
• Type: integer
than 1
table
Roles installed with Service Mapping
Service Mapping adds the following roles.

Role title [name] Description Contains roles
Service Mapping administrator Sets up the Service Mapping • [sam_core_admin.sm_admin]

[sm_admin] application. Maps, fixes, and • [discovery_admin.sm_admin]
maintains business services. • [itil_admin.sm_admin]
Also performs advanced • [personalize_dictionary.sm_admin]
configuration and customization
of the product. Assign this role
to application administrators.

Service Mapping user Views business service maps • [sam_core_user.sm_user]

[sm_user] to plan change or migration, as • [itil.sm_user]
well as analyze the continuity
and availability of services.
Assign this role to application
users.
Service Mapping application Provides information necessary [sm_user]

owner for successful mapping of
[sm_app_owner] a business service. Once
a service is mapped, this
user reviews the results
and either approves it or
suggests changes. Assign the
sm_app_owner role to users
who own business services
and are familiar with the
infrastructure and applications
that make up the services.
Pattern Designer administrator Creates new and modifies [pd_user]

[pd_admin] existing patterns, which Service
Mapping and Discovery use for
performing horizontal and top-
down discovery.
MID Server for Service Mapping This role allows accessing [rest_service]
administrator Service Mapping tables
[pd_mid]
with minimal, but sufficient
[sm_mid]
permissions.
Script includes installed with Service Mapping
Service Mapping adds the following script includes.

Script include Description
SaUploadedFiles Gets user uploaded files from the MID Server.

LoadRoutingTable Returns the routing table for the given host.
GetOutgoingPort Returns the outgoing port ID for the given host
based on the target IP and next hop IP.
PatternLibrary Contains all patterns used by Service Mapping.
ParseURL Decodes encoded sys_ID attribute on DB Views.
CancelBSDiscovery Stops the discovery process of a business
service.
Layer2ConnectionStrategy Creates representation of physical connections
between the input host and other hosts and
return the set of relation IDs.
LoadPorts Returns the list of ports for the given host.

GetPortByIP Returns the port ID of the given host associated

with the given IP address.
DiscoveryHostUtils Shows a collection of functions for retrieving
information about hosts. For example, it
translates the CI type into the OS type.
ServiceMappingUtils Shows a collection of functions to synchronize
Service Modeling with Service Mapping.
Client Scripts installed with Service Mapping
Service Mapping adds the following client scripts.

Client script Table Description
IP source change NAT Verifies that the source IP

entered during a rule change is
[cmdb_ci_translation_rule]
correct.
IP Validation NAT Validates the entered IP.
IP Target change NAT Verifies that the new target IP

entered during a rule change is
correct.
Validate host TCP Validates the host attribute for
the TCP entry point type.
[cmdb_ci_endpoint_tcp]
Enable view map Business Service If there are no entry points, this
script disables the View map
[cmdb_ci_service_discovered]
button on the business service
form.
QBS_ISQueryDefined Technical Service N/A
[cmdb_ci_query_based_service]
rewrite endpoint link Business Service Displays the Edit entry point
dialog box when you click an
entry point link on the Entry
Points tab on the Business
Service form.
ShowEditPatternButton Discovery patterns Controls display of the Edit
button in the Pattern Designer
[sa_pattern]
module.
Validation functions Endpoint A set of functions for validation
of several attributes for different
[cmdb_ci_endpoint]
entry point types.
Remove "--None--" from OS Uploaded file Prevents the value — None —
Types from being added to the OS
[sa_uploaded_file]
Types list.

Client script Table Description
Validate URL HTTP(S) Validates the URL attribute for

the HTTP(S) entry point type.
[cmdb_ci_endpoint_http]
QBS - remove options from Technical Service Removes redundant options

table drop down from the table selection list in
the Technical Business Service
form.
add url params Endpoint Saves data entered in the Edit
entry point dialog box to the
[cmdb_ci_endpoint]
related business service.
Enable Run Discovery button Business Service Disables the Run Discovery
button on the service map page
while the discovery process is
running.
Validate port TCP Validates the port attribute for
the TCP entry point type.
Remove "--None--" from OS Uploaded file Prevents the value — None —

Architecture from being added to the OS
[sa_uploaded_file]
Architecture list.
Business Rules installed with Service Mapping
Service Mapping adds the following business rules.

Business rule Table Description
Advanced translation rule NAT Exposes relevant fields to the

advanced translation rule mode.
Basic translation rule NAT Exposes relevant fields to the

basic translation rule mode.
Translation port compatibility NAT Verifies existence of the port

field on both the source and the
target.
Port validation NAT Validates the port value.
Set Name TCP Automatically creates the name

of the endpoint of the TCP type.
This name has the following
format: <host:port>.
Service Discovery - Device Device Trigger Service Mapping
Complete activities once horizontal
[discovery_device_history]
discovery finishes to discover
an IP address.

Query Based Service Table Technical Service Periodically recalculates all

Validation technical service members.
Delete business service User Deletes all user preferences

preferences associated with a business
[sys_user]
service when it is deleted.
Clear CI when "CI Type" is the Traffic Based Discovery Clears CI-related fields when CI
scope Type is selected on the Traffic
Based Discovery rules form.
Ext commands sync Mapping External Discovery Synchronizes the external
Commands commands tables with the MID
Server.
[sa_mapping_ext_commands]
Change to operational status Business service If there are no entry points,

disallows changing this
business service status to
operational.
saListCis Global Adds the List CIs link on the
Business Service form.
[global]
MID Synchronize CI Types Dictionary Entry Whenever the CI Type change,

a notification is sent to the MID
[sys_dictionary]
Server that causes it to reload
the CI list to get the updates.
Validate Uploaded File Fields Uploaded File Validates the correctness of the
inserted/modified Uploaded
[sa_uploaded_file]
File fields.
Prevent Duplicate and Special Discovery patterns Prevents the insertion or
Chars modification of pattern names
[sa_pattern]
that have certain forbidden
special characters or when
the name is already used by
another pattern.
Update NAT rule NAT Updates the inbound and
outbound relations of a NAT
rule CI type when the related
NAT rule is updated or deleted.
Remove entry point Entry Point When an entry point, which
serves as a connected business
[sa_m2m_service_entry_point]
service node in one business
service, is removed from
another business service, this
script validates the change and
turns this node into a boundary
node.
If there are no entry points left
in a business service, its status
is changed to non-operational.

Set applicative credentials type Applicative Credentials Populates fields in the

credentials table when
[sa_applicative_credentials]
applicative credentials record is
inserted or updated.
Check group name uniqueness Service Group Checks that the business
service group is unique and
[cmdb_ci_service_group]
disallows renaming the All
group.
Modify service group Service Group Checks that the business
service group has a valid parent
[cmdb_ci_service_group]
and is not its own parent.
Notify MID on Discovery revert Update Versions Notifies MID Server when a
discovery pattern runs the
[sys_update_version]
revert operation.
Clear CI type when "CI" is the Traffic Based Discovery Clears CI type-related fields
scope when CI is selected on the
Traffic Based Discovery rules
form.
Add query business service to Technical Service When a traffic-based service
group ALL is created, it is automatically
added to the All business
service group.
Validate NDL - draft Service Mapping Draft Pattern If a pattern was changed, it
creates the pattern draft and
[sa_pattern_draft]
updates the pattern that is on
the MID Server.
Query Based Service Filter Technical Service Recalculation of Technical
Updated Service members when a
Technical Service filter is
updated.
Remove business service from Service Group Members When a business service is
group deleted from all customer
[sa_service_group_member]
defined groups, it is
automatically removed from the
All business service group.
Check service name Business Service Checks that the business
uniqueness service name is unique.
[cmdb_ci_service]
Notify MID Server on NDL Discovery patterns If a pattern was changed, it

change updates the pattern copy that is
[sa_pattern]
on the MID Server.
Service Mapping setup

You get started with Service Mapping by configuring roles, credentials, and MID Server connections.

Service Mapping is part of the ServiceNow platform and deploys some of its platform-wide mechanisms
and features. At the same time, there are some configurations that are specific to Service Mapping only.
Perform the following tasks in the exact order they are listed below:
1. Request Service Mapping on page 538.
2. Install and configure MID Server. MID Servers, which are located in the enterprise private network,
facilitate communication between servers on the network and some ServiceNow applications, such
as Service Mapping, Discovery, and Service Analytics . For more information, see MID Server
configuration for Service Mapping on page 702.
3. Configure credentials required for host discovery.
4. Configure generic credentials required for Service Mapping to access hosts and map applications. For
more information, see Create credentials for Service Mapping on page 540.
5. On Unix-based hosts, configure elevated rights for Service Mapping to access these hosts using
Service Mapping commands requiring a privileged user on page 543.
6. Configure rights and permissions required for Service Mapping.
7. Grant the following Service Mapping roles to relevant users:
sm_admin Sets up the Service Mapping application.

Maps, fixes, and maintains business services.
Also performs advanced configuration and
customization of the product. Assign this role to
application administrators.
sm_user Views business service maps to plan change

or migration, as well as analyze the continuity
and availability of services. Assign this role to
application users.
sm_app_owner Provides information necessary for successful

mapping of a business service. Once a service is
mapped, this user reviews the results and either
approves it or suggests changes. Assign the
sm_app_owner role to users who own business
services and are familiar with the infrastructure
and applications that make up the services.
In addition to the obligatory configurations described here, you can perform additional configurations to
improve your experience as described in Advanced Service Mapping configuration on page 702.
Request Service Mapping

Service Mapping is available as a separate subscription and requires activation by ServiceNow personnel.
The following plugins are activated automatically when Service Mapping is activated: Event Management
and Service Mapping Core, IP-based Discovery, Pattern Designer, and Service Watch Suite Commons.
The Event Management and Service Mapping Core plugin is not the same as the Event Management
plugin.
To purchase a subscription, contact your ServiceNow account manager. The account manager can
arrange to have the plugin activated on your organization's production and sub-production instances,
generally within a few days.
If you do not have an account manager, decide to delay activation after purchase, or want to evaluate the
product on a sub-production instance without charge, follow these steps.

Role required: none




3. Click Submit.
Credentials required for host discovery

There are credentials and permissions that Service Mapping requires for discovering hosts.
Prior to discovering applications, Service Mapping accesses hosts that applications run on and discovers
them. Make sure that you provide all necessary credentials to allow host discovery.
The ServiceNow platform provides a centralized way of configuring credentials for Discovery, Service
Mapping, and other applications. It allows you to configure credentials for hosts and applications only once.
If you have already configured host-related credentials for another application, you do not need to do it
again for Service Mapping.
Credentials required for discovery of hosts running on UNIX/Linux:
Discovery and Orchestration explore UNIX and Linux devices by using commands executed over Secure
Shell (SSH), so they need SSH credentials.
To provide sufficient permissions, configure one of the following Unix and Linux credentials:
• Non-root user and password and using the ‘sudo’ utility to run selected commands as root
• Root user and password
For information on commands requiring sudo-level rights, see Service Mapping commands requiring a
privileged user on page 543 and UNIX and Linux commands requiring root privileges for Discovery and
Orchestration.
To access Unix-based hosts with non-root credentials, make sure you have the read access to the
following files and directories:

• /etc/*release
• /etc/bashrc
• /etc/profile
• /proc/cpuinfo
• /proc/vmware/sched/ncpus
• /var/log/dmesg
• APD directory
Credentials required for discovery of hosts running on Windows Servers:
To provide sufficient permissions, configure one of the following Windows credentials:

• A domain user with local administrator access on the target Windows hosts.
• A domain administrator.
Note: You may need domain administrator credentials only in some cases. For example, when
discovering domain controllers.
Configure Windows credentials as described in Domain requirements for Windows credentials.

Configure MID Server to use Windows credentials:
• Windows credential requirements for Discovery and Orchestration
• Configure MID Server credentials from the credentials table
• Configure MID Server credentials from the service account
Create credentials for Service Mapping

Create credentials to enable Service Mapping to access configuration items (CIs) inside your organization
private network.
Role required: admin or sm_admin
Some of the commands that Service Mapping uses to access CIs during discovery require credentials.
The ServiceNow platform provides a centralized way of configuring credentials for Discovery, Service
Mapping, and other applications. It allows you to configure credentials for hosts and applications only once.
If you have already configured host-related credentials for another application, you do not need to do it
again for Service Mapping.
You can assign credentials to specific MID Servers or keep credential generic so all MID Servers can use
them. MID Servers retrieve commands and credentials from the ServiceNow instance and apply them to
discover CIs inside organization private network.

Typically, it is enough to create credentials for hosts only, but some applications require separate
credentials from credentials of the host on which they run. This type of credentials is referred to in
ServiceNow as applicative credentials.
You also need to configure SNMP-related credentials to allow Service Mapping and Discovery to query
network devices using the SNMP protocol.
Use the following guidelines to decide for which MID Server to create credentials:
• If all CIs, belonging to the same CI type, share a credential, you do not need to specify a MID Server for
it. In that case, it is used on all MID Servers by default.
Note: Specifying the MID Server when configuring credentials is optional.

• If CIs of the same type and on the same network have different credentials, configure these credentials
and define order in which Service Mapping uses them when trying to connect to these CIs.
In addition to generic credentials, you configure on MID Servers, you must configure sudo-level credentials
on all Unix-based hosts in your organization.
1. Navigate to Service Mapping > Administration > Credentials.
2. Click New.
3. Click the credential type for the credential you want to create:
• For hosts with UNIX, Linux, IBM AIX, HP-UX, or Solaris OS, select SSH credentials.
• For hosts with Window OS, select Windows credentials.
• For applications requiring separate from their host credentials, select Applicative Credentials.
• For querying network devices using SNMP, select SNMP Community Credentials (Password
Only).
4. For the SSH credentials, fill in the information as described in SSH credentials.
5. For the Windows credentials, fill in the information as described in Windows credentials.
6. For the applicative credentials, fill in the information as described in Applicative credentials for Service
Mapping on page 542.
7. For the SNMP credentials, create SNMP community credentials if you use SNMP v1/v2 or SNMPv3
credentials if you use SNMP v3. For more information, see SNMP credentials.

8. Click Submit.
9. If necessary, repeat the procedure to create more credentials.
Applicative credentials for Service Mapping

Some applications require separate credentials from credentials of the host on which they run. This type of
credentials is referred to in ServiceNow as applicative credentials.
A typical credential contains a user name and a password for logging into a CI. While most CIs require
only one credential for accessing them, sometimes separate credentials are configured for the host and
for the application for extra security. This type of credentials is referred to in ServiceNow as applicative
credentials.
Typically, the following applications require applicative credentials:
• SAP Central Instance
• SAP NetWeaver Dialog Instance
• Microsoft SQL Database (for Microsoft BizTalk discovery only)
• MySQL Server
• Oracle Advanced Queue Queue
• Oracle Database
• Tibco EMS Queue
• Tibco Enterprise Message Service (EMS)
If you used applicative credentials for any CIs on your infrastructure, you must configure these credentials
in Service Mapping so that it can access such CIs.
Note: If your organization does not use applicative credentials, it is enough to configure credentials
necessary for accessing hosts.
Table 179: Applicative credentials form fields
Field Description
Name Name of the credential. Use a descriptive name

like Oracle DB or London Oracle DB (for an
Oracle database).
Active Select this check box for Service Mapping to use
this credential.
User name Enter the actual user name of the applicative
credential.
Password Enter the actual password of the applicative
credential.
CI type Select a CI type to which the CI belongs.
Applies to Select the MID Server corresponding to a
relevant location or select All MID servers.

Field Description
Order Enter a number from 1 to 100 for order in which

Service Mapping uses this credential in case
of shared credentials. A credential with an
assigned value of 1 is used first.
Service Mapping commands requiring a privileged user

Service Mapping uses commands requiring elevated rights to discover and map Unix-based hosts in your
organization.
You do not run these commands directly. Service Mapping uses commands requiring elevated rights as
part of the following processes:
• host detection
• process identification on port
• discovering CIs using patterns
Some commands are mandatory. The discovery process fails if Service Mapping cannot run these
commands with elevated rights. Configure servers in your organization to allow Service Mapping to run
these commands with elevated rights.
Attention: If you do not configure credentials for a mandatory command, a process or a pattern
using it fails leading to discovery failure.
Some of these commands do not require elevated rights, unless directories that Service Mapping must
access are protected.
Operating system commands requiring elevated rights
Table 180: AIX commands requiring elevated rights
Command Parameter Mandatory/Optional Description
cat file-name Mandatory Shows the file content.

ls -F-1 Mandatory Lists the directory content.
-1HF
-w 1
-1
procwdx Process_id Mandatory Gets working directory of

a process.
rmsock Socketname tcpcp It is mandatory to Finds process listening on
use either rmsock or a specific port.
lsof.
lsof -Pnl +M -i It is mandatory to Shows files or
use either rmsock or connections associated
lsof. with the process.
lstat Various options Optional Fetches information about
a link.

ps eww Mandatory Fetches environment

variables for the process
on AIX.
Table 181: HP-UX commands requiring elevated rights
cat file-name Mandatory Shows the file content.

ls -F-1 Mandatory Lists the directory
content.
-1HF
-w 1
-1
pfiles Process_id It is mandatory to use Shows files or

either pfiles or lsof. connections associated
with the process.
lsof -Pnl +M -i It is mandatory to use Shows files or
either pfiles or lsof. connections associated
with the process.
Table 182: Solaris commands requiring elevated rights
Command Parameter Mandatory/optional Description
cat File_name Mandatory Shows the file content.

ls ls -F-1 Mandatory Lists the directory
content.
ls -1HF
ls -w 1
ls -1
e-l Optional Fetches file attributes

used for file caching
decision.
dtrace -C -s For Solaris 11.1 and Shows process
earlier, it is mandatory listening on the given
script_name to use either the dtrace port. Required for
or lsof command. Solaris 11.1 or earlier.

lsof -Pnl +M -i For Solaris 11.1 and Shows files and

earlier, it is mandatory connections associated
to use either the dtrace with the process.
or lsof command.
For Solaris 11.2 and
later, it is mandatory to
use either the lsof or
netstat command.
netstat -anu For Solaris 11.2 and Lists the open ports.
later, it is mandatory to Required for Solaris
use either the lsof or version 11.2 or later.
netstat command.
Ifconfig Ifconfig -a Mandatory Shows interface
information (need
sudo to get the MAC
addresses).
pwdx Process_id Mandatory Gets the process
information.
pargs -e process_id Mandatory Gets the process
information.
ps -eo user, pid, ppid, Mandatory Gets the process list.
comm, args
inetadm -l or without params Optional Handles the case of
application using the
inet daemon.
Table 183: Linux commands requiring elevated rights
Commands Parameter Mandatory/Optional Description
cat File_name Mandatory Shows the file content.

ls ls -F-1 Mandatory Lists directory content.
ls -1HF
ls -w 1
ls -1
netstat -ltnup Mandatory Shows the open

network connections.
-ltnp
-ntup
-an
stat --format="%Y" Optional Shows the modification

time of the file.
-L file_name

Application commands requiring elevated rights
Service Mapping uses some of these commands in patterns.
Table 184: ABAP SAP Central Services (ASCS) (on Unix)
ls Various options Mandatory (For Unix only) Lists

files and folders in the
specified folder.
ping -c 1 Mandatory (For Unix only)
Verifies that the host is
answering.
netstat Various options Mandatory Lists open ports.
Table 185: Apache Web Server (on Unix)
grep Various options Mandatory Extracts strings from

the output.
ls Various options Mandatory Lists files and folders in
the specified folder.
Table 186: Apache Tomcat (on Unix)

the output.
cat - Mandatory Shows the file content.
netstat Various options Mandatory Lists the open ports.
find -name Optional This command is
used only for creating
the web services
connections.
Finds specific strings in
files and folders.

Table 187: Apache Tomcat WAR (on Unix)

the output.
version.sh/version.bat - Optional Gets the Tomcat
version.
the web services
connections.
files and folders.
Table 188: App TNS Service (on Unix)

the output.
Table 189: BIG-IP Global Traffic Manager (GTM) F5 (on F5 BIG-IP)
ping -a -c 1 [url[1].host] Mandatory Gets the host IP.
Table 190: BMC CTRL-M Enterprise Manager (on Unix)

the output.

Table 191: BMC CTRL-M Gateway (on Unix)

the output.
find Various options Optional This command is
used only to create
connections to Control
M Server.
Finds file and folder
paths.
Table 192: Citrix Netscaler (on Citrix Netscaler)

the output.
Table 193: FormEngine (on Unix)
grep Various options Mandatory (On Unix only) Extracts

strings from the output.
ls Various options Mandatory (On Unix only) Lists
specified folder.
cat - Mandatory (On Unix only) Shows
the file content.
Table 194: IBM Customer Information Control System (CICS) (on Unix)

the output.
Table 195: IBM CTRL-M Server (on Unix)
grep Various options Mandatory (For Unix only) Extracts


find Various options Mandatory (For Unix only)

paths.
Table 196: IBM CICS Transaction Gateway CTG (on Unix or Windows)
grep Various options Optional (For Unix only) This

command is used
only to create CICS
connections. Extracts
cat - Optional (For Unix only) This
command is used
only to create CICS
connections. Displays
the file content in the
output.
find Various options Optional (For Unix only) This
command is used
only to create CICS
connections. Finds
specific strings in files
and folders.
Table 197: IBM DB2 (on Linux)

the output.
cat - Mandatory Displays the file
content in the output.
Table 198: IBM J2EE EAR (on Linux)

the output.
find -name Mandatory Finds files and folders
in the specified folder.

Table 199: IBM Websphere Application Server (on Unix)

the output.
-type the Web Services
connections.
Finds files and folders
for the specific name.
Table 200: IBM Websphere Portal (on Linux)

Table 201: IBM WebSphere Message Broker Flow (on Unix)

the output.
ps -ef Mandatory Gets the process
information.
Table 202: IBM WebSphere Message Broker (on Unix)

information.


the output.
Table 203: IBM WebSphere MQ (on Unix)

the output.
Table 204: IBM WebSphere MQ Queue (on Unix)

the output.
Table 205: Jboss Module (on Unix)

the output.
Table 206: Jboss (on Unix and Windows)

specified folder.
the output.
dir Various options Mandatory (On Windows only)
Lists files and folders in
find Various options Mandatory (For Windows only)
files and folders.

Table 207: JRun (on Unix)
dir Various options Mandatory Lists files and folders in

Table 208: JRun WAR Inc (on Unix)

the output.
Table 209: MySQL Server (on Linux)
grep Various options Mandatory (On Unix only) Extracts

ps --pid=[process.pid] -- Optional Gets the userid
no-headers -o " %U : parameter value.
%p : %a”
Table 210: MySQL Cluster MGM Node (on Linux)

ps --pid=[process.pid] -- Optional (On Unix only) Gets the
no-headers -o " %U : userid parameter value.
%p : %a”
Table 211: Nginx (on Unix)

%p : %a”

ls [IncludeTabletmp[].files] Optional This command is used

if necessary to create
HTTP connections.
cat [IncludeTabletmp[].files] Optional This command is used

HTTP connections.
Shows the file content.
Table 212: Oracle E-Business Suite (on Unix)

the output.
export - Mandatory Sets variables.
echo Various options Mandatory Prints strings in the
output.
sqlplus Various options Mandatory Creates the connection
to the Oracle instance.
awk Various options Mandatory Manipulates the output.
netstat Various options Mandatory Gets open ports.
Table 213: Oracle Advanced Queue Queue (on Unix)
Table 214: Oracle Concurrent Server (on Unix)
grep Various options Mandatory (For Unix only) Extracts

awk Various options Mandatory (For Unix only)
Manipulates the output.
specified folder.

cat - Mandatory (For Unix only)

Displays the file
find Various options Mandatory Finds specific strings in
files and folders.
Table 215: Oracle Discoverer Engine (on Unix)
Command ParameterMandatory/Optional Description
ls Various Mandatory Lists files and folders in

options the specified folder.
grep Various Mandatory Extracts strings from
options the output.
Table 216: Oracle Discoverer UI (on Unix)

the output.
Table 217: Oracle Form UI (on Unix)

the output.
Table 218: Oracle Fulfillment Server (on Unix)

the output.

Table 219: Oracle HTTP Server (on Unix)

the output.
Table 220: Oracle Metric Client (on Unix)

the output.
Table 221: Oracle OACORE Server (on Unix)

the output.
Table 222: Oracle OAFM Server (on Unix)

the output.

Table 223: Oracle Database (on Unix)

the output.
information.
Table 224: Oracle iAS Web Module (on Unix)

the output.
specified folder.
cat - Mandatory (For Unix only) Shows
the file content.
Table 225: Oracle Process Manager (on Unix)

the output.
Table 226: Oracle Report Server (on Unix)

the output.

Table 227: Oracle Tnslsnr Engine (on Unix)

the output.
Table 228: Oracle WebLogic Module (on Unix)

the output.
connections.
Table 229: Oracle WebLogic Server (version 10.3) (on Unix)

the output.
Table 230: Oracle WebLogic On-demand Router Load Balancer (on Unix)

the output.

Table 231: Oracle Tuxedo (on Unix)

the output
ls Various Mandatory Lists files and folders
on the given folder.
find -name Optional This command is used
only to create web
service connections.
for specific name.
netstat Various Mandatory Gets open ports.
ps -ef (For Unix only) Gets
process attributes.
Table 232: Oracle Tuxedo Portal (on Unix)

the output
ls Various Mandatory Lists files and folders
on the given folder.
Table 233: PostgreSQL Database (on Unix)
ls [IncludeTabletmp[].files] Optional This command is used

only to create the
HTTP connections.

Table 234: Rabbit MQ (on Unix)
ps - ef ps -ef | grep "+ Mandatory Gets the parent

$process.parentProcessId process.
+" |egrep -v -e grep -e
beam
Table 235: SAP Central Instance (on Unix)

ping -c 1 Mandatory Verifies that the host is
answering.
Table 236: SAP NetWeaver Dialog Instance (on Unix)

answering.
Table 237: SAP Evaluated Receipt Settlement (ERS) (on Unix)

answering.
Table 238: SAP Java Cluster (on Unix)

answering.

Table 239: SAP Central Services (SCS) (on Unix)

answering.
Table 240: Sun Directory (on Solaris)
Table 241: Sun iPlanet Web Server (on Solaris)

Table 242: Sun JES (on Solaris)

the output.
Table 243: Sybase (on Unix)


Table 244: Tibco EMS Queue (on Unix)

Table 245: Tibco Enterprise Message Service (EMS) (on Unix)

Table 246: Tibco ActiveMatrix BusinessWorks (on Unix)
hostname - Mandatory Gets the hostname.

the output.
Table 247: Tibco ActiveMatrix BusinessWorks Process (on Unix)

the output.
findstr Various options Mandatory Extracts strings from
the output.
cut Various options Mandatory Splits the output line.
Service Mapping commands not requiring a privileged user

Most of commands utilized by Service Mapping for discovery and mapping do not require elevated rights.
Review this list of commands to understand how Service Mapping uses them and to make sure that the
virtual security of your company is not compromised.

You do not run these commands directly. Service Mapping uses commands requiring elevated rights as
part of the following processes:
• host detection
• process identification on port
• discovering CIs using patterns
Some commands are mandatory. The discovery process fails if Service Mapping cannot run these
commands.
Operating systems
Table 248: AIX commands
awk various options Mandatory Parses the string.

istat file_name Optional Gets last modification time
of file.
nslookup hostname Mandatory Resolve DNS host name.
ping -c count ip/host Mandatory Pings the host.
arp -an various options Mandatory Shows ARP table.
grep String to search Mandatory Finds string in previous
command output.
traceroute -n ip_address Mandatory Shows layer 3 network
route to target host.
netstat -an Mandatory Shows open network
connections.
-Aan

comm, args
grep various options Mandatory Searches text in previous
command output
find Directory and Mandatory Searches for files by
parameters to search name or type.
Table 249: HP-UX commands

arp -an Optional (required by Shows the ARP table.
network discovery)
grep String to search Mandatory Finds string in previous
command output.
awk various options Mandatory Parses the string.

traceroute -n ip_address Mandatory Shows layer 3 network

route to target host.
connections.
comm, args
grep various options Mandatory Searches text in
previous command
output
comm, args
parameters for search name or type.
Table 250: Linux
Commands Parameter Mandatory/Optional Description
nslookup hostname Mandatory Resolves the DNS host

name.
arp -an Optional (required Shows the ARP table.
for network path
calculations)
grep String to search Mandatory Finds the string in
previous command
output.
awk Various options Mandatory Parses the string.
connections.
comm, args
grep Various options Mandatory Searches text in
previous command
output.
egrep Various options Mandatory Searches text in
previous command
output.
parameters for search name or type.
traceroute -n ip_address Optional (required Shows the layer 3
for network path network route to target
calculation) host.

Table 251: Solaris
nslookup hostname Mandatory Resolves the DNS host

name.
arp -an Optional (required Shows the ARP table.
for network path
calculation)
grep String to search Mandatory Finds the string in
previous command
output.
awk Various options Mandatory Parses the string.
traceroute -n ip_address Optional (required Shows the layer 3
for network path network route to target
calculation) host.
netstat -an Mandatory Shows the open
network connections.
zoneadm List Mandatory Shows the list of zones.
grep Various options Mandatory Searches text in
previous command
output.
egrep Various options Mandatory Searches text in
previous command
output.
find for search Directory and Mandatory Searches for files by
parameters name or type.
Table 252: Windows WMI Queries
Query Description
Select * from Win32_ComputerSystem Gets the server basic information like serial
number.
Select LastModified from CIM_LogicalFile Where Gets the last modification time of a file.
Name=...
Select AddressWidth from Win32_Processor Gets the computer architecture (32 bit or 64 bit).
Select * From Win32_Process where (ProcessId Gets the process list running on the computer.
= ?)
Select Name from CIM_LogicalDisk Gets the file systems on the computer, such as
C: or D:.
Select FileName, Extension from CIM_Directory Gets the list of files in a specific directory.
where Drive=’drive’ and Path='path'

Table 253: Windows commands
get_process_info.exe Process_id Mandatory Extracts information on

the processes using
executable created by
ServiceNow.
type File_name Mandatory Shows the text file
content.
nslookup Host_name Mandatory DNS lookup
arp -a Optional (required Shows the ARP table.
for network path
calculation)
netstat -ano Mandatory Shows the network
connections.
findstr Various options Mandatory Finds the string in the
previous command
output.
dir /q Mandatory Lists files in the
directories.
/s /b
paping --nocolor -c 1 -p Mandatory Utility to run TCP ping

against given host.
port_num
ip_address
ping -n 1 Mandatory Pings the host.
ip_address/host
tracert Ip_address Optional (required Shows the layer 3

for network path network route to the
calculation) target host.
Applications
Table 254: ABAP SAP Central Services (ASCS) (on Unix or Windows)
dir Various options Mandatory (For Windows only)

msg_server -V Optional Gets the version.
ping -n 1 Mandatory (For Windows only)
answering.

Table 255: Active Directory Domain Controller (on Windows)
netstat Various options Mandatory Gets open ports on

dir Various options Mandatory Lists all files in the
specified folder.
Table 256: Apache Web Server (on Unix)
httpd -V Optional Gets the version.

cut Various options Mandatory Splits the output line.
opmnctl status -fmt Optional This command is used
%cmp32%prt32%por40%pid only for discovering the
OC4J connectivity.
and
Gets the status of the
@farm status - OPMN CTRL service.
noheaders -fsep "|" -fmt
%cmp%prt%clu%ins
%por
sort -u Optional This command is used
only discovering the
Weblogic connectivity.
Sorts the output.
Table 257: Apache Web Server (on Windows)
httpd.exe -V Optional Gets the version.

opmnctl status -fmt Optional This command is used
%cmp32%prt32%por40%pid only for discovering the
OC4J connectivity.
and
Gets the status of the
@farm status - OPMN CTRL service.
noheaders -fsep "|" -fmt
%cmp%prt%clu%ins
%por

Table 258: Apache Tomcat (on Unix or Windows)

findstr Various options Mandatory (On Windows only)
Extracts strings from
the output.
files and folders.
version.
the web services
connections.
files and folders.
Table 259: Apache Tomcat WAR (on Unix or Windows)

the output.
files and folders.
version.
netstat Various options Mandatory (Windows only) Lists
the open ports.
Table 260: App TNS Service (on Unix or Windows)


netstat Various options Mandatory (On Windows only)

Lists open ports.
grep Various options Mandatory (On Windows only)
the output.
Table 261: BIG-IP Global Traffic Manager (GTM) F5 (on F5 BIG-IP)
show /gtm pool Optional This command is

[wide_ip_pool_4_cmd[1].pool] used only to create
members connections to pool
members.
Gets the pool
members.
list /gtm server Optional This command is
[servers_from_cmd[].server] used only to create
addresses connections to pool
members.
Lists the alias server
addresses.
Table 262: BIG-IP Local Traffic Manager (LTM ) F5 (on F5 BIG-IP)
b rule [rule name] list Optional This command is

and connections from rules.
virtual address Lists existing rules on
[entry_point.ip_address] BIGPipe.
list ltm rule [rule name] Optional This command is

and connections from rules.
data-group Lists existing rules on
wts_routing_destination_prod TMSH.
| grep -A 1 [ep_uri]
Table 263: BMC CTRL-M Enterprise Manager (on Unix or Windows)
findstr Various options Mandatory (For Windows only)

the output.

netstat Various options Mandatory (For Windows only)

Lists open ports.
Table 264: BMC CTRL-M Gateway (on Unix or Windows)

the output.
find Various options Optional This command is
used only to create
connections to Control
M Server.
paths.
xargs grep <string> Optional This command is

used only to create
connections to IBM
CTRL-M Server.
Runs the command on
all lists from the output.
Table 265: BMC IT Asset Management (ITAM) Software
tnsping Various options Mandatory Retrieves information

about Oracle
connections.
Table 266: CA Identity Manager Provisioning Server (for Windows)

Table 267: Cisco ACE Command Line Interface (on Cisco CSM)
show context, running Mandatory Shows the requested

information.

include - Mandatory Extracts strings from

the output.
echo - Mandatory Displays strings to the
output.
Table 268: Cisco Global Site Selector (on Cisco CSM)
show gslb-config domain-list Mandatory Shows the domain list.

show gslb-config dns rule Mandatory Shows the DNS rule
output.
show gslb-config answer- Mandatory Show the VIP answer.
group
Table 269: Citrix Delivery Controller (on Windows)
powershell Add-PSSnapin Mandatory Gets applications

Citrix.Broker.Admin.V2; managed by this
Get-BrokerApplication Delivery Controller.
-Name
[entry_point.name]
| select
Name,CommandLineExecutable,CommandLineArguments,WorkingDirectory,Application
| Format-List
And
Add-PSSnapin
Citrix.Broker.Admin.V2;
Get-BrokerApplication
-Name
[entry_point.name]
| select
Name,CommandLineExecutable,CommandLineArguments,WorkingDirectory,Application
| Format-List
And
dd-PSSnapin
Citrix.Broker.Admin.V2;
Get-BrokerMachine -
DesktopGroupName
‘ [delivery_groups[1].name]

Table 270: Citrix XenApp (on Windows)
get_xenapp_apps.ps1 [entry_point.icon_path] Mandatory Runs powershell

commands that retrieve
the Citrix icon info from
the Citrix repository.
powershell Various options Mandatory Runs powershell
commands.
Table 271: Citrix Presentation Server (on Windows)
cscript //NoLogo Mandatory Runs VB scripts

without a popup box.
GetAppsInFolder.wsf [entry_point.icon_path] Mandatory Runs vbscript
commands that retrieve
the Citrix icon info from
the Citrix repository.
Table 272: Citrix Netscaler (on Citrix Netscaler)
show cs policy, cs action,cs Optional This command is used

Policy, lb vserver only for discovering
outgoing connections.
Shows the requested
information.
the output.
Table 273: Connect-IT Service (on Unix or Windows)

the output.

Table 274: EMC Documentum Docbase (on Windows)

the output.
files and folders.
Table 275: FormEngine (on Unix or Windows)

the output.
files and folders.
Table 276: Generic application (on Unix or Windows)

the output.
tasklist Various options Mandatory Lists all running tasks.
Table 277: HAProxy (on Unix or Windows)

specified folder.
tail Various options Mandatory (On Unix only) Displays
the end of the output.

Table 278: HP Service Manager Application Server
tnsping Various options Mandatory Retrieves information

about Oracle
connections.
Table 279: HP Service Manager Index (on Windows)
Table 280: HP Service Manager Knowledge Base (on Windows)
Table 281: IBM WebSphere Message Broker (on Windows)
dmqdocbroker -s -c getdocbasemap Mandatory Gets the docbase

information.
and
-t
[computer_system.primaryHostname]
-s -c getdocbasemap
and
-s -c getservermap
[docbas]
-t
[computer_system.primaryHostname]
-s -c getdocbasemap
[docbase]
del Various options Mandatory Deletes the XML file
containing the old
binding information.
BTSTask ExportBindings / Optional This command is used
Destination:%TEMP only if there are not
%\MyBindings.xml / MSSQL credentials.
Database:
Extracts the binding
[MgmtDbName] /
info and places it into
server:[serverName]
the XML file.

Table 282: IBM CTRL-M Server (on Unix or Windows)

the output.
Table 283: IBM CICS Transaction Gateway CTG (on Unix or Windows)
findstr Various options Optional (For Windows only)

This command is used
only to create CICS
connections.
the output.
dir Various options Optional (For Windows only)

only to create CICS
connections. Lists
specified folder.
type - Optional (For Windows only)
only to create CICS
connections. Displays
the file content in the
output.
Table 284: IBM DB2 (on Linux)
source [installed_dir]db2profile Mandatory Sets the DB2 variables.

db2 list database directory Mandatory Displays the DB2
installation parameters.
the output.
head -1 Mandatory Displays only the first
line from the output.
db2level - Mandatory Displays the DB2
version.

xargs -I {} echo list Optional This command is used

tablespace containers only to create storage
for {} ';' connections. Runs the
command on all lists
from the output.
Table 285: IBM DB2 (on Windows)
db2cmd /c /w /i Mandatory Lists the DB2

directories.
db2 list database directory Mandatory Displays the DB2
find Various options Mandatory Finds specific strings
in files, folders, or
standard output.
db2level - Mandatory Displays the DB2
version.
echo Various options Optional This command is
used only for storage
connectivity. Prints the
strings in the output.
findstr Various options Optional This command is
connectivity.
the output.
for Various options Optional This command is

connectivity. Runs
loops.
Table 286: IBM J2EE EAR (on Windows)

files and folders.


the output.
Table 287: IBM Websphere Application Server (on Unix)
versionInfo.sh - Optional Gets the Websphere

Application Server
version.
Table 288: IBM Websphere Portal (on Linux)

the output.
connections.
Table 289: IBM Websphere Portal (on Windows)

the output.
files and folders.
Table 290: IBM WebSphere Message Broker Flow (on Unix)

connections.

mqsiprofile - Mandatory Sets the variables for

WebSphere Message
Broker.
mqsireportbroker [broker name] Mandatory Gets the WebSphere
Message Broker
information.
mqsibrowse [broker name] -t Mandatory Displays the Message
BROKERRESOURCES Broker information
resources.
echo $ODBCINI Optional (On Unix only) This
command is used only
to create connections
to IBM DB2.
Prints strings in the
output.
Table 291: IBM WebSphere Message Broker Flow (on Windows)

WebSphere Message
Broker.
Message Broker
information.
information.
resources.
echo $ODBCINI Optional (On Unix only) This
command is used only
to IBM DB2.
output.
db2 list database directory Mandatory Displays DB2

and
list node directory

Table 292: IBM WebSphere Message Broker (on Unix)

WebSphere Message
Broker.
Message Broker
information.
resources.
connections.
Table 293: IBM WebSphere Message Broker (on Windows)
mqsiprofile - Mandatory SSets the variables for

WebSphere Message
Broker.
Message Broker
information.
information.
resources.
Table 294: IBM WebSphere MQ (on Unix)
dspmq - Mandatory Gets the queue

manager status.
dspmqver - Mandatory Gets the queue
manager version.
runmqsc [queue manager] Mandatory Gets the queue
information.

Table 295: IBM WebSphere MQ (on Windows)

the output.
manager status.
manager version.
information.
Table 296: IBM WebSphere MQ Queue (on Unix)

manager status.
manager version.
information.
Table 297: IBM WebSphere MQ Queue (on Windows)

manager status.
manager version.
information.
Table 298: Jboss Module (on Unix or Windows)

the output.
find Various options Mandatory (On Windows only)
files and folders.


Lists open ports.
Table 299: Jboss (on Unix and Windows)

xargs grep <string> Optional Finds strings in all files
found in the output file.
the output.
files and folders.
Table 300: JRun (on Windows)

Table 301: JRun WAR Inc (on Unix and Windows)

xargs grep <string> Optional Finds strings in the files
found in the output file.
the output.
the output.


files and folders.
Table 302: Microsoft Exchange CAS (on Windows)

containing the old
output.

powershell Add-PSSnapin Optional This command is used

only if you do not use
Microsoft.Exchange.Management.PowerShell.E2010;
Get-ExchangeServer TCP connections.
-status -Identity Gets the CAS status,
[hostname]| export- server roles, and
clixml $env:TEMP Exchange setup
\exchange_pwrshell_output.xml structure.
and
Caution: Do
Add-PSSnapin not use the
Microsoft.Exchange.Management.PowerShell.Admin; dollar sign ($)
Get-ExchangeServer in credentials
-status -Identity for Exchange
[hostname]| export- CAS, because
clixml $env:TEMP Service
\exchange_pwrshell_output.xml Mapping uses
and the dollar sign
for pattern
Add-PSSnapin variables in
Microsoft.Exchange.Management.PowerShell.E2010; the powershell
Get-ExchangeServer| command.
format-table -autosize
-HideTableHeaders
Name,Fqdn,IsMailboxServer
and
Add-PSSnapin
Microsoft.Exchange.Management.PowerShell.Admin;
Get-ExchangeServer |
-HideTableHeaders
Name,Fqdn,IsMailboxServer
and
Add-PSSnapin
Get-MailboxServer |
format-list
find Various options Optional This command is used
only if PowerShell is
not operational.
the files and folders.

the output.
Table 303: Microsoft Dynamic CRM (on Windows)


the output.
files and folders.
Table 304: Microsoft BizTalk Orchestration (on Windows)

output.
Table 305: Microsoft BizTalk Server (on Windows)

output.
del Various options Mandatory Deletes the XML
file containing
the old binding
information.
BTSTask ExportBindings / Optional This command is
Destination:%TEMP used only if there
%\MyBindings.xml / are not MSSQL
Database: credentials.
[MgmtDbName] /
Extracts the
server:[serverName]
binding information
and places it into
the XML file.
Table 306: Microsoft Exchange BackEnd Server (on Windows)

Table 307: Microsoft Exchange FrontEnd Server (on Windows)


Table 308: Microsoft FAST Search Server (on Windows)

the output.
Table 309: Microsoft Exchange Hub Transport Server (on Windows)

output.
containing the old


-status -Identity Gives the CAS status,
[entry_point.host_name]| server roles, and
export-clixml Exchange setup
$env:TEMP structure.
\exchange_pwrshell_output.xml
And Caution: Do
not use the
"Add-PSSnapin dollar sign ($)
Microsoft.Exchange.Management.PowerShell.Admin; in credentials
Get-ExchangeServer for Exchange
-status -Identity Hub Transport
[entry_point.host_name] Server,
| export-clixml because
$env:TEMP Service
\exchange_pwrshell_output.xml Mapping uses
the dollar sign
for pattern
variables in
the powershell
command.

the output.
files and folders.
Table 310: Microsoft Internet Information Services (IIS) (on Windows)
appcmd.exe Various options Optional This command is used

only for IIS version 7
and later.
Retrieves information
about the specified
application name.

Table 311: Microsoft Internet Information Services (IIS) Virtual Directory (on Windows)
appcmd.exe Various options Optional This command is used

only for IIS version 7
and later.
about the specified
application name.
iisapp.vbs Various options Optional This command is used

only for IIS version 6.
about the specified
application name.

the output.
files and folders.
Table 312: Microsoft .NET commands (on Windows)
ildasm.exe text that contains Mandatory This file is necessary

process exe path for performing the put
file operation on the
ILDisassembler alias.
This file disassembles
strings from the
command .exe file.
.findstr Various options Mandatory Gets the strings from
the output.
dir Various options Mandatory Lists all files in the
specified folder.

connection_strings_browser.exe
[encrypted_configs[*].Name]
Optional: This command is
database encrypted
connections.
This file is necessary
for performing the
put file operation on
theConnectionStringsBrowser
alias.
Decrypts the database
connections.
Table 313: Microsoft Exchange Mailbox (on Windows)

containing old binding
information.
output.


-status -Identity Gets the status, server
[entry_point.host_name]| roles, and the setup
export-clixml structure of Exchange
$env:TEMP Mailbox.
And Caution: Do
not use the
Add-PSSnapin dollar sign ($)
Microsoft.Exchange.Management.PowerShell.Admin; in credentials
Get-ExchangeServer for Exchange
-status | export- Mailbox,
clixml $env:TEMP because
\exchange_pwrshell_output.xml Service
Add-PSSnapin Mapping uses
Microsoft.Exchange.Management.PowerShell.E2010; the dollar sign
Get-ExchangeServer for pattern
-status -Identity variables in
[entry_point.host_name]| the powershell
export-clixml command.
$env:TEMP
And
Add-PSSnapin
Get-
ClusteredMailBoxServerStatus
| format-table -Property
OperationalMachines
And
Add-PSSnapin
-HideTableHeaders
Name,Fqdn,IsHubTransportServer
Add-PSSnapin
-HideTableHeaders
Name,Fqdn,IsHubTransportServer
And
Add-PSSnapin
Get-StorageGroup
-server [hostname]
| select
SystemFolderPath |
Export-Csv out.csv -
notype;cat out.csv
And

only if PowerShell is
not operational.
the files and folders.

the output.
Table 314: Microsoft SharePoint (on Windows)
Table 315: Microsoft SQL Database (on Windows)

the output.
the output.

sqlcmd -Stcp: Optional This command is

used only to discover
[computer_system.primaryMan[entry_point.database]
-U [username] -P Microsoft BizTalk.
[password] -y 0 -h-1 Gets the BizTalk
-Q"select nvcname information from the
+'###'+inboundtransporturl database.
FROM
adm_ReceiveLocation
rl, bts_receiveport
rp where
rl.receiveportid=rp.nid”
and
-Stcp:
-U [username] -
P [password] -y
0 -h-1 -Q" select
nID,nvcName,nApplicationID
from bts_receiveport”
and
-Stcp:
-U [username] -
P [password] -y
0 -h-1 -Q" select
nID,nvcName,nApplicationID
from bts_sendport”
and
-Stcp:
-U [username] -
P [password] -y
0 -h-1 -Q" select
nOrcPortID,nReceivePortID,nSendPortid
from
bts_orchestration_port_binding”
and
- Stcp:
-U [username] -
P [password] -y
0 -h-1 -Q"select
nID,nOrchestrationID
from
bts_orchestration_port”
and
- Stcp:
-U [username] -
P [password] -y
0 -h-1 -Q"select
nID,nvcFullName from
bts_orchestration”
and
Table 316: Microsoft Message Queuing (MSMQ) (on Windows)

the output.
Table 317: Microsoft SQL Database (on Windows)

the output.
sqlservr.exe Optional Gets the version of
the database from the
executable file.
Table 318: MySQL Server (on Windows and Linux)

the output.
%p : %a”
mysqld-nt/mysqld/ -V Mandatory Gets the version.
mysqld.exe

mysql --user=[username] -- Optional This command is used

password=[password] only to create cluster
--port=[jdbc_port] node connections,
--skip-column- master replications,
names --silent -- and slaves.
execute="SHOW Gets the deployment
ENGINE NDB structure of the MySQL
STATUS;;” server.
and
--user=[username] --
password=[password]
--port=[jdbc_port]
--skip-column-
names --silent --
execute="SHOW
SLAVE STATUS;;”
and
--user=[username] --
password=[password]
--port=[jdbc_port] --
skip-column-names --
silent --execute="select
host from
information_schema.processlist
where command like
'%%binlog%%';;”
which mysql Optional This command is used
only to create cluster
node connections,
master replications,
and slaves.
Gets the full path of
MySQL cluster nodes.
Table 319: MySQL Cluster MGM Node (on Linux or Windows)

ndb_mgmd -V Mandatory Gets the version and
status of the MySQL
and Cluster MGM node.
-e show

Table 320: Nginx (on Unix)
nginx -v Mandatory Gets the version.

egrep -v -e ^# -e "\t#" Optional This command is used
HTTP connections.
Ignores special
characters.
Table 321: Oracle E-Business Suite (on Unix or Windows)

the output.
files and folders.
export - Mandatory (For Unix only) Sets
variables.
output.
sqlplus Various options Mandatory Creates the connection
to the Oracle instance.
Gets open ports.
Table 322: Oracle Advanced Queue Queue (on Unix or Windows)
export - Mandatory (On Unix only) Sets a

variable.
output.
sqlplus Various options Mandatory Creates connection to
the Oracle instance.
set - Optional (On Windows only)
Sets a variable.


Lists open ports.
Table 323: Oracle Concurrent Server (on Unix or Windows)

the output.
Lists open ports.
files and folders.
Table 324: Oracle Discoverer Engine (on Windows)

the output.
files and folders.
Table 325: Oracle Discoverer UI (on Windows)

the output.
files and folders.

Table 326: Oracle Form UI (on Windows)

the output.
files and folders.
Table 327: Oracle Fulfillment Server (on Windows)

the output.
files and folders.
Table 328: Oracle HTTP Server (on Windows)

the output.
files and folders.
Table 329: Oracle Metric Client (on Windows)

the output.
files and folders.

Table 330: Oracle OACORE Server (on Windows)

the output.
find Various options Mandatory Finds specified strings
in the file and folders.
Table 331: Oracle OAFM Server (on Windows)

the output.
Table 332: Oracle Database (on Unix)
export - Mandatory Sets the variable.

sqlplus -s [username]/ Optional This command is
[password]@[entry_point.instance] used only for getting
the advanced queue
information.
Gets the Oracle version
and information about
advance queue.

echo -e set head off feed off Optional This command is

pages 0 line 3000\\n used only for getting
\"select NAME || '##' the advance queue
|| QUEUE_TABLE information.
|| '##' || QID || '##' Gets the information
|| QUEUE_TYPE || about advance queue,
'##' || RETENTION storage devices, and
from DBA_QUEUES database links.
where OWNER =
UPPER([entry_point.scheme]);
and
set head off feed off
pages 0 line 3000\\n
\"select NAME || '##'
|| QUEUE_TABLE
|| '##' || QID || '##'
|| QUEUE_TYPE ||
'##' || RETENTION
from DBA_QUEUES
where OWNER =
and
select member as
NEEBULA from v\
$logfile;
and
select value as
NEEBULA from v\
$parameter where
name='log_archive_dest'
and
select file_name
as NEEBULA from
dba_data_files;
and
select DB_LINK,HOST
from DBA_DB_LINKS
lsnrctl version Optional This command is used
only for discovering the
And real application cluster
services (RAC) version.
Gets the RAC version.

Table 333: Oracle Database (on Windows)
set - Mandatory Sets the variable.

sqlplus -s [username]/ Optional This command is
[password]@[entry_point.instance] used only for getting
the advance queue
information.
Gets the Oracle version
and information about
advance queue.
echo -e set head off feed off Optional This command is

pages 0 line 3000\\n used only for getting
\"select NAME || '##' the advance queue
|| QUEUE_TABLE information.
|| '##' || QID || '##' Gets the information
|| QUEUE_TYPE || about advance queue,
'##' || RETENTION storage devices, and
from DBA_QUEUES database links.
where OWNER =
and
set head off feed off
pages 0 line 3000\\n
\"select NAME || '##'
|| QUEUE_TABLE
|| '##' || QID || '##'
|| QUEUE_TYPE ||
'##' || RETENTION
from DBA_QUEUES
where OWNER =
and
select member as
NEEBULA from v\
$logfile;
and
select value as
NEEBULA from v\
$parameter where
name='log_archive_dest'
and
select file_name
as NEEBULA from
dba_data_files;
and
select DB_LINK,HOST
from DBA_DB_LINKS

lsnrctl version Optional This command is used

only for discovering the
And real application cluster
services (RAC) version.
Gets the RAC version.
Table 334: Oracle iAS Web Module (on Windows)

the output.
only to create the Web
Services connections.
Finds specified strings
Table 335: Oracle Net Listener (on Unix)
lsnrctl version Mandatory Gets the version and

status of the Oracle Net
and Listener.
status
export - Mandatory Sets the variable.

crsctl status res -t Mandatory Gets the services
status and
and configuration.
config service -d
Table 336: Oracle Process Manager (on Windows)

the output.


Table 337: Oracle Report Server (on Windows)

the output.
Table 338: Oracle Tnslsnr Engine (on Windows)

the output.
files and folders.
Table 339: Oracle WebLogic Module (on Windows)

the output.
files and folders.
Table 340: Oracle WebLogic Server (version 10.3) (on Windows)

the output.


files and folders.
Table 341: Oracle WebLogic On-demand Router Load Balancer (on Unix or Windows)

the output.
files and folders.
versionInfo.sh - Optional Gets the Websphere
Application Server
version.
Table 342: Oracle Tuxedo (on Unix or Windows)
findstr Various Mandatory (For Windows only)

the output
dir Various Mandatory (For Windows only)
Lists all existing files in
the given folder.
find Various Mandatory (For Windows only)
files and folders.
only to create web
for specific name.
tmadmin -v Mandatory Gets the Tuxedo
version.
netstat Various Mandatory Gets open ports.

Table 343: Oracle Tuxedo Portal (on Unix or Windows)
findstr Various Mandatory (For Windows only)

the output
dir Various Mandatory (For Windows only)
Lists all existing files in
the given folder.
find Various Mandatory (For Windows only)
files and folders.
only to create web
for specific name.
Table 344: PostgreSQL Database (on Unix and Windows)
postgres -v Mandatory Gets the version.

the output.
Table 345: SAP BO BOXI ScheduleRouter (on Windows)

the output.
type - Mandatory
tnsping instance Optional This command is used
to Oracle.

Table 346: SAP Business Objects CMS Server (on Windows)

the output.
tnsping instance Optional This command is used
to Oracle.
Gets the version.
Table 347: SAP Central Instance (on Unix or Windows)

disp + work -V Optional Gets the version.
answering.
Table 348: SAP NetWeaver Dialog Instance (on Unix or Windows)

ping -c 1 Mandatory (For Unix only)
answering.
answering.

Table 349: SAP Evaluated Receipt Settlement (ERS) (on Unix or Windows)

answering.
Table 350: SAP HANA Database (on Unix or Windows)
hdbsql -v Optional Gets the version.
Table 351: SAP Java Cluster (on Unix or Windows)

jlaunch -V Optional Gets the version.
answering.
Table 352: SAP Central Services (SCS) (on Unix or Windows)

msg_server -V Optional Gets the version.
answering.

Table 353: SQL Server Analysis Services (SSAS) (on Windows)
MsMdSrv.exe -n Mandatory Gets the instance

name.
Table 354: SQL Server Integration Services (SSIS) Job (on Windows)
MsMdSrv.exe -n Mandatory Gets the instance

name.
the output.
sqlcmd -Stcp: Optional This command is used
[computer_system.primaryManagementIP], only for discovering
[port] -y 0 -h-1 jobs.
-E -Q"select
convert(varchar(max),
convert(varbinary(max),packagedata))from
msdb.dbo.sysssispackages
where name = '[name]'
-o [tmp_dir]/[name].xml
Table 355: SQL Server Integration Services (SSIS) (on Windows)

the output.

sqlcmd -Stcp: Optional This command is used

[computer_system.primaryManagementIP], only if you need to
[$port] -h-1 -E - discover jobs.
Q"SELECT [name]
+ '###DB' FROM
msdb.dbo.sysssispackages"
and
-Stcp:
[computer_system.primaryManagementIP],
[$port] -h-1 -E -
Q"ELECT [name]
+ '###JOB' FROM
msdb.dbo.sysjobs"
Table 356: Sun Directory (on Solaris)
slapd-dirserv -D [instance] -v Mandatory Gets the version.

Table 357: Sun JES (on Solaris)
configutil - Mandatory Gets the JES

configuration.
Table 358: Sybase (on Unix or Windows)
dataserverv -v Mandatory Gets the version.

Table 359: Symantec Enterprise Vault (on Windows)

the output.
ping -n 1[ip] Mandatory Verifies that the SQL
server is running.

Table 360: Tibco EMS Queue (on Unix or Windows)
rm -f /tmp/ems.cmd Mandatory Prepares the EMS

script.
tibemsadmin -server tcp:// Mandatory Connects to the EMS
+[computer_system.primaryManagementIP]: administrator and gets
[port] -user [username] the list of EMS Queue
-password [password] - consumers.
script [script]
output.
Table 361: Tibco Enterprise Message Service (EMS) (on Unix and Windows)
rm -f /tmp/ems.cmd Mandatory Prepares the EMS

script.
tibemsadmin -server tcp:// Mandatory Connects to the EMS
+[computer_system.primaryManagementIP]: administrator and gets
[port] -user [username] the list of EMS Queue
-password [password] - consumers.
script [script]
echo Various options Mandatory (On Windows only)
output.
Table 362: Tibco ActiveMatrix BusinessWorks (on Unix or Windows)
TibcoFilesParser.ksh - Mandatory (For Unix only) This

file is necessary
for performing the
put file operation. It
replaces all tags in
Tibco configuration files
and puts them under
the /tmp folder.
cd - Mandatory (On Unix only)
Changes directory.
chmod - Mandatory (On Unix only)
Changes file
permissions.
for Various options Mandatory (On Unix only) Runs
loops.

echo Various options Mandatory (On Unix only) Prints

if Various options Mandatory (On Unix only) Starts a
condition.
wc -l Mandatory (On Unix only) Counts
the output lines.
the output.
Table 363: Tibco ActiveMatrix BusinessWorks Process (on Unix or Windows)

cd - Mandatory (On Unix only)
Changes directory.
chmod - Mandatory (On Unix only)
Changes file
permissions.
for Various options Mandatory (On Unix only) Runs
loops.
echo Various options Mandatory (On Unix only) Prints
if Various options Mandatory (On Unix only) Starts a
condition.
wc -l Mandatory (On Unix only) Counts
the output lines.
the output.
cut Various options Mandatory (On Unix only) Splits
the output line.

SNMP-based queries
Service Mapping accesses network infrastructure devices like load balancers and routers using Simple
Network Management Protocol (SNMP) v1/v2c/v3. Configure SNMP community credentials to enable this
type of access.
SNMP-based queries have the format of strings of integers.
General SNMP-based queries
SNMP-based queries have the format of strings of integers.

Make sure that the user has credentials for SNMPv3 unless read-only community string is used.
• 1.3.6.1.2.1.47.1.1.1.1.13
• 1.3.6.1.2.1.1.6
• 1.3.6.1.2.1.47.1.1.1.1
• 1.3.6.1.4.1.9.9.774.1.1.1
• 1.3.6.1.4.1.9.6
SNMP-based queries for switches and routers
• 1.3.6.1.4.1.9.9.46.1.3.1.1
• 1.3.6.1.4.1.9.9.68.1.2.1.1
• 1.3.6.1.2.1.17.1.4.1
• 1.3.6.1.2.1.17.4.3.1
• 1.3.6.1.2.1.17.7.1.2.2.1
• 1.3.6.1.2.1.17.2.15.1
• 1.3.6.1.4.1.9.9.23.1.2.1.1
• 1.3.6.1.4.1.45.1.6.13.2.1.1
• 1.0.8802.1.1.2.1.4.2.1
• 1.0.8802.1.1.2.1.4.1.1
A10 Thunder Series
• 1.3.6.1.4.1.1872.2.5.1.1.1.11
• 1.3.6.1.4.1.1872.2.5.3.1.3.2.1
• 1.3.6.1.4.1.1872.2.5.3.1.2.4.1
• 1.3.6.1.4.1.1872.2.5.1.3.1.10
• 1.3.6.1.4.1.1872.2.5.4.1.1.4.2.1
• 1.3.6.1.4.1.1872.2.5.3.1.6.3.1
• 1.3.6.1.4.1.22610.2.4.1.1.1
• 1.3.6.1.4.1.22610.2.4.1.6.2
• 1.3.6.1.4.1.22610.2.4.3.4.1.2.1
• 1.3.6.1.4.1.22610.2.4.3.2.1.2.1
• 1.3.6.1.4.1.22610.2.4.3.3.1.2.1
• 1.3.6.1.4.1.22610.2.4.3.4.3.1.1
• 1.3.6.1.4.1.22610.2.4.3.3.3.1.1

Cisco Content Services Switch CSS
• 1.3.6.1.4.1.2467.1.16.4.1
• 1.3.6.1.4.1.2467.1.31.3
• 1.3.6.1.2.1.1.2
• 1.3.6.1.4.1.2467.4.1
• 1.3.6.1.4.1.2467.4.2
• 1.3.6.1.4.1.2467.4.3
• 1.3.6.1.4.1.2467.4.4
• 1.3.6.1.2.1.1.1
• 1.3.6.1.4.1.2467.1.15.2.1
• 1.3.6.1.4.1.2467.1.16.4.1
• 1.3.6.1.4.1.2467.1.18.2.1
Cisco Global Site Selector (GSS)
• 1.3.6.1.2.1.1.5 – to get the hostname.

• 1.3.6.1.2.1.1.1 – to get product name.
Citrix Netscaler
• 1.3.6.1.4.1.5951.4.1.1.14
• 1.3.6.1.4.1.5951.4.1.1.1
• 1.3.6.1.4.1.5951.4.1.1.26.1
• 1.3.6.1.4.1.5951.4.1.3.1.1
• 1.3.6.1.4.1.5951.4.1.1.23.2
• 1.3.6.1.4.1.5951.4.1.1.23.3
• 1.3.6.1.4.1.5951.4.1.1.7
• 1.3.6.1.4.1.5951.4.1.3.1.1
• 1.3.6.1.4.1.5951.4.1.2.1.1
• 1.3.6.1.4.1.5951.4.1.2.7.1
• 1.3.6.1.4.1.5951.4.1.3.2.1
• 1.3.6.1.4.1.5951.1.5.2.1
• 1.3.6.1.4.1.5951.4.1.3.3.1
• 1.3.6.1.4.1.5951.4.1.3.11.1
• 1.3.6.1.4.1.5951.4.1.2.1.1
• 1.3.6.1.4.1.5951.4.1.2.7.1
• 1.3.6.1.4.1.5951.4.1.3.2.1
• 1.3.6.1.4.1.5951.1.5.2.1
• 1.3.6.1.4.1.5951.4.1.3.3.1
• 1.3.6.1.4.1.5951.4.1.3.11.1
BIG-IP Local Traffic Manager (LTM ) F5 (on F5 BIG-IP) and BIG-IP Global Traffic
Manager (GTM) F5
• 1.3.6.1.4.1.3375.2.1.6.3

• 1.3.6.1.4.1.3375.2.1.4.1
• 1.3.6.1.4.1.3375.2.1.3.3.3
• 1.3.6.1.4.1.3375.2.1.6.2
• 1.3.6.1.4.1.3375.2.1.2.1.1.2.1
• 1.3.6.1.4.1.3375.2.2.10.1.2.1
• 1.3.6.1.4.1.3375.2.3.12.4.2.1
• 1.3.6.1.4.1.3375.2.3.12.1.2.1
• 1.3.6.1.4.1.3375.2.1.4.1
• 1.3.6.1.4.1.3375.2.1.6.2
• 1.3.6.1.4.1.3375.2.1.4.2
• 1.3.6.1.4.1.3375.2.2.10.1.2.1
• 1.3.6.1.4.1.3375.2.2.5.6.2.1
• 1.3.6.1.4.1.3375.2.2.10.8.2.1
• 1.3.6.1.4.1.3375.2.2.5.6.2.1
• 1.3.6.1.4.1.3375.2.2.10.1.2.1
• 1.3.6.1.4.1.3375.2.1.4.1
• 1.3.6.1.4.1.3375.2.1.4.2
• 1.3.6.1.4.1.3375.2.1.6.2
• 1.3.6.1.4.1.3375.2.3.11.1.2.1
• 1.3.6.1.4.1.3375.2.3.12.3.2.1
• 1.3.6.1.4.1.3375.2.3.12.4.2.1
• 1.3.6.1.4.1.3375.2.2.5.6.2.1
• 1.3.6.1.4.1.3375.2.3.12.3.2.1
• 1.3.6.1.4.1.3375.2.3.12.4.2.1
• 1.3.6.1.4.1.3375.2.3.12.5.2.1
• 1.3.6.1.4.1.3375.2.3.6.7.2.1
• 1.3.6.1.4.1.3375.2.3.11.4.2.1
• 1.3.6.1.4.1.3375.2.3.3.1.2.1
• 1.3.6.1.4.1.3375.2.3.3.3.2.1
• 1.3.6.1.4.1.3375.2.3.9.1.2.1
• 1.3.6.1.4.1.3375.2.3.9.3.2.1
IBM WebSphere DataPower
• 1.3.6.1.2.1.1.1
• 1.3.6.1.2.1.1.5
• 1.3.6.1.4.1.14685.3.1.11.1
Juniper Junos
• 1.3.6.1.4.1.2636.3.1.3
Network Appliance Filer Storage Array
• 1.3.6.1.4.1.789.1.1.2
• 1.3.6.1.4.1.789.1.1.9

Radware Alteon NG
• 1.3.6.1.4.1.1872.2.5.1.1.1.11
• 1.3.6.1.4.1.1872.2.5.3.1.3.2.1
• 1.3.6.1.4.1.1872.2.5.3.1.2.4.1
• 1.3.6.1.4.1.1872.2.5.1.3.1.10
• 1.3.6.1.4.1.1872.2.5.4.1.1.4.2.1
• 1.3.6.1.4.1.1872.2.5.3.1.6.3.1
• 1.3.6.1.4.1.1872.2.5.4.1.1.4.2.1
• 1.3.6.1.2.1.1.1
• 1.3.6.1.4.1.1872.2.5.4.1.1.4.5.1
• 1.3.6.1.4.1.1872.2.5.4.1.1.3.3.1
• 1.3.6.1.4.1.1872.2.5.4.1.1.2.2.1
• 1.3.6.1.2.1.4.24.4.1
• 1.3.6.1.4.1.89.35.1.13.1.2
• 1.3.6.1.4.1.89.2.12
• 1.3.6.1.4.1.89.2.4
• 1.3.6.1.4.1.89.35.1.40.52.1.1
• 1.3.6.1.4.1.89.35.1.13.1
• 1.3.6.1.4.1.89.35.1.30.1
• 1.3.6.1.2.1.68.1.3.1
• 1.3.6.1.4.1.89.35.1.13.1
• 1.3.6.1.4.1.89.35.1.11.1
• 1.3.6.1.4.1.89.35.1.40.52.1.1
Rights and permissions required for Service Mapping

Service Mapping user needs to have special rights and permissions to access some applications and
network devices.
Table 364: Applications and network devices requiring special rights and permissions
CI Rights and permissions
BIG-IP Local Traffic Manager (LTM ) F5 (on Provide a user with permissions necessary to
F5 BIG-IP) and BIG-IP Global Traffic Manager run:
(GTM) F5
• bigpipe commands (for BIG-IP LTM F5 or
BIT-IP GTM F5 version 9)
• bigpipe and Traffic Management Shell
(TMSH) commands (for BIG-IP LTM F5 or
BIG-IP GTM F5 version 10)
• Traffic Management Shell (TMSH)
commands (for BIG-IP LTM F5 or BIG-IP
GTM F5 version 11)
• Traffic Management Shell (TMSH) advanced
commands (for BIG-IP LTM F5 or BIG-IP
GTM F5 version 10, 11, and 12)

Citrix XenApp, Citrix Presentation Server Provide a user who has permissions
• To run Citrix services
• To read and query the Citrix repository
IBM DB2 (on Linux) (For storage discovery only) Provide a DB2 OS
user who has permissions to run DB2 services.
IBM DB2 (on Windows) (For storage discovery only) Provide a DB2 OS
user who has permissions to run DB2 services.
IBM WebSphere Message Broker Flow (on Unix Provide an IBM WebSphere Message Broker
or Windows), IBM WebSphere Message Broker OS user with permissions to run the WebSphere
(on Unix or Windows) Message Broker service.
IBM WebSphere MQ (on Unix or Windows), IBM Provide an IBM WebSphere MQ OS user with
WebSphere MQ Queue permissions to run the WebSphere MQ services.
IBM WebSphere DataPower • Configure SNMP credentials.
• Configure applicative credentialsthat allow to
query devices using SOAP commands.
Microsoft Active Directory Provide credentials for domain administrator.

Microsoft Exchange CAS (on Windows) (For Exchange CAS 2007 and 2010) Provide
an Exchange Mailbox OS user with the rights
to run Exchange services on Windows and has
permission to query Exchange repository.
Caution: Do not use the dollar sign

($) in credentials for Exchange CAS,
because Service Mapping uses the
dollar sign in pattern variables.
Microsoft .NET Provide a IIS Virtual Directory OS user with the

rights to run the IIS service on Windows.
Microsoft Exchange Hub Transport Server (on (For Exchange Server 2007 and 2010) Provide
Windows), Microsoft Exchange Mailbox (on a user for the Exchange Mailbox OS with
Windows) permissions:
• To run Exchange services on Windows
• To query Exchange repository
Caution: Do not use the dollar sign

($) in credentials for Exchange Hub
Transport Server and Exchange
Mailbox, because Service Mapping uses
the dollar sign in pattern variables.

Microsoft SharePoint Provide a SharePoint OS user with permissions:

• To run SharePoint services on Windows
• To log into the SharePoint Admin page
Microsoft SQL Server For discovering Microsoft Biztalk using SQL

queries, provide a user and credentials for
Microsoft BizTalk.
MySQL Server (on Windows or Linux) Provide a user and credentials for the MySQL
instance that you discover.
Tibco EMS Configure applicative credentials for EMS
Management console.
Tibco EMS Queue Configure applicative credentials for EMS
Management console.
The following SAP applications: Provide a user with permissions to run SOAP on
RFC read table function.
• SAP Central Instance (CI)
• SAP Netweaver Development Infrastructure
SQL Server Reporting Server (SSRS) Provide an SSRS OS user with permissions to
run the SSRS Service.
Plan business services

You can centrally manage the process of planning, creating, and reviewing numerous business services
using the Service Map Planner.
Typically, the process of creating a business service is intensive. It includes collecting information and
performing multiple tests until you get a satisfying result. Most organizations have hundreds or thousands
of services which makes this process even harder to manage. Service Mapping allows you to gather and
test all the information related to business services in one central location.
You can create reports based on planning phases to monitor progress you made in planning and creating
business services.
The process of planning and creating business services using Service Map Planner consists of several
stages:
1. Create empty phases on page 616
Decide how you want to manage your business service planning by splitting business services into
groups. These groups are referred to as phases. You are free to organize business services into
phases whichever way you find effective: by location, by type of service, by priority, and so on. For
example, if you decided to start your planning project from business services in the EMEA office, you
create a phase with that name and populate it with all business services belonging to this office.

You do not have to accomplish planning phases in Service Mapping in any particular order. On the
contrary, you can simultaneously make progress on testing and reviewing business services belonging
to different phases.
2. Phase population on page 616
To begin the actual work on creating business services, you must add planned business services to
phases. It creates an association between business services and their phases, which helps to manage
creating business services. In our example, you add all business services used by the EMEA office to
the EMEA phase.
3. Creation of actual business services during planning on page 621
You create each business service individually even if you simultaneously added multiple business
services to the phase. During this stage, an administrator responsible for planning business
services collects data and runs the mapping process. Then a staff member who is familiar with the
infrastructure and applications reviews mapping results for correctness and approves the newly
created business service.
Going through these actions may take a long time. As a rule, a phase contains planned business
services at different stages depending on how much progress you were able to make.
Figure 156: Planning flow for business services

Create empty phases

Service Mapping allows you to split planned business services into groups which are referred to as phases.
Role required: sm_admin or sm_app_owner
Set up Service Mapping as described in Service Mapping setup on page 537.
Decide how you want to manage your business service planning by splitting business services into groups.
These groups are referred to as phases.Then populate phases with business services.You are free to
organize business services into phases whichever way you find effective: by location, by type of service, by
priority, and so on.For example, if you decided to start your planning project from business services in the
EMEA office, you create a phase with that name and populate it with all business services belonging to this
office.
You do not have to accomplish planning phases in Service Mapping in any particular order. On the
contrary, you can simultaneously make progress on testing and reviewing business services belonging to
different phases.
1. Navigate to Service Mapping > Service Map Planner > Phases.
2. Click New.
3. Define phase attributes as follows:
Field Description
Name Provide a descriptive, but short name for the

phase.
Description Provide a short description of the phase.
Status Verify that the status is set to Active.
4. Click Submit.
The new phase appears in the list of phases.
Phase population
You associate planned business services to phases.
To begin the actual work on creating business services, you must add planned business services to
phases. It creates an association between business services and their phases, which helps to manage
creating business services. In our example, you add all business services used by the EMEA office to the
EMEA phase.
You can associate business service using different methods depending on how you have been managing
your business services up until now and what information about them you gathered.

Table 365: Methods of associating planned business services to phases
Method Description Advantages Disadvantages
Import from the CSV This method suits you You associate multiple You must prepare
file if your organization business services at a all the necessary
has performed cross- time. information in a very
organization mapping specific format before
There is a relatively low
and analysis and you can perform the
chance of mistakes.
collected some import.
information about
planned business
services. If so, you can
organize the collected
information in a specific
order and save it as
a CSV file. Service
Mapping extracts
information from this
file and associates
multiple business
services to a phase in
one go.
Import from a load If there is no You associate multiple The result of the import
balancer information available business services at a is not precise. There
about planned time. may be many false
business services, or duplicate business
There is no
you can use your services created by
preparation.
load balancers as the mistake because the
source of information. data from the load
Service Mapping can balancer is raw.
extract entries directly
from load balancers
and convert them into
planned business
services.
Add business services Use this method if There is no If you have many
manually you do not have any preparation. business services for
organized data on your a phase, the process
There is a relatively low
business services or may take a long time.
chance of mistakes.
you do not want to use
other methods.
Import planned business services from the CSV file

Associate multiple business services to a phase in a single step by importing them from the CSV file
containing necessary information.
Prepare the information necessary for the import in the CSV file:
1. Copy the following template in the .xlsx format: importCSVexample.xlsx.
2. Populate the fields in the .xlsx file:

Warning: Do not modify column labels in the .xlsx file.
Warning: If information on business services is not formatted in the .xlsx file according to the
template, Service Mapping fails to create planned services or creates them with errors.
Column label Information
Name The name of the planned business service.

ServiceDeploymentOwner Enter the full name of the service
deployment owner as it is displayed in
the platform: <firstname.lastname>. The
service deployment owner is responsible for
creating and fixing business services during
planning. The service deployment owner
must have the sm_admin role.
ApplicationOwners Enter the application owner owner. The
application owner is familiar with the
infrastructure and applications making up
the service. This user provides information
necessary for successful mapping of
a business service. Once a service is
mapped, this user reviews the results and
either approves it or suggests changes. Use
the following syntax: <firstname.lastname>.
To enter more than one name, use
semicolon (;) to separate names.
PlannedEntryPoints Enter the HTTPS entry points that Service
Mapping uses to discover this business
service. To enter more than one entry point,
use semicolon (;) to separate them.
An entry point is a property of a connection
to a configuration item (CI). Service
Mapping starts the mapping process from
this point. For example, to map your
electronic mailing business service, define
an email address.
OtherEntryPoints Enter information about entry points that

either a service deployment owner or
application owner manually defines for this
business service. Enter this information as
free text.
ComponentsDetails Enter information about components you
expect to discover as part of this business
service. Enter this information as free text.
3. Save the file in a drive that you can access during the import with the .csv extension.
Role required: sm_admin

This method suits you if your organization has performed cross-organization mapping and analysis
and collected some information about planned business services. If so, you can organize the collected
information in a specific order and save it as a CSV file. Service Mapping extracts information from this file
and associates multiple business services to a phase in one go.
2. Click the relevant phase.
3. On the Phase page, click Import from CSV.
4. In the Select CSV file to import window, click Choose file.
5. Navigate to the CSV file to use for the import and click Choose.
6. Click Import.
The newly associated business services appear under Business Service Planning.
7. If necessary, troubleshoot import-related errors.
a) Click the Import Errors tab.
b) Review information on business services that Service Mapping failed to import.
c) Create a separate CSV file to these business services.
Note: Make sure that the information and its format are correct.
d) Import business services from the second CSV file by repeating 3 on page 619-6 on page
619.
Import planned business services from load-balancers

Associate multiple business services to a phase in one go by importing them from load balancers.
If there is no information available about planned business services, you can use your load balancers as
the source of information. Service Mapping can extract entries directly from load balancers and convert
them into planned business services.
3. On the Phase page, click Import from load balancer.
The Load Balancer Services page shows the list of entries in all load balancers configured in the
instance.
4. Mark the entries that you want Service Mapping to import as a business service by clicking check
boxes next to them.
5. Click Import.
The newly associated business services appear under Business Service Planning.
By default, Service Mapping assigns the following parameters for every business service:
• Name - based on the following rule: <load balancer name>+<VIP name>. You can change names
at a later stage.
• Entry point type - inferred from the port value as follows:
Port number Entry point type
443 HTTPS
80 HTTP

Port number Entry point type
Any number except 443 and 80 TCP
6. If necessary, troubleshoot import-related errors.

a) Click the Import Errors tab.
b) Review error messages and fix issues that caused errors.
Add planned business services to phases manually

If you cannot associate a business service to a phase by importing it, add it manually.
You can add a business service only to an existing phase.
Use this method if you do not have any organized data on your business services or you do not want to
use other methods.
3. On the Phase page, click New.
4. Define attributes for the business service you want to add:
Field Description
Name Enter a descriptive and short name for this

business service.
Application Owner The application owner is familiar with the
infrastructure and applications making up
the service. This user provides information
necessary for successful mapping of
a business service. Once a service is
mapped, this user reviews the results and
either approves it or suggests changes. The
application owner cannot create or modify
business services.
Click the Add me or Edit Application
Owner icons to define this parameter.
Service Deployment Owner The service deployment owner is

responsible for creating and fixing business
services during planning.
Select the name from the list. If you add
more than one name, separate them with a
semicolon (;).
5. Click Submit.

Creation of actual business services during planning

You create each business service individually even if you simultaneously added multiple business services
to the phase.
After you created phases and populated them with business services, you are ready to look at individual
business services in a phase. Business services in phases are only planned services, they are drafts.
You are going to create actual business services based on them. The actual business service inherits
all information defined for the planned service. This new actual business service appears in the list of all
business services and has the Non-Operational state.
The following users collaborate to create actual business services:
• Service deployment owner
The service deployment owner is responsible for creating and fixing business services during planning.
• Application owner
The application owner is familiar with the infrastructure and applications making up the service. This
user provides information necessary for successful mapping of a business service. Once a service
is mapped, this user reviews the results and either approves it or suggests changes. The application
owner cannot create or modify business services.
Notice that although service deployment owner fixes the actual business service, the application owner
provides feedback and approves the draft version of it - the planned business service. It allows you to have
all the information related to planning and creation of the business service in one central place.

Figure 157: Creating an actual business service (BS)
Creating an actual business service during planning has the following flow:
Collect data
A service deployment owner or an application owner collects data for the planned business service.

At this stage you are planning your business service and collect information that Service Mapping uses
later to create, review and approve this business service.
You provide information on people responsible for creating and reviewing your business service.
Make sure that your planned business service has some entry points assigned to it. An entry point is a
property of a connection to a configuration item (CI). Service Mapping starts the mapping process from
this point. You cannot create an actual business service, review, and approve the planned business
service unless it has at least one entry point. Even if this planned business service has some entry points
assigned to it during import, you can add additional entry points if necessary.
Some information, such as information about components, is not used to create a business service, but to
review it at a later stage.
2. Select the phase which contains the business service.
3. Click the name of the business service.
4. (Mandatory) Define the application owner for this business service:
The application owner is familiar with the infrastructure and applications making up the service. This
user provides information necessary for successful mapping of a business service. Once a service
is mapped, this user reviews the results and either approves it or suggests changes. The application
owner cannot create or modify business services.
a) Click the Add me icon next to Application Owner to define yourself as the application owner.
Or
b) Click Edit Application Owner (Padlock) icon next to Application Owner and enter a single or
multiple names. If necessary, enter an email.
5. Define the service deployment owner for this business service in the Service Deployment Owner
field.
The service deployment owner is responsible for creating and fixing business services during
planning.
Select the name from the list. Separate multiple names with a semicolon (;).
6. If there is no entry point, add it:
An entry point is a property of a connection to a configuration item (CI). Service Mapping starts the
mapping process from this point. For example, to map your electronic mailing business service, define
an email address.
a) Click New on the Planned Entry Points tab.
b) Select the relevant type for the entry point from Entry point type.
If there is no entry point type you need, enter its description on the Other Entry Points tab.
c) Define other entry point attributes that vary depending on the type you selected.
Attribute Description
Host/Hostname/Host Name The value of the target server on which

the service is running. This value can
contain a real host name, alias, IP, or
VIP.
Port The port number of the service that you
want to discover.
Name The name of the service that you want
to discover.

URL The URL of the service that you want to

discover.
d) Click Submit.
7. Provide information for components that are part of this business service, and that you know of:
a) Click the Components tab.
b) Click New.
c) Enter description of the business service component.
d) Click OK.
Check entry point connectivity

A service deployment owner or an application owner tests that Service Mapping can connect to the devices
that are expected to make up this business service.
Run either horizontal or top-down discovery on the host for which you want to check connectivity.
You can check if Service Mapping can connect to hosts to identify any connectivity-related issues. You
can investigate the problem source, fix it, and run the connectivity check again to verify that you are ready
to create an actual business service. The most common causes of connectivity problems are missing or
wrong credentials for a host.
You can check connectivity of entry points you defined for a planned business service. An entry point is a
property of a connection to a configuration item (CI). Service Mapping starts the mapping process from
this point. You can also check connectivity of hosts connected to specified entry points.
As part of defining entry points for a business service, you enter their IP addresses. When you run this test,
Service Mapping checks the corresponding record in the CMDB [cmdb_ci] for information on credentials
for IP addresses you defined. By default, Service Mapping checks the IP address that you defined for the
entry point, but you can add additional ID addresses during the procedure.
To check connectivity of hosts connected to entry point IP addresses, you must specify the number
of levels to check as Hop Count. In this case Service Mapping uses information on TCP and Netflow
connections stored in the [cmdb_tcp] and [sa_flow_connection] CMDB tables, to find hosts connected to
the IP address.
2. Select the phase which contains the planned business service.
3. Click the name of the planned business service.
4. On the Planned Entry Points tab, click the check boxes next to the entry points whose credentials
you want to check.
5. Click Check Connectivity.
The Check IP Address Connectivity window opens displaying the IP address you defined for the entry
points.
6. If necessary, modify or add IP addresses in the IP Address(es) field.
Use comma without whitespace to separate multiple IP addresses.
7. Select the number of levels to check in the Hop Count list.

The number of hops performed by the actual test depends on the ability of Service Mapping to connect
to hosts in the next level. If you use Netflow to collect data, you can see CIs on all levels even if
Service Mapping cannot connect to them.
8. Click OK.
The Connectivity Test page opens.
9. Verify that the status of the test is Completed.
10. Review the result of the test:
• If the status and the message state that the IP address is found, Service Mapping can connect to
this host.
• If the status is Info, there is a possibility that there is a connectivity problem or that this host is not
in the CMDB.
• If the status is Not found, either there is a connectivity problem or this host is not in the CMDB.
11. Click the IP address to read the full message. Use this information to troubleshoot connectivity issues.
To troubleshoot, you may need to:
• Run discovery on a problematic CI either from Discovery or Service Mapping.
• Define missing or wrong credentials for this CI.
12. Perform this procedure on the same entry points to verify that Service Mapping does not experience
the same connectivity issues.
Create actual business services during planning

The service deployment owner creates an actual business service based on the planned one.
The actual business service inherits all information defined for the planned service. This new actual
business service appears in the list of all business services and has the Non-Operational state.

Ideally, only the service deployment owner should create the actual business service, however, any user
with the sm_admin role can perform this task.
When Service Mapping creates an actual business service during planning, it performs the following
validation:
• Checks that the entry point is not used for another business service.
• Checks that the business service name is unique and does not exist in the CMDB.

2. Select the phase which contains the planned business service.
3. Click the name of the planned business service.
4. Make sure that the name and the service deployment owner are defined.
5. Click Create and Discover.
Service Mapping creates the actual business service and starts the process of discovery and mapping.
When the discovery process completes, the View map link appears on the page.
6. If necessary, troubleshoot validation errors:
a) Click the Validation Errors tab.
b) Review error messages and fix the issues that caused them.
7. (Mandatory) Enter the name of the application owner. The application owner is familiar with the
infrastructure and applications making up the service. This user provides information necessary for
successful mapping of a business service. Once a service is mapped, this user reviews the results and
either approves it or suggests changes.
8. Click Send for Review.
At this stage, you let the application owner review mapping results and provide feedback in the form of
notes on the planned business service page.
Review business services

An application owner reviews mapping results for correctness and provides feedback for the business
service.
Role required: sm_app_owner
As a staff member that is familiar with the infrastructure and applications, review mapping results of the
actual business service and provide your feedback in the form of notes. After that, a service deployment
owner reviews and implements your feedback, and possibly, leaves some notes for you. The process
of business service review may take some time as it requires making changes and running the mapping
process on the business service. Typically, it takes several iterations to arrive at the desired result. Once
the service deployment owner fixes all issues, you can approve it.
Ideally, only the application owner reviews the planned business service, however, any user with the
sm_app_owner role can perform this task. As the application owner for the planned business service, you
receive an email notification that the business service is assigned to you for review.
1. Navigate to the planned business service:
a) Navigate to Service Mapping > Service Map Planner > Business Service Planning.
b) Sort the list of planned business services by status and scroll to see services in In Review status.
Or
Use the filter to narrow the list.
c) Click the required business service.

2. Review the actual business service:

a) On the Planned Business Service page, check entries on the Components tab to see which
devices and applications are expected to be part of this business service.
b) Click View Map and review the map.
c) Return to the planned business service, enter your comments for the service deployment owner in
the Notes field and click Post.
At this stage, let the service deployment owner read your comments and make the necessary
changes.
3. Approve the planned business service:

a) Navigate to the same business service.
b) Review the notes from the service deployment owner.
c) Click View Map and check that the changes you required are implemented.
d) If the mapping results are satisfactory, click Approve.
Fix actual business services during planning

The service deployment owner checks the feedback and updates the actual business service as
necessary.
The process of business service review may take some time as it requires making changes and running
the mapping process on the business service. Typically, it takes several iterations to arrive at the desired
result.
Ideally, only the service deployment owner should fix the actual business service, however, any user with
the sm_admin role can perform this task.
1. Navigate to Service Mapping > Best Practice > Planned Business Services.
2. Sort the list by status.
Business services reviewed by the application owner are in In Review status.
3. Click one of the business services in In Review status.
4. Review the notes made by the application owner.
5. Click View map.
The map of the actual business service opens.
6. Make necessary changes on the actual business service page.
7. Check the map for correctness as described in Check a business service map on page 646.
8. Enter your comments for the application owner in the Notes field and click Post.
At this stage, let the application owner read your comments and review the changes you made.
Approve business services during planning

The application owner reviews the fixed business service and approves it if the result is satisfactory.
Role required: sm_app_owner
As a staff member that is familiar with the infrastructure and applications, review the mapping results of the
actual business service and provide your feedback in the form of notes. Then, a service deployment owner
reviews and implements your feedback, and possibly, leaves some notes for you. The process of business
service review may take some time as it requires making changes and running the mapping process on

the business service. Typically, it takes several iterations to arrive at the desired result. Once the service
deployment owner fixes all issues, you can approve the business services.
Ideally, only the application owner should approve the planned business service, however, any user with
the sm_app_owner role can perform this task.
1. Navigate to the planned business service:
a) Navigate to Service Mapping > Best Practice > Planned Business Services.
b) Sort the list of planned business services by status and scroll to see services in In Review status.
Or
Use the filter to narrow the list. For example, filter by your name if you are the application owner.
c) Click the required business service.
2. Review notes made by the service deployment owner.

3. Click View Map and check that the changes you required are implemented.
4. If the mapping results are satisfactory, click Approve.
Business service definition

Define business services to build comprehensive maps of all devices and applications used to provide
services in your organization.
to the organization. Business service can be internal, like organization email system or customer-facing,
like an organization web site. For example, creating financial reports through a web-based application
requires a computer, web server, application server, databases, middleware, and network infrastructure.
These applications and hosts are all configured to offer the service of financial reporting.
Create and define your business services as follows:
Define a business service

Specify entry points and the mapping method for a business service.
• Determine how important the business service is to your organization.
• Ensure that you performed procedures described in Service Mapping setup on page 537.
• Check preconfigured entry point types to make sure the type that you need exists in the application. If
not, create it as described in Create an entry point type for Service Mapping on page 735.
• If the business service contains load balancers running on a Linux host, see create a discovery
behavior for load balancers.
• If your ServiceNow instance uses domain separation and you have access to the global domain, select
the domain to which the business service belongs from the domain picker ( ).
It must be a domain without any child domains.

After you analyze your organization business services, define them in Service Mapping.
The following are the parameters you must define for every business service:
• Name: Assign a meaningful name that reflects the nature of this business service.
• Mapping method:

• Pattern-based mapping:Service Mapping discovers and maps configuration items (CIs) using
patterns. A pattern is a sequence of algorithms that establish the parameters of a CI as well as its
outbound connections. Service Mapping always uses the pattern-based method.
• Traffic-based mapping: Service Mapping discovers and maps CIs by detecting their inbound and
outbound traffic. You can use this method in addition to the pattern-based mapping. This method is
especially useful during the initial stages of mapping.
• Entry point: Whichever method you choose for mapping, specify an entry point.
An entry point is a property of a connection to a configuration item (CI). Service Mapping starts the
mapping process from this point. For example, to map your electronic mailing business service, define
an email address.
Entry points vary depending on the nature of the business service. A printer, URL, or phone
number can all serve as entry points to your services. Service Mapping comes with a wide range of
preconfigured entry point types that cover most commonly used applications.
After Service Mapping discovers CIs belonging to your business service for the first time, it then runs
discovery on CIs again to find changes and updates. Discovery schedules determine what CIs and how
often Service Mapping rediscovers.
You can also learn how to define a business service from the following video tutorial:
1. Navigate to Service Mapping > Services > Business Services.

2. Click New.
3. Define the business service attributes as follows:
Field Description
Name Enter the business service name. This

name must be unique to this business
service. Use self-explanatory names such
as mailing service or printing
service.
Business criticality Select a criticality level to define the
importance of this service in your
organization. For more information, see
Business services on page 516.
Owned by Select an owner who is responsible for
this business service in the organization.
Owners get automatic notifications for the
service if you enter their email address or
phone number.
Email Enter the email address of the owner.
Business phone Enter the phone number of the owner.
Traffic based discovery To use the traffic-based discovery method in
addition to the pattern-based method, select
this check box.
To map the business service using only
discovery patterns, clear this check box.

Field Description
Discovery status Do not change this value.

Service Mapping automatically generates
this status.
• In progress: Service Mapping is
performing discovery and mapping for
this business service for the first time.
• Done: Service Mapping discovered and
mapped this business service at least
once.
Operational status Select Operational to use this business

service. If you customized preconfigured
options for this category, select the option
whose value is set to 1.
Event Management calculates impact only
on business services in use.
If you do not want to use this business
service immediately, select Non-
Operational , Repair in Progress, or DR
Standby.
Comments Add a description or notes about the

business service.
4. Define all required entry points for your business service.

a) In the Entry Points section at the bottom of the form, click New.
b) In the Configure New Entry Point window, select the entry point type.
Entry point parameters depend on the type you select.
c) Configure attributes for the entry point as described in Entry point attributes on page 630.
d) Click Submit.
e) If necessary, repeat these steps to define an additional entry point.
5. Click View map to start mapping.

The Discovery page opens and displays the mapping in progress.
Entry point attributes

Service Mapping comes with a wide range of preconfigured entry point types that cover most commonly
used applications.
Check attribute definitions to correctly add entry points to your business services.
An entry point is a property of a connection to a configuration item (CI).
There are some general attributes shared by almost all entry point types as described in the table below:

Table 366: General attributes
Host/Hostname/Host Name The value of the target server on which the

service is running. This value can contain a real
host name, alias, IP, or VIP.
Port The port number of the service that you want to
discover.
Name The name of the service that you want to
discover.
URL The URL of the service that you want to
discover.
There are some attributes which you configure differently depending on what entry point they relate to, as
described in the table below:
Table 367: Entry point attributes specific for some entry points
Entry point type Attribute Description
Active Directory Domain to Domain name The AD domain name.

Domain Controllers
Forest name The AD forest name.
Domain controller distinguished The distinguished name of the
name AD domain controller. Usually
this is a compilation of the
domain controller name and the
hostname.
Domain Controller Name The AD Domain Controller
name.
Active Directory Forest Forest name The AD Forest name.
Application to Storage File in use by application The path to the file used by an
application. For example, mssql
uses c:\applications\mssql
\users.db. It is populated by
patterns.
File system name The file system containing the
file used by an application. For
example, if a mssql uses c:
\applications\mssql\users.db,
the value is "c:".
Connected array ids N/A
Advanced Queue Scheme The name of the Oracle DB
table where the Queue is
defined.
Instance The name of the Oracle
instance.
Queue The name of the queue.

BizTalk Connection Adapter address The connect string to the Biztalk

adapter. It can be a path, URL,
host, or port.
Transport Type The type of the Biztalk adapter.
For example a URL, file SOAP,
FTP, and so on.
CRM Component Role The role of the CRM. Leave
empty if unknown.
DB2 UDB Instance The name of the DB2 instance.
DCTM Connection to broker Repository The name of documentation
repository.
DCTM Index Agent Connection Instance Name The name of the instance of
Documentation Index Agent.
Repository The name of the documentation
repository.
DCTM Job Processor Repository The name of documentation
repository.
Citrix Delivery Controller Farm Type The Type of the Delivery
Controller.
Controller Name The name of the Citrix
Controller.
DocBase Connection Repository The name of the documentation
repository.
EJB JNDI Name The jndi name of target EJB.
EMS Queue The name of Tibco EMS queue.
EMS JNDI JNDI Name The jndi name of Tibco EMS
connection.
F5 Mirror Origin IP The IP address of the second
pair F5 device.
Origin host The hostname of the second
pair F5 device.
Fast Search Repository The name of repository of fast
search.
ITAM Asset Center Folder The path to configuration folder.
JMS Flow JMS project The name of Tibco project.
JMS Flow Queue Name The name of Tibco EMS queue.
JMS Server Queue Name The name of the queue defined
on JMS server.
HTTP Listener to WMB Directory The path to the WMB
Dependency installation directory.

MQ Queue Name The name of the IBM MQ

Queue.
MQ Flow Source IP The IP of the source IP create
connection to MQ.
Queue Name The name of IBM MQ Queue.
MQ Cross-memory Command line The command line of MQ.
Queue Name The name of IBM MQ Queue.
MSMQ Flow Queue Name The name of MS MQ queue.
MS SQL Server Instance The name of MSSQL instance.
MySQL Cluster Data Node Node ID The ID of MySQL instance.
Node group The group of MySQL instance
MySQL Cluster MGM Node ID The ID of MySQL instance.
MySQL Slave Server Config IP The IP of the MySQL Config
server.
Config Port The port of the MySQL Config
server.
Oracle DB Schema The name of table on the
Oracle instance.
Instance The name of oracle instance.
Oracle ESB Connection Adapter data The content of the adapter.
Adapter Type The type of the adapter.
Oracle RAC DB Service Name The name of the Oracle RAC
service.
PostgreSQL DB Instance The name of the PostgreSQL
DB.
Remote TCP Cross-memory Source_ IP The IP of the source host
process.
Source Port The port of source process.
SAP APP EP SID The SAP instance SID name.
Instance The instance name.
SAP BO Servers Server name The name of the BO server.
Sharepoint connection Origin URL The URL of the IIS.
SSAS Project The name of the SSAS project
(can be empty).
SSAS for MSSQL Instance The name of the MSSQL
instance.
Client Type The type of the client
connected.

SSIS Job The name of SSIS job can be

empty.
SSIS file Package file name The name of the package file.
SSIS for MSSQL Instance The name of the MSSQL
instance.
Client Type The type of the client
connected.
StoreParameters Components Front The parameters of the Citrix
application.
Farm The farm host the Citrix
application.
Application name The Citrix application name.
XenApp or Presentation Server Type The type of the Citrix
application.
Farm The farm host the Citrix
application.
Icon path The logic path of the Citrix
application.
Argument The parameters of Citrix
application.
Path The logic path of the Citrix
application.
Exec The EXE name of Citrix
application.
IP Address The IP of host is member of
Citrix. farm
Sybase Instance The name of Sybase instance.
Tibco Conf File Configuration File The path to Tibco BW project.
Process Name The name of Tibco BW main
process.
Queue Port The port of the queue used by
the Tibco process.
Config IP The IP of the source of the
queue.
Tibco BW Process name The name of Tibco BW main
process.
Tibco File Listener File The path of the file is used by
Tibco BW for integration.
Tibco Hawk Configuration directory The path to Tibco Hawk
Configuration folder.
WMB Dependency Command line The command line of the WMB.

XenApp or Presentation Server Farm The farm host the Citrix

Components application.
Icon path The logic path of the Citrix
application.
Organize business services into groups

Arrange business services by groups to perform some actions simultaneously on multiple services. Use
service groups to control user access to services. In Event Management, you can track service health by
service groups.
Typically, enterprises have hundreds of services which makes it impractical to manage them individually.
How you organize business, manual or technical services, depends on the user and service provisioning
policies of your enterprise.
The relation between business services in groups is purely logical and the same business service can be
part of more than one group. For example, the Mobile business service can be part of the following groups:
sales, Beijing, and telephony.
Figure 158: Example of a business service belonging to different groups
Groups can make your service lists much shorter and cleaner. It is especially important for large
organizations that have hundreds of business services.
You can also have a hierarchy of service groups with some groups embedded within others. If users have
access to a parent business service group, they automatically have access to all its child groups.
You can assign business services to groups and reorganize groups at any time.

When you delete a business service group, business services in the group are not deleted.
1. Create a business service group.
a) Navigate to Service Mapping > Services > Service Groups.
b) Click New.
c) Enter the name of the new business service group in the Name field.
d) To embed this group in another group, enter the name of the other group in the Parent Group
field.
2. Add a business service to the newly created group.

a) In the Service Group Members section, click New.
b) In the Name field, enter the name of the service. If you are using Event Management, you can
also enter an alert group name.
c) Click Submit.
3. Alternatively, add a service to a group from the business service form.

a) Navigate to Service Mapping > Services > Business Services.
b) Select the service you want to assign to a group.
c) In the Service Group Members section, double-click Insert a new row.
d) Enter the name of the service group to which you want to assign this service.
e)
Click the OK icon ( ).
f) Click Update.
Control user access to business services

Assign user roles to service groups to control user access to business or IT services in your organization.
Make sure that you have performed the user provisioning tasks for Service Mapping or Event Management
users:
1. Add users to groups.
2. Create new roles.
3. Assign roles to a user or user groups.
Make sure that you have created service groups as described in Organize business services into groups
on page 635.
Users inherit permissions from roles that are assigned to them. Service Mapping provides these
preconfigured roles:
sm_admin Sets up the Service Mapping application. Maps,
fixes, and maintains business services. Also
performs advanced configuration and customization
of the product. Assign this role to application
administrators.


application users.

services and are familiar with the infrastructure and
applications that make up the services.
Event Management provides these preconfigured roles:
evt_mgmt_admin Has read and write access to all Event

Management features to configure Event
Management.
evt_mgmt_operator In addition to the evt_mgmt_user permissions,

can also activate operations on alerts such as
acknowledge, close, open incident, and run
remediations.
evt_mgmt_user Has read access to all Event Management features.

Has write access to alerts to manage the alert life.
Has the itil role to be able to manage incidents that
are created from alerts.
evt_mgmt_integration Has create access to the Event [em_event] and

Registered Nodes [em_registered_nodes] tables to
integrate with external event sources.
policies of your enterprise.The relation between business services in groups is purely logical and the same
business service can be part of more than one group. For more information about service groups, see
Organize business services into groups on page 635.
By assigning a Service Mapping role to a service group, you allow all users with this role to access all
services belonging to this group.

Figure 159: Assigning a role to a service group
In the base system, all services are assigned to the All service group that lets all users view and manage
the services. When you assign a role to a service group, the users with this role can access only IT
services in this service group. Users cannot access any IT services, which are not part of that service
group.
You can give access to services to existing or new users. You can also add users to groups to assign roles
simultaneously to multiple users.
You can assign some roles directly to business service groups. However, most enterprises choose to
organize their roles as a hierarchy. It helps to manage roles across multiple ServiceNow applications. For
example, the Service Mapping administrator [sm_admin] can be part of a broader administrator role like
administrator [admin]. By assigning roles to user groups, you give permissions and rights of this role to all
users belonging to the same group.
When you delete a business service group, business services in the group are not deleted. The connection
between the role and the services making up this group (responsibilities) are removed.
1. If using Service Mapping, navigate to Service Mapping > Services > Service Group
Responsibilities.
2. If using Event Management, navigate to Event Management > Services > Service Group
Responsibilities.
3. Click New.
4. In the Business Service Group field, enter the name of the group.
5. In the Role field, enter the name of the role.
For example, evt_mgmt_admin.
6. Click Submit.
Create a discovery schedule for an application CI

You can define how often Service Mapping runs the discovery process for different configuration items
(CIs) and updates information about them.
Define your business services prior to defining discovery schedules for discovering CIs which are part of
these services.
Make sure that at least one business service that the relevant CI is part of is in the operational state.

When you define a new business service, Service Mapping performs discovery of all CIs that participate
in this business service and creates its map. After the initial mapping is complete, Service Mapping
regenerates business service maps regularly by rediscovering CIs making up a business service.
In the base system, Service Mapping is preconfigured with a generic schedule for discovering all CIs of
the application type. CIs of the application type derive from the cmdb_ci_appl table. The generic schedule
triggers discovery of all applications in your organization once a day. In addition to the generic discovery
schedule for applications, there is a preconfigured schedule for discovering load balancers deriving
from the cmdb_ci_lb_service table. Typically, these two preconfigured schedules are enough to update
information for business services.
Part of discovering an application CI is identifying its host. Service Mapping checks if the device hosting
this application CI exists in the CMDB. If not, Service Mapping triggers Discovery to perform host detection.
The information on hosts is updated in the CMDB when Discovery runs horizontal discovery. You can
manage the schedules that trigger horizontal discovery as described in Schedule discovery on page 28.
Some CI types are prone to more frequent changes and updates than others, so you can manage the load
by adjusting the discovery schedule to match the nature of each CI type. Having customized discovery
schedules also allows you to avoid redundant stress on your infrastructure. For example, if you modify
Apache Web server settings more often than updating your applications, create discovery schedules for
Apache Web server that rediscover them more frequently than other CIs.
If necessary, you can create the following discovery schedules for application CIs:
• For CI types
Service Mapping discovers all CIs belonging to this type
• For specific CIs
Service Mapping discovers only one CI that you specified for this schedule
When you define discovery schedules based on CI types, several schedules may apply to the same CI.
To avoid discovering the same CIs more than once the most specific schedule always has precedence.
For example, if there are two CI types one of which is a parent and the other is its child, and you create
discovery schedules for both of them, CIs belonging to the child CI type are discovered only using the
schedule for the child CI type, not the parent CI type. At the same time, if there is no schedule for a child CI
type, the parent CI type schedule is used to discover the child CIs.
If you define a discovery schedule for a specific CI as well as a schedule for the CI type to which this CI
belongs, Service Mapping uses the schedule for this specific CI, and not the generic schedule for its CI
type.
1. Navigate to Service Mapping > Administration > Discovery Schedules.
2. To create a specific schedule, click New.
Or
To customize the generic schedule for all application CIs, click All Applications:
The Discovery Schedule page opens.

3. Fill in the fields as follows:
Table 368: Discovery Schedule Form for Service Mapping
Field Description
Name For a new specific schedule, enter a unique

and descriptive name.
Discover For a new specific schedule, select
Service for Service Mapping.
Service discovery For a new specific schedule, select CI
Type
Note: In some special cases,

you can create a schedule just for
one specific CI. To do so, select
Specific CI.
CI type For a CI type-based schedule, select the

relevant CI type from the list.
CI For a specific CI-based schedule, select the
relevant CI from the list.
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.

Field Description
Max run time Set a time limit for running this schedule.
When the configured time elapses, the
remaining tasks for the discovery are
canceled, even if the scan is not complete.
Use this field to limit system load to a
desirable time window. If no value is
entered in this field, this schedule runs until
complete.
Run and related fields Determines the run schedule of the
discovery. Configure the frequency in the
Run field and the other fields that appear to
specify an exact time.
Note: The run time always uses

the system timezone. If you add the
optional Run as timezone field, it
has no effect on the actual runtime.
4. Define the schedule:
Table 369: Discovery Schedule run options
Daily Runs every day. Use the Time field to select the time of day this
discovery runs.
Weekly Runs on one designated day of each week. Use the Time field to
select the time of day this discovery runs.
Monthly Runs on one designated day of each month. Use the Day field to
select the day of the month. Use the Time field to select the time of
day this discovery runs. If the designated day does not occur in the
month, the schedule does not run that month. For example, if you
designate day 30, the schedule does not run in February.
Periodically Runs every designated period of time. Use the Repeat Interval
field to define the period of time in days, hours, minutes and
seconds. The first discovery runs at the point in time defined in the
Starting field. The subsequent discoveries run after each Repeat
Interval period passes.
Once Run one time as designated by the date and time defined in the
Starting field.
On Demand Does not run on a schedule. Click the Discover now link to run this
discovery.
Weekdays Runs every Monday, Tuesday, Wednesday, Thursday, and Friday.
Use the Time field to select the time of day.
Weekends Runs every Saturday and Sunday. Use the Time field to select the
time of day.
Month Last Day Run the last day of every month. Use the Time field to select the
time of day.

Calendar Quarter Runs on March 31, June 30, September 30, and December 31.
End Use the Time field to select the time of day. To change these
dates, modify the script include DiscoveryScheduleRunType.
After Discovery Allows you to sequentially stagger the schedule. Use this option to
run this schedule after the Discovery designated in the Run after
field finishes. Check the Even if canceled check box to designate
that this discovery should run even if the Run after Discovery is
canceled before it finishes.
• This option is not valid when the Discovery is started via
DiscoverNow, or when using the Discover CI feature.
• You cannot designate an inactive Discovery schedule.
• You cannot create a loop by designating the run after Discovery
to be the same Discovery.
• This Discovery does not run if the Run after discovery does
not finish, with the exception that the Even if canceled box is
checked and the Discovery is canceled.
5. Click Submit.
Enable traffic-based discovery for CI types or specific CIs

Service Mapping can discover and map CIs by detecting the inbound and outbound traffic that the CIs
generate. Create a traffic-based discovery rule to determine which configuration items are available for
traffic-based mapping.
If your ServiceNow instance uses domain separation and you have access to the global domain, select the
domain to which the business service belongs from the domain picker ( ). It must
be a domain without any child domains.
• Ensure that the traffic-based discovery is enabled at the Service Mapping product level: navigate to
Service Mapping > Administration > Properties and verify that the Traffic based discovery check
box is selected.
• Enable traffic-based discovery for a specific business service as described in Define a business service
on page 628.
You may choose to use traffic-based discovery and mapping in addition to the pattern-based mapping.
You can create rules to configure Service Mapping to use traffic-based discovery for certain CIs. You can
configure traffic-based discovery rules to monitor specific CIs or types of CIs.
Rules for specific CIs take precedence over rules for CI types. For example, if you do not want to use
traffic-based discovery on any Tomcat servers, you can define a CI type rule disabling the traffic-based
discovery on the Tomcat table. At the same time, you can create a discovery rule enabling the traffic-based
discovery for a specific Tomcat server. In that case, Service Mapping uses the traffic-based discovery only
for this specific Tomcat server out of all Tomcat servers.
If you used both pattern-based and traffic-based mapping for a business service, its map displays CIs and
hosts that Service Mapping discovered using both methods. While detecting CI inbound and outbound

traffic creates a very inclusive map, it may also result in mapping many redundant CIs that do not influence
the business service operation.
If your instance uses domain separation, you can create traffic-based rules for specific domains. Rules in
the base system are assigned to the global domain and apply to all domains of all levels.
When you create a rule for a specific domain, the new rule is used only for this domain and does not exist
in any other domains. If you customize an existing rule in the global domain and assign it to a specific
domain, you create a copy of the global rule, which is still used in all other domains except the domain that
has the customized version of this rule. Likewise, if you customize a rule in the global domain, the change
affects all domains except the one that uses a customized copy of this rule.
1. Navigate to Service Mapping > Administration > Traffic Based Discovery.
2. Click New.
3. Define the rule parameters as follows:
Field Description
Action Select Enable to add traffic-based

connections to the specific CI or CI Type.
Rule Scope Select Specific CI to detect traffic for one
configuration item, or select CI Type to
detect traffic for all configuration items in
one of the CI-based table.
CI/CI Type Select a specific CI, or select the table
that contains the CIs for which you want to
detect traffic.
Domain Select the domain to which the rule belongs.
4. Click Submit.
5. To fine-tune traffic based discovery, define advanced parameters as follows:
sa.traffic_based_discovery.conn_aging_time Time period in hours for a Traffic Based

Connection to remain active since last
discovered.
• Type: integer
• Other possible values: any number
higher than 24

sa.traffic_based_discovery.ignored_ports Ports to ignore when found by traffic-based

discovery.
This property is available in the System
Property [sys_properties] table.
Change this property to define ports
that Service Mapping ignores while
performing traffic-based discovery. It makes
discovery more efficient since resources
are not wasted on discovering irrelevant
connections.
• Type: string
• Default value: 445, 139, 111, 2049, 860,
3260, 135, 53
• Other possible values: any relevant
port numbers
• Location: System Property
sa.traffic_based_discovery.max_connections Maximum number of traffic-based

connections from a single CI.
This property is available in the System
Property [sys_properties] table.
This property helps to keep the map size
reasonable by limiting the number of
possible CI connections.
• Type: integer
• Other possible values: any number
higher than 1
Create a discovery behavior for Unix-based load balancers

If your network uses load balancers running on Linux hosts, create a discovery behavior to ensure that
Service Mapping and Discovery discover them correctly.
Make sure that Discovery is activated.
Role required: sm_admin or admin
The discovery and mapping process begins with Discovery identifying the host. After the host discovery is
complete, Service Mapping starts discovering and mapping applications running on this host.
The default discovery process identifies a configuration item (CI) as a Linux server if it finds an SSH port
in use. It may lead to incorrect discovery of load balancers running on Linux as Linux servers. Create a
discovery behavior to first discover network devices using SNMP protocol. After Discovery has discovered
Unix-based load balancers correctly and created the appropriate CIs for them, you can continue with
discovering and mapping business services in Service Mapping.

Discovery performs discovery through a MID Server located in the enterprise private network. A behavior
determines:
• What MID Server Discovery is using.
• What probes and patterns the chosen MID Server is running.
1. Create a new behavior for discovering Unix-based load balancers:

a) Navigate to Service Mapping > Administration > Behavior.
b) Click New.
c) Enter the name for this behavior.
d) Right-click on the header bar and click Save.
e) Click New on the Discovery Functionality tab.
f) Enter 1 in the Phase field.
g) Select SNMP only from the Functionality list.
h) Select the relevant MID Servers in the MID Servers area.
i) Check the Active check box.
j) Click Submit.
2. Create a discovery schedule for the newly defined behavior:

a) Navigate to Discovery > Discovery Schedules.
b) Click New.
c) Fill in the fields as follows:
Table 370: Discovery Schedule Form for Discovery
Field Description
Name Enter a unique, descriptive name for your schedule.

Discover Select Configuration items.
Service discovery Select CI Type
Note: In some special cases, you must create

a schedule just for one specific CI. To do so,
select Specific CI.
MID Server selection method Select Use behavior.

Behavior Select the behavior you created in Step 1.
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.
Max run time Set a time limit for running this schedule. When the
configured time elapses, the remaining tasks for
the discovery are canceled, even if the scan is not
complete. Use this field to limit system load to a
desirable time window. If no value is entered in this
field, this schedule runs until complete.

Field Description
Run and related fields Determines the run schedule of the discovery.
Configure the frequency in the Run field and the other
fields that appear to specify an exact time.
Note: The run time always uses the system

timezone. If you add the optional Run as
timezone field, it has no effect on the actual
runtime.
3. Create an IP range for the discovery schedule:
Important: The IP range for the schedule must correlate with the IP range of the MID Server
that you assigned to the behavior. The MID Server must also have the appropriate application
or the ALL application.
a) On the Discovery IP Ranges tab, click New.

b) Enter the name for this IP range.
c) Configure the IP range by entering IP addresses in the Starting IP and Ending IP fields.
4. Click Submit.
Check a business service map

After you create a business service and run the mapping process for the first time, check the generated
map to make sure that it reflects the business service correctly.
Service Mapping discovery patterns help ensure that only relevant CIs are discovered for each business
service. Typically, little fine-tuning is necessary for business service maps but you should always review
each map to verify that it is complete and accurate. Try to review the map with an IT administrator who is
familiar with the infrastructure used for the business service.
If necessary, edit the map manually:
• Make sure that the map includes all the configuration items (CIs) and connections that you want
to monitor. If these CIs and connections are missing, the map does not reflect the real state of the
business service and its operation. Inaccurate data can also be transferred to Event Management,
causing imprecise monitoring.
You can add missing connections. However, Service Mapping cannot discover and provide dynamic
information about changes and updates to manually added connections.
• Remove CIs that do not belong to the business service. If unnecessary CIs are included in the map,
they can generate irrelevant alerts in Event Management. For example, when creating a business
service for a web portal, Service Mapping may automatically discover a connection to external services,
such as PayPal, that do not belong to the service.
Add mapping boundaries to remove the unnecessary CIs. Service Mapping can discover only the CIs
within these boundaries.
You can also learn about business service maps from the following video tutorial:

2. Click View map next to the business service that you want to view.
3. Ensure that the map opens in Edit mode.
4. Check that all essential CIs are discovered and mapped correctly, and correct any issues as
necessary.
Option Action
Review discovery messages and errors

Click the CI with a warning icon ( ).
A list of messages appears under the Discovery
Messages tab.
For information on how to resolve discovery
errors, see Troubleshoot maps in Service
Mapping on page 657.

Option Action
Add a missing CI connection If a CI is missing connections, there are no

connectors from it to another CI. For example, in
the following figure, the Web Server on win2K12
CI is missing connections.
To add a connection:
1. Right-click the CI, and select Add manual
connection.
2. Enter connection properties as described in
Entry point attributes on page 630.
3. Click Submit.
Remove a CI that does not belong in the Right-click the connector leading to the CI, and
business service select Mark boundary.
The CI is marked as boundary on the map
( ).
Include a CI that was mistakenly removed Right-click the connector leading to the CI, and
from the business service select Unmark boundary.

Option Action
Check that the connections between CIs are 1. Click a CI to see all its connections.
correct
2. Click the connection you want to check.
The selected collection appears highlighted.
3. Review the connection details in the
Properties pane.

Option Action
Check that clusters are reflected correctly Click the plus (+) icon next to a CI.
There are two types of clusters:
Application cluster In an application

cluster, two or more
applications or devices
are configured to work
together and serve
the same purpose.
Typically, the clusters
provide high availability
or load balancing. For
example, web servers
working behind a load
balancer.
This type of cluster
appears as a stack
of CIs with a label
showing the number of
CIs in this cluster with
the multiplication sign.
Application clusters
can have a cluster
within a cluster, but
never more than two
levels as shown below:

Option Action
Check that inclusions are reflected correctly Click the plus (+) icon next to a CI.
In an inclusion, a server hosts applications that
are treated as independent objects. For example,
IIS Virtual Directory can run on a Windows
Service as its host.
5. Check a list of CI traffic-based connections to identify CIs that Service Mapping failed to discover or
did not identify correctly.
Note: You can see traffic-based connections for a CI, even if you disabled the traffic-based
discovery for a business service the CI is part of.
a) Right-click the CI whose traffic-based connections you want to check.

b) Select Show traffic based connections.
The Traffic Based Connections List opens displaying the following information:
Field Description
IP The IP address of the application

connected to the selected CI.
Port The port on the selected CI that is used
to communicate to the other application.
Process The ID of the process in the source CI.
Already on map • Yes - if this connection shows on the
map.
• No - if this connection is not part of
the business service and not on the
map.

Note: There may be a case when you can see traffic-based connections on the map, but
the Traffic Based Connections list does not display them. It happens if the connections
have been removed from the cmdb_tcp table less than three days.
c) Click Close when finished viewing this list.

d) If necessary, modify the relevant CI pattern to enable Service Mapping find the to discover CI
connections based on configuration.
Create a connection to another business service

You can create a connection to another business service, either brand new or existing. The original map
shows the link to the other business service instead of the map segment.
You create a link to another business service by transferring a map segment into another business service
and connecting to it. The connection leading into the top CI in the segment becomes an entry point when
you transfer it into another business service or create a new business service.
When you insert a link to another business service, the information about the connection leading into the
top CI in the transferred segment, is updated in the CMDB and in the model. If other business services use
the same ingoing connection (endpoint), the CMDB recognizes it and replaces map segments coming out
of the same connection with connected service CIs by analogy.
You cannot insert links to multiple business services from the same connection.
1. Open the business service map containing the segment you want to transfer:
a) Navigate to Service Mapping > Business Services.
b) Click View map next to the relevant business service.
c) Ensure that the map opens in Edit mode.

d) If the Host view is on, switch it off by clicking More Options and clicking the Display in Host
View toggle.
2. Identify the segment of the map that you want to transfer.

3. Right-click the connection leading to the CI at the top of this segment.

4. To transfer the segment into an existing business service map and connect to it:
a) Select Connect to existing service.
b) In the Add To Existing Discovered Service window, select the business service to which you want
to transfer the segment.
c) Click Choose.
The map displays the connected business service icon instead of the transferred segment. The
business service map to which you transferred the segment, shows it under the newly added
entry point. For example, the Tomcat business service map contains the Trade connected service
CI. The Trade business service map shows the segment transferred from the Tomcat business
service.

5. To transfer the segment into a new business service map and connect to it:
a) Select Create new service from here.
b) In the Create New Discovered Service window, define attributes for the business service you want
to create for this segment:
Field Description
Name Enter the business service name.

This name must be unique. Use self-
explanatory names such as mailing
service or printing service.
Group (Optional) Restrict access to a business
service by adding it to a business
service group. Users must then have
the business group role to access the
business service.
Criticality (Optional) Select the option that reflects
how important this business service to
your organization operation. For more
information about business service
criticality, see Business services on
page 516.
c) Click Create.
The map displays the connected business service icon instead of the transferred segment. The
new business service appears in the list of business services and contains the segment of the
map. For example, the Tomcat business service includes the TP rooms connected service CI.
The TP rooms business service map contains the segment transferred from the Tomcat business
service.

6. To revert this operation:

a) On the business service map containing the connected service CI, click the connection leading to
it.
b) In the Properties pane, write down the URL attribute of the connection.

c) Double-click the connected service CI.

The business service map for the CI containing the transferred segment opens.
d) Click the Settings icon.
e) Under Entry Points on the left, locate the entry point with the same URL you took note of.
f) Click the Delete button on the entry point tab, and click Remove to confirm.
This entry point disappears from this business service form.
The transferred segment disappears from the map of this business service.
g) Navigate to the map that contained the connected service CI.
This map displays a boundary instead of the connected service CI.
h) Click the boundary CI and click Unmark boundary.
The map is refreshes and displays the segment of the business service.
Troubleshoot maps in Service Mapping

You may need to resolve problems that occurred during discovery and mapping of a business service.
Role required: admin, sm_admin
If there are issues related to connectivity or credentials, Service Mapping discovers configuration items
(CIs) partially, with some important properties missing. In this case, the business service map displays
discovery messages that explain the nature of error.

You can also use the following video to learn about troubleshooting maps in Service Mapping:

3. Ensure that the map opens in Edit mode displaying discovery messages and errors.
4. Click anywhere in the map outside CIs and connections to select the entire business service.
5. Review discovery and mapping errors:
Option Action
Find a CI correlating with an error Click the error on the Discovery Messages tab.
In the map, the related CI or a CI connection is
marked in yellow.
Review all errors related to a CI on the Click the CI in the map.

Discovery Messages tab

Option Action
Review all errors related to a CI in the Point to the CI in the map.

Discovery Messages pop-up window
To view more details related to an error Right-click on the error and select Show
discovery log. If you identify a pattern-related
error in the Discovery Log window, fix the pattern
as described in Troubleshoot pattern-related
mapping errors on page 661.
6. Resolve errors as follows:
Symptom Resolution
• The business service map displays the KB0621669: Resolving failure to execute
warning icon () on top or instead of the commands using sudo during Discovery in
configuration item. Service Mapping
• The following error message displays
for the configuration item: Failed to
execute command using sudo on
host <host IP address>.
The following error message displays for the KB0564283: Resolving an issue of denied
configuration item: Access is denied. access to a Windows Server
• The business service map displays the KB0564296: Resolving failure to run
warning icon () on top or instead of the commands on Windows Servers during
Windows Server. discovery in Service Mapping
for the Windows Server: Failed to
execute WMI command on host.

Symptom Resolution
• The business service map displays the KB0564282: Resolving issue of RPC
warning icon () on top or instead of the Server unavailable during Windows Server
Windows Server. discovery in Service Mapping
for the Windows Server: RPC Server
unavailable.
• The business service map displays the KB0610414: Resolving failure to discover
warning icon instead of the load balancer operating system for a load balancer
CI.
• The following error message is
displayed: Service Mapping
triggered the horizontal
discovery to find the host
x.x.x.x, because this host
was not in the CMDB. The
horizontal discovery failed.
See discovery status for more
info.
Instead of the map, the following error KB0596671: Resolving a large topology
message displays: Cannot display the issue in business service maps
map. Topology too large.
A Virtual IP (VIP) for a load balancer KB0610412: Resolving load balancers
service CI is sometimes updated with the IP merging into one CI in Service Mapping
addresses of another load balancer.
The map displays incorrect virtual IP names KB0610413: Resolving incorrect virtual IP
for load balancers. names of load balancers in Service Mapping
The business service map consists of KB0595227: Troubleshooting inconsistent
different CIs every time you run the mapping mapping results
process on the same entry points to
discover the same business service.
A cluster CI appears detached from all CIs KB0621531: Resolving disconnected cluster
in map tiers above or below it. CIs on the business service map
• The map displays either the load KB0621576: Resolving failure to discover
balancer configuration item (CI) with a VIP for a load balancer
warning icon or just the warning icon
• The following error message appears
for the CI that is expected to be
the load balancer in the business
service: Failed to recognize
application. See the
discovery log for more
details.
The business service map shows a different KB0621616: Business service map displays
load balancer from the one you expected to a wrong load balancer in Service Mapping
see in this business service.

Symptom Resolution
• The business service map displays the KB0621670: Resolving the issue of SSH
warning icon () on top or instead of the command time out during discovery in
configuration item. Service Mapping
• The following error message displays for
the configuration item: SSH command
timed out on host.
• The business service map displays the KB0621673: Resolving a failure to

warning icon () on top or instead of the communicate with the WMI Collector during
configuration item. discovery in Service Mapping
for the configuration item: Failed
to communicate with the WMI
collector.
Troubleshoot pattern-related mapping errors

You can troubleshoot mapping errors caused by patterns.
Verify that the mapping error is caused by an inaccurate pattern by checking the discovery message. If the
message says "Failed to recognize application", the error is pattern-related.
You need to be familiar with the Pattern Designer module of Service Mapping.
Role required: admin and sm_admin
If there are configuration items (CIs) that Service Mapping could not map correctly, they appear on your
business service map with warning icons . Typically, mapping errors happen when Service Mapping
fails to connect to a CI or fails to recognize it due to an inaccurate pattern.
You can identify problematic steps in your pattern and fix them without reviewing all steps and operations
contained in the pattern. It allows you to troubleshoot pattern-related errors quickly and effectively.
The following video provides an alternative way of troubleshooting pattern-related errors:

3. Ensure that the map opens in Edit mode displaying discovery messages and errors.

4.
Right-click the CI with the warning icon ( ) and select Show discovery log.
The Discovery Log window opens showing mapping patterns and their details.
5. Expand the failed pattern which appears above the result marked red.

6. Expand the failed section and click the failed step.

7. Click Debug.
The Pattern Designer window opens showing the pattern with its steps in the left pane.
8. Click the first step and wait for Pattern Designer to run it. Repeat this action for other steps following
the order until you reach the faulty step that causes the error.
In the example below the port number is 8081 instead of 8080 which causes the problem.
9. Click OK.
10. Fix the pattern attribute that causes the problem.

11. Click Test.

12. Verify that Pattern Designer returns a success message.
In this example, the port number was fixed from 8081 to 8080 which allowed the pattern to run without
an error.
13. Click Save.

14. Click Activate.
15. Return to the business service map which contained the mapping error.
16. Right-click the CI for which the pattern was fixed and select Resume discovery.
17. Verify that the CI is discovered and mapped correctly.

Business service analysis and maintenance using maps

Service Mapping creates maps to help you see the architecture and organization of business services.
These maps are useful for planning change or migration, as well as analyzing the continuity and availability
of services.
The maps are useful in the following cases:
Planning the migration of an entire business Use the map to see which configuration items (CIs)
service or its segments need relocating or which CIs become redundant.
Planning the upgrade or replacement of a CI Check the map to see what other CIs are affected
when the CI is non-operational during maintenance.
You can assess and plan the downtime or make
provisions to avoid the downtime.
Because the same CI may be used for multiple
business services, check the CI using the
Dependency Views application. With this
application, you can see all business services that a
CI belongs to.
Analyzing a business service for high Use the map to identify CIs crucial for the service
availability and continuity performance. Decide if you want to fortify these CIs
by creating clusters.
Troubleshooting business services Use the map to understand the impact of an issue
and determine which CI is causing the problem.
Business service maps

Get introduced to maps in Service Mapping. Learn about map elements and what they represent.
Service Mapping collects and organizes data for every business service you define and creates a
visualization of this data in the form of a map. Service Mapping creates a new map every time you create a
new business service and updates this map every time it runs discovery for CIs belonging to this business
service.
You can also learn about business service maps from the following video tutorial:
Map window
Beside the map itself, the map window also displays the Properties pane and tabs with additional
information.


The kind of information and messages displayed at the bottom of the screen depends on the mode as
well as on the way you customize the map view. Service Mapping users see maps in the view mode,
while administrators use the edit mode that shows discovery messages as explained in Check a business
service map on page 646. For more information on map views, see Modify view for business service map
on page 696.
You can navigate to a different business service map directly from this window by selecting it from the list:
By default, the entire map is shown in the center of the visible map area of the window. You can zoom in
and out as well as position the map depending on what segment of the map you must see using these
controls:

You can also click anywhere in the map area and drag the required segment of the map into the visible
area.
You can view changes made to a business service as a whole and to individual CIs belonging to a service
by choosing a time range. For more information, see View change history of business services on page
686.
Map elements and their appearance
Every map consists of icons representing CIs and arrows that represent the connections between them.
Some map elements can contain other elements such as in the case of application clusters. On the map,
application clusters appear as a stack of CIs with the plus (+) symbol next to it. The cluster label shows the
number of CIs in this cluster with the multiplication sign.

When the CI has inclusions, the CI icon has the plus (+) symbol next to it and shows the contained
application when you expand it.
An OS cluster appears as a CI with the plus (+) symbol and the number of CIs in this cluster.

CI properties and CI-related messages
When a map is loaded and no elements are selected, the Properties pane shows the details of this
business service.
A selected device, application, or connector displays in blue and is highlighted. Information about the
selected map element is displayed in the Properties pane on the right of the map. The Properties pane
contains the links to the Detailed Properties page.
The properties for the server hosting applications and applications themselves are shown separately inside
the Properties pane.

If there is any information related to the selected CI or connection, it is highlighted on the tab at the bottom
of the window.

When you select information on a tab at the bottom of the map window, the related CI displays in yellow.

View and Edit modes
The View mode allows Service Mapping users to view business services without modifying them.
If you are logged in as a Service Mapping administrator, a business service map opens in the Edit mode
that shows discovery messages and warning icons that indicate discovery errors ( ) on maps.
In the Edit mode, you can modify the business service by manually adding or removing CIs, resolving
connections, and so on. For more information about modifying business services in the Edit mode, see
Troubleshoot maps in Service Mapping on page 657.

View CI properties in a service map

You can view configuration item (CI) properties discovered by Service Mapping.
Role required: sm_admin or sm_user
You can view the following information for each CI:
Name label The CI name. This parameter is either
preconfigured on the CI or configured during CI
installation.

Basic properties A summary of the most important CI properties.

Detailed properties A complete list of all properties collected about the
CI.
Each CI type has different properties. For example, the Linux Server type has different properties than the
SQL Instance type.
Properties available for viewing also depend on the Service Mapping setup.
2. Click View map next to the business service including the CIs that you want to view.
3. To see the full name of a CI name that has been shortened in the map, point to the CI.
A tooltip displays the full CI name.
4. Click the CI to see details about it in the Properties pane.
The properties of applications and the servers that host them are shown separately.

5. To view more detailed properties for the CI, click Detailed properties at the bottom of the Properties
pane.
View CI connection properties in a service map

You can view properties of connections between configuration items (CIs).
Role required: sm_admin or sm_user
You can view the following information for each connection:
• The source and target CIs of this connection displayed in the Context (right-click) menu.
• A complete list of all properties collected about the connection in the Properties pane.

By default, Service Mapping merges connection lines for the same CI to declutter a business service map.
It helps to make the map more readable.
Each connection type has different properties. For a merged connection line, all underlying connections are
listed.
Properties available for viewing also depend on the Service Mapping setup.
2. Click View map next to the business service including the connections you want to view.
3. View connection properties as follows:

To view Do this
The source and Right-click the connection.

target CIs of a
regular connection

To view Do this
The source and • Right-click the merged connection line with a number and select
target CIs for a the relevant connection.
merged connection
Or
• If a segment of a connection line is shared by more than one
merged connections, there is no indication that it is a merged
line.
Right-click the connection line coming out or going into a CI, and
select the relevant connection.

To view Do this
The source and 1. Click the CI whose connections you want to view.
target CIs for a
connection if the All concealed connections for this CI appear on the map.
spanning tree view is 2. Click the relevant connection line.
enabled.
The spanning tree
view simplifies a
business service
map concealing most
of the connection
lines.
Detailed properties of Click the connection line.

a regular connection
in the Properties
pane

To view Do this
Detailed properties of Click the merged connection line indicated by a number.

a merged connection
in the Properties All underlying connections are displayed separately in the
pane. Properties pane.

To view Do this
Detailed properties Click the connection line coming out or going into a CI, select the
of a connection relevant connection, and then choose Select edge.
segment shared
by more than one
merged connection
in the Properties
pane
The detailed properties are displayed in the Properties pane.
Note: Shared segments do not have an indication that it is

a merged line.

To view Do this
Detailed properties 1. Click the CI whose connections you want to see.

of a connection in
the Properties pane, All concealed connections for this CI appear on the map.
when the spanning 2. Click the required connection line.
tree view is enabled.
The spanning tree
view simplifies a
business service
map concealing most
of the connection
lines.
Traffic-based 1. Right-click the CI whose traffic-based connections you want to

connections for a CI. check.
Note: You 2. Select Show traffic based connections.

can see The Traffic Based Connections List opens displaying the
traffic-based information in Traffic Based Connections List table.
connections
for a CI, 3. Click Close when finished viewing this list.
even if you
disabled the
traffic-based
discovery for
a business
service the
CI is part of.

To view Do this
Manually added Click the manually added connection.

connection.
The Properties pane shows Manual Endpoint under Endpoint
You can either add Type.
a connection or
a CI manually. In
both cases, the
connection you
manually add an
entry point to the
next tier of the
application flow.
Table 371: Traffic Based Connections List
Field Description
IP The IP address of the application connected

to the selected CI.
Port The port on the selected CI that is used to
communicate to the other application.
Process The ID of the process in the selected CI.

Field Description
Already on map • Yes - if this connection shows on the

map.
• No - if this connection is not part of the
business service and not on the map.
System decision The setting defines if Service Mapping

keeps the discovered traffic-based
connection or removes it. The value comes
from the algorithm that Service Mapping
uses.
View change history of business services

You can view changes made to a business service as a whole and to individual configuration items (CIs)
belonging to a service. Change history is useful for maintenance, planning, or troubleshooting procedures.
The kind of change information gathered and displayed by ServiceNow depends on the Service Mapping
setup.
Role required: admin, sm_admin or sm_user
Information about changes to a business service or its CIs is stored in the CMDB. Typically, these changes
reflect adding or removing CIs from a business service, upgrading or updating CIs. Service Mapping
gathers this data by querying CMDB tables and creates the change history view. The kind of change
information Service Mapping queries depends on discovery patterns that Service Mapping uses to discover
CIs.
While in Service Mapping you can see change records for specific CI in the context of business services,
you can also see detailed history of a specific CI separate from its business service as described in History
Timeline.
If the ServiceNow platform is configured to validate changes, all changes are evaluated and rendered as
valid or not. If a change is valid, its change record in Service Mapping is marked as approved. For more
information about configuring the platform for change validation, see Create or edit a planned change
validation script.
Changes to the business service appear on the history timeline.

Change marks appear differently depending on the nature of changes:
Unapproved change that does not influence the

Light gray balloon ( ) business service behavior. For example, a change
in a network path or adding a node to a cluster.
Unapproved change that changes the business
Dark gray balloon ( ) service behavior.
An approved change in deployments where

Green balloon ( ) ServiceNow platform is configured to validate
changes.
Multiple separate changes that happened a short
Double balloon ( ) time from each other.
If necessary, you can mark times on the history scale by creating baselines. It lets you quickly return to the
marked view.
1. Navigate to Service Mapping > Business Services > Discovered Services.
2. Click View map for the business service for which you what to see change history.
The Changes tab Service Mapping created for this business service.
3. On the history timeline, set the time range of changes that you want to view.
Option Action
To set the time range of the history timeline Click the hour, day, week, or month icons.
To increase or decrease the time range Click the zoom in and zoom out icons.

Option Action
To change the upper limit on your history Click on the history scale.
range
The time that serves as the upper limit appears

above the history timeline.
Note:
You cannot set the lower limit on your
history range to a time before this
business service was created. This time
is marked with the Business Service
Created event on the history scale.
The map shows the history view of the business service for the time you selected.
Note: The Change tab displays all change records even if the ones, which are filtered out of
the history view.
4. To mark a time on the time scale, set a baseline:

a) Click the Compare icon.
b) Navigate to the time you want to mark as a baseline on the history scale.
c) Click Set baseline.

d) Enter the name of the baseline and click OK.

The new baseline appears as a button above the history scale and as a blue flag on the history
scale.
5. View the change history:

Option Action
To see the CI responsible for a change record Select a change record on the Changes tab.
The related CI is marked yellow in the map.

Option Action
To see only change records related to a CI Select the required CI or the connection on the
map.
The Changes tab displays only change records
related to the selected CI or connection.
To see network at the selected moment in the 1. Set the time on the history scale.
past
2. Right-click on the connection and select
Show network path.
The new tab opens displaying the network or
storage path map for the time you selected.
Note: You cannot view the network path

for connections marked as boundaries to
this business service.
6. To exit the history view and see the current status of the business service, click the current icon.

Compare two versions of a business service

You can see the summary of business service changes at a glance by comparing two versions of a
business service. This feature is useful for checking the business service status before and after a certain
change or problem.
Role required: admin, sm_admin, or sm_user
Define two points in time for Service Mapping to perform comparison. For example, if you know that the
business service functioned well up until a certain time and after that it experienced problems, you can
compare this business service before the problem started and after to see the summary of changes that
possibly led to the problems.
2. Click View Map next to the required business service.
3. Navigate to the history view you need by setting the time interval in the history area:
a) Set the time range of the history slider by clicking the hour, day, week, or month icons.
b) If necessary, increase or decrease the time range by clicking the zoom in and zoom out icons.
c) To change the upper limit on your history range, click the history scale.
The upper limit appears above the history scale.
You cannot move the lower limit on your history range to before the Business Service Created
event.

The map shows the history view of the business service for the time you selected.
Note: The Change tab at the bottom of the screen displays all change records even if you
limit the range on the history scale.
4. Click the Compare icon.
5. Define the time before the changes in the Compare point 1 field and the time after the changes in the
Compare point 2 field.
Or
Drag the pointers on the history scale to set corresponding time points.
If the history scale does not include the time set as a compare point, its corresponding pointer appears
next to the compare point in yellow:
6. Click Compare.
The comparison view opens in a separate tab.
7. Select a marked CI to see the relevant change record on the Changes tab.

8. Close the comparison view when finished.
Convert business service maps into PDFs

You may want to create a PDF for a map to share information about the service content with other people.
PDFs are especially useful during the review and approve process for business services discovered by
Service Mapping.
Role required: sm_admin, sm_user
The PDF of a business service map shows the name of the business service and the exact time when this
PDF was created.

2. Click View map next to the relevant business service.

3. Click the More options menu.
4. Click the button next to the Export to PDF option.

5. When the PDF is ready, click the link to download the PDF.
The PDF appears in the downloads folder on your computer.
View network or storage path

You can drill down to see objects behind a connection on a business service map for troubleshooting
service performance or maintaining your network.
Displaying a network or storage path allows you to see routers, switches, and host ports which are part of
the connection. The following connection types exist:
Network path The infrastructure route between two CIs of the host
type.
Storage path The infrastructure route between a CI of the host

type and a CI of the storage type.
Service Mapping discovers and displays network devices located on your organization local network, not
on WAN or the public cloud. When Service Mapping encounters a connection between two applications,
it uses traceroute on the source host to figure out the path to the target host. Then Service Mapping use
SNMP credentials to discover the devices it found on the path.
Service Mapping can show devices for storage paths using the following protocols:
• Fiber Channel: Storage Area Network (SAN)
• IP Ethernet: Internet Small Computer Systems Interface (iSCSI) or Network Attached Storage (NAS)
Note: For storage paths using Fiber Channel, Service Mapping does not display Fiber Channel
switches.
Between a host CI and a storage CI there may be two separate storage paths using different protocols:
Fiber Channel and IP Ethernet. If so, the business service map displays one connection line for both
protocols.

You can see the change history for network and storage paths for business services. Checking path history
for manual or technical services is not supported.
1. Navigate to Service Mapping > Services > Business Services and click View map next to the
relevant business service.
Or
2. Navigate to Event Management > Dashboard and double-click a business service.
3. On the map, right-click the connection for the network or storage path you want to see.
4. Select Show network path or Show storage path.
5. If necessary, select the type of protocol and click Choose in the Choose Protocol Type dialog box.
The view showing the network or storage path opens in a new tab.
If Service Mapping cannot discover all objects in a connection, the connector line on the network or
storage path appears dotted as shown above.
6. For storage paths, use the Storage Mapping tab at the bottom of the screen to view correlation
between file systems on the host and the storage volume or the shared folder on the storage device.
7. To view the change history for network paths, perform steps in View change history of business
services on page 686.
8. If you access the network or storage path map from Event Management, you can see the list of alerts
related to this path appear at the bottom of the screen.
Modify view for business service map

Customize a map view to exclude irrelevant information and increase clarity.
By default, business service maps are concise and contain every detail about all CIs that Service Mapping
discovered and mapped. While it provides a complete picture, using such a map might be difficult.

Customizing maps allows you to:

• make it easier to navigate the map
• hide irrelevant information
• show essential information
Properties you show or hide when you customize maps are not removed permanently and can be
displayed or hidden again as you need. Service Mapping saves the changes to the map view and displays
the last map view when you reopen a business service.
2. Click View map next to the relevant business service.
3. Click the More options menu.
4. Select the relevant option:

Option When Enabled When Disabled
Display in Host View The business map shows The business map shows
Switch between the CI view hosts. CIs.
that hides hosts and the host
view that hides CIs.
The host view can help
determine that Service
Mapping discovered and
mapped all hosts correctly
as well as help locate
connections to each host.
The host view also simplifies
the map especially when a
large number of applications
are running on a small
number of hosts.
Figure 160: Shown hosts
Click on the plus icons to

see CIs running on the
hosts.
Figure 161: Shown CIs
The Properties pane shows

information about both
servers who act as hosts
and applications running on
the hosts.
The Properties pane shows

only information about
servers who act as hosts.

Remove Topology Cycles The business service map The business service map
Hide connections returning hides topology cycles. shows topology cycles.
to the same configuration
item (CI) that originated
them to reduce map
cluttering.
In most cases these
returning connections are
not important for analysis or
troubleshooting of business
services.
Figure 162: Hidden

Figure 163: Shown
topology cycles
topology cycles
Show Traffic Based CIs The business service map The business service map
Display configuration items displays CIs and hosts that shows only CIs and hosts
(CIs) that were found using Service Mapping discovered discovered using patterns.
traffic-based mapping. using both patterns and
traffic-based discovery.
While detecting CIs inbound
and outbound traffic creates
an inclusive map, it may
also result in mapping many
redundant CIs that do not
influence the business
service operation.

Merge errors The business service The business service map

Merge CIs with errors map merges all CIs with shows all CIs with identical
caused by the same source identical errors into one. The errors separately.
CI to declutter a business number on the connector
service map. line indicates the number of
CIs with this error.
A discovery or operational
error in a CI is often
propagated to all its
connections down the
hierarchy crowding your
view. You can remove
identical errors caused by
the same CI by consolidating
them in one object on the
map. For example, if one
CI causes an error in six
CIs that are connected to
it, you can show only one
CI with this error on the
map. The connector line
shows the number of actual
connections.
Map indicators For each record type The business service map
Display records from tables that is set to display, a shows CIs without related
that extend the main Task corresponding tab appears indicators.
table and that are related to underneath the map. For
the CIs. example, if alerts are set
to display, then an Alerts
The base system provides tab appears. Click any tab
map indicators for the to display the respective
following record types: records.
• Affected CIs Event Management Map
• Open alerts Indicators (Video)
• Current, planned, or
recent change requests
• Open incidents
• Current, planned, or
recent outages
• Open problems
Figure 165: Hidden map

indicators
Figure 164: Displayed map

indicators

Spanning tree view The map displays a business The map reflects the actual
service as a tree. structure of a business
Simplify the map by
service.
organizing CIs into a tree
structure and concealing
some connection lines.
This option is especially
relevant for very large maps.
To view actual connections,

point to a CI. For more
information on viewing
connections, see View CI
connection properties in a
service map on page 677.
Check CI dependencies
You can see if a particular configuration item (CI) is part of other business services and check if it depends
on other CIs.
Display a business service map by navigating to Service Mapping > Services > Business Services and
selecting View map for the relevant business service.
While Service Mapping shows position of a CI in a particular business service, your organization may also
use the same CI in other business services. If you are planning to perform changes to this CI, make sure
that the changes do not affect other business services.
1. In the map, right-click the relevant CI and select Open dependency views.

The Dependency Views page opens in the new tab showing the selected CI in the center.
2. Click Details.
3. Click the Related Business Services tab.

The list of links to business services containing this CI appear on the Related Business Services tab.
4. To view the map of another business service containing this CI, click the relevant link.
Advanced Service Mapping configuration

Fine-tune Service Mapping collaboration with other components and modules as well as customize data
display in business service maps.
In addition to the basic setup described in Service Mapping setup on page 537, you can perform optional
configurations to meet the needs of your organization.
MID Server configuration for Service Mapping

Configure Service Mapping and MID Servers to work together.
MID Servers, which are located in the enterprise private network, facilitate communication between servers
on the network and some ServiceNow applications, such as Service Mapping, Discovery, and Service
Analytics .
The number of MID Servers that you require and where you place them depends on your organization
needs. If you want to map devices and applications inside your private network, place the MID Servers
inside the private network. If you want to map devices and applications located in the DMZ, place the MID
Servers both in the DMZ and inside the private network.

In deployments where domain separation is enabled and domains are configured to form a hierarchy, MID
Servers must be placed in the lowest domain level, a "leaf domain."

Once MID Servers are installed, configure them to work with Service Mapping for the best discovery
results.
MID Server configuration for Service Mapping in fresh installs

For fresh Istanbul installations, Service Mapping uses a new algorithm to choose a MID Server for a
discovery request.
MID Servers have the following mandatory selection criteria that Service Mapping in fresh installs uses to
choose a MID Server for a discovery request:
• Application - defines what application a MID Server works with. Set it to Service Mapping to reserve this
MID Server exclusively to Service Mapping discovery requests. Alternatively, set it to ALL to allow any
ServiceNow application to use this MID Server.
• Capability - defines the network capability. For Service Mapping, set this parameter to ALL or any
combination of SSH, WMI, or SNMP.

• IP range - limits operation of this MID Server to this IP range. Service Mapping does not choose this
MID Server for a discovery request whose endpoint is outside this IP range.
Important: These selection criteria are mandatory for the new MID Server algorithm in fresh
installs. Configure them in every MID Server you are planning to use with Service Mapping.
Note: In upgraded deployments, Service Mapping uses the legacy algorithm for selecting MID
Servers. For more information, see MID Server configuration for Service Mapping in upgraded
deployments on page 705.
In addition to selection criteria, you can configure one of the MID Servers as the default server that Service
Mapping uses.
In fresh installs of the ServiceNow deployment, Service Mapping selects a MID Server using a new
improved algorithm:
• Service Mapping chooses the MID Server whose selection criteria best match the parameters of the
discovery request.
• If there are no MID Servers with matching selection criteria, Service Mapping chooses the default MID
Server.
• If there are no MID Servers with matching selection criteria or default MID Server, Service Mapping
cannot start the discovery process.
While by default Service Mapping uses a new algorithm in fresh installs, it can support both new and
legacy algorithms for selecting a MID Server. For more information, see Choose MID Server selection
algorithm on page 706.
MID Server configuration for Service Mapping in upgraded deployments

For ServiceNow deployments upgraded from earlier versions to Istanbul, Service Mapping uses the legacy
algorithm to choose a MID Server for a discovery request.
MID Servers have the following selection criteria that Service Mapping in upgraded deployments uses to
choose a MID Server for a discovery request:
• Application - defines what application a MID Server works with. Set it to Service Mapping to reserve this
MID Server exclusively to Service Mapping discovery requests. Alternatively, set it to ALL to allow any
ServiceNow application to use this MID Server.
In earlier releases, you could configure MID Servers to work only with Service Mapping by using the
Capability parameter. If you had MID Servers with this configuration, during the upgrade to Istanbul the
application parameter is automatically set to ServiceMapping for them.
• IP range - limits operation of this MID Server to this IP range. Service Mapping does not choose this
MID Server for a discovery request whose endpoint is outside this IP range.
In addition to the IP range, you can configure one of the MID Servers as the default server that Service
Mapping uses. For operational information, see Configure a default MID Server for Service Mapping for
upgraded deployments on page 706.
In upgraded deployments, Service Mapping selects a MID Server using a legacy algorithm:
• Service Mapping chooses the MID Server whose application criteria is set to ServiceMapping or to ALL.
• By default, Service Mapping selects the MID Server whose IP range matches the IP in the discovery
request.
• If Service Mapping cannot find a MID Server with the matching IP range and matching application, it
assigns the discovery request to the default MID Server.
• If there is no default MID Server and none of the MID Servers have IP ranges configured for them,
Service Mapping uses a random MID Server.

• If there is no default MID Server and no IP range matches the IP in the discovery request, Service
Mapping cannot start the discovery process.
The new algorithm for selecting MID Servers uses an additional selection criteria: capability. It allows
Service Mapping to take a network protocol into consideration. For information about updated selection
criteria and the new MID Server selection algorithm, see MID Server configuration for Service Mapping in
fresh installs on page 704.
While by default Service Mapping uses the legacy algorithm in upgraded deployments, it can support
both new and legacy algorithms for selecting a MID Server. If necessary, you can enable the new MID
Serverselection algorithm for your upgraded deployment. For more information, see Choose MID Server
selection algorithm on page 706.
Configure a default MID Server for Service Mapping for upgraded deployments
Service Mapping uses the default MID Server when it cannot find a MID Server with the matching IP range.
Configuring a default MID Server improves the discovery process.
Perform this procedure only for upgraded deployments. For fresh installs, perform Set a default MID Server
for an application.
Ensure you know the name of the MID Server you want to configure as the default MID Server for Service
Mapping.
request.
1. Navigate to System Properties by entering sys_properties.list in the navigation filter.

2. Click New.
3. Configure values for the new property as follows:
Name Enter mid.server.sm_default.

Description Enter a free text description of the use of
this MID Server.
Type Select string.
Value Enter the name of the MID Server you
want to configure as the default for Service
Mapping.
4. Click Update.
Choose MID Server selection algorithm

Service Mapping supports the new and the legacy algorithms for selecting a MID Server for a discovery
request. Depending on your organization needs, you can choose which algorithm to enable.


In fresh installs of the ServiceNow deployment, Service Mapping selects a MID Server using a new
improved algorithm:
• Service Mapping chooses the MID Server whose selection criteria best match the parameters of the
discovery request.
• If there are no MID Servers with matching selection criteria, Service Mapping chooses the default MID
Server.
• If there are no MID Servers with matching selection criteria or default MID Server, Service Mapping
cannot start the discovery process.
By default, Service Mapping uses the new algorithm in all fresh installs.
request.
By default, Service Mapping uses the legacy algorithm in all upgraded deployments.
1. Navigate to Service Mapping > Administration > Properties.
2. To enable the new algorithm for upgraded deployments:
a) Clear the Enable Legacy MID selection algorithm check box.
b) Click Save.
c) Configure MID Server selection criteria as described in MID Server configuration for Service
Mapping in fresh installs on page 704.
3. To enable the legacy algorithm for fresh installs:

a) Select the Enable Legacy MID selection algorithm check box.
b) Click Save.
c) Configure MID Server selection criteria as described in MID Server configuration for Service
Mapping in upgraded deployments on page 705.
Upload the rctrlx.exe file to MID Servers

Upload the rctrlx.exe file to MID Servers to enable running discovery commands on Microsoft Exchange
SAP 2007 and 2010, and Citrix XenApp.
During the discovery process, the MID Server runs Service Mapping and Discovery patterns on
applications and devices located inside the organization network. A pattern is a sequence of operations
whose purpose is to establish attributes of a CI and its outbound connections. To execute commands over
PowerShell correctly, MID Server runs patterns as services using the rctrlx.exe file. The rctrlx.exe file is
part of the open source ManagePC utility and is available for downloading from the Internet.

You must upload an rctrlx.exe file for every MID Server in your deployment.
1. Download the rctrlx.exe file onto your computer from the Internet.
For example, https://github.com/leonsodhi/rctrlx/releases offers the latest versions of the rctrlx.exe
file:
2. Place the rctrlx.exe file into the folder for Windows 32-bit servers:
<MID Server installation directory>\agent\bin\sw_wmi\bin\32
For example, C:\SN_MID\SN_MID_Dev\agent\bin\sw_wmi\bin\32.
3. Place the rctrlx.exe file into the folder for Windows 64-bit servers:
<MID Server installation directory>\agent\bin\sw_wmi\bin\64
For example, C:\SN_MID\SN_MID_Dev\agent\bin\sw_wmi\bin\64.
Configuring Search Assistant for Windows

The Search Assistant feature of Pattern Designer allows you to search within files or registries. Upload
grep files on to your instance to enable this feature to search on Windows servers.
You must download the necessary grep files from the internet, for example from http://
gnuwin32.sourceforge.net/packages/grep.htm.
Grep is a utility that the Search Assistant feature uses to search files for matches. Grep is native to Unix-
based systems, therefore you must upload it only for Windows-based configuration items (CI). Once you
upload grep files onto the instance, it transfers them onto all MID Servers which distribute the files onto all
Windows-based CIs in your organization.
1. Download the following files onto your computer from the internet.
• egrep.exe
• libiconv2.dll
• libintl3.dll
• pcre3.dll
• regex2.dll
Note: Make sure to unzip folders if necessary.
2. Navigate to Pattern Designer > Uploaded Files.

3. Click New.
4. Enter the original file name in the Name field on the Logical Name tab, for example egrep.exe.
5. Click OS Types and select Windows.

6. Click OS Architectures and select both 32-bit and 64-bit option.

7. Click the Manage Attachments icon.
8. Click Choose Files.
9. In the Downloads folder on your computer, navigate to the file which name you entered before, for
example egrep.exe.
10. Click Choose.
11. Close the Attachments window.
12. Repeat Step 3 to Step 11 to upload the rest of the files:
• libiconv2.dll

• libintl3.dll
• pcre3.dll
• regex2.dll
Data collection and discovery using Netflow

Service Mapping can perform discovery based on data collected using the Netflow protocol. Netflow is a
protocol that Service Mapping can use to collect data about CIs and their connections along with Netstat
and lsof commands.
Using the Netflow protocol for collecting data is one of the traffic-based discovery methods. Other methods
deployed by Service Mapping are using netstat and lsof commands and the VPC Flow Logs. For more
information, refer to Traffic-based discovery in Service Mapping on page 522.
In base systems, traffic-based discovery uses only TCP-related data collected with the help of the netstat
and lsof commands. Discovery based on Netflow and VPC logs requires additional configuration. You can
enrich your traffic-based discovery by configuring Service Mapping to use the Netflow protocol.
The component, which receives data in the Netflow format is the Netflow Collector. Its location depends on
whether you configure data collection for testing purposes or standard operation:
For the test purposes This setup results in half automated data collection
flow, where Service Mapping imports data only if
you manually copy it from the Netflow Collector.
You place the Netflow Collector on a server inside
your organization network. This must be a server
different from the server hosting the MID Server.
You configure and test this setup as described in
Configure onetime data import using Netflow for
testing purposes on page 714.
For standard operation This setup results in fully automated data collection
flow, where all involved components send, collect
and analyze data automatically. You place the
Netflow Collector on the same server as the MID
Server inside your organization network. For
instructions, see Configure data collection using
Netflow on page 716.
Netflow-based discovery has the following flow:

1. The Netflow daemon runs and receives data from switches communicating with servers in the
organization. The Netflow Collector writes received data from the Netflow daemon.
2. The server, hosting the Netflow collector, uses the Netflow nfdump utility to write the data into the
nfdump output file. This file summarizes the raw data on all switches used for server communication.

3. In testing setups, where the Netflow Collector is located not on the same server as the MID Server,
you may need to convert the nfdump into the gzip format. Then you must manually copy the raw data
in the nfdump output file onto the MID Server.

4. The MID Server processes the raw data in the nfdump output file and places the processed
information onto the ECC queue.

5. A sensor retrieves the processes data from the ECC queue and writes it into the Flow Connection
[sa_flow_connection] table.
6. Every time Service Mapping checks the ECC queue and receives information on a CI discovered
using patterns, it also checks if there is any data on outbound connections related to this CI. This
information is in tables holding data discovered using traffic-based discovery: [cmdb_tcp] and
[sa_flow_connection]. If these two tables contain unique data that patterns did not discover, Service
Mapping enriches the information about the CI connections and adds them to the map.

Configure onetime data import using Netflow for testing purposes

Configure and test Service Mapping discovery process based on data collected using the Netflow protocol.
Learn about Traffic-based discovery in Service Mapping on page 522.
enrich your traffic-based discovery by configuring Service Mapping to use the Netflow protocol. For more
information about the way Service Mapping to collect Netflow data, see Data collection and discovery using
Netflow on page 710.
For testing purposes, install the Netflow Collector (dfdump) on a Unix server inside your organization. In
this case, this Unix server should be different from the server hosting the MID Server server.
1. Download and install the Netflow collector (nfdump) on a Unix or Ubuntu server inside your
organization.
• For a Linux server, follow operational instructions at https://sourceforge.net/projects/nfdump/
• For an Ubuntu server, open the command-line window and run the following command:
sudo apt-get install nfdump
2. Configure the Netflow collector to save the nfdump file in a certain directory.
For operational information, refer to https://sourceforge.net/projects/nfdump/.
3. Configure the Netflow collector to save data for one day:

a) Open the command-line window on the server hosting the Netflow collector.
b) Create a cron job by using the following command:
crontab -e
c) Enter the following command using the correct paths:
*/10 * * * * /usr/local/bin/nfexpire -e /data/nfdump -t 1d.
4. Create a file with the nfdump data. For example, use the following command:
nfdump -q -m -R /data/nfdump/ -o extended -t 2016/07/06.07:00:00-2016/07/06.07:10:00 'inet and
proto tcp' >> /tmp/my_file
5. If the file is very large, you can compress it using the gzip format. Use the following command:
gzip /tmp/my_file
6. Copy the nfdump data file to the MID Server.
7. Configure Service Mapping to receive data collected by the Netflow collector:
a) Navigate to Service Mapping > Administration > Flow Connectors.
b) Click New.
c) Click ndfdump file.
d) On the dfdump file page, configure parameters as follows:
Field Description
Name A descriptive name for the connector.

nfdump data path The path to a location on the MID
Server to which you saved the nfdump
data file in 6 on page 715.
MID Server The MID Server, onto which you copied
the nfdump file.
Gzipped file If you converted the nfdump file into
the gzip format before saving it on the
MID Server, set this parameter to true
to unzip it.
e) Click Submit.
8. Verify that Service Mapping collects data using Netflow:

a) On the nfdump file form, select the newly configured connector and click Run now to start the
data collection flow and populate the Flow Connection [sa_flow_connection] table.
b) Navigate to System Definitions > Tables.
c) Click the Flow Connection [sa_flow_connection] table.
d) Under Related Links, click Show List.
e) Verify that the table contains data.
If you are satisfied with the results of the test, configure Netflow-based data collection as described in
Configure data collection using Netflow on page 716.

Configure data collection using Netflow

Enable Service Mapping to perform discovery based on data collected using the Netflow protocol. This
setup results in fully automated data collection flow, where all involved components send, collect, and
analyze data automatically.
Learn about Traffic-based discovery in Service Mapping on page 522.
enrich your traffic-based discovery by configuring Service Mapping to use the Netflow protocol. For more
information about the way Service Mapping uses Netflow, see Data collection and discovery using Netflow
on page 710.
Configure the ServiceNow Netflow connector to trigger the MID Server to collect the data from the Netflow
flows and process them.
1. Install the nfdump package on a server hosting the MID Server in your organization:
• For a Linux server, follow operational instructions at https://sourceforge.net/projects/nfdump/
• For an Ubuntu server, open the command-line window and run the following command:
sudo apt-get install nfdump
2. Configure the Netflow collector to save the nfdump file in a certain directory.
a) Open the /etc/init.d/nfdump file.
b) Modify the parameter responsible for saving this file in the required location.
For example, on an Ubuntu server, specify the location using the DEAMON_ARGS parameter:
DATA_BASE_DIR="/var/cache/nfdump"
DAEMON_ARGS="-D -l $DATA_BASE_DIR -P $PIDFILE"
For operational information, refer to https://sourceforge.net/projects/nfdump/.

3. Configure the switches to forward their nfdump files to the MID Server. The default value for the MID
Server is the IP address and port 9995.
4. Configure the Netflow collector to save data for one day:
a) Open the command-line window on the server hosting the Netflow collector.
b) Create a cron job by using the following command:
crontab -e
c) Enter the following command using the correct paths:
*/10 * * * * /usr/local/bin/nfexpire -e /data/nfdump -t 1d.
5. Verify that the Netflow collector is configured correctly and receives the correct data from the network
resources.
a) Run the following command:
nfdump -q -O tstart -R /data/nfdump/ -o extended
b) In the command output, verify that marked fields contain real data:

6. Configure Service Mapping to receive data collected by the Netflow collector:

b) Click New.
c) Click nfdump install.
d) On the nfdump install page, configure parameters as follows:
Field Description

MID Server The MID Server on which you installed
the Netflow collector.
nfdump data directory The data directory where you
configured the Netflow collector to save
the nfdump files.
e) Click Submit.
7. Verify that Service Mapping collects data using Netflow:

a) On the nfdump install form, select the newly configured connector and click Run now to start the
data collection flow and populate the Flow Connection [sa_flow_connection] table.
Data collection and discovery using VPC Flow Logs

Service Mapping can perform discovery based on data collected using VPC Flow Logs. Amazon VPC
hosts Amazon Elastic Compute Cloud (EC2) instances that provide Amazon Web Services. VPC Flow
Logs collect data on IP traffic going to and from network interfaces in the VPC.
Using VPC Flow Logs for collecting data is one of the traffic-based discovery methods. Other methods
deployed by Service Mapping are using netstat and lsof commands and the Netflow protocol. For more
information, refer to Traffic-based discovery in Service Mapping on page 522.
enrich your traffic-based discovery by configuring Service Mapping to use VPC Flow Logs.
Service Mapping discovery based on VPC Flow logs has the following flow:

1. Amazon EC2 instances collect their individual logs into log streams and forward them to the central
flow log group.
2. The MID Server collects the data from the flow log and processes it.
3. The MID Server places the processed information onto the ECC queue.

4. A sensor retrieves the processes data from the ECC queue and writes it into the Flow Connection
[sa_flow_connection] table:
5. Every time Service Mapping checks the ECC queue and receives information on a CI discovered
using patterns, it also checks if there is any data on outbound connections related to this CI. This
information is in tables holding data discovered using traffic-based discovery: [cmdb_tcp] and
[sa_flow_connection]. If these two tables contain unique data that patterns did not discover, Service
Mapping enriches the information about the CI connections and adds them to the map.
Configure data collection using VPC Flow Logs

Enable Service Mapping to perform discovery based on data collected using Virtual Private Cloud (VPC)
logs. This method is relevant for organizations using Amazon Web Services (AWS).
and lsof commands. Discovery based on Netflow and VPC logs requires additional configuration. You
can enrich your traffic-based discovery by configuring Service Mapping to use VPC Flow Logs. For more
information about the Service Mapping discovery flow based on VPC Flow logs, see Data collection and
discovery using VPC Flow Logs on page 717.
Amazon VPC hosts Amazon Elastic Compute Cloud (EC2) instances that provide Amazon Web Services.
VPC flow logs collect data on IP traffic going to and from network interfaces in the VPC.
1. Configure VPC Flow Logs on the Amazon EC2 console as described in http://docs.aws.amazon.com/
AmazonVPC/latest/UserGuide/flow-logs.html.
2. On the server hosting the MID Server, install and set up the AWS Command Line Interface. For
details, see Installing the AWS Command Line Interface and Configuring the AWS Command Line
Interface.
3. Verify that you have configured VPC Flow Logs correctly:
a) Open the command line window.

b) Enter this command:

aws logs describe-log-streams --log-group=<replace with the group name>
c) Check the log group and the log stream appear correctly in the output:
4. Configure Service Mapping to work with VPC Flow Logs:

b) Click New.
c) Click AWS VPC flow logs.
d) On the AWS VPC flow logs page, configure the connector parameters as follows:
Field Description

Group name The name of the central flow log group
to which Amazon EC2 instances
forward their log streams.
MID Server The MID Server on which you installed
the AWS Command Line Interface.
e) Click Submit.
5. Verify that Service Mapping collects data using VPC Flow Logs:
a) On the AWS VPC flow logs form, select the newly configured connector and click Run now to
start the data collection flow and populate the Flow Connection [sa_flow_connection] table.

Modify display for CI properties

You can control what configuration item (CI) properties Service Mapping displays in the Properties pane.
Get familiar with the notion of views. For more information on views, see View management.
Decide which CI types you need to modify.
Decide whether you want to modify parent CI types to see the change in all their child CI types.
1. Navigate to Tables.
2. Set the search field to Name, and enter the relevant CI type.
The list of all CI types that match the name is displayed.
3. Check the Extends table column to see the parent CI types.

When working with Service Mapping maps, the Properties pane displays properties for CIs and
connections you select in a map. Since there are dozens of properties to display, you may want to choose
which properties are displayed, and in what order.
The properties and their order of display is determined by a combination of the CI type definition and the
view for this CI type.
Preconfigured CI types that come with the ServiceNow platform form a hierarchy where some CI types
serve as parents to others who automatically receive their parent's attributes in addition to parameters you
configure specifically for them. CI type hierarchy is used widely for configuring CI behavior, relationships,
and display. Child CI types derive properties from their parents.

The view that controls the property display in Service Mapping is called sa_map_properties. You can
assign it to new CI types or modify it for CI types which already have it. Use the CI type hierarchy to
configure the sa_map_properties view:
• The parent CI type at the top of the hierarchy is cmdb.
• If you do not define the view for a child CI type, Service Mapping displays properties configured for its
parent with the addition of all properties of this child CI type.

• If you define the view for a child CI type, it includes only the properties that you specifically added.
Service Mapping does not display any of its parent properties automatically.

• If you do not add a parent CI type or its child CI type to the view, Service Mapping uses the ascendant
CI type that was added to the view in addition to all properties of all parent CI types in the hierarchy
between this child CI type and the parent CI type that is added to the view.

For example, if you define the sa_map_properties view for the CI type for Windows Servers, the same
properties are displayed for all Windows Servers.

You can modify the view at any time.

2. Click View map for the map that contains required CIs.
3. In the business service map, select a CI property.
4. In the Properties pane, click Detailed Properties.

5. In the CI Detailed Properties page, click the Additional actions icon and select Configure > Form
Layout.
6. In the View name list under For view and section, define which view you want to modify:
• Select sa_map_properties if it appears in the list, or

• If sa_map_properties does not appear in the list:
1. Select New.
2. In the View name field, enter sa_map_properties.
3. Click OK.
7. To add properties to the view, from the Available pane, select the properties that you want to display
and click the Add button.

8. To remove properties from the view, from the Selected pane, select properties that you want to hide
and click the Remove button.
9. Use the Move up and Move down buttons to define the order in which the properties appear.
10. Click Save.
11. Click Update.
The Properties pane displays the properties that you selected.
12. If necessary, repeat the procedure for other CI types.
Configure support for Windows servers with non-English OS

You can configure your ServiceNow platform to support Windows servers that use non-English Windows
operating system (OS).
You can perform this procedure only on the MID Servers that serve locations using non-English operating
system. Alternatively, you can perform this configuration on all MID Servers in one go, even MID Servers
that are used for locations using English operating systems.
Role required: mid_server
If your organization does not deploy Service Mapping, this configuration is not necessary.
Sometimes organizations choose to use operating systems in local languages. While having a localized
operating system (OS) may be very user-friendly, it poses a problem when it comes to automatically
discovering Windows servers running the localized OS. During the discovery and mapping process Service
Mapping sends discovery commands to Windows servers on your infrastructure via a MID Server. If a
Windows server returns a message in a language other than English, Service Mapping does not recognize
it as a valid response and the interaction fails.
If your organization uses non-English operating system for some of the Windows servers, you must
perform this procedure to make sure that Service Mapping can access all Windows servers, not exclusively
Windows servers using the English operating system. This configuration allows the MID Server, that is
located between Service Mapping and Windows servers, to recognize a non-English response from a
Windows server and to change the language of the CI operating system into English.
This configuration affects only the user for which you perform this procedure.
1. Navigate to MID Servers > Properties in the Modules pane.
2. Click New.
3. In the Name field, enter mid.servicewatch.wmi.mui.
4. In the Value field, enter true.
5. In the MID server field, select the server to which you want to apply this change:
Option Action
To apply the change to all MID Servers in your Leave the MID Server field blank.
organization
To apply the change to a specific MID Server Select the relevant MID Server from the list.
6. Click Submit.
Create or modify map indicators for a business service map

Business service maps use map indicator icons to display additional information for a CI by displaying its
related records such as alerts, outages, incidents and problems. Map indicators are available in business
service maps for discovered and manual services, only in View mode, and only for current time views.

The default configuration includes map indicators for the following record types. By default, the display of
all map indicators is disabled:
• Open incident
• Open alert
• Unplanned current outage
• Planned current outage, or an open problem
• Current, planned, or recent change request
You can create a map indicator to define additional record types, such as trouble sources for business
service CIs. You can also modify an existing map indicator, for example to use a different color scheme
or to alter the priority of a task. Affected CIs are based on the cmdb_ci field in the Task table and its
extensions. Therefore, if you use custom tables to store CIs for incidents, problems and changes, the
calculation of affected CIs is affected.
For more information see Event Management Map Indicators (Video).
1. Navigate to Dependency Views > Map Indicators.
2. Click New to create a new map indicator, or click the name of an indicator from the Table column to
modify an existing map indicator.
3. Fill in the fields on the form, as appropriate.
Table 372: Map Indicator form
Field Description
Table Name of the table represented by this map

indicator.
Note: The list shows only tables and
database views that are in the same scope
as the map indicator.
Name Name of the indicator.

Order Priority order of the task. The highest priority
task is the indicator with the lowest order
number. When more than one indicator is
present on a CI, the displayed color is the
color associated with the highest priority
task.
Additionally, a glyph on a CI displays the
color indicator of the highest priority task
attached to that CI.
Node color This field is used for backward compatibility.

Icon File name and path of the icon image file,
which can be a system image.
• To create a new icon, see Create or
modify map icons.
• To create or use a system image see
Storing images in the database.
Active Check box to enable display of the indicator

in a Service Mapping business service map.

Field Description
CMDB CI field Name of the field on the selected table to be

associated with the map indicator.
Start field This field is used for backward compatibility.
End field This field is used for backward compatibility.
Description field Name of the field on the selected table that
contains the description of the configuration
item.
Description Text to display when pointing to the
indicator. Alphanumeric characters and
spaces are valid for this field.
Conditions Condition builder that specifies for which
CIs to apply this indicator. For example, a CI
that has a current past outage is highlighted
for 5 days. You can configure a condition to
designate a different timeframe for what is
considered to be current.
Active Dependencies Check box to enable display of the indicator
in a Dependency Views map.
Label Text to display for the indicator on the map.
Tooltip Label The prefix of the tooltip (Tooltip Label :
Tooltip info).
Tooltip Info The suffix of the tooltip (Tooltip Label :
Tooltip info).
4. Click Submit to enter a new map indicator. Click Update to modify an existing map indicator.
Pattern customization
Service Mapping and Discovery use patterns in their discovery process. The base system contains a wide
range of patterns that cover most industry standard network devices and applications. You can customize
these patterns and create new ones.
A pattern is a sequence of operations whose purpose is to establish attributes of a CI and its outbound
connections. Service Mapping and Discovery share a set of preconfigured patterns that cover most of
the commonly used devices and applications. Patterns can be of infrastructure and application type.
Infrastructure patterns are used only by Discovery for creating lists of devices. Application patterns serve
both Service Mapping and Discovery that use the same application patterns for their purposes. For
example, Discovery runs the horizontal discovery with the Apache Web Server pattern to find and list all
Apache Web Servers in your organization. Service Mapping runs the top-down discovery using the same
pattern to discover a specific Apache Web Server and place it on a business service map.
Table 373: Pattern usage by Service Mapping and Discovery
Product Pattern type Result
Discovery Infrastructure pattern Inventory list of devices

Product Pattern type Result
Application pattern Inventory list of applications

Service Mapping Application pattern Business service map
For discovering devices that act as hosts for applications, Service Mapping relies on Discovery. As part of
the top-down discovery process, Service Mapping triggers Discovery to perform its horizontal discovery
behind the scenes. Service Mapping then uses information on hosts provided by the horizontal discovery to
create its business service maps.
Discovery uses a combination of probes and patterns. For more information, see Horizontal discovery
process flow on page 8.
You can customize the pattern set in the following cases:
• If your organization uses proprietary devices and applications, create patterns for these items to enable
Discovery and Service Mapping to discover them.
• If you modify key attributes of CI types that had corresponding patterns, modify the relevant patterns to
reflect the change.
Patterns are assigned to the CI types that they serve to discover. If necessary, you may assign more
than one CI type per pattern. In that case, you define one main CI type and multiple related CI types. For
example, a pattern for discovering BIG-IP Global Traffic Manager (GTM) F5 has BIG-IP Global Traffic
Manager (GTM) F5 as its main CI type and related CI types for the DNS name, network adapter and other
components.
For top-down discovery performed by Service Mapping, each application pattern serves to discover only
the main CI type.
At the same time, Service Mapping usually uses more than one pattern to discover the same CI type, since
a CI type can use different protocols, operating systems, entry points, and so on.
Unlike top-down discovery, the process of horizontal discovery uses each pattern to discover a main CI
type with all related CI types.

Follow these steps to create a pattern:

1. Create a CI type for Service Mapping and Discovery on page 732.
2. Create a pattern on page 738 and define the identification section.
3. Define the connection section on page 787.
4. Finalize a pattern on page 792.
Every time you modify and save a pattern, you create a version of this pattern. By default, the latest
version is used for discovery, but you can choose any other version to use.
Create a CI type for Service Mapping and Discovery

Every application in your organization must have a corresponding configuration item (CI) type which allows
Service Mapping and Discovery to discover and process this application correctly.
Role required: sm_admin, personalize_dictionary, or admin
A wide range of preconfigured CI types that cover most commonly used applications are available to you. If
your organization uses a less known or proprietary application that does not have a corresponding CI type,
you must create it.
A CI type is a generic notion that is used by several ServiceNow applications, but there are some attributes
that are specific to Service Mapping and Discovery.
Note: Some ServiceNow applications refer to CI types as CI classes.
A CI type (or class) contains several important definitions that apply to all CIs belonging to it:
• CI attributes are added as fields to the CMDB tables.

• Identifiers help Service Mapping and Discovery differentiate between new and existing CIs. For
example, if there is an Apache Web Server CI type defined in the CMDB, and Service Mapping and
Discovery both discover an Apache Web Server CI, the system processes it using identifiers. It then
recognizes the discovered Apache Web Server CI as an updated version that already exists in the
system, not a new Apache Web Server CI. For information about the attributes the system uses to
identify CIs for different classes, see the identifier rules in Discovery identifiers on page 114.
• There are reconciliation rules that help the ServiceNow platform to consolidate CI properties received
from different applications correctly. These rules are necessary for organizations where more than one
application participates in the discovery process. Reconciliation rules define how properties of the same
CI discovered by different discovery sources are merged. For example, Service Mapping discovers
the version and home directory attributes of an Apache Web Server CI, while Discovery discovers
the version and patch level attributes for the same Apache Web Server CI. The ServiceNow platform
applies the reconciliation rule and as a result Service Mapping does not overwrite the attributes found
by Discovery.
• Preconfigured CI types that come with the ServiceNow platform form a hierarchy where some CI
types serve as parents to others who automatically receive their parent's attributes in addition to
parameters you configure specifically for them. CI type hierarchy is used widely for configuring CI
behavior, relationships, and display. Child CI types derive properties from their parents. In this example,
the Apache Web Server CI is a child of the Web Server CI and derives many attributes from its parent,
such as name, version, and model ID.
In addition to these CI type definitions, the horizontal discovery process uses a CI classification to define
to which CI type a CI belongs. Create a device CI classification if you create a CI type for devices using
SNMP and a process CI classification for an application CI type.
1. Navigate to Configuration > CI Class Manager.
2. To use an existing CI type as a parent for the new CI type, in the Class Hierarchy pane, navigate to
the required CI type, right-click it and select Extend.
3. Create a table to store the CI type attributes:
Table 374: New table form
Field Description
Label CI type name. For example, Apache Web

Server.
Name The table name. For example,
cmdb_ci_apache_web_server.
Use a name similar to the other
CMDB classes (for example,
u_cmdb_ci_laptop).

Field Description
Extends table The table name of the parent CI type.

All CI types are extensions of the
Configuration Item [cmdb_ci] table or its
child tables. For example, if the new class is
Laptops, which is a subclass of Computers,
select the cmdb_ci_computer table. If the
new class is a top-level class, select the
cmdb_ci table.
The most commonly used parent CI types
are:
• cmdb_ci - basic
• cmdb_ci_database - for databases
• cmdb_ci_app_server - for application
servers
• cmdb_ci_infra_service - for infrastructure
services
• cmdb_ci_endpoint_inclusion - for entry
points of the inclusion type
• cmdb_ci_appl - for applications
• cmdb_ci_web_server - for web servers
• cmdb_ci_lb - for load balancers
• cmdb_ci_endpoint - for entry points
4. Configure how the instance determines if a discovered CI is an upgraded CI existing in the instance or
a brand new CI. See Create or edit a CI identification rule.
Warning: If there is no CI identification rule for a CI type, Service Mapping discovers CIs
belonging to this type, but cannot interpret the results of the discovery process. In this case,
the ServiceNow platform rejects the discovery results for these CIs and their information is not
updated.
a) On the Identifiers page, configure the parameters as follows:
Table 375: Identifier form
Field Description
Name Use a meaningful name.

Applies to Enter the CI type.
Active Select the check box.
Independent Clear the check box.
b) Configure the identifier entry parameters as follows:

Table 376: Identifier entry form
Field Description
Criterion attributes Select Class.

Allow null attribute Select the check box.
Priority If there is more than one identifier entry,
add priority to determine the order in
which Service Mapping applies these
entries. If none of the identification
criteria matches the discovered CI, this
CI is new.
5. (Optional) Configure the instance to consolidate CI properties received from different data sources
correctly. See Create or edit a CI reconciliation rule.
Configure the following Service Mapping-related parameters correctly:
Table 377: Reconciliation Definition form
Field Description
Data source Select ServiceWatch.

Applies to Select the relevant CI type.
Optional condition Set a condition if necessary.
Note: If you do not create a CI reconciliation rule, data discovered by patterns is used to
update CI properties.
6. Configure the CI classification for your CI type:

• For CI types representing applications, perform configuration as described in Create a Discovery
process classification on page 96.
• For CI types representing SNMP devices, perform configuration as described in Create a Discovery
CI classification on page 91.
Note: There is no need to create CI classifications for hosts because these classifications are
included in the base system.
7. For CI types that represent inclusions, define the hierarchy for the new CI type. Clear the Reverse
Relationship Direction check box while performing this configuration.
See Create or edit containment service rule metadata.
8. If necessary, customize icons that represent CIs in maps.
See Create or modify map icons.
Create an entry point type for Service Mapping

An entry point is a property of a connection to a configuration item (CI). You can create a new entry point
type in addition to preconfigured entry point types in Service Mapping.

Role required: sm_admin or admin
Service Mapping starts the discovery and mapping process for every business service from the entry point
you define for it. In addition to this, Service Mapping patterns use entry points to discover CI outbound
connections.
Service Mapping includes a wide range of preconfigured entry point types that cover most commonly
used applications. If your organization uses a less known or proprietary application that does not have a
corresponding entry point type in Service Mapping, you must create it.
Entry points are modeled in the ServiceNow CMDB as CIs of endpoint type.
Like any other CI type, an entry point contains several important definitions that apply to all CIs belonging
to it:
• CI attributes are added as fields to the CMDB tables.
• Identifiers help Service Mapping and Discovery differentiate between new and existing CIs.For
example, if there is an Active Directory Forest endpoint CI type defined in the CMDB, and Service
Mapping discovers an Active Directory Forest CI, it processes it using identifiers and recognizes it as an
updated version of the Active Directory Forest CI that exists in the system, not a new Active Directory
Forest CI. Unlike with regular CI types, identifiers for new endpoint CI types are created automatically.
• CI type hierarchy. Preconfigured CI types that come with the ServiceNow platform form a hierarchy
where some CI types serve as parents to others who automatically receive their parent's attributes
in addition to parameters you configure specifically for them. CI type hierarchy is used widely for
configuring CI behavior, relationships, and display. Child CI types derive properties from their parents.
Create standard entry points as child CIs for the endpoint CI type, which creates an extension for the
cmdb_ci_endpoint table. For entry points of inclusion type create child CIs for the inclusion endpoint CI
type extending the cmdb_ci_endpoint_inclusion table. In an inclusion, a server hosts applications that
are treated as independent objects.
1. Navigate to Configuration > CI Class Manager.

2. To create a standard entry point, right-click Endpoint from the Class Hierarchy pane and select
Extend.
3. To create an entry point of the inclusion type, right-click Inclusion Endpoint from the Class
Hierarchy pane and select Extend.
4. Create an entry point type using the following parameters.
See Create a table.
Table 378: New table form
Field Description
Label Entry point type name. For example, HTTP

entry point.
Name The table name. For example,
cmdb_ci_endpoint_http.

Field Description
Extends table The table name of the parent CI type is

automatically filled by the system:
• cmdb_ci_endpoint - for entry points
• cmdb_ci_endpoint_inclusion - for entry
points of the inclusion type
5. Add entry point properties on the Columns tab at the bottom of the page.
By default the new entry point derives properties from its parent CI, but you can modify the properties
as necessary.
6. Click Submit.
Patterns for instances using domain separation

In instances that use domain separation, patterns may be domain-specific, covering only domains that you
created them for, or global, applying to all domains.
This information is relevant only for instances that use domain separation.
Patterns belong to domains. By default, all preconfigured patterns are assigned to the global domain and
apply to all domains of all levels.
You can create patterns for specific domains. In that case, the new pattern is used only for this domain and
does not exist in any other domains. If you customize an existing pattern in the global domain and assign
it to a specific domain, you create a copy of the global pattern, which is still used for all other domains
except the domain that has the customized version of this pattern. Likewise, if you customize the pattern
belonging to the global domain, the change effects all domains except the one that uses a customized
copy of this pattern.

Create a pattern
Create a pattern and define its basic attributes.
Role required: admin, discovery_admin, or sm_admin
Make sure that the application for which you want to create a pattern, has a corresponding configuration
item (CI) type and a CI classification. If the CI type you require is not in the list, create it as described in
Create a CI type for Service Mapping and Discovery on page 732.
Patterns can be of infrastructure and application type. Infrastructure patterns are used only by Discovery
for creating lists of devices. Application patterns serve both Service Mapping and Discovery that use the
same application patterns for their purposes.
1. Navigate to Pattern Designer > Discovery Patterns.

2. Click New.
3. Define the basic pattern attributes on the Basic tab:

Field Description
Name Enter the pattern name. This name

must be unique to this pattern. Use self-
explanatory names such as Apache on
Unix pattern.
Pattern type • Select Application for an application
pattern. It can be used both for top-down
discovery performed by Service Mapping
and horizontal discovery performed by
Discovery.
• Select Infrastructure for an
infrastructure pattern used for the
horizontal host discovery performed by
Discovery.
CI type Select the CI type which you want this

pattern to discover.
4. Click Submit.
5. Click the pattern you created in the list.
6. Define advanced attributes:
• For an infrastructure pattern, click Edit for Discovery.
• For an application pattern used for horizontal discovery by Discovery, click Edit for Discovery.
• For an application pattern used for top-down discovery by Service Mapping, click Edit for
Mapping.
Field Description
Description Provide a description for this pattern.

Operating system [Application patterns Select the operating system that the
only] selected CI runs:
• All - if the CI runs more than one
operating system.
• Windows
• Unix - Select this option for any of the
following operating systems: Linux,
Solaris, HP-UX, AIX
• IBM Z/OS
If the required operating system does not

match any options, add it.

Field Description
Run Order [Application patterns only] For an application pattern used by Service
Mapping, select the order in which this
pattern always runs:
• Before
• After
Then select the other applicable pattern. In

most cases, this field is not relevant. It is
only relevant if a particular pattern can be
confused with another pattern.
For example, Both IIS and MS Exchange
applications have an HTTP entry point.
However MS Exchange uses some of the
components of IIS. Therefore, if the IIS
pattern ran first, discovery might incorrectly
identify MS Exchange as IIS. To prevent
this error, in the Run Order field in the MS
Exchange pattern definition, select Before
and IIS.
7. Define a set of identification steps for every incoming connection of a configuration item (CI).
a) Under Identification Section, click the plus icon to create a new identification set of steps.
b) Configure the following parameters:
Field Value
Name Unique name for the identification section.
Entry Point Types [Application patterns only] Select all relevant entry point types. Every CI
has incoming connections that are referred
to in Pattern Designer as entry points. You
base your CI identification process on the CI
entry points creating steps and defining step
operations and variables for every entry point
separately.
For application patterns used by Discovery,
enter either TCP or All.
Find Process Strategy [Application patterns Select the appropriate strategy for finding the
only] process that populates the Process variable in
the Temporary Variables table.
• LISTENING_PORT: The entry point is the
listening port.
• TARGET_PORT_AND_IP: The entry point
port communicates with another server.
• NONE: The process variable is not
populated.
Typically, the port type of the entry point

determines the strategy.

Field Value
Order For an application pattern used by Service
Mapping, select a number that determines
the order in which Service Mapping uses
identification sections. The section with the
lowest order number is used first.
c) Click Create New.

d) Define pattern variables for this section. For more information, see Pattern variables.
e) Define discovery steps as described in Define discovery steps on page 741.
f) Click Save.
g) Click the Back to pattern link in the upper-right.
8. If necessary, create more identification sections.

9. If necessary, change the order of your identification sections by using arrow buttons:
10. When creating an application pattern, make sure you define both modes: for Discovery and for Service
Mapping.
• For application type patterns, continue with Define the connection section on page 787.
Define discovery steps

For each Identification Section and Connection Section entry that you added to the discovery pattern,
define discovery steps. These steps are the basis for discovery.
You can choose to define these steps immediately after adding an Identification or Connection section, or
you can choose to do it after adding all Identification and Connection sections.
You need to define an operation for every step. The type of operation dictates which parameters and
variables need to be configured.
1. On the pattern form, double-click the relevant entry in the Identification Sections or Connectivity
Sections. Connectivity Sections is for Service Mapping only.
If no discovery steps have been identified for this pattern, an _Untitled_Step_ node appears in the
Operational Step tree in the left pane of the window.
2. In the tree, right-click a step in the left pane and select Add Step Before or Add Step After.
3. Select an operation from the list and then fill in the fields that appear for the operation.

Operation Objective
Change User Use operating system credentials instead of the
default administrative credentials.
Create connection Provide information about outgoing connections.

This is for the connectivity section of a pattern
that applies to Service Mapping only.
Filter table Filter a table according to specified criteria.
Find matching URL Find the best match for a URL in a list of URLs.
Get registry key Query for registry keys.
Get process Search for a process according to specified
criteria.
LDAP query Query an LDAP directory.
Library reference Combine a number of steps to be executed as a
group.
Match Terminate if a condition is not met.
Merge table Merge two tables.
Parse command output Extract information from the output of the
command.
Parse file Extract information from a file.
Parse a URL on page 766 Break down a URL into its components.
Parse variable Extract information from a variable.
Relation and/or reference Create relationships and references between CIs
that were discovered within the pattern.
Transfer a file on page 779 Transfer a file to a remote system.
Set a variable on page 778 Set the value of a variable.

SNMP query Execute an SNMP query.
Transform table Add computed columns to an existing table.
Unchange user Switch back to the default administrative
credentials.
Union table Append two tables that share the same format.
WMI method invocation Execute a method using WMI (Windows
Management Instrumentation).
WMI query Execute a WMI query.
4. Specify the following discovery step settings.

Field Description
Precondition Check box to perform the step of a specific

criteria. If the step is always performed as
defined, leave this setting unchecked.
For more than one condition, consider
defining a step for each condition rather
than multiple conditions.
For more information, see Make a step
conditional on page 750
CI Attributes Table that is automatically populated with CI
attribute variables that are generated when
you add a CI type.
This table does not support Container or
Tabular variables.
You can use shortcuts to enter values as
described in Useful shortcuts in Pattern
Designer on page 743.
All variables are notated with a $ prefix
and constants are formatted within double
quotes.
For more information, see Pattern variables
on page 751.
Temporary Variables Table that is automatically populated with
temporary variables that are generated
when you define a discovery pattern.
You can add or remove variables from the
Temporary Variables table.
You can use shortcuts to enter values as
All variables are notated with a $ prefix
and constants are formatted within double
quotes.
For more information, see Pattern variables
on page 751.
5.
To add comments to any step, click the comment icon ( ) and add the text in the comment field.
6. To delete a step from the section, select the step and click the trash can icon.
7. After you define all steps, click Save.
8. On the pattern record, click Activate to make that pattern available for use.
Click Debug to access the additional actions, and you can browse to and open information source files
rather than looking them up separately.
Useful shortcuts in Pattern Designer
There are several shortcuts that make entering values in Pattern Designer easier.

Table 379: Useful shortcuts in Pattern Designer
To Do this Example
Enter constant values, a string Enclose the value in quote Enter the path with quote marks
marks ("). (") at the beginning and at the
end of the string.
Enter a value that can change, Start the variable name with the Enter the variable name
a variable dollar sign ($). beginning with the dollar sign
($).
Enter a value that can change Enter the variable name in the Enter the dollar sign ($),
from a variable that contains following format: followed by process for the
several variables container variable name, period
$<container_variable>.<variable>
(.), and then pid for the name
of the string variable.

To Do this Example
Enter a value from the specific Enter the variable in the To use the value from
field in a table following format: the second row in the
$tabular_variable[row instanceID column from
number].column_name the IfTable variable, enter
$IfTable[2].InstanceID.
Enter values from a specific Enter the variable in this format: To use the value from
column in a table sequentially, the current row in the
$tabular_variable[].column_name
starting from the current row instanceID column from
the IfTable variable, enter
$IfTable[].InstanceID.

To Do this Example
Enter values from a specific Enter the variable in this format: To use the value from the first
column in a table sequentially, row in the instanceID column
$tabular_variable[*].column_name
starting from the first row from the IfTable variable, enter
$IfTable[*].InstanceID.
Note: When used in

Match a condition on
page 761 with the Is
Not Empty operator,
the system extracts
values from fields,
even if some fields are
empty.

To Do this Example
Copy a value or a variable into Select the variable or the value Drag the company variable
a field you want to copy from the CI from the CI Attributes pane
Attribute pane and drag it into into the Values field.
the target field.

To Do this Example
Enter a variable using auto- 1. Type the dollar character Variables have a $ prefix.
complete ($) and the first letters of Typing $P in a field displays a
the variable name. list of possible values beginning
with "P".
2. Select the relevant value
from the list showing all
currently available values
that match the characters
you entered.
If only one choice fits, that value

is automatically entered into the
field.
Specify complex (concatenated) Enter a value, then add a plus To specify the path, use the
values in fields sign (+), and then enter another install_directory variable and
value. extract of the actual path
connected by a plus sign (+).
Note: You can drag
values and variables to
create complex values.
To enter a constant value,

enclose it in quote marks (").
Activate pattern debug mode

Working in the debug mode, Pattern Designer performs all operations as you configure them. It allows you
to see results immediately.
Before starting this procedure, verify that the debug mode is not activated. If the debug mode is activated,
the debug button appears with a green check icon: .

Many operations require that you enter a specific value from a specific source, for example, a particular
value, or a particular location and delimiter, in a particular file. If you are not in debug mode, you need
to type details such as path and file name, or an actual relevant value or related information. However, if
you work in debug mode, you can browse to and open information sources such as files, and then select
specific values from those files.

Service Mapping and Discovery share patterns, but execute them differently. Discovery runs infrastructure
and application patterns for horizontal discovery, while Service Mapping runs application patterns for
the top-down discovery. When you activate debug mode, you choose how pattern steps are run: as if by
Discovery or as if by Service Mapping.
Service Mapping and Discovery share a set of preconfigured patterns that cover most of the commonly
used devices and applications.Patterns can be of infrastructure and application type. Infrastructure patterns
are used only by Discovery for creating lists of devices. Application patterns serve both Service Mapping
and Discovery that use the same application patterns for their purposes.
When you activate the debug mode, the following additional actions become available:
Table 380: Debug Mode Actions
Action Description
Search assistant Allows you to search within files or the registry.
Note: Perform additional configuration

to enable this feature as described
in Configuring Search Assistant for
Windows on page 708.
Run command Runs all steps on the target machine. Verifies

that all required attributes contain values, and
that discovery leads to a valid CI with no errors.
Test Tests the current step. This action is
automatically run after you define a step and
create a new one.
Activate Enables the new pattern.
If you are not in debug mode, actions are not performed and values are not displayed in the tables.
1. In the Pattern Designer, click Debug > Debug for Discovery or Debug for Service Mapping
depending on how you need the pattern executed.
The Debug Identification Section window is displayed.
2. Fill in the required details for the entry point type:
Field Description
Type Select the required entry point type from the

list.
Host Enter the relevant value for the entry point
host.
Port Enter the relevant value for the entry point
post.
Protocol Enter the relevant value for the entry point
protocol.
Original IP Select the check box and enter the IP for
this entry point.
3. The Debug Identification Section window, click Debug.

The debug mode is activated and the green check mark appears on the Debug button .
4. To deactivate the debug mode, click the Debug button in the Pattern Designer window.
Make a step conditional

If necessary, create conditional criteria that define how an operational step is executed.
Create a pattern or select a pattern that you want to modify.
You can define prerequisite conditions, filtering criteria, matching criteria. If required, you can add more
than one condition to the same step.
1. Double-click an entry in one of these locations:
• the Identification Sections or Connectivity Sections for Service Mapping
• the Step window for Discovery
2. Click the Set Precondition check box.

Not all operations allow you to use preconditions.
3. In the first condition field, enter the required value. For example, a variable name.
4. Select an operator from the list.

If you select Is Empty, the second field is rendered irrelevant and disappears.
5. To add more conditions, click the plus icon next to the Set Precondition check box icon and define
the criteria.
6. If you define multiple conditions, set the logical relationship between them by clicking the AND or the
OR icon.
7. Define if the criteria must be satisfied or not for the step operations to run: from the If precondition is
list, select True or False.
Pattern variables
You use variables in discovery patterns to refer to parameters or attributes that the pattern needs to
discover.
There are several kinds of variables used in discovery: global variables, CI attribute variables, and
temporary variables.
Characteristics Global variable CI attributes Temporary variables

Description Refers to general Refers to parameters Refers to a parameter
parameters of a device defined for the relevant used for a specific
or application: CI type. operation in a pattern
step.
• computer system -
contains information
about the host of the
CI for the CI for which
you create a pattern.
• entry point - contains
information about
the connection which
serves as an entry
point for the CI for
which you create a
pattern.
• process - contains
data about the
process detected at
the port pointed to by
the entry point.
Type/structure Container variable: a A variable can be: Scalar, tabular, or vector

variable can hold any
• Scalar - a single • Scalar - a single
combination of single
string string
strings and tabular
variables. • Tabular - a table, • Tabular - a table,
where each cell is a where each cell is a
scalar variable. scalar variable.
• Vector - a single, • Vector - a single,
unnamed column unnamed column
with as many rows as with as many rows as
needed needed
Origin Preconfigured in Service Derived from a CI type You create these

Mapping. definition. variables while defining
operations for pattern
steps.

Characteristics Global variable CI attributes Temporary variables

Modifiable in Pattern No No Yes
Designer
Pattern Designer displays different kinds of variables in different areas of its interface.


Always prefix variables with the dollar symbol ($) which indicates variables, but is not actually a part of the
variable name. For example, if you specify $Abc as the variable name, the actual name of the variable is
Abc.
Change credentials for discovery
You can define a Change user operation to make Service Mapping or Discovery use SSH or Windows
credentials instead of the default administrative level credentials. This operation is relevant only for
configuration items (CIs) hosted on Windows or Unix operating systems.
Ensure that the operating system (OS) credentials you want to use instead of the default credentials are
correctly configured. Configure the tag attribute to the OS CI type whose credentials you want to use. For
operational information on how to create credentials, see SSH credentials and Windows credentials.
When you define a Change user operation, the appropriate credentials for the same CI type, or a different
CI type on the same or different host are used for the discovery process.
1. Select Change user from the Operation list in one of the following locations:
2. Fill in the fields, as appropriate.

Field Description
Use different host Select the check box to use a specific host
and then fill in the host name.
Use Different CI Type Select the check box and select the CI type
from the list.
The following configuration is an example of the Change user operation.
Field Value
Hierarchy Applications > Business Integration
Software
CI Type IBM WebSphere MQ Queue
Pattern WMQ Queue Unix Pattern
Section Identification for MQ Queue entry point
types
Step number and Name 5. Change user credentials
Provide connection information

Use the Create connection operation to provide information about an outgoing connection. This operation
is only available for connectivity sections.
Always start with this step when creating a connectivity section entry for a new pattern.
1. Select Create connection from the Operation list.

Field Description
Select Connection Type • Application flow: Used between two

applications (can be of the same type).
• Cluster: Used for connections to CIs of
the cluster type. Specify a Cluster name.
• Inclusion: Used for connections to an
object that is included in the current
object. For example, a connection from
J2EE to EAR, and a connection from IIS
to a website.
• Storage flow: Used for connections
between configuration items (CIs) of host
type and devices of storage type.
Select Entry Point Select the entry point type from the list.
Target CI type Select the target CI type from the list.
Is Artificial Select the check box if the connection
should be hidden (that is, not shown in the
user interface), but is used for continuing the
discovery flow.
Is Traffic Based Select the check box to use the traffic-based
discovery method for this connection.
The following configuration is an example of the Create connection operation.
Field Value
Software
Section Alias queues connectivity
Step number and Name 6. Create outgoing connection to alias
queues
Merge tables
Use the Merge table operation to merge content from two source tables into a target table.
You can specify the following type of criteria:
• Field equality: If there are matching values in specified fields, both source tables are merged.
• Condition: If both source tables satisfy the criteria, then they are merged.
1. Select Merge table from the Operation list in one of the following locations:


Field Description
First table Specify the name of the first source table.

Second table Specify the name of the second source
table.
Target table Specify the name of the target table.
Unmatched values For tables that meet the merge criteria,
select an action from the list for unmatched
rows:
• Keep: If merge criteria is met for any
row, it merges all rows from both source
tables into the target table.
• Remove: Merges only matching rows
from both source tables into the target
table, and excludes non-matching rows.
Merge Criteria Select a merge type from the list:

• Field equality: Merge based on fields
that have matching values. Specify fields
in the tables to be compared.
• Condition: Merge based on certain
criteria being met. Use the condition
builder to specify the criteria.
You can use variables including values
from tabular variables as described in
Useful shortcuts in Pattern Designer on
page 743.
The following configuration is an example of the Merge table operation.
Field Value
Hierarchy Applications > Application Servers
CI Type WebSphere EAR
Pattern J2EE EAR On Linux
Section DB2 JDBC connectivity
Step number and Name 21. merge the scanned_result with
outgoing_conns
Find a matching URL

Use the Find matching URL operation to find the best match for a URL in a list of URLs.
1. Select Find matching URL from the Operation list in one of the following locations:


Field Description
Values Specify the table and records containing

potential URLs. You can use values from
variables, including temporary tabular
variables: from a specific field or a specific
column in a table sequentially, starting from
the first row. For more information, see
page 743.
URL Specify the URL for which you are seeking
the best match.
Target variable Specify the variable to place the best match.
Filter a table
You can use the Filter table operation to search a source table for a specified value. If found, values are
logged in a specified target table.
1. Select Filter table from the Operation list in one of the following locations:

Field Description
Source table Name of source table to be searched.

Use drag-and-drop or auto-complete to
copy table names, fields, and values from
the Temporary Variables and CI Attributes
tables.
Target table Name of target table to contain the values

that were found.

Field Description
Condition builder Specify the criteria for determining which

values from the Source table are placed in
the Target table:
1. Enter the table name and the column
from which the values are retrieved.
You can also use variables including
values from tabular variables as
2. Choose the relevant operator.
3. Enter the string that Pattern Designer
uses to filter values.
4. If necessary, add more criteria lines by
clicking the plus icon (+).
Note: If the specified target table is already populated, the new fields and values from the
source table overwrite the existing fields and values of the target table.
The following configuration is an example of the Filter table operation.
Field Value

Field Value
Pattern J2EE EAR On Linux
Section DB2 JDBC connectivity
Step number and Name 8. Filter DB2 JDBCProviders
Get a process
Use the Get process operation to search for a specific process to store in a tabular variable.
Make sure that you are in debug mode as described in Activate pattern debug mode on page 748.
You can manually specify the filtering criteria, or you can select a process from the list of all processes
on the system. The values of the selected process are used to populate the filtering fields. Modify these
criteria as needed (for example, to delete irrelevant criteria).
Processes that satisfy the specified filtering criteria are placed in a tabular variable whose name you
specify. This tabular variable appears in the Temporary Variables table.
1. Select Get process from the Operation list in one of the following locations:
2. Click Browse to open a form containing a list of processes.

3. Select a process and click OK. Filtering criteria are populated with values from the selected process.
4. Define the field values as needed.
5. In the Target: Variable Name field, specify a name for the tabular variable that holds the list of
processes that satisfy the filtering criteria.
You can also enter a value from the specific field in a tabular variable as described in Useful shortcuts
in Pattern Designer on page 743.
The following configuration is an example of the Get process operation.
Field Value
Software
CI Type Web Servers - IIS
Pattern IIS
Section Identification for HTTP(S) entry point types
for IIS6 second logic
Step number and Name 40. Get IIS process
Get a registry key

Use the Get registry key operation to retrieve and select registry key attributes to store in a table.
This operation is relevant only for Windows.
1. Select Get registry key from the Operation list in one of the following locations:

2. Define a registry query:

Option Description
Using the browse function, if in Debug mode 1. Click Browse and select the registry key.
The selected key path is placed in the
Registry key path field. A form opens and
displays a list of keys in a tree.
2. Select the key to show the attributes.
3. Select the attributes and specify a name in
the variable column of the table that stores
the value of the key in the Results table.
You can use variables. You can also enter
a value from the specific field in a tabular
variable as described in Useful shortcuts in
Pattern Designer on page 743.
Manually, if not in Debug mode 1. In the Registry key path field, specify the
registry key path.
2. Ensure that the By using all keys from the
registry directory is selected.
3. Click Test and verify that the table is
populated with variable names and values.
3. If discovery must terminate when no results are found for the operation, select the Terminate check
box.
The following configuration is an example of the Get registry key key operation.
Field Value
Hierarchy Applications > Portals
CI Type SharePoint
Pattern Microsoft SharePoint
Section Identification for SharePoint
Step number and Name 1. Find SharePoint version from registry
Define an LDAP query

Use the LDAP query operation to query an LDAP directory.
1. Select LDAP query from the Operation list in one of the following locations:

Field Description
Base DN Specify the point from where a server

searches for users.
Host Specify a host name.
Port Specify a port name.
Query Specify the query parameters.
Scope Specify the scope from the list:
• Sub Tree: The object and all
descendants.
• Object: The object only.
• One Level: The object and one level
below.
3. In the Variable Table, click Add and define the table name and column name to hold the query result.
For multiple results, click Add for each additional column that is needed.
The following configuration is an example of the LDAP query operation.
Field Value
Hierarchy Applications > Mail Services
CI Type ExchangeBackEndServer
Pattern ExchangeBackEndServer On Windows
Pattern
Section Storage connectivity
Step number and Name 2. Query ldap -
msExchStorageGroup.msExchESEParamSystemPath
Match a condition
Use the Match operation to specify conditions that must be met in order for the discovery process to
continue. If these conditions are not met, the discovery process terminates.
1. Select Match from the Operation list in one of the following locations:
2. You can use an actual string or a variable. You can also use values from temporary tabular variables:
from a specific field or a specific column in a table sequentially, starting from the first row. For more
information, see Useful shortcuts in Pattern Designer on page 743.
3. To add more conditions, click the plus icon.
The following configuration is an example of the Match operation.

Field Value
Software
CI Type IBM WMB HTTP Listener
Pattern WMB HTTP Listener On Unix Pattern
Section Identification for HTTP
Step number and Name 1. Check process name to match http lstnr
During discovery of an IBM WMB HTTP Listener, use the Match operation to check the
process name.
Parse command output

Use the Parse command output operation to extract information from the command output to be placed in
a variable table.
1. Select Parse command output from the Operation list in one of the following locations:

2. Specify the command. You can concatenate multiple commands.
Important: Avoid entering a specific path to a location or file because it can be different on
different operating systems. It is recommended to use variables for paths.
You can use variables. You can also enter a value from the specific field in a tabular variable as
described in Useful shortcuts in Pattern Designer on page 743.

Field Description
Parsing strategy To change from the default, select a parsing

strategy from the list. The parsing strategy
is independent of the parse operation. See
Parsing strategies on page 769.
Quick find To find content quickly within a text box,
specify the search text.
4. To change the execution mode or credentials, click Advanced and fill in the fields, as appropriate.
Field Description
Execution mode Select the mode from the list. The mode
determines how communication with the
remote system is invoked.
CI Type Select the CI type from the list.
To insert variables for the credentials ($
$username$$, $$password$$):
1. Position the cursor in the appropriate
location in the Command field.
2. Click the plus icon.
Alternately, you can add the variables

manually.
Host Specify the host.
5. Click Run Command.
The following configuration is an example of the Parse command output operation.
Field Value
Hierarchy Business Integration Software
CI Type IBM WebSphere MQ WebSphere EAR
Pattern WMQ On Unix Pattern
Section Identification for WMB_DEB entry point
type
Step number and Name 5. Handle default q manager case
Parse a file
Use the Parse file operation to extract information from a file to be stored in a variable table.
1. Select Parse file from the Operation list in one of the following locations:


Field Description
File path Specify the file path and click Retrieve File.
Important: Avoid entering a

specific path to a location or file
because it can be different on
different operating systems. It is
recommended to use variables for
paths.
You can use variables. You can also use

values from a temporary tabular variable:
from a specific field or a specific column in a
table sequentially, starting from the first row.
For more information, see Useful shortcuts
in Pattern Designer on page 743.
Quick find (Optional) To find content quickly within a
text box, specify the search text.
The following configuration is an example of the Parse file operation.
Field Value
CI Type BizTalk Orchestration
Pattern BizTalk Orchestration pattern
Section Identification for BizTalk Orchestration
Step number and Name 7. get all send ports
Parse a URL
Use the Parse URL operation to break down a URL to the component level.
1. On the Identification or Connectivity Sections form, select Parse URL from the Operation list.

Field Description
Source Specify the URL:

• Enter a value that can change, a
variable. Type the dollar character ($)
and the first letters of the variable name.
For example, $ldap_url.
• Specify complex (concatenated) values
in fields. Enter a value, then add a plus
sign (+), and then enter another value.
For example, $install_directory
+"conf/httpd.conf".
• Enter constant values, a string. For
example, "/opt/ibm/mqsi/7.0/
bin/".
• Enter a value from a tabular variable:
from a specific field or a specific column
in a table sequentially, starting from
the first row. For more information, see
page 743.
Important: Avoid entering a

specific path to a location or file
because it can be different on
different operating systems. It is
recommended to use variables for
paths.
Target Specify the table into which the results

variables, complex values or strings as
described above.
If not found Select this check box to terminate discovery
if no results are found.
The following configuration is an example of the Parse URL operation.
Field Value
Pattern J2EE EAR on Linux
Section Web Services Connectivity
Step number and Name 3. parse the wsdlfile into table
Parse a variable
Use the Parse variable operation to extract information from a variable to be stored in a variable table.
1. Select Parse variable from the Operation list in one of the following locations:


You can use regular variables. You can also use values from a temporary tabular variable: from
a specific field or a specific column in a table sequentially, starting from the first row. For more
information, see Useful shortcuts in Pattern Designer on page 743.

Field Description
Variable Specify the name of the variable.

Quick find (Optional) To find content quickly within a
text box, specify the search text.
The following configuration is an example of the Parse variable operation.
Field Value
Section EAR to MQ Connectivity
Step number and Name 6. Calc base_was_dir location
Parsing strategies
In discovery patterns, you can use parsing strategies to extract text from any text file and to specify a
variable to store the extracted content.
Parsing strategy Description
File parsing strategy (except vertical) Retrieve text from various file types including:
• .ora file (used by various Oracle products)
• .properties file (common for Java)
• xml file
• .ini file
For more information, see Parse text

from .ora, .properties, .xml, or .ini file on page
770.
Vertical file parsing strategy Retrieve text from a structured text file where
each set of data spans multiple lines

Parsing strategy Description
Keyword, command, and positional type parsing • Retrieve text directly following a specific
strategy keyword
• Retrieve the value of a command-line
parameter using Java-style parameters
• Retrieve the value of a command-line
parameter using standard Unix/Windows
parameters
• Retrieve text specified by its position from the
end of the line
• Retrieve text specified by its position from the
beginning of the line
Regular expression parsing strategy Retrieve text specified by a regular expression

Delimited text parsing strategy Retrieve text specified by delimiters and position
within the line (the most common way to retrieve
text from generic text files)
Parse text from .ora, .properties, .xml, or .ini file

You can use the file type parsing strategy to parse text in files of the following formats: .ora file (used by
various Oracle products), .properties file (common for Java), .xml file and .ini file. For vertical files,
use the vertical file parsing strategy instead.
You can use this parsing strategy only for text files.
Attention: Do not use this parsing strategy for non-text files such as binary files.
You can define multiple extracts and variables. When identifying text for extraction into variables, what you
are really doing is identifying the text location within a context.
You can use one of the following methods:
• In Debug mode, you can select the relevant string from the file contents in the text box. For each string
you select, its position and delimiters relative to its context are stored. It enables the same definitions
to apply to other files with the same structure even though the text varies. However, it selects the entire
text within a context.
For example, if you try to select only 456 in the text box of an XML file with the following line, the entire
string between the keywords is selected.
<ciTypeID>123-456-7890000000</ciTypeID>
• On the Advanced Parsing Options form (outside of Debug mode), you can specify a delimiter and
position to identify the text string. You can also use this form to make a more refined selection than from
within the text box.
For example, you could specify a delimiter (-) and the number of positions to extract after the delimiter
(3) to extract the string (456).
1. Select one of parsing operations from the Operation list in one of the following locations:
2. Select one of these options from the Parsing strategy list:

• Ini file
• Oracle file
• Properties file
• XML file
3. Define the string to be parsed from within Debug mode, or on the Advanced Parsing Options form
(outside of Debug mode).
Option Description
In Debug mode 1. Select the string in the text box. All matching
strings in the same context are automatically
selected.
2. Assign the string to a variable on the Define
Variable Name form. Provide a unique and
meaningful name and click OK.
3. To identify additional strings and variables,
click the plus icon.
Outside of Debug mode (Advanced Parsing 1. Click Advanced and specify the root path.
Options form) The root path is the section (hierarchical
branch in the file structure) where parsing
takes place.
2. Click the plus icon for each string and
variable to be added and fill in the fields, as
appropriate.
• Name: Specify the column name.
• XPath query: Specify the XPath query
for the string. For example, appcmd/APP/
@APP.NAME.
• Delimiter: Specify the delimiter for the
string.
• Position: Specify the position of the
string.
4. To end the discovery process if no results are found, select the If not found check box.
5. Click Close Advanced.
Parse text from a vertical file

In discovery patterns, you can use the Vertical file parsing strategy to parse text into variables for vertical
files.
1. Select one of parsing operations from the Operation list in one of the following locations:
2. Select the Vertical file from the Parsing strategy list.


Field Description
Separators for Specify the separators used between

sections, lines, and columns.
Set variables as • Table: Select this option if the target
table contains multiple columns.
• List: Select this option for a single string
(scalar).
Target Table Specify the target table name.
Parse text using keyword, command, and positional type

In discovery patterns, you can parse text into a variable for keyword, command, and positional type parsing
strategies.
The following strategies are generally used to extract a value from a variable. You can use them to define
only a single value for extraction. To extract multiple strings, define multiple steps.
• After keyword
• Command-line Java style
• Command-line Unix style
• Position from start
• Position from end
1. Select one of the parsing operations from the Operation list in one of the following locations:
2. Select one of the keyword, command, or positional types from the Parsing strategy list.
3. Define the string to be parsed from within Debug mode, or outside of Debug mode.
Option Description
In Debug mode 1. Select the string to be parsed in the text box,

or by using the Quick find field.
2. Provide a unique and meaningful name for
the variable and click OK. The variable is
added to the Variables table.
Outside of Debug mode 1. Specify the value and delimiter for the
Keyword, Position from Start, or Position
from End.
2. To add more strings and variables, click the
plus icon.
Parse text using a regular expression

In discovery patterns, you can parse text into variables using the Regular expression query language as
the parsing strategy.

Familiarize yourself with the query language.

1. Select one of the parsing operations from the Operation list in one of the following locations:
2. Select the Regular expression from the Parsing strategy list.

Field Description
Regular expression Specify the regular expression. You cannot

select text in the text box using this parsing
strategy.
You can only specify a single expression,
but depending on its wording, multiple
values can be extracted (enclosed in
parentheses).
Matching of variables to parentheses occurs
according to the order of the parentheses
sets. (The first variable is matched to the
first set of parentheses, and so on).
Set variables as • Table: Select this option if the target

table contains multiple columns.
• List: Select this option for a single string
(scalar).
Parse text using delimited text

In discovery patterns, you can parse text into variables using the Delimited text parsing strategy.
1. Select Delimited text from the Parsing strategy list in one of the following locations:

Field Description
Include lines with Specify the constraints used to determine

which lines are included in the text selection.
Exclude lines with Specify the constraints used to determine
which lines are excluded in the text
selection.
Line separator Specify the non-default character used as a
line separator in the text. Default separators
are either NEWLINE or CARRIAGE
RETURN, depending on the operating
system.

Field Description
Use default Select this check box to use the default line
separator.
3. Define the string to be parsed from within Debug mode, or outside of Debug mode.
Option Description
In Debug mode 1. Select the string to be parsed in the text box,

or by using the Quick find field.
2. Provide a unique and meaningful name
for the variable. The variable is added to
the Variables table. The Line Separator,
Delimiters, and Positions attributes for the
variable are filled in automatically.
Outside of Debug mode 1. Click Delimiters and specify the delimiter

settings. For additional delimiters, click the
plus icon, and then click OK when finished.
2. Specify the positions, separating multiple
positions by commas.
3. Click the plus icon to add the variable and
assign a unique and meaningful name. The
variable is added to the Variables table.
Create a relationship and a reference

Use the Relation and/or Reference condition to create relationships and references between CIs being
discovered within the pattern.
1. In the Step window for the Discovery pattern, select Relation and/or Reference from the Operation
list.
2. Complete the form using the fields in the table.
Table 381: Relation and/or Reference operation fields
Field Description
Source table Source table to compare.

Target table Target table to compare.
Result table The table that the results are inserted into.
Relation type The relationship between CIs from the
specified target tables. For example, you
might select Used by::Uses or Runs
on::Runs.
Reference Selection for reference details. When this
check box is selected the Direction and
Column name fields are available.

Field Description
Direction Direction of the reference. Your choices are

Parent to Child or Child to Parent.
Column name Name of the reference field to use.
Unmatched values Operation for values in the two tables that
do not match. You can keep or remove
unmatched values.
Merge criteria Criteria for merging table fields. Select one
of these options:
• Field equality:
• Condition: Opens a condition builder to
create a merge condition.
Source table field Field from the source table to compare.

You can use variables including values from
tabular variables as described in Useful
shortcuts in Pattern Designer on page
743.
Target table field Field from the target table to compare.

Figure 166: Relation and reference condition form
Reuse a step sequence

You can reuse a sequence of discovery steps that you created for one pattern in other patterns.
Reusing existing step sequences saves you from recreating the same steps manually.
First, you save the steps you want to reuse into a repository (library), and then you can insert them
wherever relevant and as many times as needed.
1. If the steps you want to re-use already exist, create a reusable step sequence as follows:
a) Navigate to the pattern containing the steps that you want to reuse.
b) Navigate to the steps that you want to combine and select the check box for each step.
c) Right-click a selected step and choose Create Library From Marked Steps.

d) Fill in the fields, as appropriate, and click OK.

Field Description
Library Name Specify a unique name for the library.

Library Description Specify a meaningful description for the
library.
The combined steps are saved in the library of reusable sequences.
2. Reuse the step sequence you created:

a) Navigate to the pattern in which you want to insert your step sequence.
b) Select Library reference from the Operation list in one of the following locations:
c) Select the required reusable sequence from the Library list.

The sequence is inserted as substeps inside an untitled step.
d) Rename _Untitled_Step_ to reflect the purpose of the step.

Set a variable
Use the Set variable operation to apply a value to a variable.
1. On the Identification or Connectivity Sections form, select Set variable from the Operation list.
Field Description
Value Specify the value that you want to assign

to the parameter. You can use strings
or variables. You can also use values
from temporary tabular variables: from a
specific field or a specific column in a table
sequentially, starting from the first row. For
more information, see Useful shortcuts in
Parameter Specify the variable or table name.
To consume web services, use EVAL statements in the Value field.

For Value example Parameter
HTTP Get For Windows $getResult

OS: EVAL(return
com.snc.sw.util.HttpInvokerUtil.get(ctx,
${target_url}, ${ci_type});)
For Unix OS: EVAL(return
com.snc.sw.util.UnixInvokerUtil.get(ctx,
${target_url}, ${ci_type});)
HTTP Post For Windows $postResult
OS: EVAL(return
The web service may require
com.snc.sw.util.HttpInvokerUtil.post(ctx,
a POST request with some
${target_url},
data to determine the right
${postJSON},'application/
information to return. Most
json' ,${ci_type});)
common post data types are
REST/JSON and SOAP. For Unix OS: EVAL(return
com.snc.sw.util.UnixInvokerUtil.post(ctx,
${target_url},
${postJSON},'application/
json' ,${ci_type});)

The following configuration is an example of the Set variable operation.
Field Value
Section Identification for J2EE EAR entry point.
Step number and Name 1. sets the ear name
Transfer a file
You can transfer a file from the MID Server to a computer in your organization.
1. Upload the file to the MID Server:
a) Navigate to Service Mapping > Administration > Uploaded Files.
b) Enter a meaningful name in the Name field.
c) Click the Operation Systems tab.
d) Click OS Types and select the relevant type from the list.

e) Click OS Architectures and select the relevant option from the list.
Note: You can select both 32 and 64 bit option for the same file if necessary.
f) Click the Manage Attachments icon.

g) Attach a file.
See Add and manage attachments.

2. Select Put file from the Operation list in one of the following locations:

3. Click Refresh.
The name of the uploaded file appears in the File name field.
4. Specify the variable that refers to the MID Server path on the remote computer in the Full Path Target
field.
The following configuration is an example of the Put file operation.
Field Value
Hierarchy Applications > Web servers
CI Type Website
Pattern IIS Website
Section XML Web Services Connectivity
Step number and Name 9. Upload strings utility
Define an SNMP query

You can use the SNMP query operation to define and execute an SNMP query. You can define a variable
and SNMP OID for the query manually or using the browse feature.
1. Select SNMP query from the Operation list in one of the following locations:
2. To browse for and select the variables and SNMP OIDs for the query, follow these steps.
a) Activate the debug mode.
b) Click Browse and select the MIB in the list or perform a search based on MIB values.

c) Select either a single scalar value or multiple columns in the MIB tree. Multiple columns must be
in the same table.
d) Click Get Data to display the data in the SNMP Browser form and then click OK.
3. To manually define variables and SNMP OIDs for the query, choose either Scalar or Table variable
type and fill in the fields, as appropriate.
Table 382: Scalar fields
Field Descriptions
Variable name Name of the scalar variable.

SNMP OID Name of the SNMP OID assigned to the
variable.
4. Click the plus icon to add a column to the Variables table.
Table 383: Table fields
Field Descriptions
Table name Replace _Table_Name_ with the name of

the Variables table.
Table OID Replace _Table_OID_ with the SNMP OID
of table.
New column name Replace _new-column-name_ with the
column name.
New OID Replace _new_OID_ with the SNMP OID of
the column.
If not found Select this check box to terminate discovery
if no results are found.
The following configuration is an example of the SNMP query operation.
Field Value
Hierarchy Network > Load Balancer
CI Type Radware Load Balancer
Pattern Radware Appdirector SNMP
Section create outgoing connections
Step number and Name 1. get farm table
Add a column to a table

Use the Transform table operation to add one or more computed columns to an existing table and place
the results in a target table. The target table can be the source table.
1. Select Transform table from the Operation list in one of the following locations:



Field Description
Source table Specify the name of the source table.

Target table Specify the name of the target table. The
target table can be the same as the source
table.
3. Click the plus icon to add each target field and fill in the fields, as appropriate.
Field Description
Target Field Name Specify a name for the column.

Value Specify the operation expression that
determines the values added to the column.
You can use variables including values from
tabular variables as described in Useful
shortcuts in Pattern Designer on page
743.
The following configuration is an example of the Transform table operation.
Field Value
Hierarchy Applications > Web Servers
CI Type IIS
Pattern IIS
Section IIS7 and IIS8 Virtual Folder connectivity
Step number and Name 6. remove website name from vpath
Unchange user
Use the Unchange user operation to switch back to default administrative credentials if you previously
performed a Change user operation.
Select Unchange user from the Operation list in one of the following locations:
The following configuration is an example of the Unchange user operation.
Field Value
Software

Field Value
Section Local queue connectivity
Step number and Name 11. exit change user credentials
Append two tables

Use the Union table operation to append two tables of the same format.
Appending two tables adds the second table at the end of the first table and places the results in the
additional, target table. If necessary, you can specify one of the source tables as the target table.
1. Select Union table from the Operation list in one of the following locations:

Field Description
First table Specify the name of the first source table.

Second table Specify the name of the second source
table.
Target table Specify the name of the table into which the
results are placed.
The following configuration is an example of the Union table operation.
Field Value
Section Oracle JDBC connectivity
Step number and Name 5. Union JDBCProviders with
JDBCProviders2
Define WMI method invocation

Use the WMI method invocation operation to execute a method selected from a table returned by a WMI
query.
1. Select WMI method invocation from the Operation list in one of the following locations:
2. Specify the source table name in the Source table field.

3. To populate the WMI method with the methods relevant for the table you selected in Source table,
click Get methods.
This step is relevant only for the debug mode.
4. Fill in the fields, as appropriate:
Field Description
WMI method Select the desired method from the list.

Target table Specify the target table name.
Result column Specify the name of the column to contain
the results of the method invocation.
The following configuration is an example of the WMI method invocation operation.
Field Value
Hierarchy Applications > Directory Services
CI Type IIFP
Pattern IIFP On Windows Pattern
Section AD Home Forest connectivity stage-wmi
Step number and Name 2. Invoke WMI Method Run Details ()
Define a WMI query

Use the WMI query operation to execute a query on a remote Windows system either explicitly or
automatically. Successful values are logged in a specified target table.
1. Select WMI query from the Operation list in one of the following locations:
2. Define the namespace path in the Namespace field.

3. If in the debug mode:
a) Click Get WMI data to populate the table and field values automatically.
b) Select a table from the Table name pane.
The field values are displayed in the Fields pane.
c) Select a table from the Table name pane.
4. If you are working in the manual mode, manually configure the following parameters:
Field Description
Table name Search for or select the table name. Table

fields are shown in the Fields section.
Fields Shows the fields in the table. Select the
applicable fields for the query.
5. Define parameters and operators for the condition in the Condition clause.

The actual query text is displayed in the Full statement.
6. Enter the variable for the table in which the retrieved data is saved in the Target table field.
You can enter a value from the specific field in a table as described in Useful shortcuts in Pattern
7. Select the Terminate check box to terminate discovery if no results are found.
The following configuration is an example of the WMI query operation.

Field Value
Hierarchy Applications > Directory Services
CI Type IIFP
Pattern IIFP On Windows Pattern
Section AD Home Forest connectivity stage-wmi
Step number and Name 1. Get all agents details via WMI step
This step uses the WMI Query operation to extract data on agents from the
MicrosoftIdentityIntegrationAgent namespace and save this data in the variable table
named $ManagementAgents.
Define the connection section

Define a set of discovery steps to discover outbound connections of a configuration item (CI). This
operation is relevant for Service Mapping.
Create a pattern or select a pattern that you want to modify as described in Create a pattern on page
738.
A connection section identifies a type of outgoing connection. CIs can have multiple outgoing connections.
Configure a separate connection section for each type of outgoing connection. For example, a .NET
application CI can have outgoing connections of several types: ADO.NET, XML Web Services, or .NET.
So, you must add connection sections for these three types to the .NET Application pattern.
1. Open the required pattern by clicking Edit for Mapping on the pattern record.
The pattern must be of the Application type.
2. In the Connectivity Section, click the plus icon.
Note: The Connectivity Section is grayed out if the pattern cannot be edited for Service
Mapping.
3. Enter the name and click Save.

4. On the pattern form, click Save to save the pattern.
5. Click the created connection section.
The pattern designer opens showing the connection step.
6. Select Create connection from the Operation list.

Field Description
Select Connection Type • Application flow: Used between two

applications (can be of the same type).
• Cluster: Used for connections to CIs of
the cluster type. Specify a Cluster name.
• Inclusion: Used for connections to an
object that is included in the current
object. For example, a connection from
J2EE to EAR, and a connection from IIS
to a website.
• Storage flow: Used for connections
between configuration items (CIs) of host
type and devices of storage type.
Select Entry Point Select the entry point type from the list.
Target CI type Select the target CI type from the list.
Is Artificial Select the check box if the connection
should be hidden (that is, not shown in the
user interface), but is used for continuing the
discovery flow.
Is Traffic Based Select the check box to use the traffic-based
discovery method for this connection.
8. If necessary, create more connectivity sections on the pattern form.
The following configuration is an example of the Create connection operation.
Field Value
Software
Section Alias queues connectivity
Step number and Name 6. Create outgoing connection to alias
queues
Customize a pattern
Customize an existing pattern to reflect any changes or peculiarities in the configuration item (CI)
implementation or setup.


Patterns can be of infrastructure and application type. Infrastructure patterns are used only by Discovery
for creating lists of devices. Application patterns serve both Service Mapping and Discovery that use the
same application patterns for their purposes. For example, Discovery runs the horizontal discovery with the
Apache Web Server pattern to find and list all Apache Web Servers in your organization. Service Mapping
runs the top-down discovery using the same pattern to discover a specific Apache Web Server and place it
on a business service map.
Typically you must modify a pattern in the following cases:
• If there is a pre-configured pattern for a CI whose setup is not standard. For example, if the CI uses
different reference folders than in a standard setup.
• If there are changes to the CI that the pattern serves. For example, if a CI supports a new version that
was released after you implemented Service Mapping or Discovery.
When you customize a pattern, you actually create a copy of the original pre-configured pattern. While
Service Mapping or Discovery use the customized version, the original version is not deleted. When you
upgrade your ServiceNow platform, it updates the original pattern, not the customized copy of it.
If at some point you want to abandon the customized pattern and start using the updated original pattern,
you can revert to the original pattern as described in Choose the pattern version on page 790.
1. Navigate to the appropriate module Pattern Designer > Discovery Patterns.
2. Click the pattern you want to modify.
3. To modify the pattern to perform horizontal discovery using Discovery, click Edit for Discovery.
4. To modify the pattern to perform top-down discovery using Service Mapping, click Edit for Mapping.
5. In the Pattern Designer window, modify the relevant sections of the pattern.
• Finalize a pattern on page 792

Choose the pattern version

Choose which pattern version Service Mapping uses for discovery.
Every time you modify and save a pattern, you create a version of this pattern. By default, the latest
version is used for discovery, but you can choose any other version to use.
1. Navigate to Service Mapping > Administration > Discovery Patterns.
2. Click the required pattern.
The form for this pattern opens.
3. Click the Pattern tab.
4. Scroll down to the Versions section.

The state of the active pattern version that Service Mapping uses is Current.

5. Click the version you want to use.

6. Click Revert to this version under Related Links.

This pattern version becomes the active version that Service Mapping uses and its state changes to
Current.
Finalize a pattern
After you finish defining your pattern, make it ready for use by Service Mapping and Discovery.
Role required: admin, discovery_admin, or sm_admin

There are several ways to finalize a pattern after creating or modifying it:
• Saving – Save all the information you defined for the pattern creating a draft. You can continue working
on the pattern draft at any time. Service Mapping and Discovery do not use the pattern draft for
discovery and mapping.
• Checking – Actually run the pattern on the relevant configuration item (CI) to check that the operations
that you defined for it are correct. Check your pattern before activating it. This option is available only
for application patterns used by Service Mapping.
• Activating – Make Service Mapping and Discovery use this pattern for discovery and mapping. A new
version of this pattern is created. The state of the pattern version used previously changes to History.
1. On the pattern definition form, complete your pattern definition by performing one or more of the
following actions:
To accomplish this Do this
Save the pattern Click Save.

Check the pattern 1. Click Check Pattern.
(only for application patterns used by Service 2. Configure parameters for connecting to this
Mapping) CI.
3. Click Connect.
4. Wait for Pattern Designer to run the pattern
and check that there are no errors.
5. Troubleshoot any errors. If there are no
errors, you can activate or save your pattern.
Activate the pattern Click Activate.

2. Close the Pattern Designer tab.

Example of creating an application pattern

Follow this example to see a step-by-step process of creating and defining a new application pattern for
Service Mapping.
Role required: admin and sm_admin
This example shows how to create a mapping pattern using the debug mode.
The pattern is for Apache Web Server on Unix.
1. Navigate to Pattern Designer > Discovery Patterns.
2. Click New.
3. Define the basic pattern attributes as follows:
Field Description
Name Enter Apache Web Server on Unix

pattern.
CI type Select Apache Web Server from the list.
Pattern type Select Application.
4. Click Submit.
5. Find the pattern in the list and click it.

6. Click Edit for Mapping.

The Pattern Designer window opens.
7. Define advanced attributes as follows:

Field Description
Description This pattern discovers Apache Web Servers

on Unix versions up to 2.4.
Operating system Select Unix:All from the list.
8. Click Save.
9. In the Pattern Designer Pattern window, click the plus icon in the Identification Sections pane.
10. Define the identification section as follows:

Field Value
Name Enter Identification for HTTP(S) entry
point type(s).
Entry Point Types Select TCP, HTTP(S) from the list.
Find Process Strategy Select LISTENING_PORT for the strategy.
11. Click Create New.
The new identification section appears in the Identification Sections pane.
12. Double-click the created identification section.
The Identification Section window opens.
13. Activate the debug mode:

a) In the Pattern Designer, click Debug.

The Debug Identification Section window is displayed.

b) Fill in the required details for the entry point type:
Field Description
Type Select HTTP(S) for the entry point type

from the list.
URL Enter
http://10.196.39.244:6080/ITO.
c) In the Debug Identification Section window, click Debug.

The debug mode is activated and the green check mark appears on the debug button.
Notice that the following variables are populated with values once the debug mode is active:
• computer_system # the Apache host information
• entry_point # identified by the URL in this case
• process # the Apache process information
14. Check that the process name on the CI is Apache Web Server:
a) Rename the first step to Check process name to match Apache.
b) Select Match from the Operation list.
c) Enter $process.executable in the process name field.
d) Select Contains from the conditional operator list.
e) Enter httpd in the string field.
f) Click the plus icon to add another condition row.
g) Enter $process.executable in the process name field.
h) Select Contains from the conditional operator list.
i) Enter apache in the string field.
j) Click OR for the logical operator.

k) Click Test and verify that you get the following message: No changes were made during this test.
15. Populate the label attribute for your CI:

a) In the step tree, right-click the first step and select Add Step After.
b) Rename the new step to sets the display label.
c) Select Set variable from the Operation list.
d) Enter "Apache" in the Value field.
Note: Make sure to enter the value with the quote marks (").
e) Enter $label in the Parameter field.

f) Click Test and verify that the following message appears:
g) Click OK.
16. Populate the home directory attribute:

a) In the step tree, right-click the last step and select Add Step After.
b) Rename the new step to Get home dir.
c) Select Parse variable from the Operation list.
This operation extracts the value after the -d in the content box.
d) Expand the process variable in the Temporary Variables pane.
e) Drag the commandLine variable from the Temporary Variables pane into the variable field under
operation.
Note: For more information on using the drag-and-drop feature, see Useful shortcuts in
f) Select Command line Unix style from the Parsing strategy list.
g) In the Variables pane, add the new intall_directory variable.
h) Click Test.
17. Obtain the home directory attribute if Pattern Designer from HTTP daemon.
If the previous step populated the home directory attribute, skip this step. In this example, it is
necessary to perform it.
b) Rename the new step to Condition – check that home dir was set if not
extract it from httpd –V.
c) Select Parse command output from the Operation list.
d) Click Set Precondition.

e) Enter $install_directory in the condition value field.

f) Select Is Empty from the conditional operator list.
g) Enter $process.executablePath+" -V " in the Command field.

h) Click Run Command.
i) Select Delimited text from the Parsing strategy list.
j) Enter HTTPD_ROOT in the Include lines field.
k) Click the Edit button next to Delimiters.

l) Add the two delimiters: equals (=) and quotes (").

m) Click OK.
n) Enter 2 in the Positions field.
o) Click Test.
The Debug Results window shows the home directory attribute populated with a value.
p) Click OK.
18. Populate the CI configuration file attribute:

b) Rename the new step to Get config file.
d) Expand the process variable in the Temporary Variables pane.
e) Drag the commandLine variable from the Temporary Variables pane into the variable field under
operation.

Note: For more information on using the drag and drop feature, see Useful shortcuts in
The value is populated: /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf.

f) Enter 1 in the Positions field.
g) Click Test.
19. Extract the CI configuration file attribute from HTTP daemon:

If the previous step populated the configuration file attribute, skip this step. In this example, it is
necessary to perform it.
b) Rename the new step to Condition – check that conf_file was set if not
extract it from httpd –V.
e) Enter $conf_file in the condition value field.

g) Enter $process.executablePath+" -V " in the Command field.

h) Click Run Command.
i) Select Delimited text from the Parsing strategy list.
j) Enter SERVER_CONFIG_FILE in the Include lines field.
k) Click the Edit button next to Delimiters.
l) Add the two delimiters: equals (=) and quotes (").

m) Click OK.
n) Enter 2 in the Positions field.

o) If the new conf_file variable is not added automatically, create it in the Variables pane.
p) Click Test.
The Debug Results window shows the configuration file attribute populated with a value.
q) Click OK.
20. If the configuration file attribute is still not populated, perform this step:
b) Rename the new step to default location of conf file.
g) Enter $home_dir+"/conf/httpd.conf" in the Value field.
h) Enter $conf_file in the Parameter field.
i) Click Test and verify that the configuration file attribute is populated.
21. Concatenate the home directory and configuration file values:

b) Rename the new step to check if the SERVER_CONFIG_FILE is relative or not.
f) Select Starts With from the conditional operator list.
g) Enter "/" in the string value.
h) Enter $home_dir+"/"$conf_file in the Value field.
i) Enter $conf_file in the Parameter field.

j) Click Test and verify that the configuration file attribute is populated.
22. Populate the version attribute:

b) Rename the new step to get version from version.signature (IBMHTTPSERVER).
c) Select Parse file from the Operation list.
d) Enter the concatenated $home_dir variable and "/version.signature" string ($home_dir+"/
version.signature") in the File path field.
e) Click Retrieve File.
f) Create the new Version variable in the Variables pane.

g) Click Test and verify that the version attribute is populated.
In this example, the version is not extracted at this stage.
23. Extract the version attribute from HTTP daemon:

b) Rename the new step to Condition - check that version was set if not extract
it from httpd -v.
e) Enter $version in the condition value field.
g) Click the plus icon (+) to add another condition.
h) Enter $version in the condition value field.
i) Select Contains from the conditional operator list.
j) Enter "directory" in the string value.
k) Click OR for the logical operator.

l) Select True from the If precondition is list.

m) Enter $process.executablePath+" -V | grep 'Server version' | cut -d '/' -
f 2 | cut -d ' ' -f 1" in the Command field.
n) Click Run Command and verify that the version attribute appears in the content box.
o) Enter 1 in the Positions field.
p) Click Test and verify that the configuration file attribute is populated.
Note: The version number is not moved into the CI Attributes pane because confirmation
of its value in the Content box and the Debug Results dialog box is sufficient.
Notice that at this stage you have successfully identified the Apache Web Server and populated
its various attributes except the version attribute that is left blank on purpose.

24. Find additional attributes by reusing a step sequence.

b) Rename the new step to reference to enrich library.
c) Select Library reference from the Operation list.
d) Select Apache Enrich Attributes from the Library list.
This operation inserts a sequence of preconfigured substeps into the step tree.

25. Populate process-related attributes:

b) Rename the new step to get processes.
c) Select Get process from the Operation list.
d) Click Test and verify that the attributes are displayed:

26. Discover the process IDs:

b) Rename the new step to process_ids.
d) Enter $procs[*].pid in the variable field.
e) Select Delimited text from the Parsing strategy list.

f) Create the new ids variable in the Variables pane.

g) Click Test.
h) Verify that all the necessary attributes are populated:

27. Click Save.

Event Management
The ServiceNow® Event Management application helps you identify health issues across the datacenter on
a single management console.
Event Management is available as a separate subscription from the rest of the ServiceNow platform. You
must request activation from ServiceNow personnel.
Service Analytics is automatically activated with Event Management and provides alert aggregation and
root cause analysis (RCA) for discovered business services. To enhance Event Management and Service
Analytics, you can also activate Operational Metrics. Operational Metrics learns from historical metric data,
and builds standard statistical models to project expected metric values along with upper and lower control
bounds.

• Event Management and • Event Management setup on • Create an event rule in
Service Analytics release page 819 advanced view on page 923
notes • Get started with Event • Create or edit an alert rule on
• Upgrade to Istanbul Management on page 818 page 944
• Understanding Event • Event collection configuration • Create or edit CI remediation
Management on page 813 on page 860 on page 985
• Service Analytics on page • Alert correlation rules on page
1012 1006
• Operational Metrics on page • Apply alert remediation on
1030 page 984
• Configure Operational Metrics
anomaly score thresholds on
page 1048
• Create an SLA definition for a
CI or business service on page
849

• Events • Developer training • Search the HI knowledge base
• Alerts • Developer documentation for known error articles
• Use the Event Management • Installed with Event • Ask or answer questions
overview dashboard on page Management on page 831 in the Event Management
1003 community
• View events on page 857 • Contact ServiceNow Support
• Alert management on page
971
• Alert monitoring on page 987
Understanding Event Management

Event Management enables you to monitor the health of business services and infrastructure using a
single management console and respond appropriately to any issues that come up. It provides intelligent
event and alert analysis to ensure continuity of your business service performance.

What Event Management can manage
Event Management can manage external events and configure alerts for discovered business services,
manual services, technical services, and alert groups.
Discovered business services Business service that is a definition of interrelated

CIs from the CMDB. The discovered service, from
Service Mapping, includes a business service
map with mapping relationships. It also includes
an impact tree to show outage severity, active or
related alerts, and CI properties. Business service
information is discovered by Service Mapping. The
mapping information appears on dashboards, the
Alerts list, and the Events list.
Manual services A manual service is a business service that you
manually create by selecting CIs to include in the
service. Manual service information appears on
dashboards with drill-down capability to a map view.
Technical services A technical service is a dynamic grouping of CIs
based on some common criteria. For example, you
can create a technical service based on location for
all web servers or all Oracle databases in Boston.
Alert groups Alert groups, not to be confused with automated
alert groups in Service Analytics, show sets of alerts
for ease of maintenance.
Architecture
Event Management receives and processes events via the MID Server.
As events occur on various systems, the MID Server connector instance sends the events to the
ServiceNow instance. Event Management generates alerts, applies alert rules, and prioritizes alerts for
remediation and root cause analysis. You can use a browser to view this information on dashboards, the
Alert Console, or from a service map.

Figure 167: Event Management architecture
Process flow
Event Management either pulls events from supported external event sources using a MID Server or
pushes events from external event sources using JavaScript code.
Inbound events are collected in the Event [em_event] table and then processed in batches. For events
that meet the defined criteria in alert rules, alerts are created or updated in the Alert [em_alert] table. If
an alert does not exist for the event, a new alert is created. If the alert exists, the existing alert is updated
appropriately.
As part of the alert life cycle, you can manage alerts in the following ways:
• Acknowledge alerts.
• Create a task such as an incident, problem, or change.
• If automatic remediation tasks apply to the alert, begin automatic remediation to start a workflow.
• Complete all tasks or remediation activities.
• Close alerts for resolved issues.
• Add additional information, such as a knowledge article for future reference.

Figure 168: Event Management process flow
Event Management and Service Mapping
Event Management uses discovered services from Service Mapping and automated alert groups with root
cause analysis from Service Analytics to expedite alert resolution.
When an event from an external source arrives from the MID Server, script, or web service API (not
pictured), Event Management locates CI information for alert generation and CI remediation. CI information
is stored into the CMDB from sources such as Service Mapping, Discovery, third-party sources, and
manual population. If Service Analytics is enabled, additional correlated alert group and root cause
analysis information is available to resolve the issue.

Figure 169: Event Management interoperability
Supported browsers
• Firefox version 31 ESR and version 38 or later

• Chrome version 43 or later

• Microsoft Internet Explorer (IE) 7 or later
• Safari version 6.1 or later
For UI16:
• Firefox version 31 ESR and version 38 or later
• Chrome version 43 or later
• Microsoft Internet Explorer (IE) 9 or later
• Safari version 6.1 or later
Get started with Event Management

To get started with Event Management, request the plugin, set up the appropriate event and alert filters
and rules.
Do the following:
1. Request Event Management on page 818.
2. Set up one or more MID Servers.
3. Create manual services or technical services.
4. Create alert groups and assign a role to a service group.
5. Finally, perform further configuration of events and alerts.
Request Event Management

Event Management plugin (com.glideapp.itom.snac) requires a separate subscription and must be
activated by ServiceNow personnel. This plugin includes demo data and activates related plugins if they
are not already active. The Service Analytics plugin (com.snc.sa.analytics) is activated automatically when
Event Management is activated.




3. Click Submit.
Event Management setup

After activating Event Management, set it up to receive and process events, and generate and analyze
alerts.
While setting up Event Management, you can complete these tasks in the following order:
1. Navigate to Event Management > Guided Setup and follow the configuration steps.
2. Configure a MID Server to receive and process events via the MID Server
3. Configure connector definitions and connector instances to receive external events.
4. Configure event field mappings, event rules, and alert binding to manage alert generation.
5. Configure alert rules, alert remediation, and CI remediation for alert management.
6. Get a top-down discovery to receive CI relationships for software and hardware.
7. Configure impact calculation for services, to establish priority for alert resolution.
8. Configure alert groups to consolidate related alerts.
9. Enable Service Analytics root cause analysis for business services and for manual services:
a. Configure a dedicated RCA MID Server as described in Configure a MID Server for Service
Analytics RCA.
b. Set the sa_analytics.rca_enabled property to true as described in Properties installed with Service
Analytics on page 1015.
c. To enable RCA for discovered business services, ensure that Service Mapping is enabled as
described in Request Service Mapping on page 538. This step is not required for RCA for
manual services.
10. Create an event rule to populate alert attributes that are used for analysis, and are essential for
effective alert aggregation. For details, see Create an event rule for automatic alert aggregation on
page 1018.
11. If you upgraded from the Fuji release, Import a business service as a manual service.

12. Configure any other general tasks that appear in this section as appropriate.
Additional Event Management setup tasks

After configuring Event Management to receive and process events and generate alerts, you can perform
additional setup activities.
Create a manual service

A manual service is a business service that you manually create by selecting CIs to include in the service.
Role required: evt_mgmt_admin
If you do not have Service Mapping, you can create a manual service to describe CI relationships for alert
monitoring. The CI relationships, which contain class and instance information, originate from the CMDB.
Note: If you have existing business services from the Fuji release, you must import them as
manual services. For more details, see Import a business service as a manual service.
1. Navigate to Event Management > Manual Services.

2. Click New.
Table 384: Manual Service form
Field Description
Name The business service name.

Owned by The party that is responsible for the
business service.
Business criticality The importance of this service to the
business. This field can determine disaster
recovery strategies for this service.
• 1 - most critical
• 2 - somewhat critical
• 3 - less critical
• 4 - not critical
Version The business service configuration version.

Used for The purpose of the business service.
• Production
• Staging
• QA
• Test
• Development
• Demonstration
• Training
• Disaster recovery

Field Description
Operational status The status of the business service.

• Operational: The business service is
running. Impact calculation runs only on
services in the Operational status.
Select this option to use this business
options for this category, select the
option whose value is set to 1. Event
Management calculates impact only on
business services in use.
service, select one of these options:
• Non-Operational: The business service
is unavailable, disabled, or down.
• DR Standby: The business service is
available as a disaster recovery (DR)
standby.
• Repair in progress: The business
service is receiving maintenance.
Service Classification The service classification. For example,

Business Service.
Location The geographical location or area for the
business service.
Comments Any additional notes and information.
Approval group The Change Control Board (CAB) or group
approval name.
Support Group The group managing the contract covering
the asset.
Managed by The person managing the contract covering
the asset.
SLA The Service License Agreement (SLA) for
Service Group Members section The business services group which contains
this service.
Related items A list of CI instances and corresponding
relationships.
Service Configuration Item Associations A list of items that are currently part of
the manual service. Each item includes
the CMDB class name and a link to
corresponding instance information that
describes physical attributes.

For a particular device, service, or application, the CI relationship includes:
• Basic information, such as a device name.

• Configuration details such, as operational status, software version, or firmware version.

• Network connectivity information such as a port number.
5. Do one or more of the following to update CI relationships:

Option Action
View CIs that are present in the manual Review the Service Configuration Item
service Associations section.
View CMDB relationships between CIs In the form header, click View map.
Use a CI class to add corresponding CI In the Service Configuration Item Associations
instances and relationships to the manual section:
service
1. Click New.
2. Select a Configuration Item class from the
CMDB.
3. Click Submit.
Add a list of CI instances and relationships to In the Related Items section:

the Related Items section
1.
Click the Add CI Relationship icon ( ).
2. Use the CMDB relationship editor to select
the Suggested relationship types. See .
3. In the Filter section, select conditions to find
the CI class and click Run Filter.
4. In the Configuration Items section, select one
or more CI instances for the manual service.
5. In the Relationships section, click the plus
icon (+).
6. Click Save or Save and Exit.
7. Click OK to add the CI instance information
to the Related items section of the Manual
Service form.
Note: The CIs only attach to the

manual service after you click
Populate.
Copy all suggested CI relationships from the In the Service Configuration Item Associations
Related Item section to the manual service section:
and BSM map
1. Click Populate.
2. Select the number of related item layers to
add or import.
3. Click OK.

Option Action
Delete a CI from the manual service In the Service Configuration Item Associations
section:
1. Click the CI name.
2. In the Actions on selected rows dialog box,
select Delete.
3. In the dialog box to confirm this click Delete.
Event Management removes the information
from the manual service. However, the
CMDB information remains intact.
Restore deleted CIs on the Service In the Service Configuration Item Associations
Configuration Item Associations list section, click Populate.
Delete the manual service In the form header.
1. Click Delete
2. In the dialog box, click Delete.
Event Management removes only the
manual service. However, the CMDB
information remains intact.
Create a technical service

A technical service is a dynamic grouping of CIs based on some common criteria. For example, you can
create a technical service based on location for all web servers or all Oracle databases in Boston.
Use the technical services form to create user defined collections of configuration items.
1. Navigate to Event Management > Technical Services.
2. Click New.
Table 385: Technical Service form
Field Description
Name The business service name.


business service.

Field Description
Email Enter the email address of the owner who is

responsible for this business service in the
organization.
Business phone Enter the business phone number of the
owner who is responsible for this business
service in the organization.
To use this business service at a later
time, select one of these options:
standby.
• Repair in Progress: The business

Service Group Members section The business services group which contains
this service.
4. Select a source table and specify the criteria for the technical service query.
Field Description
Table Name of source table to be searched.

You can use autocomplete to locate table
names, or select the appropriate table from
the list.

Field Description
Filter Specify the criteria for determining the

values from the specified source table to be
displayed:
1. Specify the filter condition.
2. Choose the relevant operator.
3. Choose the input field.
4. Choose the operator.
5. Choose the input value.
Create an alert group

An alert group is a set of alerts that meet special criteria for a particular business service.
Navigate to Event Management > Properties, and ensure that the Enable alert group support
(evt_mgmt.impact_calculation.alert_group_support) property is set to Yes.
Role required: evt_mgmt_admin or evt_mgmt_operator
Create alert groups to combine similar alerts that meet the specified criteria. Alert groups appear on the
Event Management dashboard.
Note: Alert groups that are created in this procedure do not display in the Alerts console.
You can learn about Event Management basics, including alert groups, from the following video.
1. Navigate to Event Management > Services > Alert Groups.
2. Click New
Table 386: Alert Group Form fields
Field Description
Name The alert group name.


Field Description
Used for field Specify the purpose of the alert group.

Select from:
• Production (Default)
• Staging
• QA
• Development
• Demonstration
• Training
• Disaster recovery

business service.
Email The email alias for the alert group.
Business phone The phone number for the business.
service now, select one of these options:
standby.
• Repair in progress: The business

Service Group Members The business services group which contains
this service.
Filter The conditions for sending a notification to
the alert group. The conditions must meet
the alert values.
4. Click Update.
Assign a role to a service group

To ensure that group members can manage and act on alerts, assign an Event Management role to the
business service group.

Configure a service group to enable users to manage business services, manual services, or alert groups.
1. Navigate to Event Management > Services > Service Group Responsibilities.
2. Click New.
3. In the Business Service Group field, select the name of the service group.
4. In the Role field, select an Event Management role:
• evt_mgmt_admin
• evt_mgmt_integration
• evt_mgmt_operator
• evt_mgmt_user
5. Click Submit.
6. To find users who are assigned to the role, navigate to User Administration > Users > Roles and
search for the role.
Control user access to business services

Assign user roles to service groups to control user access to business or IT services in your organization.
Make sure that you have performed the user provisioning tasks for Service Mapping or Event Management
users:
1. Add users to groups.
2. Create new roles.
3. Assign roles to a user or user groups.
Make sure that you have created service groups as described in Organize business services into groups
on page 635.
Users inherit permissions from roles that are assigned to them. Service Mapping provides these
preconfigured roles:
sm_admin Sets up the Service Mapping application. Maps,

fixes, and maintains business services. Also
performs advanced configuration and customization
of the product. Assign this role to application
administrators.

application users.

services and are familiar with the infrastructure and
applications that make up the services.

Event Management provides these preconfigured roles:
evt_mgmt_admin Has read and write access to all Event

Management features to configure Event
Management.
evt_mgmt_operator In addition to the evt_mgmt_user permissions,

can also activate operations on alerts such as
acknowledge, close, open incident, and run
remediations.
evt_mgmt_user Has read access to all Event Management features.

Has write access to alerts to manage the alert life.
Has the itil role to be able to manage incidents that
are created from alerts.
evt_mgmt_integration Has create access to the Event [em_event] and

Registered Nodes [em_registered_nodes] tables to
integrate with external event sources.
policies of your enterprise.The relation between business services in groups is purely logical and the same
business service can be part of more than one group. For more information about service groups, see
Organize business services into groups on page 635.
By assigning a Service Mapping role to a service group, you allow all users with this role to access all
services belonging to this group.
Figure 170: Assigning a role to a service group
In the base system, all services are assigned to the All service group that lets all users view and manage
the services. When you assign a role to a service group, the users with this role can access only IT
services in this service group. Users cannot access any IT services, which are not part of that service
group.
You can give access to services to existing or new users. You can also add users to groups to assign roles
simultaneously to multiple users.
You can assign some roles directly to business service groups. However, most enterprises choose to
organize their roles as a hierarchy. It helps to manage roles across multiple ServiceNow applications. For

example, the Service Mapping administrator [sm_admin] can be part of a broader administrator role like
administrator [admin]. By assigning roles to user groups, you give permissions and rights of this role to all
users belonging to the same group.
When you delete a business service group, business services in the group are not deleted. The connection
between the role and the services making up this group (responsibilities) are removed.
1. If using Service Mapping, navigate to Service Mapping > Services > Service Group
Responsibilities.
2. If using Event Management, navigate to Event Management > Services > Service Group
Responsibilities.
3. Click New.
4. In the Business Service Group field, enter the name of the group.
5. In the Role field, enter the name of the role.
For example, evt_mgmt_admin.
6. Click Submit.
Configure domain separation

You can configure Event Management for domain separation to create logically defined domains that limit
unauthorized access to data. With domain separation, Event Management users can only see and manage
alerts and events from their own domain.
Role required: evt_mgmt_admin and evt_mgmt_integration
Activate the Domain Support – Domain Extension Installer plugin and configure the MID Server for Event
Management.
The following Event Management features have limited domain separation support.
Table 387: Features with limited domain separation support
Feature Support
Business service groups Supported.

Limitation: The user can define a business
service that is visible in other domains with
services that are not visible in other domains. In
this case, other domains can see impact results
but cannot see how this result was calculated.
Event – alert flow Supported.

Separation is based on the domain user that
sent events. User access is required for the
credentials of the sending API events or in the
configuration of the MID Server reporting events.
In a multi-domain environment, each MID Server
can serve only one domain according to the
integration user that it uses. In the configuration
of the connector instance, make sure that the
MID Server uses the same domain as Event
Management.

Feature Support
Impact calculation Supported.

Segregation is based on the manner in which
CIs are segregated.
Manual services Partially supported.

CIs are segregated.
Technical services Partially supported.

CIs are segregated. Note: The discovery
process does not segregate CIs by domain.
Remediation Supported.
While editing alert rules, users can only apply
relevant workflows.
1. Activate the Domain Support – Domain Extension Installer plugin if it is not already active.
2. Configure a connector instance to use a MID Server from same domain as Event Management.
Get top-down discovery service mapping

A top-down discovery provides a list of CIs and their interrelationships. This information is useful for
managing software services and hardware issues that are associated with alerts.
You can use Service Mapping to get top-down discovery information. Service Mapping, which is closely
related to Event Management, provides tools to discover the relationships between network, hardware,
software, storage, and other devices.
In Event Management, Service Mapping relationships appear on alerts. You can view the related CI and
other information in the Event Management dashboard. The mapping relationships appear in a business
service map with the generated alert, any CIs that are bound to the alert, and all related CIs.
Purge status and alert history

You can configure automatic table cleanup to improve performance. Automatic table cleanup is
recommended for status and alert history retention.
If records are older than 90 days, by default they are purged. If records are retained for a longer period,
larger volumes of data are stored and performance may be impacted.
Note: Events are purged after 7 days. For information about backing up events to a custom table,
seeEvent Management considerations on page 849
1. Navigate to Automated Test Framework > Administration > Table Cleanup.

2. Shorten the retention period (in seconds) for records of the following tables:
• Alerts [em_alert] (Default: 7,776,000)
• Alert History [em_alert_history] (Default: 7,776,000)

• Impact Status [em_impact_status] (Default: 7,776,000)
Installed with Event Management

Activating the Event Management (com.glideapp.itom.snac) plugin adds several tables, properties, user
roles, script includes, business rules, and scheduled jobs to the system.
Tables installed with Event Management
Event Management adds these tables.

Table Description
Alert Alerts that Event Management manage.

[em_alert]
Alert Correlation Rule [em_alert_correlation_rule] Rules specifying primary and secondary

correlated alerts.
Alert Aggregation Group Alerts Relationships between secondary alerts and the
correlation group they belong to.
[em_agg_group_alert]
Alert Aggregation Group Relationships between correlation groups and

primary alerts.
[em_agg_group]
Alerts History History of alerts. Used for impact calculation.

[em_alert_history]
Alert Rule Mappings of alert fields to the Incident [incident]

table.
[em_alert_rule]
Alert Template Alert templates. This table extends the Template

[sys_template] table.
[em_alert_template]
Event Management SLA Event management SLA tasks for CIs and
business services.
[em_ci_severity_task]
Connector Definition Settings for gathering events from external event

sources.
[em_connector_definition]
Connector Instance Connection details for external event sources.

[em_connector_instance]
MID Server to Connector Instance Mappings of MID Servers to connector

instances.
[em_connector_instance_to_mid]
Event Events received by Event Management.

[em_event]
Event Filter Storage for defined event filters.

[em_event_filter]

Table Description
Event Match Rule Updated events for alert processing. Used by

event rules.
[em_match_rule]
Event Match Field Mappings of event fields to alert fields. Simple

mapping. Used by Event Rules.
[em_match_field]
Event Compose Field Mappings of event fields to alert fields.

Composite mapping. Used by Event Rules.
[em_compose_field]
Event Mapping Rule Updated event fields for alert processing.

[em_mapping_rule]
Event Processing Statistics Statistics on Event Management performance.

[em_event_stats]
Event Type Event types.

[em_event_type]
Task Template Templates that define how to populate new

tasks. For example, how fields of an incident
[em_incident_template]
that is being created from an alert, must be
populated. This table extends the Template
[sys_template] table.
Registered Nodes Registered nodes data.
[em_registered_nodes]
Threshold Rule Alert threshold rules.

[em_threshold_rule]
Binding Device Map Event binding to network paths and storage

paths.
[Em_binding_device_map]
Process to CI Type Mappings Event binding to specific processes.

[Em_binding_process_map]
CI Remediation Remediation rule definitions.

[em_ci_remediation]
Impact Graph Impact tree of CIs containing CI hierarchy and

impact rules to be used for impact calculation.
[em_impact_graph]
Impact Graph History History of changes in impact tree.

[em_impact_graph_history]
Impact Rule Definitions Definition of rules used for impact calculation.

[em_impact_rule_definition]

Table Description
Impact Rule instance Rules based on impact rule definitions.

[em_impact_rule]
Infrastructure Relations Child-parent pairs or CI types. CIs matching

these definitions are added to impact trees.
[em_impact_infra_rel_def]
Impact Maintenance CIs CIs that are in maintenance and therefore are
excluded from impact calculation.
[em_impact_maint_ci]
Impact Status Calculated status of CIs and services to be

displayed in the dashboard and business service
[em_impact_status]
maps for technical services.
SLA Configuration SLA configuration records that identify the CIs
that SLAs can run on.
[em_sla_configuration]
Service Analytics Metric Type Registration Source registration details for processing raw
data.
[sa_metric_registration]
Manual Service Stores records that represent Business

Services that were created manually using
[cmdb_ci_service_manual]
Event Management > Manual Services
capabilities, or imported from the Business
Service [cmdb_ci_service] table. The added
functionality of the Business Service table
[cmdb_ci_service_manual] is that it supports
Business Service maps and impact calculations.
Event Management adds the following tables that are shared with Service Analytics.
Table Description
Alert Aggregation Group Stores alert aggregation query groups formed

using co-relation rules and the groups generated
[em_agg_group]
using analytics.
Alert Aggregation Group Alerts Stores alerts associated to alert aggregation
group.
[em_agg_group_alert]
Properties installed with Event Management
Event Management adds these properties. Be cautious when changing Event Management property
values, as these settings can greatly affect overall system performance.
Note: To open the System Property [sys_properties] table, enter sys_properties.list in the
navigation filter.

evt_mgmt.query_based_service_graph_handler.page_count
Page size of CIs from the technical service to
be fetched at once while calculating technical
service Impact Tree Page size in a single fetch
of CIs while calculating the Impact Tree for a
technical service.
• Type: integer
• Location: Event Management > Properties
evt_mgmt.event_processor_enable_multi_node Enable multi node event processing

• Location: Event Management > Settings >
Properties
• Learn More: Alert binding procedures on
page 936
evt_mgmt.event_processor_job_count Number of scheduled jobs processing events

• Type: integer
Properties
• Learn More: Event Management
considerations on page 849
evt_mgmt.max_events_processing_per_job Maximum events to be processed by every

scheduled job
• Type: integer
Properties
evt_mgmt.impact_calulation.alert_group_support Enable alert group support

Properties
• Learn More: Alert impact calculation on page
957

evt_mgmt.impact_maintenance.sleep_time_sec Minimum time in seconds for checking CI

maintenance: checks both the Status field on
the CI and any change request schedule for the
CI.
• Type: integer
Properties
evt_mgmt.alert_auto_close_interval Auto close interval (in hours), within which open

alerts will be automatically closed; Setting to 0
disables the feature
The number of hours the system waits until it
automatically closes an expired alert.
• Type: integer
Properties
• Learn More: Configure automatic actions for
alerts and incidents on page 952
evt_mgmt.active_interval Active interval (in seconds), within which a new

event reopens a closed alert
Determines the time interval within which a new
event that is identified as a recurrence of an
existing issue updates the existing alert or, if the
alert has been closed, reopens the alert.
• Type: integer
Properties
• Learn More: Configure the alert active
interval on page 951
evt_mgmt.connector_test.progress_timeout Test connector timeout interval

The number of seconds the Test Connector UI
action waits for a response before timing out.
• Type: integer
Properties

evt_mgmt.log_debug Display logs for debugging

Determines whether Event Management logs
event and alert processing.
Properties
sa.impact.crash_interval Timeout for the impact calculation (in minutes)

If the calculation is not complete within the
specified period, it is assumed as failed and any
free calculation thread/node will attempt to re-
calculate.
• Type: integer
Properties
• Learn More: Alert impact calculation on page
957
evt_mgmt.flap_interval Flap interval (in seconds), within which an alert

enters the flapping state
Determines the time interval within which an alert
enters into the flapping state. An alert enters
the flapping state if its flap count—that is, the
number of times it has fluctuated between states
—meets or exceeds the flap frequency value
within the flap interval time period.
• Type: integer
Properties
• Learn More: Configure alert flapping on page
951

evt_mgmt.flap_frequency Flap frequency, frequency an alert must reoccur

to enter the flapping state. An alert enters the
flapping state if its flap count meets or exceeds
the specified value within the time period
specified by the flap interval property.
Determines the number of times an event must
reoccur within the flap interval time period for the
alert to enter the flapping state. An alert enters
into the flapping state if its flap count meets
or exceeds the flap frequency within the flap
interval.
• Type: integer
Properties
951
evt_mgmt.flap_quiet_interval Flap quiet interval (in seconds), quite time that

must pass for an alert to exit the flapping state.
An alert exits the flapping state if the difference
between the alert's last flap time and the time of
the new event exceeds the specified value.
Determines the time interval that determines
whether an alert exits the flapping state. An alert
exits the flapping state if the time between alert's
last flap update and the time of the new event
exceeds this property.
• Type: integer
Properties
951

evt_mgmt.max_alerts_to_display Maximum number of alerts to show on the Event

Management alert panel on the dashboard and
map
Specifies the upper limit of the number of alerts
that are displayed in the alert panel under the
Event Management dashboard and map. For
example, if the value 5 is specified and there are
6 alerts, only 5 alerts are displayed. To see all
the alerts without regard to this upper limit, open
the Alert Console.
• Type: integer
Properties
evt_mgmt.fetch_limit Fetch limit, number of queued events to be

fetched by the event processor in a single fetch
Determines the number of queued events to be
fetched at a time by Event Management.
• Type: integer
Properties
evt_mgmt.alert_ack_on_close Acknowledge an alert when manually closing it

Determines if manually closing an alert
acknowledges the alert.
Properties
evt_mgmt.alert_closes_incident Closing alerts determines the system action

when an alert is closed
• Type: choice list
• Default value: Resolve Incident
• Other possible values:
• Value 1: Close Incident
• Value 2: Do nothing

Properties

evt_mgmt.alert_reopens_incident Reopening alerts determines the system action

when an incident is reopened
• Type: choice list
• Default value: Create New Incident
• Value 1: Reopen Incident
• Value 2: Do nothing

Properties
evt_mgmt.incident_closes_alert Resolving an incident closes the associated

alerts.
Determines if associated alerts are closed when
an incident is resolved.
Properties
evt_mgmt.import_service.levels Number of connected CI levels when importing a

Fuji Event Management business service into a
new manual service
• Type: integer
• Range of possible values: 1-11
Properties
mid.server.connector_default Default MID Server for connectors

Determines the MID Server connectors to use
when no MID Server is specified. Must match a
MID Server name.
• Type: string
table

evt_mgmt.update_alert_restricted_fields_elapsed_time
Minimum time in seconds to wait before updating
an alert for identical events
• Type: integer
Properties
evt_mgmt.event_rules.num_of_events_to_handle Number of events to handle for event rules

processes.
• Type: integer
Properties
evt_mgmt.max_alerts_to_display Maximum number of alerts to show on the

dashboard
• Type: integer
Properties
evt_mgmt.valid_processing_duration_of_event_ruleTime (in seconds) of valid processing duration of

event in event rules evaluating.
• Type: integer
Properties
evt_mgmt.enable_alert_correlation Enable alert correlation calculation

Properties
evt_mgmt.max_worknotes_on_alert Maximum alert work notes. When the maximum

number is reached, further work notes are
purged from the alert.
• Type: integer
Properties

evt_mgmt.remote_incident_url URL of the instance for incident management

• Type: string
Properties
evt_mgmt.remote_incident_credentials Name from the credentials list that defines which

credentials to use when accessing a remote
incident management instance
• Type: string
Properties
sa.map.LIMIT_MAX_GRAPH_SIZE Enable limitation of business service maps

drawing by number of nodes and edges.
ServiceNow recommends that this property be
specified and not be disabled.
Properties
sa.map.MAX_NODES_FOR_LAYOUT Maximal number of displayable nodes on

business service maps. Maps with larger values
are not displayed. ServiceNow recommends that
the value specified not to exceed 5000.
• Type: integer
Properties
sa.map.MAX_EDGES_FOR_LAYOUT Maximal number of displayable edges on

business service maps. Maps with larger values
are not displayed. ServiceNow recommends that
the value specified not to exceed 1000.
• Type: integer
Properties

sa.map.LIMIT_GRAPH_DEGREE Maximal degree of node on business service

map for large map modes. Maps with smaller
degrees are displayed in regular mode. Maps
with larger degrees apply more edge merging
for a view that is more compact. ServiceNow
recommends that the value specified not to
exceed 1000.
• Type: integer
Properties
Roles installed with Event Management
Event Management adds these roles.

Event Management Has read and write access to all • evt_mgmt_user

Administrator Event Management features to • template_editor_global
configure Event Management.
[evt_mgmt_admin]
Event Management Integrator Has create access to the Event

[em_event] and Registered
[evt_mgmt_integration]
Nodes [em_registered_nodes]
tables to integrate with external
event sources.
Event Management User Has read access to all Event • itil
Management features. Has
[evt_mgmt_user]
write access to alerts to
manage the alert life . Has the
itil role so they can manage
incidents that are created from
alerts.
Event Management Operator In addition to the • evt_mgmt_user
evt_mgmt_user permissions,
[evt_mgmt_operator]
can also activate operations on
alerts such as acknowledge,
close, open incident, run
remediations.
Script includes installed with Event Management
Event Management adds these script includes.

EvtMgmtIncidentHandler Creates an incident for an alert based on the

incident template defined in the alert rule.
SaAlertsQuery Displays alerts information on the dashboard.

SaAlertsQueryByCI Displays alerts information for a selected CI.

EventRuleUtil Used in Event Rules form for upgrade from
ServiceWatch to event rules.
EvtMgmtCustomIncidentPopulator Placeholder for a custom script used to populate
incident fields from an alert.
EvtMgmtKBHandler Associates knowledge article to any alert and
acknowledge alert based on the found alert
rules.
ConnectorUtil Connector handler.
Business rules installed with Event Management
Event Management adds these business rules.

Add message key if missing Alert Constructs a message key from

the Source, Node, Type, and
[em_alert]
Resource field values.
After insert (async) Alert Updates the parent field of an
alert, creates mapping between
[em_alert]
alerts and CMDB services, and
automatically creates incidents
based on the alert rules.
Alert Parent Validation Alert Check cycles in alerts.
[em_alert]
After update (async) Alert Creates incidents automatically

based on the alert rules.
[em_alert]
Apply overwrite rule and Alert Applies and validates overwrite

validate rules.
[em_alert]
Change definition by Impact On Impact Rule Synchronizes the impact rule

with impact definition according
[em_impact_rule]
to impact on field.
Close associated incident Alert Closes the incident associated
with an alert as defined by the
[em_alert]
evt_mgmt.alert_closes_incident
property.
Convert Clear severity to Info Event Management SLA Sets the severity to Info.
[em_CI_severity_task]
Delete related Threshold Alert Removes closed alerts
Staging records from the Threshold Staging
[em_alert]
[em_threshold_staging] table.

Disable default rule edit Impact Rule Reverts changes in the default
impact rule.
[em_impact_rule]
Event rule grouping calculation Event rule calculation Calculates suggested grouping
for events.
[em_event_rule_calculation]
Forward stats Event Processing Statistics Forwards event statistics to

usage analytics instance.
[em_event_stats]
Handle Classification Change Alert Removes alert from impact

calculation if it is reclassified as
[em_alert]
a security alert.
Handle Delete alert Alert Removes deleted alert from
impact calculation.
[em_alert]
Handle deleted event rule Event Rule [em_match_rule] Removes deleted event rule.
Handle SLA configuration SLA Configuration When SLA configuration filters
delete [em_sla_configuration] are deleted, deletes CIs in the
em_ci_severity_task table.
Name and pattern cannot be Event Type Verifies that the Name and
empty Pattern fields have values.
[em_event_type]
Notify impact Impact Rule Notifies impact calculation

about modifications to impact
[em_impact_rule]
rules, triggering an impact
recalculation as needed.
Prevent duplicate records Impact Rule Reverts a change to impact
rules if the change causes
[em_impact_rule]
duplication.
Rebuild Impact Tree on InfraDef Infrastructure Relations Notifies impact calculation
change about changes to the
[em_impact_infra_rel_def]
definition of infrastructure
relationships, triggering an
impact recalculation as needed.
Reset service hashes Alert Notifies the dashboard that an
alert has changed.
[em_alert]
Reopen associated closed Alert Reopens the incident

incident associated with an
[em_alert]
alert, as defined by the
evt_mgmt.alert_reopens_incident
property.
Run automatic remediation Alert Runs the remediation task
actions defined for an alert.
[em_alert]
Save type in userPreference Alert Rule Passes parameters between

alert rule update forms.
[em_alert_rule]

SLA Configuration Service Filter SLA Configuration Updates the

Updated [em_sla_configuration] em_ci_severity_task table with
the records that match the
filter in the SLA configuration
records.
Update Instance Parameters Connector Instance Refreshes connector instance
parameters in memory before
[em_connector_instance]
connecting.
Validate BS Impact Rule Verifies the business service in
an impact rule.
[em_impact_rule]
Validate CI Impact Rule Verifies the CI in an impact rule.

[em_impact_rule]
Validate contribution type Impact Rule Verifies the contribution type in

an impact rule.
[em_impact_rule]
Validate contribution value Impact Rule Verifies the contribution value in

an impact rule.
[em_impact_rule]
Validate impact definition Impact Rule Verifies the impact definition in

impact rule.
[em_impact_rule]
Validate Inputs Connector Definition Validates entries in the Name

and Schedule fields.
[em_connector_definition]
Validate Inputs Event Match Rule Validates entries in the Name

field.
[em_match_rule]
Validate Inputs Event Mapping Rule Validates entries in the Name,

From field, and Field to fields.
[em_mapping_rule]
Validate severity fields Impact Rule Verifies severity fields of impact

rule.
[em_impact_rule]
Verify overwrite template table Alert Rule Verifies that the overwrite
template of the alert rule is
[em_alert_rule]
defined in the Alert table.
Verify template is on Incident Alert Rule Verifies that the incident
template of the alert rule is
[em_alert_rule]
defined in the Incident table.
Scheduled jobs installed with Event Management
Event Management adds these scheduled jobs.

Scheduled job Description
Event Management - Connector execution job Compares current time with time when active
connector instances were last run and sets
relevant connectors to execute. Runs every 10
seconds.
Event Management - Delete Work Notes Trim content of alert work notes. When the
maximum number of work notes (default is
50) is reached, further work notes are purged
from the alert. Modify the default using the
evt_mgmt.max_worknotes_on_alert
property. Runs every hour.
Event Management - Impact Calculator Trigger Trigger the impact calculation. Runs every 19
seconds.
Event Management - Update stuck connectors Release connector instances that are stuck.
Runs every 2 minutes.
Event Management - auto close alerts Alerts that are idle longer than
7 days (default time period) are
closed. Modify the default using the
evt_mgmt.alert_auto_close_interval
property. Runs every 10 minutes.
Event Management - close flapping alerts Close flapping alerts. Runs every 5 minutes.
Event Management - close threshold alerts Close threshold alerts. Runs every 2 minutes.
Event Management - create/resolved incidents Job to:
by alerts
• Create incidents for alerts according to alert
action rules.
• Update incidents according to alert state.
Runs every 11 seconds.

Event Management - Maintenance Calculator Calculate the maintenance for CIs. Runs every
minute.
Event Management - Node Count Calculate license usage. Runs once every hour.
Event Management - Queue connector Bi-directional functionality. Processes all pending
processor alerts in the Update Queue and sends them
to the MID Server. By default, this dequeue
process is performed in batches of 1,000 alerts.
Runs every 30 seconds.
Update SLA Configuration Result Synchronizes the CIs that match the SLA
configuration filter with the Event Management
SLA [em_ci_severity_task] table.
Update Event Management SLA Updates Event Management SLA
[em_ci_severity_task] table with the new
severity.

Content packs for Event Management

Performance Analytics Solutions contain preconfigured dashboards. These dashboards contain actionable
data visualizations that help you improve your business processes and practices.
Content packs
To enable the content pack for Event Management, an admin can navigate to Performance Analytics >
Guided Setup. Click Get Started then scroll to the section for Event Management. The guided setup takes
you through the entire setup and configuration process.
SLAs for business services and CIs

Event Management supports the creation of SLAs for business services and for CIs.
You can monitor and manage the quality of the business services offered by your organization. For
example, you might want to set up an SLA that is triggered when the max alert severity of a business
service or CI is Critical, and measure the time it takes to bring the business service or CI back to the Info
state, when the conditions that caused the alert have been resolved.
SLAs and the Task table
You can create SLA definitions only for tables that extend the Task table. The Event Management
application provides a table named Event Management SLA [em_ci_severity_task], which extends the
Task table. Use this table in your SLA definitions to specify the severity level that should trigger and stop
the SLA. During alert impact calculation, changes in the severity level of business services and CIs are
automatically updated in the Event Management SLA table. Scheduled jobs keep the information in this
table up to date.
How the Event Management SLA table is populated
The Event Management SLA table is populated differently for business services and CIs:
• For business services, the system automatically populates the Event Management SLA table when a
business service is created or when its max severity is changed.
• For CIs, you must first identify which CIs can be made available for SLAs by creating an SLA
configuration record. The system then automatically populates the Event Management SLA table with
the CI max severity is changed.

Note: Duplicate CIs are not added to the Event Management SLA table even if the same CI
matches more than one SLA configuration filter.
Create an SLA configuration for CIs

Create an SLA configuration from the Event Management application to determine which CIs are available
for SLAs.
The SLA configuration record is a filter on a table in the system. Select a table that has the CIs for which
you want to create an SLA. If you are creating an SLA definition on a business service, you do not need to
create an SLA configuration.
1. Navigate to Event Management > SLA Configuration.
2. Click New.
Table 388: SLA Configuration form fields
Field Description
Name Provide a descriptive name.

Table Select a table with the CIs for which you
want to create the SLA. You can also
use the Configuration Item to Host View
[query_based_service_basic_view] table,
which is used by technical services.
Filter Configure the filter for the records.
4. Right-click the header and select Save.
The following is an example.

If you want to run an SLA on all Linux servers for major and critical alerts, first create an
SLA configuration on the Linux Server [cmdb_ci_linux_server] table. Then create the SLA
definition with this filter:
• CI.class is Linux Server
• Severity is Major or Critical
Create an SLA definition on the CIs that match this SLA configuration.
Limit the records for the SLA configuration filter

If too many records are returned by the SLA configuration filter, you can add a property to set the
maximum number of records.
1. Enter sys_properties.list in the application navigator.
2. Add the following property:
sa.qbs.max_num_of_cis
3. Set the value to an integer that represents the maximum number of records to return.

Create an SLA definition for a CI or business service

You can create SLA definitions for CIs and business services just as you can for other task records in the
instance.
1. Navigate to Service Level Management > SLA > SLA Definitions.
2. Click New.
3. Fill out the fields on the SLA Definition form for a description of each field.
See .
4. For the Table field, select Event Management SLA [em_ci_severity_task].
5. Configure the Start condition filter by adding conditions, such as:
For all CIs where the Severity is Critical

Type is CI
Severity is Critical
For a specific business service, such as Email, when the Severity is Critical
Business Service is Email
Severity is Critical
6. Also configure pause and stop conditions.
Event Management considerations

Considerations for setting of properties and general configuration.
Table 389: General considerations
Topic Details
Business rules • Avoid writing business rules for event tables

[em_event] as they can result in performance
degradation.
• Business rules that are written for alert tables
[em_alert] must be highly efficient or they
may result in performance degradation.
Instead of writing a business rule, consider
whether it is more appropriate to write a job.
• Do not create async business rules for alert
tables.

Topic Details
Configure for large-scale environments • Set the Enable multi

node event processing
(event_processor_enable_multi_node)
property to Yes.
• Set the Number of scheduled
jobs processing events
(event_processor_job_count) property to 4.
• If you are sending events from a custom
source, verify that events have Message Key
or Source, Node, Type, and Resource data.
Latency issues for receiving events Check the following settings:

• Verify that the Bucket field in the Event
[em_event] table is set to a value that is
greater than zero (0).
• Navigate to System Scheduler > Scheduled
Jobs Scheduled Jobs and search for Event
Management - process events*.
Check that all Event Management - process
events* jobs exist according to the Number
of scheduled jobs processing events
(event_processor_job_count) property
configuration. Verify that the State is Running
or Ready. If the state is Queued or Error, set
the job state to Ready.
Archive events Avoid changing the default retention time for

events.
To log events for a longer time, create an
archive table and a job that copies new events to
it. Do this by scheduling a job to regularly back
up events [em_event] to a custom table.
Do not extend table rotation by adding more
days.
Planning
• Organize event source configuration of filters, modules, and so on, into multiple parallel efforts, rather
than in serial.
• Validate processed event formats to ensure that the data that is parsed is aligned with desired results.
• Test production events in a non-production environment. Integrate with non-production element
managers and ServiceNow instances. If non-production element managers are not available, send
events from element managers to both production and non-production environments.

Event integration
SNMP traps
• It is preferable to use a monitoring tool to send SNMP traps rather than sending them directly from
devices.
• Upload MIBs prior to defining event rules to avoid having to rewrite the Event Rules.
Web service API

• Using a web service API for integration can reduce the number of Event Rules needed. This avoids
having to transform events (prepared data is sent in an event to ServiceNow).
• Use dedicated credentials for Event Management integration. Optionally, designate credentials specific
to each event source.
CloudWatch
• Use dedicated credentials for integrating CloudWatch with ServiceNow.
Email
• Use email only if the source has a low volume and other options are not available, such as, running a
script or forwarding an SNMP trap.
Event rules
• Write Event Rules to apply to the broadest number of events possible. More specific rules can then be
created as necessary. More specific rules should use a lower-order value.
• Avoid writing Event Rules that apply only to a certain subset of events if a more general rule can
achieve the same outcome.
• When Event Rules are applied to events, no changes are made to the original event. All processing
occurs in memory, so use the Processing Notes field and/or use the Check Process of Event UI
action link to troubleshoot.
• If you change a rule/transform that has existing mapping rules, you should review and retest with events
that are either real or simulated.
• Establish a consistent naming convention. A common convention is: <customer acronym>.<Event
Source>.<Description>. For example, ACME.OEM.Normalize
• Use the Order field to control which Event Rule runs if two Event Rules have similar conditions set.
Construct Event Rules using these guidelines
Table 390: Effective rules should be written to achieve:
Desired result Required activity
Effective de-duplication and Populate the Source, Node, Type, Resource, Metric Name fields.
enabling efficient parallel
event processing
CI binding • Bind to host - by populating the Node field and optionally CI
identifiers.
• Binding to application and / or device – by populating the CI
type field and the Additional Info fields.

Desired result Required activity
Alert Correlation, using Populate the Resource and Metric Name fields.
Service Analytics
Note: If CI is also bound, Alert Correlation is improved.
Event Mapping rules
• Ensure that the From field value exactly matches a string in the JSON in the additional_info field. This
matching happens when a rule has been configured based on information in a MIB file. However, if
the MIB file is not uploaded, the JSON for the SNMP trap then shows varbinds (variable binding) with
dotted names, instead of the translated name in the MIB. The event field mapping rule then fails to be
applied.
• Establish a consistent naming convention. A common convention is: <Customer acronym>.<Event
Source>.<Mapping target>. For example, ACME.OEM.Severity.
De-Duplication
• The message_key field is used for De-Duplication. If reliable message key values are not provided with
the source event, it is important to have a well-defined plan for constructing these identifiers.
• If the message key is not defined, then the message key is <Source + Node + Type + Resource +
Metric Name> .
• The guideline is to have the event source populate the above five fields out-of-the-box (OOB), and
populate the message key. This enables a better distribution of event processing among instance
workers and nodes.
• If the source event does not have values for these fields, make sure to populate them using transform
rules. This does not affect event processing, but is used for de-duplication.
CI Binding
• Where possible, always attempt to bind an alert to a CI.
Note: Alerts are bound to CIs, not events.

• To bind a host, machine or any device with an IP, the guideline is to populate the event Node field with
a unique host name, FQDN, IP or MAC address. If other identifiers are necessary to identify a host,
then populate the ci_identifiers field with JSON that contains the CMDB field name and value to perform
the match.
Note: This has to be populated from the source before the event is inserted.
• The primary binding strategy is to use the Node field. If the Node field is not pre-populated in the event,
it can be populated using Event Rules.
Alert Rules
• A scheduled job applies Alert Rules to new Alerts every 11 seconds. If an Alert Rule does not
immediately start, allow 10–15 seconds before you start troubleshooting.

• Use the Order field to control which Alert Rule runs if two Alert Rules have similar conditions set.
Task templates
• Create a user called Event Management (or a similar name) so that the Created by field in a task
template (for example, Incident) can be set to indicate that Event Management was the source of the
task.
• To perform any dynamic value assignment or to override OOB dynamic value assignment, use the
EvtMgmtCustomIncidentPopulator script include.
Remediation
• Always set orchestration workflow properties to the Remediation Task [em_remediation_task] table.
• Use ECC Queue and Workflow > Live Workflow > All Contexts to find more detailed information on
remediation activities.
Services and Dashboard
• Use Service Groups to group business services into logical groups to reduce the number of services
displayed on the Service Health dashboard.
• Import manually built service maps. For a description of the conversion process, see Import a business
service as a manual service.
Performance
Enable multi-node in production environments and set values based on the size of the deployment and
expected event rate.
Operational Metric collector logs and files
The Operational Metric collector logs and files are located under the path $(MID_SERVER_DIR)/agent.
Use these logs and files for troubleshooting and monitoring purposes.
Table 391: Location of Operational Metric collector logs and files:
Log or file Path
PowerShell metric collector log file Logs/retrieve_metrics{connector instance ID}.log

PowerShell output file work/metrics/metrics_output_{connector instance
ID}.txt
PowerShell input file work/metrics/parameters_{connector instance
ID}.txt
The performance of Operational Metrics can be checked in the MID Server log file when the mid.log.level
MID Server parameter is in debug mode.

Operational Metrics performance numbers are available in the sa_performance_statistics table. To display
the performance numbers, filter the Performance Statistics list for Metric Collector.
Add custom fields to an event
Additional fields should be included in the Additional info field of the event. Additional fields should not be
added to an event by adding a custom field to the event table [em_event]. For more information about how
to include additional fields in events, see Custom alert fields on page 931.
Administer events
An event is a notification from one or more monitoring tools that indicate something of interest has
occurred, such as a log message, warning, or error.
Event process flow
Event Management receives external events and generates alerts based on event and alert rules. Events
can be sent directly to your instance using an email server, script, SNMP trap, or a web service API. The
corresponding alerts appear on dashboards for tracking and remediation purposes.
As the computer, software, or service generates events, the MID Server polls the external event tracking
tool. The MID Server, which maintains a connection to Event Management, sends the information to your
instance for storage, processing, and remediation.
Event fields uniquely identify each event. Event Management uses this information to determine whether to
create a new alert or update an existing one. By default, each event is uniquely identified by the Message
Key. If the Message Key is not populated, a concatenation of the Source, Type, Node, Resource, and
Metric Name fields are used and these fields populate the Message Key. If identifiers are not supplied in
the event, you can add them with event rules.
The instance stores events in the Event [em-event] table and attempts to generate alerts based on pre-
defined rules and event mappings. Regardless of whether an alert generates, the original event is always
available for review and remediation. Alerts then generate according to the following process flow.
1. Find the best matching event rule for an event. If the source of the event matches the source specified
in an existing rule, then a rule is matched. Also, if the event matches the optional rule Filter and the
event additional_info value matches the rule Additional Information filter. A rule without any filter
is ignored, for example the source filter is missing or the Additional Information filter is missing. If
multiple rules are defined for the same type of event, use the rule Order to determine the order of rule
application.
• If the rule Ignore check box is selected, no alert generates. However, the event is still available for
review and remediation.
• If the Transform check box is selected, apply the transforms. If transform compose parameters are
also set, apply additional content to display to the user in the alert.
• When the Threshold check box is selected, accumulate all events until the threshold is met.
Generate a single alert for the events.
2. Search for an event field mapping even if there was no event rule. If an event field mapping is found,
apply the mapping information. If the event has no severity after the event transformations, retain the
event for reference purposes and do not generate an alert.
3. Search the Alert [em_alert] table for a matching message key. If a matching message key exists,
update the alert according to the event information. Otherwise, create an alert. Later, if another event

has the same matching key, associate the events under a single alert. If possible, bind the alert to a
specific CI for root cause analysis.


View events
Event Management tracks individual events to manage external systems. An event is a notification
from one or more monitoring tools that indicates that something of interest has occurred, such as a log
message, warning, or error. Event Management receives or pulls events from one or more external event
sources and stores them in the Event [em_event] table. Event Management provides a list of raw incoming
events.
Role required: evt_mgmt_admin, evt_mgmt_operator, evt_mgmt_user, or evt_mgmt_integration
The event monitoring tool generates the values of the source and resource fields. Event Management
implementers can define event types and register nodes to help uniquely identify incoming events and
create alerts for the specific needs of the enterprise. Event Management uses this information to determine
whether to create a new alert or update an existing one.
An event source may generate duplicate events with the same identifying information. For events with the
same identifying information, Event Management uses the time interval between events to determine if
events represent an existing issue or new issue.
Additional fields should be included in the Additional info field of the event. Do not add additional fields to
an event by adding a custom field to the event table [em_event]. For more information about how to include
additional fields in events, see Custom alert fields on page 931.
Note: Business rules that are written for alert tables [em_alert] must be highly efficient or they may
result in performance degradation.
1. Navigate to Event Management > All Events.

The All Events list displays the following columns.
Table 392: All Events list
Column Description Populated by
Time of event The time that the event External event monitoring
occurred, in the network tool
node time zone.
Source Event monitoring software External event monitoring
that generated the event, tool
such as SolarWinds or
SCOM. This field has a
maximum length of 100.
It is formerly known as
event_class.
Description Reason for event generation. External event monitoring
Shows extra details about an tool
issue. For example, a server
stack trace or details from
a monitoring tool. This field
has a maximum length of
4000.

Node Node name, fully qualified External event monitoring

domain name (FQDN), IP tool
address, or MAC address
that is associated with the
event, such as IBM-ASSET.
This field has a maximum
length of 100.
Type Pre-defined event type, such External event monitoring
as high CPU, which is used tool
to identify an event record.
This field has a maximum
length of 100.
Resource Node resource that is External event monitoring
relevant to the event. For tool
example, Disk C, CPU-1,
the name of a process, or
service. This field has a
Message Key Event unique identifier to External event monitoring
identify multiple events that tool
relate to the same alert.
If this value is empty, it is
generated from the Source,
Node, Type, and Resource
field values. This field has a
State The status of the event: Event
• Ready: Event has been

received and is waiting to
be processed.
• Queued: Event is queued
by the event processor
job.
• Processed: Event was
successfully processed.
• Error: Failure occurred
while processing the
event. For example, the
event collection method
or event Severity is
blank.
• Ignored: Value is not in
use.

Severity Mandatory. The options Event

are typically interpreted as
follows:
• Critical: Immediate
action is required. The
resource is either not
functional or critical
problems are imminent.
• Major: Major functionality
is severely impaired
or performance has
degraded.
• Minor: Partial, non-critical
loss of functionality or
performance degradation
occurred.
• Warning: Attention is
required, even though the
resource is still functional.
• Info: An alert is created.
The resource is still
functional.
• Clear: No action is
required. An alert is not
created from this event.
Existing alerts are closed.
Alert If an alert was created as A matching event rule or

a result of the event, this event field mapping
field contains the unique
ID that Event Management
generates to identify the
alert.
2. To review a single event, click the Time of event.

3. To review the rules that processed the event, click Check process of event.
Enable automatic CI creation

IT and Operational Metrics events pushed from specified sources can automatically create CIs.
The source being configured must be registered in the system.
You can configure from which source Event Management automatically creates CIs in cases where CIs
could not be found in the CMDB. For the registration of CIs that result from raw Operational Metric data,
see Create or configure metric type registration on page 1046.
1. In the application navigation filter, enter sa_metric_registration.list.
Existing registrations are displayed.
2. Configure an existing registration or click New.

Column Description
Source Specify the name of the source exactly as it

appears in the Source field of the event.
Registration Mode Not relevant to the creation of CIs that do
not result from raw Operational Metrics data.
Specify None (default).
For CIs that do result from raw Operational
Metrics data, see Create or configure metric
type registration on page 1046.
Type default mode Not relevant to the creation of CIs that do

not result from raw Operational Metrics data.
Specify None (default). For
CIs that do result from raw Operational
Metrics data, see Create or configure metric
type registration on page 1046.
Generate Missing CIs Select to create CIs automatically.
3. Click Submit.
Event collection configuration

Event Management receives external events via an event collector or script. If you are using a script to
collect events, no configuration is required. All other methods of collecting events require configuration.
After event collection configuration, Event Management can collect events via the MID Server, SNMP trap,
or email.
Event field format for event collection

Event Management requires all events to use a standard form, regardless of how they arrive at the
instance.
Table 393: Event fields
Name Description
em_event.source Mandatory. Event monitoring software that

generated the event, such as SolarWinds or
SCOM. This field has a maximum length of 100.
It is formerly known as event_class.
em_event.node Recommended. Node name, fully qualified
domain name (FQDN), IP address, or MAC
address that is associated with the event, such
as IBM-ASSET. This field has a maximum length
of 100.
em_event.type Optional. Pre-defined event type, such as high
CPU, which is used to identify an event record.
This field has a maximum length of 100.

Name Description
em_event.resource Recommended. Node resource that is relevant

to the event. For example, Disk C, CPU-1, the
name of a process, or service. This field has a
em_event.event_class If the em_event.node field is not specified, it is
mandatory for alerts to be created automatically.
Values for the em_event.event_class field
originate from either the source generating the
events or by event rule. Name of the machine or
software that generated the event. For example,
SolarWinds on 10.22.33.44. Corresponding field
display name is Source Instance.
em_event.ci_type Recommended. JSON string that
represents a configuration item.
For example, {"name":"SAP
ORA01","type":"Oracle"}. CI identifier
that generated the event appears in the
Additional information field. This field has a
em_event.message_key Recommended. Event unique identifier to
identify multiple events that relate to the same
alert. If this value is empty, it is generated from
the Source, Node, Type, and Resource field
values. This field has a maximum length of 1024.
em_event.severity Mandatory. Event severity options are:
• Critical: Immediate action is required. The
resource is either not functional or critical
• Major: Major functionality is severely
impaired or performance has degraded.
• Minor: Partial, non-critical loss of functionality
or performance degradation occurred.
• Warning: Attention is required, even though
the resource is still functional.
• Clear: No action is required. An alert is not
created from this event. Existing alerts are
closed.
• Info: An alert is created. The resource is still
functional.
em_event.time_of_event Mandatory. Time that the event occurred in the

source system. This field is a GlideDateTime
field in UTC or GMT format. This field has a

Name Description
em_event.state Current processing state of the event:

• Ready: Event has been received and is
waiting to be processed.
• Queued: Event is queued by the event
processor job.
• Processed: Event was successfully
processed.
• Error: Failure occurred while processing
the event. For example, the event collection
method or event Severity is blank.
• Ignored: Value is not in use.
em_event.alert If an alert was created as a result of the event,

this field contains the unique ID that Event
Management generates to identify the alert.
em_event.description Mandatory. Reason for event generation. Shows
extra details about an issue. For example, a
server stack trace or details from a monitoring
tool. This field has a maximum length of 4000.
em_event.additional_info Optional. A JSON string that gives more
information about the event. The JSON data
is supported for String values only, other
value types are not supported. Numbers must
be converted to String values by enclosing
them in double quotes, for example, this
value is not supported: {"CPU":100 } while
this value is supported: {"CPU":"100"}.
Another example of a valid JSON string
is: {"evtComponent":"Microsoft-Windows-
WindowsUpdateClient","evtMessage":"Installation
Failure: Windows failed. Error 0x80070490"}.
This information can be used for third-party
integration or other post-alert processing. Values
in the Additional information field of an Event
that are not in JSON format are normalized to
JSON format when the event is processed. For
example, assume that the following plain text is
in the Additional information field “Connection
instance is successful”. When the event is
processed, all this plain text becomes one JSON
string and might not be useful within an alert. In
the resultant alert, this string is in the Additional
information field in JSON format, containing the
data: {“additional_content”: “Connection instance
is successful"}.
em_event.resolution_state Optional. Event state from the event source is
either Closed or empty. Closed event state
closes corresponding alerts. If the field is empty,
the resolution on corresponding alerts is still
pending.

Event collection via MID Server

Configure connector instances to use script instructions that enable the MID Server to connect to external
servers to obtain event information.
Connector definitions are script instructions that enable the MID Server to connect to external servers to
obtain event information.
Use one connector instance for each type of event server that sends events via a MID Server. You can
configure connector instances to use the default connector definitions for supported event sources.
Alternatively, you can create a custom definition that enables the MID Server to run a script for event
collection.
Events are collected from external servers using a pull operation. The schedule for the pull interval is set
in the Schedule field of the connector instance. Users of the external servers must have read permission.
However, if the connector instance is also configured to be bi-directional, the external server users must
also have write permission. After configuring the connector instance, use the Test connector to verify the
connection with the external source. Thereafter, set the connector instance to Active and events start to be
received from the external server according to the pull interval schedule.
Table 394: Default connector definitions
Connector definition Description
HPOM Provides connectivity to HP Operations Manager.

Hyperic Provides connectivity to VMware vRealize Hyperic servers.
IBM Netcool Provides connectivity to an IBM Netcool/OMNIbus ObjectServers
and Impact Servers.
SCOM Provides connectivity to Microsoft System Center Operations
Manager (SCOM).
SolarWinds Provides connectivity to:
• SolarWinds Service & Application Monitor (SAM)
• Network Performance Monitor (NPM)
vRealize Provides connectivity to VMware vRealize Operations.

Zabbix Provides connectivity to Zabbix servers.
Connector instances
Connector instances use script instructions that enable the MID Server to connect to external servers to
obtain event information. Each connector instance is specific to an event source vendor.
Configure a connector instance
Configure a connector instance to schedule the frequency of event collection.
Before starting this procedure:
• Locate or define a connector definition
• Create the credentials to connect to the event source.
• If the connector instance is to be used for the collection of Operational Metrics, the ITOA Metric
Management plugin must be activated.

You can use a connector instance to control the location and manner in which events arrive from external
sources. You can optionally select to collect Operational Metrics information from the external sources that
you are connecting to. The Operational Metrics feature is for the investigation of alert root causes, analysis
of trends, threshold definitions, and anomaly predictions. You can run a test to confirm that connector
instance parameters let the MID Server receive events from a supported external event source to the
Event [em_event] table. The test also confirms:
• The MID Server is running.
• The host is running on the IP address that is in the Host IP field.
• Both the MID Server and the host are running in the same domain.
• The connector instance values fields are valid.
• A connection can be made to SCOM, using API, to retrieve events.
1. Navigate to Event Management > Connectors > Connector Instances.

2. Click New.
Table 395: Connector Instance Form
Field Description
Name A unique name for the connector instance

record, such as the name of event source
host.
Host IP The IP address of the event source
host. The system uses this IP address
to select the appropriate MID Server for
communicating with the event source host.
Credential The record from the Credentials
[discovery_credentials] table containing
valid credentials to the event source host.
Schedule (seconds) The frequency in seconds that the system
checks for new events from the external
event source. This value cannot be lower
than the minimum schedule property,
which by default is 120 seconds. For more
information, see Properties installed with
Event Management on page 833 .
Description Any optional information that the
administrator wants to use to identify this
record.

Field Description
Connector definition The vendor and protocol used to gather

events from the external event source.
Select the connector definition that matches
the source of external events. The default
options are:
• HPOM
• Hyperic
• IBM Netcool
• SCOM
• SolarWinds
• vRealize
• Zabbix
Active Select this check box to enable pulling

events from this external event source.
Do not select this check box until after you
test the connection between the MID Server
and the connector.
Last event signature The identifier of the last event processed

from this external event source. The system
uses the event signature to determine what
events to import on the next run.
Last run time The date and time of the most recent
event import. The value of this field is
automatically populated.
Last run status The status of the last import. The value of
this field is automatically populated.
• None - A valid connection has not yet
been established.
• Success - A successful connection was
established.
• Error - A connection was established.
However the external event source was
not updated.

Field Description
Bi-directional Select to invoke the bi-directional option.

This option is available only when the
specified connector definition has been
configured with bi-directional values.
When selected, this option enables the
bi-directional exchange of values to-and-
from the external event source. The Last
bi-directional status option displays only
when this option is selected.
Note: This feature is not supported

on a MID Server that is installed in
a directory that has a space in its
path.
Last bi-directional status The value of this field is automatically

populated. The status values are:
• None - A valid connection has not yet
been established.
established.
However the external event source was
not updated.
Metrics collection Select to enable the collection of

Operational Metrics.
Note:
• The metrics connector supports
working against the SCOM
database (MSSQL) that is
configured to work with SSL.
• This feature is not supported on
a MID Server that is installed in
a directory that has a space in its
path.
Metrics collection schedule (seconds) The time, in seconds, to repeat the

Operational Metrics collection scheduled
job.
This option displays only when the Metrics
collection option is selected.
Last metrics collection status Status of the Operational Metrics

collection activity. The value of this field is
automatically populated.

Field Description
Metrics collection running When selected, indicates that the

Operational Metrics collection is running.
Last error message Last error message received by the
connector. If the test connector fails, an
error message is displayed in this field.
Connector Instance Values The related list containing connection
parameters for the event source host. The
list of parameters depends on the selected
connector definition.

5. Click Test connector to verify that the MID Server can communicate with the external server host.
6. If the test fails, follow the instructions on the page to correct the problem and then do another test. The
description of the reason for failure is shown in the MID Server log, according to the type of error, such
as, Events, Metrics, or Bi-Directional.
7. After a successful test, select the Active check box and then click Update.
8. Confirm that Event Management processes events using this connector instance by manually creating
an event.
Connector definitions
Each connector definition is specific to an event source vendor. The connector definition specifies the MID
Server script include that pulls events from the external event source. In addition, the connector definition
specifies what connector instance value parameters are needed to connect to the external event source
host.
Create a connector definition
Create a connector definition to support a new external event source from which to receive events.
Write custom JavaScript code that accomplishes these actions:
• Connect to an event monitoring tool.
• Retrieve events from an event monitoring tool.
• Send events to the Event [em_event] table using the web service API.
Role required: em_mgmt_operator or evt_mgmt_admin

This procedure automatically creates a JavaScript code file using the name that you enter in the Name
field as the filename.
1. Navigate to Event Management > Connectors > Connector Definitions.
2. Click New.
3. In the Name field, type a descriptive name for the connector definition.
4. In the Script type field, select Javascript.
6. The Javascript to run field is automatically populated with the name of the JavaScript template
file. You can optionally replace the default JavaScript with your JavaScript code. To edit the default
JavaScript file, click the exclamation symbol to the right of the JavaScript file name and follow these
steps:
a) Specify the information required for the testConnection function. This function tests the
connector definition to verify if the connection to the target is valid.

b) Specify the information required for the execute function. This function retrieves the information
from the external source.
Table 396: Connector Definition form
Field Description
Default schedule Mandatory. The number of seconds

between attempts to receive events.
Bi-directional Specify to enable the external monitoring
system to be updated if the alert is changed.
There is default implementation for SCOM.
Alert field identifier Mandatory. Specify the alert field that, if
changed manually, causes the external
monitoring system to be updated.
Note: This field only appears if Bi-

directional is selected.
Collect metrics Select to enable the collection of metrics.
Note: Metrics are collected only for

SCOM external event sources.
Metrics collection default schedule Specify the number of seconds of

(seconds) information that must be collected. The
default is 10 seconds.
Note: This field only appears if

Collect metrics is selected.
Connector Parameters Specify the parameters to enable

communication with an event server.
Connector Definition to MID Server The MID Server name to process events
Capabilities from the event server. If not specified, an
available MID Server is used.
8. Click Submit.
Create a custom connector

A custom connector requires a script, connector definition, and connector instance to retrieve events on
behalf of an event source.
A custom connector script can make remote API calls for a new event source to send events to the
ServiceNow instance. You can create a script, and then add it as part of a new Event Management
connector definition and connector instance. The custom code that accomplishes these actions must:
• Connect to an event monitoring tool.
• Retrieve events from an event monitoring tool.

• Send events to the Event [em_event] table using a web service API. See .
1. Create a custom MID Server script include. This example uses Groovy (deprecated). In place of a
script include in Groovy, it is recommended to use JavaScript.
a) Implement these methods:
• @Override OperationStatus testConnection()
• @Override OperationStatus execute()
b) Design the class to extend the ThirdPartyConnector.
public class HypericConnector extends ThirdPartyConnector
c) Import platform classes for event creation, sending, logging, and third-party connector base
classes.
package com.service_now.mid.probe.tpcon.test
import com.glide.util.Log
import com.service_now.mid.MIDServer
import com.service_now.mid.probe.event.IEventSender
import com.service_now.mid.probe.event.SNEventSender
import com.service_now.mid.probe.tpcon.OperationStatus
import com.service_now.mid.probe.tpcon.OperationStatusType
import com.service_now.mid.probe.tpcon.ThirdPartyConnector
import com.snc.commons.eventmgmt.Event
d) Connect to the data collector, such as SCOM or VMware vRealize Hyperic (Hyperic), with the API
provided by the collector. Use the context parameters to set the event field values that came from
a connector instance.
def authString = (context.username +

':'+ context.password).getBytes().encodeBase64().toString()
def urlStr = 'http://'+context.host + ':' + context.parameters.port +
'/' + apiFunction
e) Implement the execute function in the script. It reads events from the connector using its API to
create Event objects and send them to the ServiceNow instance. For example:
GPathResult alertsResponse1 = readAlerts('hqu/hqapi1/alert/find.hqu?

begin=' + lastSignatureStr +
'&end='+ tillStr
+'&count=1000000&severity=1&inEscalation=false&notFixed=false');
Event event = new Event()

event.emsSystem = context.name
event.source = "Hyperic"
event.description = it.@reason
event.type = it.@name
...
IEventSender eventSender = MIDServer.getSingleton(SNEventSender.class)
for (Event event : list) {
eventSender.sendEvent(event)
}

2. Navigate to MID Server > MID Server Script Files and create a script. Specify the Parent field as
Groovy, complete the form as appropriate, and then click Submit.
3. Navigate to Event Management > Connector Definitions and create a connector definition.
4. In the Groovy script to run field, select the MID Server script file, complete the form as appropriate.
In addition to username or host, you can add any other parameter, for example, port, and then click
Submit.
5. Navigate to Event Management > Connector Instances and create a connector instance.
6. In the Connector definition field, select the connector definition, complete the form as appropriate,
and then click Submit.
7. To confirm or debug the script, use debug printouts from Groovy to the MID Server log.
8. To monitor incoming events using the custom connector instance, navigate to ECC > Queue and filter
on ConnectorProbe.
Create a custom pull metric connector

A custom pull metric connector requires a script, connector definition, and connector instance to retrieve
raw metric information from an external source.
Ensure that the ITOM Metric Management plugin is activated.
The custom metric connector makes remote API calls to an external source to get raw metric data and then
write/send that data to the instance (using the handleMetric() function).
Process flow to collect raw metric information from a custom metric connector instance:
• Create a custom metric connector script to collect raw metric information.
• Add the custom metric connector script to a new Event Management connector definition in the
JavaScript to run field. The connector definition uses the script to enable the MID Server to connect to
the external server to obtain metric raw data.
• Define a custom metric connector instance. The custom connector definition is specified in this
connector instance.
• The Event Management – Connector execution job job executes all connectors in “running mode”
and sends a message to the MID Server on the ECC queue.
• The MID Server executes the custom metric connector script.
• The custom metric connector script collects raw metric information that it adds to be processed on the
MID Server.
• The custom metric connector script returns results to the instance.
• The Event Management – Connector business rule on the ecc_queue table updates the custom
metric connector instance with the results, such as, status, error, and signature.
The custom metric connector script must:
Note: You can use the MetricCollector MID Server script include that is provided in the base
instance as an example for these items.
• Be written in JavaScript.
• In the connector definition, be specified in the JavaScript to run field.
• Include the retrieveKpi() method. The connector framework uses the retrieveKpi() method to
collect metrics. In this method, include the logic for reading data from the external source system and
transform to the RawMetric object (in ServiceNow format).
• Read the required connector instance parameters defined in the probe object.
• Collect raw metric data from the metric source.
• Prepare a RawMetric record. The RawMetric object can be created by passing these attributes in the
constructor:

Table 397: RawMetric record description
Element Description
metricType Name of the metric.

metricTypeId SysId of the metric, if available. Otherwise pass the value
null
resource Information about the resource for which metric data is being
collected.
node IP, FQDN, name of the CI, or host. For example, the name of
the Linux server where the disks are installed.
ci SysId of the CI if available. Otherwise use the provided
information as part of ciIdentifier for the binding.
value Value of the metric.
timestamp Epoch timestamp of the metric in milliseconds.
ciIdentifier List of key-value pairs to identify the CI.
source Data source that is monitoring the metric type.
sourceInstance Source instance.
monitoredObjType Monitored Object Type
• Use the handleMetric function to add the raw metric information from the RawMetric record to be
processed in the MID Server. To get access to the MetricHandle object, make the following call to
the MetricCollector:
var metricHandler = MetricFactory.getMetricHandler()
Then for each RawMetric object execute:
metricHandler.handleMetric(rawMetric)
• Write error logs to the MID Server log using ms.log. You can use the debugLog() function in the
MetricCollector script as an example to write debug messages.
The custom script should return this data:

Element Description
Status Success or Failure

error_message Error Message
(This element displays
only if the status is
Failure)
last_kpi_signature last metric time in milliseconds

This instruction is used for the next query to start from this time. Use
any signature that you want to save to retrieve the next metric. This
value is updated according to the metric collector Last signature field.
metric_source Your source

metric_count Count of retrieved metrics

Element Description
metric_duration Duration time of the retrieve metrics process in

milliseconds
Test connector requirements - Implement the testConnection() function. The function returns either
Success or Failure. If Failure, check the writeError() function for a failure message. You can also
check the sa_performance_statistics table to see that metrics are being received. For an example of test
connector script, see the SolarWindsJS Mid Server script include.
Metric types that the connector collects:
• Use set active: true/false to define the types you want to collect.
• In the metric collector script use HandleTypes.getActiveTypesForSql("Your Source"):
for a comma-separated list of supported types. If the type is not active, the type is not returned. If the
metric source is in registration mode, not type is retrieved. In registration mode, all types are
collected to be able to add any missing types.
• You can collect all metrics types. The metricHandler.handleMetric() function filters the
types that are collected. However, using only active types in the query commands should improve
performance.
1. Create a custom MID Server script include. As an example, use the MetricCollector script that is
provided with the base instance.
2. Navigate to MID Server > Script Includes and click New.
3. In the Name field, specify the name.
4. Select Active.
5. In the Script field, enter the custom metric collector script. Use JavaScript to compose this script.
6. Complete the form as appropriate, and then click Submit.
7. Configure a dedicated MID Server. For more information, see Configure a MID Server for Operational
Metrics on page 1034.
8. Navigate to Event Management > Event Connectors (Pull) > Connector Definitions and click New.
a) In the Name field, specify the name.
b) Select the Collect metrics option.
c) Right-click the form header and select Save.
d) In the JavaScript to run field, select the newly created custom MID Server script file.
9. In the Connector Parameters area, specify the parameters for all additional information needed for
the connector, for example, topics that you want to subscribe to.
10. In the Connector Definition to MID Server Capabilities area, specify the details of the MID Server.
Use a dedicated MID Server with ServiceAnalytics as a supported application, and with the ITOA
Metrics capability. For more information, see Configure a MID Server for Operational Metrics.
11. Complete the form as required, then click Submit.
12. Navigate to Event Management > Event Connectors (Pull) > Connector Instances and click New.
Note: Remember to specify values for parameters that you defined.
a) In the Name field, specify the name.

b) In the Connector definition field, select the newly created custom metric connector definition.
c) Select the Metrics collection option.

d) In the Metrics collection schedule field, specify the number of seconds for the metrics collection
schedule job to wait before it repeats.
e) Right-click the form header and select Save.
f) Complete the form as required, then click Save.
13. Click Test Connector to verify the connection between the MID Server and the custom metric
connector.
14. Click Update.
• To confirm or debug the custom metric connector script, use debug printouts to the MID Server log.
• To monitor incoming events using the custom metric connector instance, navigate to ECC > Queue and
filter on ConnectorProbe.
Custom connector code sample

The code sample used in this connector definition demonstrates how to manage events using web service
API.
Note: The sample connector code is not updated automatically. Check the connector code on the
instance from time-to-time as it might be updated.
You can use the following code sample to create a JavaScript connector for receiving events from a
SolarWinds external source.
var SolarWindsJS = Class.create();
var SUCCESS =
Packages.com.service_now.mid.probe.tpcon.OperationStatusType.SUCCESS;
var FAILURE =
Packages.com.service_now.mid.probe.tpcon.OperationStatusType.FAILURE;
var Event = Packages.com.snc.commons.eventmgmt.Event;
var SNEventSenderProvider =
Packages.com.service_now.mid.probe.event.SNEventSenderProvider;
var HTTPRequest = Packages.com.glide.communications.HTTPRequest;
var SOLAR_WINDS = "SolarWinds";

var MAX_EVENTS_TO_FETCH = 3000;
SolarWindsJS.prototype = Object.extendsObject(AProbe, {
// test the connection with SolarWind server

testConnection : function() {
ms.log("Solarwinds testing connection");
var retVal = {};
try {
var query = 'SELECT TOP 10 NodeID FROM Orion.Nodes';
var response = this.getResponse(query);
ms.log('SolarWindJS Connector Test Connection response:' +

response.getBody());
ms.log('result:' + response.getStatusCode());
if (response.getStatusCode() == 200)

retVal['status'] = "" + SUCCESS.toString();

else
retVal['status'] = "" + FAILURE.toString();
} catch (e) {
ms.log("Failed to connect to Solarwinds");
ms.log(e);
retVal['status'] = FAILURE.toString();
}
ms.log("SolarWindJS Connector testConnection " + retVal['status'] );
return retVal;
},
execute: function() {
ms.log("SolarWindJS Connector: execute connection ...");
var retVal = {};
var lastSignature = this.probe.getParameter("last_event");
var events = this.getEvents(lastSignature);

if (events == null) {
retVal['status'] = FAILURE.toString();
return retVal;
}
// send all events

var sender = SNEventSenderProvider.getEventSender();
var i = 0;
for (; i< events.length; i++) {
if (events[i]) {
sender.sendEvent(events[i]);
}
}
retVal['status'] = SUCCESS.toString();
if (events.length > 0) {
// the result is sorted, but the sort order can differ.
Therefore
// the last signature is either on the first or the last event
var firstEventSignature = events[0].getField("swEventId");
var lastEventSignature =
events[events.length-1].getField("swEventId");
if (firstEventSignature >= lastEventSignature)

retVal['last_event'] = firstEventSignature;
else
retVal['last_event'] = lastEventSignature;
}
ms.log("SolarWindJS Connector: sent " + events.length +

" events. Return to instance: status="+retVal['status'] +
" lastDiscoverySignature=" + retVal['last_event'] );
return retVal;
},

getResponse: function(query) {
var username = this.probe.getParameter("username");

var password = this.probe.getParameter("password");
var host = this.probe.getParameter("host");
var port = this.probe.getAdditionalParameter("port");
var url = 'https://'+host+':' + port + '/SolarWinds/

InformationService/v3/Json/Query?query='
+encodeURIComponent(query);
ms.log('SolarWindJS Connector URL: ' + url);

var request = new HTTPRequest(url);
request.setBasicAuth(username, password);
request.addHeader('Accept','application/json');
var response = request.get();
return response;
},
getEvents: function(latestTimestamp)
{
var query = "SELECT TOP " + MAX_EVENTS_TO_FETCH +

" EventID, EventTime, NetworkNode, NetObjectID, EventType,
Message, Acknowledged, " +
"NetObjectType, Timestamp FROM Orion.Events " +
"WHERE NetworkNode > 0 AND NetObjectID > 0 ";
if (latestTimestamp != null) {
query = query + "AND EventID > " + latestTimestamp + " order by
EventID asc ";
} else {
// if this is the first time just take maxEventsCount events
from the end
query = query + " order by EventID desc ";
}
var resultJson = this.getJSON(query);
if (resultJson == null)
return null;
var emsName = this.probe.getParameter("connector_name");

var events = [];
// if no events were found, return

if (resultJson.results.length === 0)
return events;
// init all maps with additional information for events

var eventTypes = this.getEventTypes();
var applications = this.getApplications();
var components = this.getComponents();
var nodes = this.getNodes();
if (eventTypes == null || applications == null || components == null

|| nodes == null) {

return null;
}
var i = 0;
for (; i<resultJson.results.length; i++) {
var event = Event();
if (resultJson.results[i].EventTime != null) {
// input is yyyy-MM-dd'T'HH:mm:ss.mmm. we are taking yyyy-

MM-dd HH:mm:ss
var stringToParse = resultJson.results[i].EventTime;
var dateStr = stringToParse.substr(0,10);
var timeStr = stringToParse.substr(11,8);
event.setTimeOfEvent(dateStr + " " + timeStr);
}
var component = components[resultJson.results[i].NetObjectID];

if (component != null) {
event.setMetricName(component[0]);
if (component[1] != null) {
var applicationName = applications[component[1]];
if (applicationName != null) {
event.setResource(applicationName);
}
}
}
// remove not ascii chars

var sanitizedMessage = resultJson.results[i].Message.replace(/[^
\x00-\x7F]/g, " ");
// replace \" with "

sanitizedMessage = sanitizedMessage.replace(/\\"/g, "\"");
event.setText(sanitizedMessage);
if (nodes[resultJson.results[i].NetworkNode] != null) {
var node = nodes[resultJson.results[i].NetworkNode];
event.setHostAddress(node[0]);
event.setField("hostname", node[1]);
event.setField("eventType", resultJson.results[i].EventType);
if (eventTypes[resultJson.results[i].EventType] != null)
event.setField("icon",
eventTypes[resultJson.results[i].EventType]);
event.setField("netObjectId",
resultJson.results[i].NetObjectID);
event.setField("swEventId", resultJson.results[i].EventID);
event.setField("networkNodeId",
resultJson.results[i].NetworkNode);
event.setSource(SOLAR_WINDS);
event.setEmsSystem(emsName);

event.setResolutionState("New");
// filter out events on first pull

if (latestTimestamp != null || !this.filterEvent(event)) {
events[i] = event;
}
}
return events;
},
filterEvent : function (event) {

var icon = String(event.getField("icon"));
if (icon === "Add" || icon === "Green" || icon === "Start") {
return true;
}
return false;
},
getEventTypes : function () {
var resultJson = this.getJSON(

"SELECT EventType, Name, Icon, NotifyMessage,NotifySubject FROM
Orion.EventTypes");
return null;
var resultMap = {};
var i = 0;
for (; i<resultJson.results.length; i++)
resultMap[resultJson.results[i].EventType] =
resultJson.results[i].Icon;
return resultMap;
},
getApplications : function () {
var resultJson = this.getJSON("SELECT ApplicationId, Name FROM

Orion.Apm.Application");
return null;
var resultMap = {};

var i = 0;
resultMap[resultJson.results[i].ApplicationId] =
resultJson.results[i].Name;
return resultMap;
},
getComponents : function () {
var resultJson =
this.getJSON("SELECT ComponentID, Name, applicationID FROM
Orion.Apm.Component");

return null;
var resultMap = {};

var i = 0;
for (; i< resultJson.results.length; i++)
resultMap[resultJson.results[i].ComponentID] =
[resultJson.results[i].Name,
resultJson.results[i].applicationID];
return resultMap;
},
getNodes : function () {
var resultJson = this.getJSON(

"SELECT NodeID, IPAddress, DNS FROM Orion.Nodes");
return null;
var resultMap = {};
var i = 0;
resultMap[resultJson.results[i].NodeID] =
[resultJson.results[i].IPAddress,
resultJson.results[i].DNS];
return resultMap;
},
getJSON : function (query) {
var response = this.getResponse(query);
if (response == null) {
ms.log("SolarWindJS Connector: Failed to bring data. Null
response");
return null;
}
if (response.getStatusCode() != 200) {
ms.log("SolarWindJS Connector Error Code: " +
response.getStatusCode());
return null;
}
var parser = new JSONParser();

var resultJson = parser.parse(response.getBody() );
ms.log("SolarWindJS Connector: Found " + resultJson.results.length +
" records");
return resultJson;
},
type: "SolarWindsJS"
});
Custom connector guidelines

You can improve the configuration settings of a custom connector that connects to an external source by
considering the following tips.
Best practice Details
Alert information collection Collect the required information about the alerts.
• Node – Identifier for host (IP/FQDN, mac, name).
• Resource – For example, disc, CPU.
• Message key – The default is
source&node&type&resource&metricName
• Severity – If one or more fields in the target monitor must be
mapped to ServiceNow severities.
• Resolution State – If the source monitor has closed alerts, the
alerts are closed in the ServiceNow instance.
• Type - Event type.
• Metric name - The name and description of the metric to which
the alert applies.
• Additional information – Any other information that might be
used to bind the alert to the CI or used for alert rules, metric
value, or alert ID in the target monitor.
Create ServiceNow events If an event must be created, ensure that you have the required
details.
To populate node, source, event class (ems system), resource,
message key, severity, state, type, metric name, additional
information and description
• Source – the name of the monitor
• Event class = ems system = the name of the connector instance
= this.probe.getParameter ("connector_name")
• Consider where you can cache information to avoid
unnecessary API calls.
Debugging Save the debugging information to ms.log. This requires

being logged in to the MID Server. An example of a ms.log is:
ms.log("Solarwinds testing connection")
To find the log, search in the MID Server for agent\logs
\agent0.log.0 file. If there is failure, search the log for more
information. The log must reveal the cause of the failure, for
example, missing DLLs files or incorrect credentials.

Execution • Differentiate between the first pull of events with the subsequent
events that are pulled. The first pull of events:
• Takes events that exist.
• Must be limited either in time or number of events that are
pulled.
• Must only pull open alerts.
• Use the main API to get all events data since last signature and
limit the number of events.
• Create ServiceNow events by parsing.
• Send all event using: var sender =
SNEventSenderProvider.getEventSender()
• Update the lastSignature timestamp.
• Fill the resultant record with the status.
Last signature Each time that events are pulled, all events are pulled with the time
of that the event occurred, which is >= last signature timestamp.
In cases where the last event arrives at the last signature time,
it is pulled repeatedly. To prevent this, ‘remember’ the last event
ID. Thereafter, when events are next pulled, exclude this event ID
if it is in the group of pulled events and its time of event remains
unchanged.
Parameters Determine which parameters are available and how to use them.
• For context parameters, such as, connector name, user
name, password, host, and last event signature. For example:
this.probe.getParameter("connector_name").
• For connector instance values. For example:
this.probe.getAdditionalParameter ("port").
Target monitor information Collect information about the target monitor.

collection
• APIs in use, for example, DB or web service.
• How to connect to the external source:
• Credentials.
• Parameters (for example, url, port, protocol).
• Required Jar or dll files needed to run commands on the MID
server.
Test connection Verify the connection with the monitor:

• A valid connection returns a SUCCESS status.
• Use the main API that returns alerts/events data without sending
data.
• Fill the result record with status information according to
the result of the connection test: retVal['status'] = "" +
SUCCESS.toString()/ FAILURE.toString(). Detailed failure
information must be saved to a log.

Time of event The Time of event is the time that the event occurred. Convert the
event time to GMT using the yyyy-MM-dd HH:mm:ss format.
Configure a default MID Server for connectors

You can set a default MID Server for connectors to ensure that there is always a MID Server available to
receive external events.
Role required: em_mgmt_operator
The default MID Server must have connectivity to all external event sources.
1. Enter sys_properties.list in the navigation filter to open the System Property [sys_properties]
table.
mid.server.connector_default Default MID Server for connectors

Determines the MID Server connectors to
use when no MID Server is specified. Must
match a MID Server name.
• Type: string
Note: You can reset the default MID Server by clearing the mid.server.connector_default
property or by updating the value of this property to a different MID Server. This property is not
automatically reset in all scenarios.
Configure event collection from HPOM

The HPOM connector instance requires configuration prior to receiving events from the HP Operations
Manager (HPOM).
2. Click New and create an HPOM connector instance with the following details:
Field Value
Name Specify a unique name for the HPOM connector instance.

Host IP Specify the HPOM IP address.
Credential Click in the Credential field. Select a credential from the list
or click the search icon. Either select the required credentials
from the list or click New and create the required credentials.
If you create the credentials, save them using a unique and
recognizable name, for example, HPOMOPS.
Schedule (seconds) The frequency in seconds that the system checks for new
events from HPOM.

Field Value
Description Type a description for the use of the HPOM event collection
instance.
Connector definition The vendor and protocol used to gather events from the
external event source. Select the HPOM connector definition.
Last error message The last error message is automatically updated.
Last run time The last run time value is automatically updated.
Last run status The last run time status is automatically updated.
MID Servers (MID Server Specify a MID Server that is up and is valid. You can configure
for Connectors section) several MID Servers. If the first is down, the next MID Server is
used. If that MID Server is not available, the next is selected,
and so on. MID Servers are sorted according to the order that
their details were entered into the MID Server for Connectors
section. If no MID Server is specified, an available MID Server
that has a matching IP range is used.

The connector instance values are added to the form and the parameters that are relevant to the
connector appear.
4. In the Connector Parameters section, specify the values of the mandatory HPOM parameters.
• driver. Specify the driver to be used to make the call. This driver is specific to the type of database
you are calling into.
• For an IBM DB2 Universal driver, specify: com.ibm.db2.jcc.DB2Driver
• For an Oracle driver, specify: oracle.jdbc.OracleDriver
• For a Microsoft SQL driver, specify: com.microsoft.sqlserver.jdbc.SQLServerDriver
• For a MySQL driver, specify: com.mysql.jdbc.Driver
• For a Sybase driver, specify: com.sybase.jdbc3.jdbc.SybDriver
• url. Specify a URL. The JDBC protocol uses a connection string to establish the authentication and
other parameters to establish a connection between the client and the database. Each database
has its own connection string format. In the following URLs, replace the variables, for example,
<username> and <password>, with your values.
• For an IBM DB2 Universal URL, specify: [jdbc:db2://sysmvs1.stl.ibm.com:<port number>/
<database name>:user=<username>;password=<password>]
For example: jdbc:db2://sysmvs1.stl.ibm.com:5021/regionsdb:user=example;password=wlrs21
• For an Oracle URL, specify: [jdbc:oracle:thin:@<IP address>:<port number>:<database name>]
For example: jdbc:oracle:thin:@172.31.255.255:4028:OracleMain
• For a Microsoft SQL URL, specify: [jdbc:sqlserver://<IP
address>;user=<username>;password=<password>]
For example: jdbc:sqlserver://localhost;user=example;password=w3lrs2
• For a MySQL URL, specify: [jdbc:mysql://<IP address>/database?
user=<username>;password=<password>]
For example: jdbc:mysql://localhost/database?user=example;password=65wlrs
• For a Sybase URL, specify: [jdbc:sybase:Tds:<IP address>:<port number>/<database name>?
user=<username>;password=<password>]

For example: jdbc:sybase:Tds:172.31.255.255:4100/SYBMAIN?

user=example;password=wlrs1m
5. Use a network tool, such as ping, to verify that the HPOM server is running and the IP address
matches the value in the Host IP field.
6. Click Test connector to verify the connection between the MID Server and the HPOM connector.
7. If the test fails, follow the instructions on the page to correct the problem and then run another test.
Tip: Use a network tool, such as ping, to verify that the HPOM server is running and the IP
address matches the value in the Host IP field.
Configure event collection from VMware vRealize Hyperic

The Hyperic connector instance requires configuration prior to receiving events from the VMware vRealize
Hyperic (Hyperic) server.
2. Click New and create a Hyperic connector instance with the following details:
Field Value
Name Specify a unique name for the Hyperic connector
instance. Mandatory.
Host IP Specify the Hyperic IP address. Mandatory.
Credential In the Credentials form, click New and create the
required credentials. Save the credentials using
a unique and recognizable name, for example,
HypericOPS. Mandatory.
Schedule (seconds) The frequency in seconds that the system checks
for new events from Hyperic.
Description Type a description for the use of the Hyperic
event collection instance.
Connector definition The vendor and protocol used to gather events
from the external event source. Select the
Hyperic connector definition. Mandatory.
MID Servers (MID Server for Connectors section) Specify the MID Server that must run the Hyperic
connector instance. If not specified, an available
MID Server that has a matching IP range is used.
4. In the Connector Parameters section, specify the values of the mandatory Hyperic parameters.
a) port Default value 7080.
b) protocol Default value http.

5. Click Test connector to verify the connection between the MID Server and the Hyperic connector.
Tip: Use a network tool, such as ping, to verify that the Hyperic server is running and the IP
Alert collection from SCOM

Alerts from the Microsoft System Center Operations Manager (SCOM) are collected using the SCOM
connector instance.
Configure the SCOM connector instance
The SCOM connector instance requires configuration prior to receiving alerts and Operational Metric raw
data from the Microsoft System Center Operations Manager (SCOM).
Before starting this procedure, verify:
• That the required permissions, for example, local admin, to enable the MID Server to run PowerShell
are provided.
• The MID Server resides in the same domain as the SCOM server.
• The MID Server uses the same time zone as the SCOM server.
• The MID Server is running on Windows.
• The MID Server has .NET framework version 3.5.
• The MID Server service must run with a user having read-and-write access to the SCOM API.
• If Operational Metrics is selected, that the MID Server Operational Metric Manager Context is
configured. See Configure the Operational Metric extension on page 1036.
If Bi-directional is selected, ensure that:

• PowerShell version 3.0 is installed on Windows.
• As Windows authentication is used by the connector to access the SCOM API, the MID Server service
should be running with a user having read-and-write access to the SCOM API. Do this by ensuring that
the correct credentials are used:
1. In the local services, right-click the MID Server service and select Properties.
2. In the Log On tab, ensure that This account is selected with the details of the user in the Windows
domain having access to the SCOM API.
If Collection of metric data is selected, ensure that:

• PowerShell version 3.0 is installed on Windows.
• As Windows authentication is used by the connector to access the SCOM database
(OperationsManagerDW), the MID Server service should be running with a user having read access to
the SCOM database. Do this by ensuring that the correct credentials are used:
1. In the local services right-click the MID Server service and select Properties.
2. In the Log On tab, ensure that This account is selected with the details of the user in the Windows
domain having read access to the SCOM database.
Note: If the OperationsManagerDW database has been renamed, also change the database
name in the SCOMConnector.groovy MID Server Script as well as in the MetricCollector
script include.
• If you upgraded from an earlier release and a SCOM connector was defined:

1. Configure the Operational Metrics extension and assign it to the MID Server that is used to collect
events and Operational Metrics. See Configure the Operational Metric extension on page 1036.
2. Define the Log On user on the MID Server service, ensuring that This account is selected with the
details of the user in the Windows domain having read access to the SCOM database.
If you want to receive SCOM alerts, you can obtain the redistributable SCOM files from your SCOM
application. Add the files to the MID Server, and then configure a SCOM connector instance to collect the
alerts and Operational Metric raw data.
1. On the SCOM server, download the following files to a local computer.
Version and location SCOM path and library names
SCOM 2012R2 or SCOM 2012 or SCOM 2016 %ProgramFiles%\Microsoft System

Center 2012 R2 or 2012\Operations
Manager\Server\SDK Binaries
• Microsoft.EnterpriseManagement.Core.dll
• Microsoft.EnterpriseManagement.OperationsMana
• Microsoft.EnterpriseManagement.Runtime.dll
SCOM 2007 %ProgramFiles%\System Center

Operations Manager 2007\SDK
Binaries
Note: Do not append 2007 to the

Microsoft.EnterpriseManagement.OperationsM
file.
Note: To work with both SCOM 2012 and SCOM 2007 in your instance, before
uploading the following files to your instance, append .2012 to the end of the
filename Microsoft.EnterpriseManagement.OperationsManager.dll
that is found in the 2012 path and append .2007 to the end of the filename
Microsoft.EnterpriseManagement.OperationsManager.dll that
is found in the 2007 path. This enables the MID Server to load the applicable
dll when both SCOM versions are deployed. Do not append 2007 to the
Microsoft.EnterpriseManagement.OperationsManager.Common.dll file (for SCOM 2007).
2. Navigate to MID Server > JAR Files.

3. Click New and add a separate record for the SCOM version for each of the DLL files that you
downloaded from the SCOM server.
a) In the Name field, specify the SCOM version and an identifier to make the name unique, for
example 2012 1. If you are using SCOM 2007, specify 2007 as the version. For SCOM 2012,
specify 2012 as the version.
b) Click the paper clip icon in the form header and then attach one of the appropriate DLL files that
you downloaded.
c) Click Submit.
4. Repeat step 3, creating a separate record for each of the remaining DLL files. Ensure that you have a
unique identifier after the SCOM version for each file that you attach, for example 2012 2.


6. Click New and create a connector instance with the following details:
Field Value
Name Specify a unique name for the SCOM connector
instance.
Host IP Specify the SCOM IP address.
SCOMOPS.
for new events from SCOM Operations.
Description Type a description for the use of the SCOM event
collection instance.
from the external event source. Select the SCOM
connector definition.
Active Select this option only after running a successful
test.
Bi-directional Select to invoke the bi-directional option. This
option enables the bi-directional exchange of
values to-and-from the external event source.
The Last bi-directional status option displays
only when this option is selected.
Note: This feature is not supported on a

MID Server that is installed in a directory
that has a space in its path.
Last bi-directional status The value of this field is automatically populated.

The status values are:
• None - A valid connection has not yet been
established.
established.
However the external event source was not
updated.
Metrics collection Select to enable the collection of Operational

Metrics.
Note:

Field Value
• The metrics connector supports
working with the SCOM database
(MSSQL) that is configured to work
with SSL.
• This feature is not supported on
a MID Server that is installed in a
directory that has a space in its path.
Metrics collection schedule (seconds) The time, in seconds, to repeat the Operational
Metrics collection scheduled job.
Last metrics collection status Status of the Operational Metrics collection

activity. The value of this field is automatically
populated.
Last error message Last error message received by the connector.

If the test connector fails, an error message is
displayed in this field.
MID Servers (MID Server for Connectors section) Specify the MID Server that must run the SCOM
8. In the Connector Parameters section, specify the values of the mandatory SCOM parameters.
a) metric_chunk_size Default value 5000.
b) scom_date_format Default format M/d/yyyy/ h:mm:ss a
c) scom_initial_sync_in_days Default value 7.
d) scom_version It is mandatory to specify the SCOM version, either 2007 or 2012.
Note: If you are working with SCOM 2016, specify 2012 for the scom_version
parameter.

10. Click Test connector to verify the connection between the MID Server and the connector.
Tip: Use a network tool, such as ping, to verify that the SCOM server is running and the IP
Note:
The default binding rules that contain SCOM as the external source, that applies to IT alerts
and Operational Metric raw data, are the following SCOM Management Packs:

• All OS Management Packs

• MS SQL Server
• IIS
13. Restart the MID Server service to copy the files.
If bi-directional is configured, the bi-directional exchange of values to-and-from the

external event source is enabled.
These scenarios describe the out of the box bi-directional functionality for SCOM
connectors:
• When an alert is resolved in SCOM, it is auto-closed in ServiceNow. However, it is
updated irrespective of the bi-directional feature because during each collection cycle,
all alert changes are updated.
• When an alert is manually closed in ServiceNow, it is auto-closed in SCOM. If the alert
state is changed to Reopen, SCOM is also updated.
• When an incident is created and associated to an alert in ServiceNow, SCOM receives
the incident number as a ticket ID. However, the state of the incident is not available on
SCOM. Therefore when the incident is resolved in ServiceNow, SCOM is not updated
as the incident number remains the same. When the alert is associated with a new
incident, the new incident number is updated in SCOM.
Limit collected SCOM alerts to specific SCOM groups

Limit the collection of SCOM alerts to only those alerts that belong to the specified SCOM group.
1. Use the SCOM Authoring workspace and Operations console to define a SCOM group. Ensure that
the group contains the required computers or instances. For further information about SCOM groups,
see the SCOM documentation.
2. Create a role that has a scope of the SCOM group.
3. Add the new role to the SCOM user.
4. Assign the role to the user defined in the credentials given to the SCOM connector instance.
5. Remove all other roles from the user.
Only alerts from the specified SCOM group arrive at the instance.
Configure event collection from Netcool
The Netcool connector requires configuration prior to receiving events from IBM Netcool/OMNIbus Object
Servers and Impact Servers.
Download the jconn3.jar from http://www.java2s.com/Code/Jar/j/Downloadjconn3jar.htm.
To use the Netcool connector, configure a connector instance for the MID Server and add the
jconn3-1.0.jar file that contains the necessary Netcool Sybase jar file.
1. Navigate to MID Server > JAR Files.
2. Click New.
3. Fill in the Name and Description fields.
4. Attach the file that was uploaded in the Before you begin section:
a)
Click the attachments icon ( ).

b) Click Choose Files and navigate to the temporary download directory.

c) Select the jconn3.jar file and click Open.
d) Close the pop-up window to return to the form.
5. Click Submit.
Field Value
Name Specify a unique name for the Netcool connector
instance.
Host IP Specify the Netcool IP address.
NetcoolOPS.
for new events from Netcool.
Description Type a description for the use of the Netcool
from the external event source. Select the IBM
Netcool connector definition.
MID Servers (MID Server for Connectors section) Specify the MID Server that must run the Netcool
9. In the Connector Parameters section, specify the value of the mandatory Netcool parameter, url. Build
a URL using the provided format.
For example: jdbc:sybase:Tds:10.11.15.118:4100/NCOMS
Note: After updating the Host IP field, you must update the URL parameter, as it does not
update automatically.
10. Use a network tool, such as ping, to verify that the Netcool server is running and the IP address
matches the value in the Host IP field.
12. Click Test connector to verify the connection between the MID Server and the Netcool connector.
Tip: Use a network tool, such as ping, to verify that the Netcool server is running and the IP

Configure event collection from SolarWinds

The SolarWinds connector instance requires configuration prior to receiving events from the SolarWinds
server.
Role required: evt_mgmt_admin and evt_mgmt_integration
Note: The SolarWinds connector instance can import events from:

• SolarWinds Service & Application Monitor (SAM)
• Network Performance Monitor (NPM). The SolarWinds connector instance has been validated
on version NPM 12.

2. Click New and create a SolarWinds connector instance with the following details:
Field Value
Name Type a descriptive name for the SolarWinds
connector. Mandatory.
Host IP Specify the SolarWinds IP address. Mandatory.
Credential Select a credential that uses Basic Auth. The
format for the User name is domain\username.
Mandatory.
for new events from the SolarWinds server.
Description Type a description for the use of the SolarWinds
Connector Definition Select Solarwinds. Mandatory.
MID Servers (MID Server for Connectors section) For cases in which the connector cannot be
determined from the IP address range defined on
the MID Servers, such as in a multi-domain set
up, select the MID Server that is up and is valid
to run the SolarWinds connector instance. The
privileges that are required for the user account
that is used for the MID Server to collect events
from SolarWinds is that of evt_mgmt_integration.
4. In the Connector Parameters section, specify the value of the port parameter. Default value 17778.
5. Click Test connector to verify the connection between the MID Server and the SolarWinds connector.
Tip: Use a network tool, such as ping, to verify that the SolarWinds server is running and the
IP address matches the value in the Host IP field.

Configure event collection from VMware vRealize Operations

Configure the VMware vRealize Operations (vRealize) connector instance to receive events from the
vRealize Operations Log and Event Management servers.
Supported version: VMware vRealize Operations Manager version 6.1.0.3038036
2. Click New and create a vRealize Operations connector instance with the following details:
Field Value
Name Specify a unique name for the vRealize
Operations connector instance. Mandatory.
Host IP Specify the vRealize Operations IP address.
Mandatory.
vRealizeOPS. Mandatory.
for new events from vRealize Operations.
Description Type a description for the use of the vRealize
Operations connector.
from the external event source. Select the
vRealize connector definition. Mandatory.
MID Servers (MID Server for Connectors section) Specify a MID Server that is up and is valid. You
can configure several MID Servers. If the first is
down, the next MID Server is used. If that MID
Server is not available, the next is selected, and
so on. MID Servers are sorted according to the
order that their details were entered into the MID
Server for Connectors section. If no MID Server
is specified, an available MID Server that has a
matching IP range is used.
The connector instance values are added to the form and the parameters that are relevant to the
connector appear.
4. In the Connector Parameters section, specify the values of the mandatory vRealize Operations
parameters.
a) port Default value 443.
b) protocol Default value https.

5. Click Test connector to verify the connection between the MID Server and the vRealize Operations
connector.
Tip: Use a network tool, such as ping, to verify that the vRealize Operations server is running
and the IP address matches the value in the Host IP field.
7. After a successful test, select Active and then click Update.
Configure event collection from Zabbix

The Zabbix connector instance requires configuration prior to receiving alerts from the Zabbix server.
Field Value
Name Type a descriptive name for the connector.
Host IP Specify the Zabbix IP address.
Credential Select a credential that uses Basic Auth. The
format for the User name is domain\username.
Read-only permission is sufficient.
for new events from the Zabbix server.
Description Type a description for the use of the Zabbix event
collection instance.
Connector Definition Select Zabbix.
MID Servers (MID Server for Connectors section) For cases in which the connector cannot be
determined from the IP address range defined
on the MID Servers, such as in a multi-domain
set up, select the MID Server to run the Zabbix
connector instance.
The parameters that are relevant to the Zabbix connector appear.
4. In the Connector Instance Values section, specify the Zabbix values.
a) days from Specify the number of days that have passed for which events must be collected.
Default value 2 days. Note: The maximum number of past events that can be collected is 3,000.
The first time that this connector runs, the number of past events is counted in the past from the
current date. In subsequent runs, the 3,000 maximum number of past events collected is counted
from the last event that was collected.
b) port Default value 80.

6. Click Test Connector to verify the connection between the MID Server and the connector.

Tip: Use a network tool, such as ping, to verify that the SCOM server is running and the IP
Event collection via web service API

You can use a web service interface, supported by ServiceNow, that operates on the JSON object as the
data input and output format.
Role required: evt_mgmt_integration
Use these web service API's to insert records in the event table (em_event):
• Web service API to create multiple records with a single call https://<instancename>.service-
now.com/em_event.do?JSONv2&sysparm_action=insertMultiple
• Web service API to create one record for each single call https://<instancename>.service-
now.com/api/now/table/em_event
Do not add additional fields to an event by adding a custom field to the event table [em_event]. However,
additional fields should be included in the Additional information field of the event. For more information
about how to include additional fields in events, see Custom alert fields on page 931.
1. Send the request with these headers:
Parameter Type Description
Accept String The acceptable type for this

message.
The default value is
application/json.
Content-Type String The content type for this

message.
application/json.
POST String The request type is POST,

with one or more trailing
records.
2. One or more events in JSON format can be sent as the payload of the web service call. Event fields
that should be populated are:
Variable Description
Source The name of the event source type. For

example, SCOM or SolarWinds.
Source Instance (event_class) Specific instance of the source. For
example, SCOM 2012 on 10.20.30.40

node The node field should contain an identifier

for the Host (Server/Switch/Router/etc.) that
the event was triggered for. The value of the
node field can be can one of the following
identifiers of the Host:
• Name
• FQDN
• IP
• Mac Address
If it exists in the CMDB, this value is also

used to bind the event to the corresponding
ServiceNow CI.
resource If the event refers to a device, such as,
Disk, CPU, or Network Adapter, or to an
application or service running on a Host,
the name of the device or application must
be populated in this field. For example,
Disk C:\ or Nic 001 or Trade web
application.
metric_name Name of the metric that triggered the alert.
For example, Used Memory or Total CPU
utilization.
type The type of event. This type might be similar
to the metric_name field, but is used for
general grouping of event types.
message_key This value is used for deduplication of
events. For example, there might be two
events for the same CI, where one event
has CPU of 50% and the next event has
CPU of 99%. Where both events must be
mapped to the same ServiceNow alert, they
should have the same message key. The
field can be left empty, in which case the
field value defaults to source+node+type
+resource+metric_name. The message_key
should be populated only when there is a
better identifier than the default.
severity Severity of the event. ServiceNow values
for severity range from 1 – Critical to 5 –
Info, with the severity of 0 – Clear. Original
severity values should be sent as part of the
additional information.

additional_info This field is in JSON key/value format, and

is meant to contain any information that
might be of use to the user. It does not map
to a pre-defined ServiceNow event field.
Examples include IDs of objects in the event
source, event priority (if it is not the same as
severity), assignment group information, and
so on. Values in the Additional information
field of an Event that are not in JSON key/
value format are normalized to JSON format
when the event is processed.
time_of_event Time when the event occurred on the event
origin.
resolution_state Optional – To indicate that an event has
been resolved or no longer occurring, some
event monitors use ‘clear’ severity, while
other event monitors use a ‘close’ value for
severity. This field is used for those monitors
proffering the latter. Valid values are ‘New’
and ‘Closing’.
3. To create multiple records with a single call, trigger the event web service using the following url,
where the <instance name> variable is replaced with the name of the required instance:
https://<instance name>.service-now.com/em_event.do?
JSONv2&sysparm_action=insertMultiple
Example showing the payload for two events that are sent in a single web service call:
{ "records":
[
{
"source":"SCOM",
"event_class":"SCOM 2012 on scom.server.com",
"resource":"D:",
"node":"name.of.node.com",
"metric_name":"Percentage Logical Disk Free Space",
"type":"Disk space",
"severity":"4",
"description":"The disk D: on computer V-W2K8-abc.abc.com is running
out of disk space. The value that exceeded the threshold is 38% free
space.",
"additional_info":"{
'scom-severity':'Medium',
'metric-value':'38',
'os_type':'Windows.Server.2008'
}"
},
{
"source":"SCOM",
"resource":"MSSQL-database-name",
"node":"other.node.com",
"metric_name":"DB Allocated Size (MB)",
"type":"Database Storage",
"severity":"3",
"description":"High number of active connections for MSSQL-database-
name running on name.of.node.com. Active connections exceed 5000.",

'scom-severity':'High',
}"
}
]
}"
4. To create one record with a single call, trigger the event web service using the following URL, where
the <instance name> variable is replaced with the name of the required instance:
https://<instancename>.service-now.com/api/now/table/em_event
Note: Use of this URL is limited as far as the rate of events it can support.
Example showing the payload for one event that is sent in a single web service call:
{ "record":
[
{
"source":"SCOM",
"resource":"C:",
"node":"name.of.node.com",
"metric_name":"Percentage Logical Disk Free Space",
"type":"Disk space",
"severity":"4",
"description":"The disk C: on computer V-W2K8-dfg.dfg.com is running
out of disk space. The value that exceeded the threshold is 41% free
space.",
'scom-severity':'Medium',
}"
}
]
}"
Event collection via script

You can create a scripted integration with Event Management to push external events from monitoring
tools such as Icinga and Nagios. You can use the cURL command-line tool to send one or more events to
a ServiceNow instance.
For Mac, cURL is automatically available.
For Unix, Linux, or Windows, make sure that the cURL command-line tool is installed. You can download it
at http://curl.haxx.se/download.html.
For scripted integration, no configuration is required. If your monitoring tool is a supported event source,
you can instead select a connector and configure an instance to pull events using a MID Server. In either
case, the system uses a web service API to add events to the Event [em_event] table.
1. Use a text editor to create a shell (.sh) file with event records.
curl -v -H "Accept: application/json" -H "Content-Type: application/json"

-X POST --data "{
\"records\":
[

{
\"source\" : \"Simulated\",
\"node\" : \"nameofnode\" ,
\"type\" : \"High Virtual Memory\",
\"resource\" : \"C:\",
\"severity\" : \"5\",
\"description\" : \"Virtual memory usage exceeds 98%\",
\"ci_type\":\"cmdb_ci_app_server_tomcat\",
\"additional_info\":\"{"name":"My Airlines"}\"
},
{
\"source\" : \"Simulated\",
\"node\" : \"01.myairlines.com\" ,
\"type\" : \"High CPU Utilization\",
\"resource\" : \"D:\",
\"severity\" : \"5\",
\"description\" :
\"CPU on 01.my.com at 60%\"
}
]
}" -u myUserID:myPassword "https://my-instance.service-now.com/
em_event.do?JSONv2&sysparm_action=insertMultiple"
2. Use the -H option. For the POST parameter, start the data block with an open bracket and delimit the
data with backslashes. For example:
POST --data "{\"records\":[{\"source\" : [. . .]}"
Table 398: Header parameters for use with -H option
Parameter Type Description
Accept String The acceptable type for this

message.
application/json.
Content-Type String The content type for this

message.
application/json.
POST String The request type is POST

with one or more trailing
records.
3. Use the -u option and the instance URL with login credentials. For example:
-u myUserID:myPassword "https://my-instance.service-now.com/em_event.do?
JSONv2&sysparm_action=insertMultiple"
4. Test the scripted integration.

Event collection for SNMP traps

Event Management can process SNMP traps as events. In this configuration, a MID Server acts as a
collection endpoint for SNMP traps. Event Management can then periodically pull events from the MID
Server.
Before starting this procedure, confirm with your ServiceNow representative that the server and software
specifications for hosting the MID Server are met. Also confirm that the MID Server version matches the
ServiceNow instance version. For example, navigate to MID Server, click a Name, and confirm that the
Version is the same as the ServiceNow instance version.
Role required: evt_mgmt_operator
Use the Discovery Trap Collector Extension to process SNMP traps as events. In this configuration, a MID
Server acts as a collection endpoint for SNMP traps.
1. Navigate to MID Server > Extensions > SNMP Trap Collectors.
2. Click New.
3. Complete the form:
Option Description
Name Unique name for the SNMP Trap Collector.

Short description [Optional] Short description of the MID Server
extension execution context.
Extension The MID Server extension of this context.
UDP Port UDP port for SNMP Trap Collector to receive
SNMP Traps. The default value is 1,162.
However, if the port is already in use, you can
use port 162 instead.
Status The current status of this extension execution
context.
Execute on Select either Specific MID Server or Specific
MID Server Cluster.
MID Server MID Server or MID Server Cluster to host the
SNMP Trap Collector from the MID Server
reference field.
4. In the Related Links section, click Test.
5. Click Submit.
6. Optional: If the MID Server fails to start, review the MID Server log errors.
7. Optional: For high availability, add a second MID Server and configure the trap sender so that both
MID Servers receive the same SNMP traps. To prevent duplication, only the active MID Server
actually processes SNMP traps.
Configure SNMP Trap collection for high availability

For SNMP traps, the MID Server requires failover configuration for the trap listener.
You can configure two MID Servers for failover. Because the SNMP Trap listener on the MID Server
receives inbound traffic on the IP address and port of the MID Server, you configure each MID Server
to receive the same SNMP traps. Only one MID Server is active at any point in time, therefore Event
Management does not receive duplicate traps.

Configure Amazon CloudWatch integration

Integrate Amazon CloudWatch with Event Management to process alarms as events.
To process CloudWatch alarms as events, configure both Amazon CloudWatch and Event Management
event rules.
When a CloudWatch alarm arrives, Event Management:
• Extracts information from the original CloudWatch alarm to populate required event fields.
• Uses the AWS resource ID, for example VolumeReadOps, to map the generated the alert with the CIs
and get the event type.
• Captures the content in the additional_info field.
You can use an event rule transform to parse the content depending on your business needs. The
ServiceNow base system can also perform test case analysis on the events from CloudWatch.
1. On the AWS console, select SNS and create a new SNS topic if one does not already exist.
2. Under the topic, create a new subscription.
a) Take the Topic ARN from the topic that you created.
The Amazon Resource Name (ARN) is necessary for binding an Event Management alert to a CI.
b) Set the Protocol to https.
c) Set the Endpoint to: https://<user>:<password>@<instance>/evt_mgmt_proc.do.
3. Wait until the subscription goes from Pending to Confirmed and the subscription ARN is populated.
4. Create alarms in CloudWatch to send to Event Management. Link them to the SNS topic that you just
created.
5. In your ServiceNow instance, navigate to Event Management > Rules > Event Rules.
6. Click the link for events or grouped events that are not mapped to rules.
7. Select a CloudWatch event that you want to use for creating the rule.
8. In the simple view, create a rule to manage the following incoming values from CloudWatch:
Data from AWS event Use this field in the Event Field Rules section
node node
type type
description description
alarm body additional_info
AWS CloudWatch source source
Original source instance and SNS topic event_class
Configure event collection from email

Configure an inbound email action to send email notifications when events and alerts are triggered.
When you add an inbound email action to send email, Event Management uses inbound email actions to
process inbound email in the same manner as any external event. The email content is used to generate

and update events, use rules to generate alerts, or change event severity. The severity is updated after the
impact calculation and stored in the em_impact_status table.
1. Navigate to System Properties > Email Properties.
2. In the Inbound Email Configuration section, in the Email receiving enabled option, select Yes to
enable the collection of events from email.
3. To configure the email information to pass to Event Management for event and alert processing,
navigate to System Policy > Email > Inbound Actions and in the list of Inbound Email Actions
records search for and open the default create event form.
a) In the Inbound Email Actions form, specify these values.
Field Value
Active Select the check box to enable the email
notification.
Description Type a description for this email message.
Target table Select Event [em_event].
Action type Select Record Action.
b) Click the Actions tab and select these Field Actions.

• [Severity] [To] [<the event severity>]
• [Type] [From email] [<portion of the email>]
For example, you can select Subject as the portion of the email to use.
4. To customize the inbound parameters and map the text to event variables, add a Script.
For example:
current.source = 'email';
current.event_class = 'email';
current.description = email.body_text;
current.time_of_event = new GlideDateTime();
current.insert();
5. From the instance, send an email that contains matching data, and then confirm that the event or alert
information appears in Event Management. For more information sending email messages to create
an instance, see Inbound email actions.
Note: Ensure that the user who sends the email has the evt_mgmt_integration role.
6. Click Submit.
The inbound email is sent to the em_event table and regular Event Management processes continue, for
example, event rules and alert action rules run.
Configure email notification on business service severity change

Configure an email notification to notify users when there is a business service severity change.
Configure an email notification to notify users when there is a business service severity change. The
notification involves specifying when to send it, who receives it, and what it contains.
1. Navigate to System Properties > Email Properties.

2. In the Outbound Email Configuration section, in the Email sending enabled option, select Yes to
enable sending severity information by email.
3. Click Save.
4. Navigate to System Notification > Email > Notifications.
5. Click New.
a) In the Email Notification Actions form, specify these values.
Field Value
Name Type a descriptive name, for example,
Business Service severity change.
Table Select the required service type and its
corresponding table: Alert Group, Discovered
Service, Technical Service, or Manual Service.
Active Select the check box to enable email
notification.
b) Click the Who will receive tab. In the Users area, search for and select the required user (the
user does not require System Administrator credentials). Repeat this step for as many users that
are required to receive this notification.
c) Click the When to send tab. In the choose field box, search for and select Severity.
d) Click the What will it contain tab. In the Subject field, type meaningful text that makes it clear to
the receiver of the email notification what the content of the email is.
e) In the Message HTML message area, using the Select variables functions, compose the
conditions under which the email notification is to be sent. For example, configure these variables
to change severity:
severity changed
Severity: ${severity}
on business service
Name: ${name}
6. Click Submit.
Manually create and send events

You can manually create and send events to confirm that Event Management properly manages events
and generates alerts.
For example, you can manually send events to:
• Confirm that the MID Server is using an event connector definition and instance to send events.
• Confirm that event rules, event field mapping, and other configurations generate do alerts.
• Track an operation or action that did not generate an event.
1. Navigate to Event Management > All Events.

2. Click New.

3. On the form, fill in the fields.
Table 399: Event form
Name Description
Source Event monitoring software that generated

the event, such as SolarWinds or SCOM.
This field has a maximum length of 100. It is
formerly known as event_class.
Node Node name, fully qualified domain name
(FQDN), IP address, or MAC address that
is associated with the event, such as IBM-
ASSET. This field has a maximum length of
100.
Type Pre-defined event type, such as high CPU,
which is used to identify an event record.
Resource Event unique identifier to identify multiple
events that relate to the same alert. If this
value is empty, it is generated from the
Source, Node, Type, and Resource field
values. This field has a maximum length of
1024.
Source instance Name of the machine or software that
generated the event. For example,
SolarWinds on 10.22.33.44. Corresponding
field display name is Source Instance.
Message key Event unique identifier to identify multiple
1024.

Name Description
Severity The severity of the event. The options are

typically interpreted as follows:
• Critical: Immediate action is required.
The resource is either not functional or
critical problems are imminent.
• Minor: Partial, non-critical loss of
functionality or performance degradation
occurred.
• Warning: Attention is required, even
though the resource is still functional.
• Clear: No action is required. An alert
is not created from this event. Existing
alerts are closed.
• Info: An alert is created. The resource is
still functional.
Time of event Time that the event occurred in the source

system. This field is a GlideDateTime field
in UTC or GMT format. This field has a
State The current processing state of the event:
• Ready: Event has been received and is
waiting to be processed.
• Processed: Event was successfully
processed.
• Ignored: Value is not in use.
• Error: Failure occurred while processing
the event. For example, the event
collection method or event Severity is
blank.
Alert If an alert was created as a result of the

event, this field contains the unique ID that
Event Management generates to identify the
alert.
Description Reason for event generation. Shows
extra details about an issue. For example,
a server stack trace or details from a
monitoring tool. This field has a maximum
length of 4000.

Name Description
Additional information A JSON string that gives more information

about the event. The JSON data is
supported for String values only, other value
types are not supported. Numbers must
Failure: Windows failed. Error
0x80070490"}. This information can be
used for third-party integration or other post-
alert processing. Values in the Additional
information field of an Event that are not
in JSON format are normalized to JSON
format when the event is processed. For
example, assume that the following plain
text is in the Additional information field
“Connection instance is successful”. When
the event is processed, all this plain text
becomes one JSON string and might not be
useful within an alert. In the resultant alert,
this string is in the Additional information
field in JSON format, containing the data:
{“additional_content”: “Connection instance
is successful"}.
4. Click Submit.
Event field mapping configuration

Event field mappings are used to map values from specific fields to values in other fields.
Event Management stores event field mappings in the Event Field Mapping [em_mapping_rule] table.
The mappings apply after event rule processing and prior to alert generation. The mapping values from
the Event Mapping Pair [em_mapping_pair] table apply to the alert. The original event severity remains
unchanged.
For example, if the events came with the field "org_severity" that get the values "Low, Medium, High"
and you want the alert Severity to hold the value, create an event field mapping rule that maps the field
org_severity to Severity, with values.
Table 400: Example showing org_severity mapped to Severity
Original org_severity value Map to alert Severity value
Low Warning
Medium Major
High Critical

Default event field mappings
Event Management provides default event field mappings for commonly used system monitoring tools. The
Event Mapping Pairs from event field mappings format the incoming event data for Event Management.
You can view the default event field mappings and mapping pairs by navigating to Event Management >
Event Field Mappings and double-clicking Name. The default event field mappings that are available for
the following event sources:
• enterprises.20006.1.5
• enterprises.20006.1.7
• HPOMWIN
• Microsoft Operations Manager
• netappDataFabricManager
• oraEM4Traps
• SNMPv2 Generic Trap
• SolarWinds
• Trap From Enterprise 9
• vmwVC
• whatsup-whatsupState
HP Operations Manager For HP Operations Manager, the following default

event field mappings are active by default in the
HPOMWIN Source category.
Table 401: Default HP Operations

Manager event field mappings
Event field mapping Description

name
HPOMWIN- Maps the source

hpomSeverity hpomSeverity field to
the event severity.
NetApp DataFabric Manager For NetApp DataFabric Manager, the following

default event field mappings are active by default in
the netappDataFabricManager Source category.
Table 402: Default NetApp DataFabric


name
netappDataFabricManager-
Maps the source
dfmEventSeverity dfmEventSeverity
field to the event
severity.
NetDiscover For NetDiscover, the following default event

field mappings are active by default in the

enterprises.20006.1.5 and enterprises.20006.1.7

Source categories.
Table 403: Default Net

Discover event field mappings

name
enterprises.20006.1.5- Maps the source

trap_severity trap_severity field to
the event severity.
enterprises.20006.1.7- Maps the source
trap_severity trap_severity field to
the event severity.
Microsoft Operations Manager For Microsoft Operations Manager, the following

default event field mappings are active by default in
the mom Source category.
Table 404: Default Microsoft Operations


name
mom-momSeverity Maps the source

momSeverity field to
the event severity.
Oracle For Oracle, the following default event field

mappings are active by default in the oraEM4Traps
Source category.
Table 405: Default Oracle event field mappings

name
oraEM4Traps- Maps the source

oraEM4AlertSeverity oraEM4AlertSeverity
field to the event
severity.
SNMP Traps For SNMP Traps, the following default event field
mappings are active by default in the SNMPv2
Generic Trap Source category.

Table 406: Default SNMP

Traps event field mappings

name
ifOperStatus Maps the source

ifOperStatus field to
the ifOperStatus.
ifAdminStatus Maps the source
ifAdminStatus field to
the ifAdminStatus.
SolarWinds For SolarWinds, the following default event field

mappings are active by default in the SolarWinds
Source category.
Table 407: Default SolarWinds

event field mappings

name
solarwinds-icon- Maps the source

severity icon field to the event
severity.
solarwinds-Availability- Maps the source
severity Availability field to the
event severity.
solarwinds- Maps the source
ComponentStatus- ComponentStatus
severity field to the event
severity.
solarwinds-Status- Maps the source
severity Status field to the
event severity.
solarwinds-type Maps the source
eventType field to the
event type.
Trap from Enterprise 9 For Trap from Enterprise 9, the following default
event field mappings are active by default in various
Source categories.

Table 408: Default Trap from

Enterprise 9 event field mappings

name
mnState (mnState Maps the source

category) mnState field to the
mnState.
tslineSesType Maps the source
(tslineSesType tslineSesType field to
category) the tslineSesType.
cisco.snmpTrapOID Maps the source
(snmpTrapOID snmpTrapOID field to
category) the snmpTrapOID.
ciscoFlashCopyStatus Maps the source
(ciscoFlashCopyStatus ciscoFlashCopyStatus
category) field to the
ciscoFlashCopyStatus.
tcpConnState Maps the source
(tcpConnState tcpConnState field to
category) the tcpConnState.
VMware VCenter For VMware VCenter, the following default

event field mappings are active by default in the
vmwVpxdNewStatus Source category.
Table 409: Default VMware

VCenter event field mappings

name
vmwVC- Maps the source

vmwVpxdNewStatus vmwVpxdNewStatus
field to the event
severity.
Whatsup For whatsup, the following default event field

mappings are active by default in the whatsup
Source category.

Table 410: Default whatsup

event field mappings

name
whatsup-whatsupState Maps the source

whatsupState field to
the event severity.
Create event field mappings

Use event field mappings to provide more comprehensive information in an event alert by substituting
values from the event field mapping rule into the event.
Create the rule to match the event by its class and original values. Also specify the new values to replace
the original values in the event.
1. Navigate to Event Management > Event Field Mapping.
2. Click New or open an existing rule to edit.
Table 411: Event Field Mapping form
Field Description
Name Event field mapping name.

Mapping type Mapping mechanism that is used to change
an event field value.
• Constant: Mapping rule that transforms
any value in the specified field to the new
value provided. For example, a mapping
rule could transform any value in the
Node field to a hard-coded value such as
Linux1.
• Single field: Mapping rule that
transforms specific values from
one event field to another event
field. For example, whenever the
ciscoFlashCopyStatus mapping
rule finds the specific value 8 in the
ciscoFlashCopyStatus name-value
pair, the mapping rules updates the field
value to copyDeviceBusy.
Active Check box that activates or deactivates the

event field mapping. If possible, find and
apply another event field mapping rule.

Field Description
From field Event field to replace.

To field Event field where the mapping rule inserts
or updates the value. When this field is
identical to the From field, the mapping rule
updates the value in memory of the event
field.
Value Value you want to use for the To field. This
field appears when the Mapping Type is
Constant.
Key (Event Mapping Pairs section) Value that the mapping rule searches for.
Whenever the event field has this value, the
mapping rule adds the value listed in the
Value field to the field listed in the To field.
This field appears when the Mapping Type
is Single field.
Value (Event Mapping Pairs section) Value you want to insert or update into the
To field. The mapping rule overwrites any
existing value in the To field. This field
appears when the Mapping Type is Single
field.
4. Click Submit.
For example, see these values for a predefined rule that is applied to events in the Trap
From Enterprise 9 class. If the events contain the snmpTrapOID element with a
value of iso.org.dod.internet.private.enterprises.cisco.0.0, the mapping
rule changes the value to reload in alerts. If the events contain the snmpTrapOID
element a value of iso.org.dod.internet.private.enterprises.cisco.0.1,
the mapping rule changes the value to tcpConnectionClose in alerts.
Field Values
Name cisco.snmpTrapOID
Source Trap From Enterprise 9
Mapping type Single field
From field snmpTrapOID
To field snmpTrapOID
Event Mapping Pairs • Pair 1
• Key:
iso.org.dod.internet.private.enterprises.cisco.0.0
• Value: reload
• Pair 2
• Key:
iso.org.dod.internet.private.enterprises.cisco.0.1

Field Values
• Value: tcpConnectionClose
Test an event field mapping by sending an event that contains a field that is present in the event field
mapping.
Event rule configuration

You can configure event rules to generate alerts for tracking and remediation. Event rules are stored in
the Event Rule [em_match_rule] table. The rules do not change the event records in the Event [em_event]
table. Instead, changes to event data are stored in the instance memory.
You can use the default event rules or create rules to:
• Apply an event rule filter to determine whether the rule applies to an event.
• Apply a transform with Event Match Fields and optional Event Compose Fields to format the alert
text.
• Apply a transform to ignore an event.
• Apply a threshold to create custom alerts for rapidly recurring events.
• Automatically create or close alerts.
Default event rules
Default event rules are available for various sources. You can customize these rules as necessary to
manage events and alert generation. To view the default rules, navigate to Event Management > Rules >
Event Rules.
Default events are available from the following sources:
• HPOMWIN
• oraEM4Traps
• Generic Trap
• SNMPv2
• SolarWinds
• Trap From Enterprise 9
• vmwVC
Oracle For Oracle, the following event rules are active by

default in the oraEM4Traps source category.
Table 412: Default Oracle event rules
Event rule name Description
OracleGrid Database Manages Oracle grid

Traps database traps. The CI
type is Oracle Instance
[cmdb_ci_db_ora_instance].

OracleGrid Non- Manages Oracle

Database Traps grid non-database
traps. The CI
type is Computer
[cmdb_ci_computer].
SNMP V1 Generic Traps For Simple Network Management Protocol (SNMP)

Version 1, the following event rules are active
by default in the SNMPv1 Generic Trap source
category.
Table 413: Default SNMP V1 event rules
snmpV1.coldStart Manages SNMP v1

cold start messages
with the generic_trap
field value.
snmpV1.warmStart Manages SNMP v1
warm start messages
with the generic_trap
field value.
snmpV1.authentication Manages SNMP v1
Failure authentication start
messages with the
generic_trap field
value.
snmpV1.linkDown Manages SNMP v1 link
down messages with
the generic_trap field
value.
snmpV1.linkUp Manages SNMP v1
link up messages with
the generic_trap field
value.
snmpV1.egp Manages SNMP
NeighborLoss v1 egp Neighbor
Loss events with the
generic_trap field
value.
SNMP V2 Generic Traps For Simple Network Management Protocol (SNMP)

Version 2, the following event rules are active
by default in the SNMPv2 Generic Trap source
category.

Table 414: Default SNMP V2

Generic Trap event rules
snmpV2.coldStart Manages SNMPv2 cold

start messages with
the SnmpTrapOID field
value.
snmpV2.warmStart Manages SNMv2 warm
start messages with
value.
snmpV2.authentication Manages SNMPv2
Failure authentication
messages with the
SnmpTrapOID field
value.
snmpV2.linkDown Manages SNMPv2 link
down messages with
value.
snmpV2.linkUp Manages SNMP 2 link
up messages with the
SnmpTrapOID field
value.
snmpV2.egp Manages SNMPv2 cold
NeighborLoss start messages with
value.
SolarWinds For SolarWinds, the following event rules are active

by default in the SolarWinds source category.
Table 415: Default SolarWinds event rules
Component_Status Manages SolarWinds

event messages with
the ComponentStatus
field value.
Node response time Manages SolarWinds
dropped events where node
response time had
dropped below the
Threshold field value.

Node response time Manages SolarWinds

above events where node
response time exceeds
the Threshold field
value.
Solarwinds Generic Manages SolarWinds
App events app up-down events.
Host not responding Manages SolarWinds
host stop responding
events.
Interface Utilization Manages SolarWinds
Triggered interface utilization
events.
Interface status Manages SolarWinds
interface names for
node events.
Solarwinds Node Manages SolarWinds
Status node status events.
Packet loss dropped Manages SolarWinds
events for packets lost
rate dropped.
Application Status Manages SolarWinds
application status
events.
Group status down Manages SolarWinds
group on node status
events.
Group Status Manages SolarWinds
group status events.
Counter is up Manages SolarWinds
counter for app on
node events.
Interface High Transmit Manages SolarWinds
high transmit utilization
events.
Packet loss risen Manages SolarWinds
events for lost packets
that exceed the above
rate.
Response_time Manages SolarWinds
host responding again
with response time
events.
ComponentOnAppStatus Manages SolarWinds
component status
events.

Solarwinds Group Manages SolarWinds

events group events.
Interface Utilization Manages SolarWinds
Reset interface reset alert
trigger events.
IOS change Manages SolarWinds
events for Cisco
Internetwork Operating
System (IOS).
Counter status Manages SolarWinds
counter-status events.
Solarwinds Cluster Manages SolarWinds
events cluster events.
Solarwinds Node Manages SolarWinds
events node events.
Node reboot Manages SolarWinds
node reboot events.
Group status 1 Manages SolarWinds
group on node status
events.
Solarwinds Volume Manages SolarWinds
events physical or logical
volume events.
IOS Image family Manages SolarWinds
IOS Image family
changes for node.
Solarwinds Interface Manages SolarWinds
events interface events.
Splunk For Splunk, the following event rules are active by

default in the Splunk source category.
Table 416: Default Splunk event rules
All Splunk Catches all Splunk

events that do not
match previous
rules, and maps the
Description field to the
Unmapped field. The
CI type is Computer
[cmdb_ci_computer].

Enterprise 9 For Enterprise 9, the following event rules are active

by default in the Trap From Enterprise 9 source
category.
Table 417: Default Trap From

Enterprise 9 event rules
cisco.reload Manages Cisco reload

traps that indicate
that the entity is
reinitializing or that the
implementation has
changed.
ciscoV1.reload Manages Cisco version
1 reload traps that
indicate that the entity
is reinitializing or that
the implementation has
changed.
cisco.tcpConnectionCloseManages Cisco
teletype (tty) traps
for terminated TCP
sessions.
cisco.ciscoFlashCopyCompletionTrap
Manages Cisco
teletype (tty) traps for
the initiation of flash
copy operations.
cisco.cmiMrStateChange Manages Cisco Mobile
Router state change
notifications. The
cmiTrapControl object
controls the generation
of this notification.
ciscoV1.tcpConnectionClose
Manages Cisco version
teletype (tty) traps
for terminated TCP
sessions.
VMware For VMware vCenter, the following event rules are

active by default in the vmwVC source category.

Table 418: Default VMware event rules
esx_lost connectivity Manages VMware

Network-Connectivity-
Lost-Alarm events. The
CI type is Computer
[cmdb_ci_computer].
ESX host Manages all VMware
events for an ESX
hostname. The CI
type is Computer
[cmdb_ci_computer].
vmware vm Manages all
VMware events for
a VMname. The CI
type is Computer
[cmdb_ci_computer].
View event rules

You can view all event rules on the Event Rules list.
You can learn about event rules from the following video tutorial.
Navigate to Event Management > Rules > Event Rules.
Table 419: Event Rules list
Field Description
Name The event rule name.

Active Check box to activate the event rule or
event mapping rule.
CI type binding (legacy) Legacy binding criteria.
If, in the Bind section criteria have not been
specified or if the specified bind criteria are
not matched, then the legacy binding criteria
are considered.
Order Order in which an event rule is evaluated

when multiple rules are defined for the same
type of event. Event rules are evaluated in
ascending order.
Updated Update date and time for the rule.

Note: You can filter the Event Rule list to display the required subset of the information.
However, if you create a favorite link after filtering, when the link is clicked the Event Rule list
does not display the correct filter.
Find rules that were applied to events or alerts

View the rules that were applied to events and alerts to confirm how events are processed.
Role required: evt_mgmt_admin, evt_mgmt_operator, or evt_mgmt_user
Do one of the following:
Option Description
Find rules that apply to an event 1. Navigate to Event Management > All
Events, and then click an event Number.
2. Under Related Links, click Check process
of event.
3. Review the information that appears above
the Source field, and review all Processing
Notes.
Find rules that apply to an alert 1. Navigate to Event Management > All
Alerts, and then click an alert Number.
2. In the processing notes, review information
about the applied event rule.
Create an event rule in simple view

Use the simple view to create an event rule without complex regular expressions.
Options to create an event rule in simple view are:
• Create an empty event rule and assign event fields for alert generation.
• Create a rule from an existing event or groups of events that do not have a rule. The event fields are
copied to the Event Field Rules section of the rule.
Note: Do not change the view of the Event rule list by clicking an option from the context menu in
the List controls context menu in the form header.
This video explains the use of event rules.
Note: Only one rule is applied to each event, according to the filter applied to the events. Multiple
event rules do not apply to an event.
1. Navigate to Event Management > Rules > Event Rules.

2. Do one of the following actions:

Option Description
Create an event rule 1. Click New.

2. Type a name for the rule.
4. Click Go to simple mode.
Create an event rule from an existing event 1. Click the link for events or grouped events
and or group of events that are not mapped to rules.
2. Click the event that you want to use for

creating the rule.
The event fields are copied to the Event Field
Rules section of the rule.
3. Fill in or edit the fields, as appropriate. For example, use the Event Compose Fields section to map
event data to alert fields.
Table 420: Event Rule form [Simple view]
Field Description

Active Check box to activate the event rule or
event mapping rule.
CI type Pre-defined definition that resides in
the CMDB that describes a category for
hardware, software application, or web
service.
ascending order.
Source Category to which this matching rule
applies. The mapping rule only applies to
events with the same event class value.
If this value is empty, apply the rule to all
events.
Event Field Rules section

Field Description
Field An event field to use for generating an

alert. This field can either be from the
Event [em_event] table or a field defined
by a name-value pair in the Additional
Information field. Used with the Value field.
Value The event value and any dot-plus (.+)
symbols that represent event fields that can
be updated.
Event Compose Fields section
Field A field to use for generating the alert
message. The field from the Event
[em_event] table or a field defined by
a name-value pair in the Additional
Information field. For example:
message_key.
See Custom alert fields on page 931 for
more information on how to populate custom
alert fields with data contained in Additional
information field.
Composition For alert message generation. The text

and relevant fields from the original
event. For example: ${netObjectId}_
${networkNodeId}_appUpDownEvent
Ignore Event section
Ignore event Check box to ignore matching events and
not create an alert.
Threshold section
Threshold Check box to configure the generation of
alerts for rapidly recurring events.
Threshold Metric Threshold name from the event. For
example, cpu. This field appears when the
Threshold check box is selected.
Create Alert Operator Specify a count or relational operator for
creating an alert. Options include Count, >,
>=, < >=, =, and !=. If the criteria matches,
generate an alert. For example, if the
ThresholdMetric is cpu and Count is 5,
generate a threshold alert after five events
that contain cpu. This field appears when
the Threshold check box is selected.
Star (*) A numeric value. This field appears when
a relational operator is selected from the
(for Create Alert Operator)
Create Alert Operator list.

Field Description
Occurs Number of times that the event must occur

with the Threshold metric and Create Alert
Operator values to generate the alert. This
field appears when the Threshold check
box is selected.
Over (seconds) Number of seconds in which the event
Threshold Metric and corresponding fields
must occur to open the alert. The value 0
specifies an infinite time frame and can be
used to exclude time from this threshold.
This field appears when the Threshold
check box is selected.
Close Alert Operator Count or relational operator to define the
threshold that must be met for closing an
existing alert. Options include --None--,
Idle, >, >=, < >=, =, and !=. If the criteria
matches, the threshold alert is generated.
For example, if the number of events that
match other criteria = 5, generate an alert.
This field appears when the Threshold
check box is selected.
Over (seconds) The number of seconds in which the event
threshold metric must occur to close the
(for Close Alert Operator)
alert. The value 0 specifies an infinite time
frame and can be used to exclude time from
this threshold. This field appears when the
Threshold check box is selected.
Close Alert Operator list.
4. Double-click any highlighted value to select event fields and CI attributes.

For example, in the Event Field Rules section, double-click any dot-plus (.+) symbols and type the
event field CI attribute name.

5. Click Submit.
Find events that are not matched to rules

Find events that are not matched to any rules, and determine if it is necessary to create event rules to
manage them.
To change the response time for the Event Rule page to recommend rules, modify the
default value of 50000 in the Number of events to handle for event rules processes
(evt_mgmt.event_rules.num_of_events_to_handle) property. This property is located here: Event
Management > Settings > Properties.
This video describes event rules and how to find events that are not matched to rules.
2. Near the top of the form, click the link for events or grouped
events that are not mapped to rules.
If necessary, use either the simple or advanced view to create an event rule. For example, event rules are
useful for managing events that occur regularly.

Create an event rule in advanced view

Use the advanced view to create an event rule with regular expressions (regex). Event rules use the fields
from the event to generate alerts.
You can create rules that:
• Ignore events that match the specified criteria.
• Transform information in events to populate specified alert field values.
• Configure threshold rules that create alerts only when the incoming matching events pass over the
specified threshold.
• Bind alerts to CIs using CI identifiers.
Note: Only one rule is applied to each event, according to the filter applied to the events. Multiple
event rules do not apply to an event.
After you add advanced mapping information to the event rule, it may not be viewable from the simple
view. For example, the simple view cannot open an event rule that contains regex patterns, such as, \b[A-
Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b. An error message reminds you that the rule cannot be viewed in
simple mode.
Options to create the rule are:
• Create an empty event rule and assign event fields for alert generation.
• Create a rule from an existing event or groups of events that do not have a rule, so the event fields are
copied to the Event Match Fields section of the rule.
You can learn about transform, compose, and binding from the following video.
Note: Event rules that are not configured to perform any action are skipped. Therefore, if the rule
is not configured as ignore, threshold, or binding, it is important to specify either the match or the
compose fields.

2. Do one of the following:
Option Description
Create a new event rule Click New.

Option Description
Create an event rule from an existing event 1. Near the top of the form, click the link for
events or grouped events that are not
mapped to rules.
2. Select the event that you want to use for

creating the rule.
The event fields are copied to the Event Field
Rules section of the rule.
3. Click Go to advanced mode.
3. Fill in the Name, Source, and Order fields.

4. Optional: Use the fields from the event to set the filter for incoming events. Fill in the Event Field Rules
section as appropriate.
For example, if the filter requires a regex expression, double-click the dot-plus (.+) symbol placeholder
and add the event field name. In the Event Match Fields section, double-click the event to confirm and
customize this information.
5. If necessary, add or delete extra event field names in the Event Match Fields section. Use the Event
Compose Fields section to generate the output verbiage that appears on alerts for this type of event.
Table 421: Event Rule form [Advanced view]
Field Description

Source Category to which this matching rule
applies. The mapping rule only applies to
events with the same event class value.
If this value is empty, apply the rule to all
events.
ascending order.
Active Select to activate or deactivate the event
rule.
When the rule is deactivated, Event
Management finds and applies another
event rule. An alert is still created for the
event unless Ignore is selected in another
applicable rule.

Field Description
Description Type additional information that describes

the event rule.
Filter Conditions that must be matched by the
fields of events that this rule applies to.
Depending on the event field, the filter
can match a string, pattern, or regular
expression. For regular expressions, the
dot-plus (.+) symbol is a placeholder for
mapping the event field name. The same
information appears in the Event Match
Fields section.
Additional Info Filter An optional string or regular expression
filter. For regular expressions, the dot-plus
(.+) symbol is a placeholder for mapping
the event field name. The same information
appears in the Event Match Fields section.
Ignore event Check box to ignore matching events and
not create an alert.
Transform
Active Select to enable manipulation of information
from events to populate specified alert field
values.
CI type binding (legacy) Select the binding criteria from the list.
Available when Active is selected in the
Transform section.
Event Match Fields section

Field The field that the event rule searches for
a matching value. This field can either be
from the Event [em_event] table or a field
defined by a name-value pair in the event
Additional Information field. Available
when Active is selected in the Transform
section.
See Custom alert fields on page 931 for
more information on how to populate custom
alert fields with data contained in Additional
information field.

Field Description
Regular expression The string, match pattern, or regular

expression that the event rule uses to
identify matching event values. Each
dot-plus (.+) symbol requires a comma-
separated value in the Mapping field. For
example, consider the sentence: Node
localchost has dropped its
average response time to 55 ms,
which falls below the threshold.
Enter the replacement event field
names for localhost and the value
55 in the hostNameFromEvent and
newAvgresponseTime Mapping fields,
respectively. Examples of correct regex that
match this expression are:
• Node (.+) has dropped its
average response time to (.+)
ms .*
• Node (.+) has dropped its
average response time to (.
+) ms which falls below the
threshold
The following is an example that is incorrect,

as the final regex expression is missing:
Node (.+) has dropped its
average response time to (.+)
ms
Available when the Transform check box is
selected.
Mapping Each comma-separated event field name

corresponds to a dot-plus (.+) symbol.
For example, hostNameFromEvent,
avgResponseTime, newAvgresponseTime,
responseTimeThreshdold. This field
appears when Active is selected in
the Transform section. Note: Only use
unmapped as a variable or field name when
the mapping used is not actual mapping.
Event Compose Fields section
Field The field that the event rule inserts or
updates. This field can either be from the
Information field of the event. This field
appears when Active is selected in the
Transform section.

Field Description
Composition The value to insert or update into the alert

and bind to the CI on an incoming event.
This value can use dynamic data from the
Information field of the event. Specify
dynamic data with the following format:
${field}. This field appears when Active
is selected in the Transform section.
Threshold
Active Check box to configure the generation of
alerts for rapidly recurring events. Create
alerts only when the incoming matching
events pass over the specified threshold
Threshold metric Threshold name from the event. For
example, cpu. Available when Active is
selected in the Threshold section.
Create Alert Operator Specify a count or relational operator for
creating an alert. Options include Count, >,
>=, < >=, =, and !=. If the criteria matches,
generate an alert. For example, if the
ThresholdMetric is cpu and Count is 5,
generate a threshold alert after five events
that contain cpu. This field appears when
Active is selected in the Threshold section.
Create Alert Operator list.
with the Threshold metric and Create Alert
field appears when Active is selected in the
Threshold section.
Over (seconds) Number of seconds in which the event
Threshold Metric and corresponding fields
must occur to open the alert. The value 0
specifies an infinite time frame and can be
used to exclude time from this threshold.
This field appears when Active is selected
in the Threshold section.
Close Alert Operator Count or relational operator to define the
threshold that must be met for closing an
existing alert. Options include --None--,
Idle, >, >=, < >=, =, and !=. If the criteria
matches, the threshold alert is generated.
For example, if the number of events that
match other criteria = 5, generate an alert.
This field appears when Active is selected
in the Threshold section.

Field Description
(*) Value Specify a numeric value. This field appears

when a relational operator is selected from
the Close Alert Operator list.
with the Threshold metric and Close Alert
field appears when the Active check box is
selected in the Threshold section.
Over (seconds) The number of seconds in which the event
threshold metric must occur to close the
alert. The value 0 specifies an infinite time
frame and can be used to exclude time
from this threshold. This field appears when
Active is selected in the Threshold section.
Bind
Active Select this option to bind alerts to CIs using
CI identifiers.
CI type Pre-defined definition that resides in
the CMDB that describes a category for
hardware, software application, or web
service. This field appears when Active
is selected in the Bind section. See the
example.
Event field First specify a value for the CI identifier
attribute and then specify the value for
this field, which is the value that the event
rule searches for a match. Valid values for
this field depend on the selection in the CI
identifier attribute field. In addition, you
can specify field names that were defined in
the Transform section.
CI identifier attribute Select the identifier attribute from the list.
This field appears according to the selection
in the CI type field. The values in this field
are derived from the attributes specified
in the CI Identifiers form. To see this form,
navigate to Configuration > Identification/
Reconciliation > CI Identifiers. In the
Identifiers list, search for the required CI
name.

Field Description
Container Level 1 Select the container type from the list. This
field appears according to the selection in
the CI type field.
Note: The number of containers

levels that appear depend on how
many parameters must be specified
to identify the CI. For example, if
Oracle iAS web module is selected
as the CI type, then a server must
be specified for Container Level 1
and hardware must be specified for
Container Level 2.
To see the definition, navigate to

Configuration > Identification/
Reconciliation > Metadata Rules Editor.
Note: In the case of hardware (for

example, cmdb_ci_hardware), if
no value is specified in the Event
field and the CI identifier attribute
fields, then the node value from the
event is used as a basis to search
for CI hardware values to populate
these fields.

Figure 172: Example - event rule binding
6. Click Submit.

The settings and values are validated. If the validation is successful, the Event Rule list displays.
Otherwise, an error message displays, indicating where to find information to complete the configuration.
For example, if PostgreSQL DB [cmdb_ci_endpoint_postgresql] is specified for the CI type and
insufficient attributes were specified, then a message, similar to the following, displays.
Missing information for the CI type: cmdb_ci_endpoint_postgresql. For more
details, use the
CI rule: PostgreSQL DB
In this case, in the message, click the PostgreSQL DB link. The Identifier displays, showing that the
criterion attributes are port,ip_address,host,instance,host_name.
Ignore an event
You can configure an event rule to ignore extraneous events and prevent alert generation.
Even if an event is ignored, it is still recorded in the Event [em_event] table.
2. Create or open an event rule.
3. Select the Ignore event check box.
Compose alert text

You can configure an event rule to customize alert content.
You can customize alert content by adding text and the required event fields.
2. Click New or open an event rule.
3. If you are in the advanced view, select the Transform check box.
4. To associate the event with an existing CI, select a CI type.
5. In the Event Compose Fields section, double-click the Composition field and add the text and event
fields that you want.
Use the following syntax for adding the original event information to the alert:
${EventFieldName}
Use an underscore (_) to separate the fields.
For example: ${networkNodeId}_${netObjectId}_response_time
6. Fill in or edit the remaining rule fields as necessary.
To populate custom alert fields with data contained in the Additional information field of the event, see
Custom alert fields on page 931.
Custom alert fields

You can populate custom alert fields with data contained in Additional information field of the event.
Valuable data contained in Additional information fields of events can be useful, for example, for
reporting. Alert fields are automatically populated from fields that have the same name in the event. This
behavior holds true for Additional information event fields and for Additional information fields that
Event Rules adds. Therefore, to populate a custom alert field with the value in Additional information

fields, use the custom field name in the Additional information field. You can also use Event Rules for
this purpose. Values in the Additional information field of an Event that are not in JSON key/value format
are normalized to JSON format when the event is processed.
Depending on permissions, you may only be able to create fields with the user_ prefix. If so, use Event
Rules to create an Additional information field with the same name. To prevent some fields to be copied
to the alert field, use the evt_mgmt.alert_black_list_fields property and add the field names that must be
excluded. By default, the fields that are not copied are:
• message_key
• category
• additional_info
• sys_updated_on
• sys_updated_by
• sys_created_by
• sys_created_on
• sys_mod_count
• sys_id
Set a threshold to suppress alert generation

You can configure an event rule to suppress alert generation according to a threshold based on the value
of event fields or number of occurrences, over a period of time.
Role required: evt_mgmt_admin, evt_mgmt_operator
Configure the properties in an event rule to suppress alert generation, create alerts, or close existing alerts
according to the specified threshold.
Note: Threshold metric can be the name of any numeric field in the Additional information field
of the event. Therefore, if cpu is an additional information field for a specific event, then cpu can be
used as a Threshold metric.
Assume you want to generate an alert when CPU utilization reaches or exceeds 80% where there is a
period of 20 seconds between events. Create an event rule with these settings (an explanation for each
value is given in parenthesis):
• Threshold metric: cpu (events regarding high CPU usage)
• Create alert operator: = > (operator to determine whether utilization of Threshold metric reaches or
exceeds the specified value)
• *: 80 (percent)
• Occurs: 3 (three events occur where the cpu usage is equal to or above "=>" 80%)
• Over: 20 (over twenty seconds between each event)
To demonstrate how the above settings are evaluated, assume that the following events are received:
First scenario
Reported elapsed time and the cpu usage for each event:
• First event elapse time 20, cpu=85
• Second event elapse time 40, cpu=80
• Third event elapse time 60, cpu=70
In this scenario, no alert is generated since one event has a CPU utilization that is under 80%.
Second scenario


In this scenario, an alert is not generated since the elapsed time in one event is over the specified 20
seconds.
Third scenario
In this scenario, an alert is generated since in all events the elapsed time is within the specified time and
the cpu usage is over 80%.
Note: When configuring an event rule to create or close alerts according to a threshold, events
that arrive at the same second, as determined by the time_of_event field, are skipped as they are
considered to be duplicates.

2. Create or open an event rule.
3. In either the simple or advanced view, select Threshold.
4. Select the Active check box and enter a Threshold metric value.
5. To automatically open alerts, select a Create Alert Operator and configure the corresponding Occurs
and Over fields.
6. To automatically close alerts, select a Close Alert Operator and configure the corresponding Over
fields.
7. Fill in the remaining rule fields as necessary.
To create an alert when a specific event occurs 5 times in 10 minutes, in the Threshold
tab, specify the following properties:
1. Select the Active check box.
2. In the Threshold metric field, specify the name of any additional information field that
exists in the event. The value of the field is irrelevant.
3. In the Create Alert Operator field, select Count.
4. In the Occurs field, specify 5.
5. In the Over field, 600 (10 * 60 seconds).
View patterns for event group creation

Event groups are sets of events that do not have a matching event rule. You can view the patterns in a
group of events to learn the impact of creating a rule based on the event source and description patterns.
Events are grouped according to their source and description.

2. Click the event or grouped event link.

3. In the list of events, click an event.
4. To change the pattern of an event, double-click the pattern, make your changes, and then click
Update.
Alert binding to CIs with event rules

When alerts are associated with CIs, the task of remediation is simplified. During alert generation, Event
Management uses event rules and other mechanisms to automatically bind alerts to CI information from
the CMDB. For tracking purposes and remediation, the alert shows information about the CI that caused
the event.
Alert binding process flow
Alerts bind to CIs based on the following process flow:

1. When an event arrives, Event Management checks the node or CI identifiers.
2. If no node exists, the generated alert can bind to the CI using the alert Type, Additional information,
or Configuration item identifier fields.
3. If the event has a node value, search for a valid host.
4. If the event has a host and a CI type, try to bind to a device CI.
5. If the event has a host, try to bind to the application CI.

Figure 173: How alerts bind to CIs

The event can contain the binding process flow in its Processing Notes field. For example, while binding
the alert to a process, the following steps occurred:
• The node, which is found by node name, resolved to the CI ID 775cbc6093120200e0e931f6357ffb17.
• There was no CI type on the event and the sa_process_name variable was set to /ora92/
pmon_U2P3_db.
• Event Management tried to match the CI ID to the process pattern from the em_binding_process_map
table.
• Event Management found the CI ID 6d6cbc6093120200e0e931f6357ffb78: pattern ${oracle_home}/
pmon_${instance} (from em_binding_process_map) and matched it to the /ora92/pmon_U2P3_db
pattern that was defined in the sa_process_name variable.
• The alert was bound to CI ID 6d6cbc6093120200e0e931f6357ffb7.
Alert binding procedures

Alerts can be bound to CIs from the CMDB for tracking purposes and remediation. Event Management
uses event rules and various mechanisms to automatically bind CIs to alerts. When information from an
event populates a field with a value, the value either originates from the event source or from event rules.
This enhances remediation, functionality, and integration with other ITOM products.
You can use these procedures to ensure that alerts bind properly to CIs.
Note: In this section, the phrase "populate event field XXX with value YYY", occurs by sending
the field value from the event source, or by using event rules to populate the field (assuming this
information is contained somewhere in the event).
Binding to an application running on a specific host
If the event is specific to an application type, use the following steps to bind alerts to a specific application:
• Use the recommendations in Binding to a host computer, switch, or router CI on page 937.
• Create an event rule with a filter that captures events on the application type you want.
• In the event rule, select the Transform check box and populate the CI Type with the CI type you want
to bind.
• In the binding process, after the host is found, the algorithm matches all additional_info attributes that
have the same name as CI fields for that CI type. If the match is successful, the event is bound to the
CI.
• If more than one matching application is found on the host, alert is bound to the host and not the
application.
If there is no CI Type, for example, you want to bind alerts to a SQL server application when the CPU on
sqlServer.exe is over 90%, use these steps instead:
• Use the recommendations in Binding to a host computer, switch, or router CI on page 937
• Create an event rule with an event match field which maps the process name to the mapping variable
sa_process_name. In this case, do not use the CI type.
• Use the Process to CI Type Mapping module to add custom patterns.
Binding to a non-host CI
If the event is specific to a non-host CI, for example a business service, manual Service, or alert group, use
the following steps to bind alerts to a non-host CI:
• Leave the Node field empty.
• Populate the CI Type with the CI type you want to bind.

• Make sure the additional_info field has enough information to uniquely identify the CI. The algorithm
matches all additional_info attributes that have the same name as CI fields for that Event Type. If the
match is successful, the event will be bound to the CI.
Optional method:
• Populate the CI Identifier field as above with attributes that will uniquely identify the CI.
Binding to a host computer, switch, or router CI
Use the following steps to bind alerts to a host, such as a computer, switch, or router CI:
• Populate the Node field in the event with the CI name, FQDN, IP or MAC value. The bind is successful
even if host has more than one IP address or MAC.
• If you want to use a unique identifier that is not one of the four mentioned above, populate the event
rule CI Identifier field with one or more unique identifiers of the CI. This field should be in JSON format.
For example, if you want to use a unique identifier which is not one of the four mentioned above, add a
CI Identifier filter field with one or more unique identifiers of the CI. If the host CI is VMWare VM, and it
has a field called MOID, use the JSON format and specify: {"moid":"<CI moid>"}
Binding to a process
You can define pattern of processes that matches with the sa_process_name variable. The
sa_process_name variable must be filled with the process name using an event rule. The Process to CI
Type Mapping table is used for process binding. The table includes default patterns. The pattern variables
extract from this table according to the host related CI Type. The table contains these columns for process
binding:
• The Process field contains the process pattern. Use any combination of free text, regex, and pattern.
• The ci_type field contains the CI type in CMDB.
Binding an alert to a process, Event Management first receives all the processes that are running on the
node (the alert resolving node). Then, Event Management matches every related process pattern with the
name that is defined in the sa_process_name variable. Regular expressions are supported.
For example, if the sa_process_name contains /ora92/pmon_U2P3_db for an oracle instance:
• The sa_process_name variable must be filled by the event rule to store the process name.
• The Process to CI Type Mapping table has the following record:
Process: ${oracle_home}/pmon_${instance}
CI type: cmdb_ci_db_ora_instance.
• Binding the process, Event Management finds a process of type cmdb_ci_db_ora_instance is running
on the node.
• Event Management matches /ora92/pmon_U2P3_db from the sa_process_name variable with the
process pattern from the Process to CI Type Mapping table for type cmdb_ci_db_ora_instance.
• If the oracle instance has ${oracle_home} = ora92 and ${instance} = U2P3_db extracted from the
database, then there is a match and this oracle process is bound in the alert cmdb_ci.
/ora92/pmon_U2P3_db= ${oracle_home}/pmon_${instance}.
To bind a process, use the Process to CI Type Mapping [em_binding_process_map] table.

Binding to an application
In the binding process, the following steps occur:

• Identify the host.
• If the host is found, find the application on the host. An application is considered to be running on the
host if it has a "Runs on:Runs" relationship from the application to the host CI in the cmdb_rel_ci table.
• If the event rule for the transform CI type is defined, find an application CI on that host in the CMDB.
• If all the alert additional_info about the CI matches CMDB CI fields, bind the alert to the application CI.
Binding to a device
The Process to CI Type Mapping table provides all of the necessary information for binding the alert to
device CIs. The table can be extended to support more device types in the future. The Process to CI Type
Mapping table contains these columns for device binding:
• The from_ci_type field matches with the Event Type.
• The to_ci_type field contains the CI Type to look for in the CMDB.
• The mapped_column field contains the name of the column which stores the relationship to the node.
To bind a device, use the Process to CI Type Mapping [em_binding_process_map] table. For example,
the table below shows a record in the Process to CI Type Mapping table. If the Event Type is
cmdb_ci_file_system, Event Management searches the File System [cmdb_ci_file_system] device table for
a computer field contains the node sys_id. If there is a match, the alert binds with this CI.
Table field Value
from_ci_type cmdb_ci_file_system
to_ci_type cmdb_ci_network_adapter
mapped_column computer
Binding a device to a specific host CI
In the binding process, after the host is found, the algorithm matches all additional_info attributes that
have the same name as CI fields for that event type. If match is successful, the event is bound to the CI. If
more than one matching device is found on the host, the alert is bound to the host and not the application.
Use the following steps to bind alerts to a specific device:
• Create an event rule with a filter that captures events on the device type you want. In the event rule,
select the Transform check box and select the appropriate CI Type:
Device to bind CI Type
File System cmdb_ci_file_system

Port cmdb_ci_network_adapter
Storage Device cmdb_ci_storage_device
Volume cmdb_ci_storage_volume
• To bind custom device types, use the Process to CI Type Mapping [em_binding_process_map] table.

Bind alerts to a host CI

You can create an event rule to bind alerts to host CIs. An incoming event from a host CI can bind to an
alert based on the event Node field value. If the value resides in a different event field, you can use an
event rule transform to copy the data to the Node field on the alert.
Use the following steps to bind alerts to a host, such as a computer, switch, or router CI:
• Populate the Node field in the event with the CI name, FQDN, IP or MAC value. The bind is successful
even if host has more than one IP address or MAC.
• If you want to use a unique identifier that is not one of the four mentioned above, populate the event
rule CI Identifier field with one or more unique identifiers of the CI. This field should be in JSON format.
For example, if you want to use a unique identifier which is not one of the four mentioned above, add a
CI Identifier filter field with one or more unique identifiers of the CI. If the host CI is VMWare VM, and it
has a field called MOID, use the JSON format and specify: {"moid":"<CI moid>"}

2. Click New, and fill in the appropriate fields of the event rule.
4. In the Filter condition builder, select Node, select an operator, and then enter the CI name, FQDN, IP,
or MAC address value.
5. Select the Transform check box.
6. In the Event Match Fields section, specify any Additional information mappings.
7. Click Submit.
Bind alerts to a specific host CI

You can create an event rule to bind alerts to the correct device CI. An incoming event from a device CI
can bind to an alert based on event rule transform information. However, first identify the host CI that the
device is running on.
In the binding process, after the host is found, the algorithm matches all additional_info attributes that
have the same name as CI fields for that event type. If match is successful, the event is bound to the CI. If
more than one matching device is found on the host, the alert is bound to the host and not the application.
Use the following steps to bind alerts to a specific device:
• Create an event rule with a filter that captures events on the device type you want. In the event rule,
select the Transform check box and select the appropriate CI Type:
Device to bind CI Type

• To bind custom device types, use the Process to CI Type Mapping [em_binding_process_map] table.

2. Click New and fill in the appropriate fields of the event rule.
4. From the CI type list, select the device that is used in the filter condition.

For example, if you build a filter condition for a port, select Port.
Device to bind CI type

5. In the Event Match Fields section, specify any Additional info mappings.
6. Click Submit.
7. To bind to custom device types, configure the alert binding to a process and add the custom device
type to the Process to CI Type Mapping [em_binding_process_map] table.
Bind alerts for non-host CIs

An incoming event from a discovered business service, manual service, or alert group can bind to an alert
based on an event rule and the corresponding event field mapping. The event field mapping requires a
URL or the port number and corresponding IP address for each service or alert group.
If the event is specific to a non-host CI, for example a business service, manual Service, or alert group, use
the following steps to bind alerts to a non-host CI:
• Populate the CI Type with the CI type you want to bind.
• Make sure the additional_info field has enough information to uniquely identify the CI. The algorithm
matches all additional_info attributes that have the same name as CI fields for that Event Type. If the
match is successful, the event will be bound to the CI.
Optional method:
• Populate the CI Identifier field as above with attributes that will uniquely identify the CI.

5. From the CI type list, select cmdb_ci_service_auto.
6. In the Event Match Fields section, insert a new row with these parameter values:
Field Value
Field node
Regular Expression (.*)
Mapping temp node
7. In the Event Compose Fields section, insert a new row with these parameter value:
Field Value
Field node

Field Value
Composition (empty)
8. Click Submit.
9. Navigate to Event Management > Rules > Event Field Mapping.
10. Create the corresponding event field mapping with these parameter values:
Field Value
Source Specify the event monitor software that
generated the event.
Mapping type Select Single field.
From field Specify temp node.
To field Specify name.
11. In the Event Mapping Pairs section, insert new rows for each event mapping pair.
a) Set the Key with the URL or an IP address with corresponding port value.
b) Set the Value with the business service, manual service, technical service, or alert group name.
For example, you can add an event mapping pair for each business service.
12. Click Submit.
Bind alerts to a process CI

The association between an application process and a CI type is helpful for alert remediation. The
association allows an event rule transform to generate an alert and bind the correct CI type. A CI type can
map to more than one business process. For example, the cmdb_ci_apache_web_server CI type can bind
to http.* and apache.* business processes.
You can define pattern of processes that matches with the sa_process_name variable. The
sa_process_name variable must be filled with the process name using an event rule. The Process to CI
Type Mapping table is used for process binding. The table includes default patterns. The pattern variables

extract from this table according to the host related CI Type. The table contains these columns for process
binding:
• The Process field contains the process pattern. Use any combination of free text, regex, and pattern.
• The ci_type field contains the CI type in CMDB.
Binding an alert to a process, Event Management first receives all the processes that are running on the
node (the alert resolving node). Then, Event Management matches every related process pattern with the
name that is defined in the sa_process_name variable. Regular expressions are supported.
For example, if the sa_process_name contains /ora92/pmon_U2P3_db for an oracle instance:
• The sa_process_name variable must be filled by the event rule to store the process name.
• The Process to CI Type Mapping table has the following record:
Process: ${oracle_home}/pmon_${instance}
CI type: cmdb_ci_db_ora_instance.
• Binding the process, Event Management finds a process of type cmdb_ci_db_ora_instance is running
on the node.
• Event Management matches /ora92/pmon_U2P3_db from the sa_process_name variable with the
process pattern from the Process to CI Type Mapping table for type cmdb_ci_db_ora_instance.
• If the oracle instance has ${oracle_home} = ora92 and ${instance} = U2P3_db extracted from the
database, then there is a match and this oracle process is bound in the alert cmdb_ci.
/ora92/pmon_U2P3_db= ${oracle_home}/pmon_${instance}.
You can assign custom-developed business process applications to CI types. The following default
CI Types automatically bind to application process names during alert generation. The CI Types have
global domain availability. The Process to CI Type Mapping [em_binding_process_map] table stores the
mappings for the binding process.
Table 422: Default mappings
Default CI Type Application Process Name
cmdb_ci_apache_web_server httpd.*, apache.*

cmdb_ci_appl_ibm_wmq runmqlsr.*
cmdb_ci_app_server_jboss org.jboss.*
cmdb_ci_app_server_tomcat tomcat.*
cmdb_ci_app_server_weblogic weblogic.Server, beasvc.exe
cmdb_ci_app_server_websphere com.ibm.ws.runtime.WsServer
cmdb_ci_db_db2_instance db2sysc.*
cmdb_ci_db_mssql_server sqlServer.exe
cmdb_ci_db_mysql_instance mysqld.*
cmdb_ci_db_ora_instance pmon_${instance}, *tnslsnr.*
cmdb_ci_endpoint_iis w3wp.exe
cmdb_ci_nginx_web_server nginx.*
1. Navigate to Event Management > Settings > Process to CI Type Mapping.

2. Click New or double-click a CI type.
3. Type the process Name, and then select a CI type.

4. Click Submit.
Bind alerts for application CIs

An incoming event from an application CI can bind to an alert based on event rule transform information.
Create an event rule to bind alerts to the host CI and also to the application CI.
For example, you can bind alerts to a SQL server application when the CPU on sqlServer.exe is over 90%:
• Make sure that the event includes the host name.
• Create an event rule with an Event Match Field entry that maps the process name to the
sa_process_name mapping variable. In this case, do not use the CI type.
• Use the Process to CI Type Mapping module to add custom patterns.
In the binding process, the following steps occur:

• Identify the host.
• If the host is found, find the application on the host. An application is considered to be running on the
host if it has a "Runs on:Runs" relationship from the application to the host CI in the cmdb_rel_ci table.
• If the event rule for the transform CI type is defined, find an application CI on that host in the CMDB.
• If all the alert additional_info about the CI matches CMDB CI fields, bind the alert to the application CI.

4. In the Filter condition, select Node, select an operator, and then enter the CI name, FQDN, IP, or
MAC address values for the host binding.
6. Select the application CI type.
7. In the Event Match Fields section, specify any Additional information mappings.
8. Click Submit.
Trigger alerting bind to a CI

You can manually bind an alert to a CI by triggering a new alert.
If an alert did not automatically bind to a CI, you can manually trigger a new alert and rebind:
• Delete the alert and resend the event.
• Close the alert, temporarily set the evt_mgmt.active_interval system property time to 0, and then
resend the alert. After the bind completes, reset the property back to the previous value.
View CIs that have alert binding

Event Management uses the Event Management - Node Count job to show CIs that have alert bindings.
This information is stored in the Licensed Usage [em_unique_nodes] table.
To view CIs that are bound to alerts, navigate to Event Management > License Usage.
If CIs are not bound to alerts or if no alerts were generated for them, CIs are not included in the
Licensed Usage list.

Note: License usage is based on node and domain. For example, where alert Alert0021744
from node tech.mgmt, is bound to the WebServer CI1, and another alert, Alert0012979, from a
different domain, is bound to the WebServer CI2, then the license usage count is 2.
Manage and monitor alerts

An alert is a notification generated by Event Management for selected events that are considered to be
important and require attention. The generation of alerts is based on event rules.
After alerts generate, the manner in which you can monitor and resolve alerts is based on alert
configuration settings and properties, and alert impact calculation.
Create or edit an alert rule

Select the conditions that an alert must match for the rule to apply, and configure actions that the rule can
execute for matching alerts.
To enable remediation, create the workflow to remediate CIs. In the workflow settings, select Remediation
Task [em_remediation_task] in the Table field. After you finish configuring the workflow, make sure you
publish it.
You can configure the alert rule to:
• Use an overwrite alert template to automatically modify alert field values before creating or updating an
alert.
• Use a task template to automatically generate resolution tasks based on alert values, before the alert is
created or updated.
• Automatically generate and link incidents, tasks, or knowledge articles to alerts.
• Automatically apply a remediation workflow or let users manually run remediation.
• Automatically construct a URL that is created according to the value of specified fields in the alert.
Note: If more than one alert rule can apply to an alert, if the alert rules resolve the alert with the
same action, then only one alert rule is applied, according to order. However, if each of the rules
resolves the alert with a different action, then each of these rules apply. For example, if one alert
rule creates a KB and another alert rule creates an incident, then both alert rules are applied.
1. Navigate to Event Management > Rules > Alert Rules.

2. Click New or select an alert rule to edit.

Figure 174: Alert Rule form
Table 423: Alert Rule form
Field Description
Name A name to identify the alert rule.

Active A check box to activate the rule.

Field Description
Alert filter The conditions that an alert must meet for

the rule to apply. Use the condition builder
to construct the rule.
Order The priority for rule evaluation. Rules with
lower-order values are given priority. An
alert is checked against every alert rule until
a match is found.
Action tab
Auto acknowledge A check box to enable automatic
acknowledgment of the alert. An
acknowledged alert indicates that a user is
aware of the issue.
If this check box is cleared, users must
manually acknowledge the alert.
Overwrite alert template The template that is used to overwrite alert

values before additional resolution updates
occur.
Knowledge article A link to the knowledge base article that
contains additional information to help
resolve the alert.
Auto open A check box to automatically open a task,
such as an incident, change, or problem.
Type The type of task to create and attach to the
alert. For example, if Problem is selected, a
problem task is generated with information
from the alert.
Task template The template that assigns actions to the
task Type. For example, a task template
can assign a person or group to address a
Problem task.
When a Type is selected, the template
applies regardless of the Auto open setting
in the alert rule. For example, the template
can apply to manual or auto-generated
tasks as long as an alert rule applies to the
alert.
Remediation tab
Enable remediation The check box to enable remediation with
an Orchestration workflow.
Execution Whether the workflow selected in
the Orchestration workflow field is
automatically invoked or users can invoke it
manually.
Orchestration workflow If the Enable remediation check box is
selected, the remediation workflow runs.

Field Description
Launcher tab
Enable The check box to launch web-based
applications from the Alert Console or
dashboard alert panel.
Display Name A descriptive name for the window that
appears when users launch the application.
URL A dynamic URL that uses specified fields
in the alert, including the Source and
Additional Information fields. For example,
the values in these fields in the alert replace
the parameters in the URL: http://
${source}.com/${my_application}.
In an alert, the value in the Source field is
used for the {source} section of the URL.
The Additional Information field
contains a JSON code with the value
of {my_application}, such as
{'my_application':'application_name'}.
Alert lifecycle configuration

Event Management provides various modules, templates, and properties for configuring alerts and the
actions that execute for these alerts.
Populate alert fields from a task template and custom script

When configuring or modifying an alert rule, you can assign a task template to add required information.
Custom script can be used to dynamically assign alert fields to the task. When required, both task
templates and custom script can be used.
Assigning a task template
Assign a task template to an alert rule to populate fields in the alert that is generated with predetermined
information. The information in the task template fields populate the fields of the resultant alert. This
information is fixed and repeated each time the template is used.
Configuring custom script
Configure custom script to populate fields in the alert that is generated with dynamic information. The
resultant alert shows information that is current and this information can change each time that an alert is
generated.

Assign a task template and use custom script
You can optionally both assign a task template to an alert rule and use custom script that inserts dynamic
values into the alert fields. In this way, certain fixed information is displayed along with information that
changes according to the specified requirements. When both a task template and script are used, the task
template runs first and thereafter the script runs.
Assign a task template from an alert rule
When configuring or modifying an alert rule, you can assign a task template from the template library or
create a task template.
Task templates that you create are added to the task template library. Within an alert rule, you can assign
an existing task template from the template library to the rule, or you can create a new task template. In the
latter case, relevant fields defined in the alert rule automatically populate the corresponding fields in the
task template with values.
2. Click the existing alert rule that you want to modify or click New.
3. Fill in the fields, as required. For more information, see Create or edit an alert rule on page 944.
4. In the Action tab:
a) In the Task template field, click the search icon.
b) In the Task Templates screen, either select an existing task template from the list or click New.
If you clicked New, the User and Table fields are automatically populated with values from the
existing alert rule. The Active option is also automatically selected.
c) In the Short description field, enter the description of the template.
d) In the Template field, specify the field and its corresponding value to add to the task. Repeat this,
as required. This content automatically populates records based on this template.
e) Click Submit. The new task template is automatically assigned as the value for the Task
template field of the alert rule.
5. Click Submit.
Assume that there is an alert rule named InfoTest. This example describes how to create a
task template from within the InfoTest alert rule.
2. Click the InfoTest alert rule.
3. In the Action tab:
• Select Auto open.
• In the Type field, select Incident.
• In the Task template field, click the search icon.
• In the Task Templates screen, click New. The User and Table fields are
automatically populated with values from the existing alert rule. The Active option
is also automatically selected.
• In the Short description field, enter the subject line that must appear in the email
notification.
• In the Template field, specify the required fields and corresponding values.
• Click Submit. The new task template is automatically selected for the Task
template field.

4. Click Submit.
Dynamically assign fields from alerts to its associated task

Use the EvtMgmtCustomIncidentPopulator script to dynamically assign alert fields to the task
template.
Add a custom script to the EvtMgmtCustomIncidentPopulator placeholder to assign fields from the
alert to fields that you specify in the task. For example, use the custom script to query any table and to
assign the value of the alert Severity field to the Short description field in the task.
1. Navigate to System UI > Script Includes.
2. Edit the EvtMgmtCustomIncidentPopulator script to assign fields from the alert to the task that is
opened by default to an incident.
3. Click Update.
The custom script runs against each alert update.
Assume that the current resource type must appear in the Short description field of the
alert. Enter this script in the EvtMgmtCustomIncidentPopulator placeholder:
task.short_description += ' resource: ' + alert.resource;

return true;
Configure an overwrite alert template

An overwrite alert template modifies alert field values before inserting the alert in the Alert [em_alert] table.
For reference purposes, the original information is always available in the event.
You can customize alert field values by adding an overwrite alert template to an alert rule. The template
specifies the alert field values to modify before the alert is written to the Alert [em_alert] table. For example,
you can use an overwrite alert template to reduce the severity of active alerts for test CIs or test sources.
2. Click New or select an existing alert rule to edit.
3. Select Alert filter criteria to match alerts with field values that you want to modify.
4. Click the Action tab.
5. Next to the Overwrite alert template field, click the lookup icon.
6. Click New.
Table 424: Alert Template form
Field Description
Name A name to identify the alert template.

Table The table name for alerts. Read only.
Active A check box to activate the alert template.
User The user who is authorized to change this
alert template.

Field Description
Group The group that is authorized to change this

alert template.
Global A check box to notify all members of your
organization.
Short Description The purpose of the alert template.
Template The alert field name and new substitution
value to use when alert rule conditions are
met.
8. To specify the time interval and conditions for automatically opening an alert:
a) Click Schedule.
b) Fill in the fields as appropriate, and then click Submit.
Table 425: Scheduled Entity Generation form
Field Description
Name The schedule name.

Active A check box to activate this schedule.
Run The interval for generating a task until the
alert or alert group is resolved.
• Daily: Every day at the specified Hour,
Minute, and Second until the alert or
alert group is resolved.
• Weekly: Every week on the specified
Day, Hour, Minute,and Second until the
alert or alert group is resolved.
• Monthly: A day of each month on
the specified Day, Hour, Minute, and
Second until the alert or alert group is
resolved.
• Periodically: The Repeat Interval with
Days, Hour, Minutes, and Seconds
with a Starting date.
• Once: Generate a single task on the
specified Day, Hour, Minute, and
Second.
• On Demand: Generate a single task only
when a user selects Create Incident.
Conditional The set of conditions in which to apply this

schedule.
Generate This The name of the task template that can use
this schedule for generating tasks.
The new template is populated in the Overwrite alert template field on the Alert rule form.

Configure the alert active interval

The active interval property determines how Event Management handles a new event that is similar to
events that appear on an existing alert. Based on the active interval, event, and existing alert information,
the event information is added to either the existing alert or a new alert.
When the new event is received, Event Management compares the active interval time to the elapsed time
between the Time of event and Initial event time field values on the alert. Then either the existing alert is
updated or a new alert is created, as explained in the following table.
Scenario Result
The new event occurs before the active interval The alert is updated with the event information.
elapses for the existing alert. The event is identified as a recurrence of an
existing issue and its severity is copied to the
alert.
If the alert was closed before the active interval
elapses, the alert is reopened and updated with
the event information.
The new event occurs after the active interval A new alert is created because the event is
elapses for the existing alert. identified as a new issue. The event information
is added to the new alert.
Change the active interval by editing the Active interval (in seconds), within which a new event
reopens a closed alert property value.
1. Navigate to Event Management > Settings > Properties.
2. Change the number of seconds for the Active interval (in seconds), within which a new event
reopens a closed alert property.
3. Click Save.
Configure alert flapping

You can set flapping properties to determine when an alert enters and exits the flapping state.
Flapping condition occurs when the event source continues to generate events even after its associated
alert has been closed. Flapping causes the status of the resource to repeatedly fluctuate between an Info
Severity and another severity that requires attention (such as Critical).
An alert enters the flapping state when its current Flap Count value reaches or exceeds the given
evt_mgmt.flap_frequency property value within the time period specified by the evt_mgmt.flap_interval
property.
An alert exits the flapping state when the time interval between the latest occurrence of the event and the
Flap last update time of the alert reaches or exceeds the evt_mgmt.flap_quiet_interval property value.
An alert can also exit flapping in these conditions:
• When an incoming event arrives after the flap_quiet_interval time has elapsed. The new alert generates
and its state value depends on the incoming event severity.

• After a background job, which runs every five minutes, verifies that no alert updates occurred and the
flap_quiet_interval time has elapsed. If there are no updates, the alert shows the previous state value
that it had before the background job ran.

2. Edit the following properties, as appropriate.
• Minimum time in seconds before updating an alert for identical events
(evt_mgmt.update_alert_restricted_fields_elapsed_time)
• Flap interval (in seconds), within which an alert enters the flapping state
(evt_mgmt.flap_interval)
• Flap frequency, frequency an alert must reoccur to enter the flapping state
(evt_mgmt.flap_frequency)
• Flap quiet interval (in seconds), quiet time that must pass for an alert to exit the flapping
state (evt_mgmt.flap_quiet_interval)
3. Click Save.
You can monitor the Event Management > All Alerts list for alerts that are in the flapping state. For
details, see View alerts in the flapping state on page 976.
Configure automatic actions for alerts and incidents

Event Management can perform additional actions after alerts or incidents close, reopen, or age.
You can set properties to allow Event Management to:
• Specify how incidents are handled after an associated alert closes or reopens.
• Automatically close aging alerts.
• Specify how alerts are handled after an associated incident is resolved.

2. Edit the following properties, as appropriate.
• Acknowledge an alert when manually closing it (evt_mgmt.alert_ack_on_close)
• Closing alerts will (evt_mgmt.alert_closes_incident)
• Reopening alerts will (evt_mgmt.alert_reopens_incident)
• Auto close interval (in hours), within which open alerts will be automatically closed; Setting
to 0 disables the feature (evt_mgmt.alert_auto_close_interval)
• Resolving an incident closes the associated alerts (evt_mgmt.incident_closes_alert)
3. Click Save.
Create maintenance rules

Define maintenance rules to mark CIs in maintenance status. When in maintenance status, these CIs are
excluded from impact calculation.
You can define rules to mark CIs that match the specified criteria as being in maintenance status. The
marked CIs populate the Impact Maintenance cis [em_impact_maint_ci] table.

Note: When running maintenance rules, the cmdb_ci status of matching CIs is not changed.
However, matching CIs are flagged in the em_impact_maint_ci table by these rules and this status
is considered for impact and alert calculations.
The maintenance rules provided with the base instance are:

Default maintenance rule Description
CI in Change Window Where the CI has an active change window,

the matching CIs are marked as being in
maintenance status.
The rule runs a query against the change
request [change_request] table to determine if
the rule is applied. All these conditions in the
change_request table must be met:
• State is one of these options: Scheduled,
Implement, Work in Progress, or Open/New
(state in (-2, -1, 1, 2)).
• Approval is Approved (approval =
'approved').
• The change request window is active, that
is, the current time is between Planned start
date and Planned end date) or current time
is between Actual start and Actual end.
• The change request record is not an on-hold
record (on_hold='false').
Note: All these conditions must be present

for the CI to be placed in maintenance status
by this rule. For example, if the State of the
change request approval status is Change is
waiting for approval then the change is
not added to the em_impact_maint_ci table.
Maintenance status of CI CIs whose CMDB status field is In Maintenance
are flagged by this rule as being in maintenance
status.
The use of these legacy scripts has been deprecated:
gs.setProperty('evt_mgmt.impact_maintenance.use_change_request', 'false');
gs.setProperty('evt_mgmt.impact_maintenance.use_in_maintenance', 'false');
1. Navigate to Event Management > Rules > Maintenance Rules.

2. Click New.
Column heading Description
Name The maintenance rule name.

Active Select to activate the maintenance rule.
Clear to deactivate the maintenance rule.

Advanced Select to enable the optional script section

to display.
Description Information that describes this maintenance
rule.
Flag CIs that run on this host Select to flag CIs in a host to be in
maintenance status when the host is in
maintenance.
Table Select the table that contains the CI that you
require.
Filter Specify how to select the data.
CI field name Select the CI from the list. The list is
populated according to your selection in the
Table field.
If a CMDB table, or a table derived from
CMDB, was selected, specify sys_id for
the CI field name. Otherwise, specify the
required CI field that you want to use. See
the examples.
4. Click Submit.
Example of a maintenance rule using a CMDB table.

Assume that a company defines a CI as being in maintenance when the Operational
Status of the CI is either Repair in Progress or DR Standby.

Example of a maintenance rule using a table other than CMDB.

Assume that a company uses Incident records to track maintenance. Any maintenance
request is translated to an incident when it has a description that starts with “Performing
maintenance on CI”. As long as the status of such an incident is open, this status indicates
that the maintenance is in progress. For the CI field name field, specify a CI name from
the table that was chosen, in this case Incident.

Example of a maintenance rule that uses the advanced script feature.

In the Maintenance Rule page, select the Advanced option. You can use this following
script as an example to prepare your own customized script. The return value for
this example script is a text string that represents an array of CI IDs, for example,
['sys_id1','sys_id2','sys_id3'].

Alert impact calculation

Impact calculation shows the magnitude of an outage on CIs, services, alerts, and alert groups. As an alert
generates, factors such as impact rules and CI relationships are used to calculate the severity. The alert
severity is then displayed on the impact tree, business service or manual service maps, and dashboards.
Impact calculations are available for business services, manual services, and alert groups. The following
factors are used to calculate the overall impact of an outage.
• Impact rules.
• Number of related active alerts.
• Past history of the affected CI.
• Relationships between CIs for a particular business service or manual service.
• If the CI element includes a network or storage devices.
• If the CI is in maintenance. CIs in maintenance, alerts on the CI are excluded from impact calculation.
Note: Starting with the Helsinki release, CIs are considered to be in maintenance not only
when an active change request is scheduled, but also when the Status field of the CI is set to In
Maintenance. In both cases, the CI is excluded from impact calculation and alerts for the CI do
not appear in the Alert console.
Note: When a child CI is put in maintenance, it also puts the parent CI in maintenance.
If there is a connection between services, the impact of one service on the other is also calculated.

Figure 175: Impact calculations use information from various sources to set the alert severity
How impact is calculated
Impact calculation varies depending on the CI relationships for a business service or manual service.
Additional factors, such as change requests, network paths, storage paths, and related CIs, all affect
impact calculation.
You can learn about the impact tree from the following video tutorial.
Business services The following impact calculation flow operates for

alerts where the outage does not affect a network or
network storage. Event Management performs the
following steps:
1. Create a business service map. Use the
svc_ci_associated and cmdb_rel_ci tables
to create child-parent relationships in the
business service or manual service.

2. If there is no CMDB path from the business

service to the CI but an association appears in
the svc_ci_assoc table, show a Depends-on
relationship between the business service and
the CI. Otherwise, show no connection.
3. For a manual service, if the CIs assigned to
the service are also connected to the service
in the CMDB, the map keeps the hierarchy
between CIs as they appear in CMDB. The
CI service assignments appear in the Service
Configuration Item Associations section of the
Manual Services form. If there is no connection
to the service in the CMDB, the CIs appear
directly under the service in the map.
4. Create the impact tree. Mark the magnitude
of an outage by 100% down, 60% affected,
40% impaired, or 20% impaired. If the items in
two or more clusters are affected, the impact is
100% down.
Change requests and the In Maintenance status If an active change request is scheduled for the
CI or if the Status of the CI is In Maintenance,
all alerts on the affected CI are excluded from
impact calculation. The Alerts tab and Alert console
also temporarily hide all corresponding alerts. The
impact tree shows the CI in green with a note of (In
Maintenance). The impact tree and the business
service map temporarily show CIs in green.
Note: Starting with the Helsinki release,

CIs are considered to be in maintenance
not only when an active change request
is scheduled, but also when the Status
field of the CI is set to In Maintenance. In
both cases, the CI is excluded from impact
calculation and alerts for the CI do not
appear in the Alert console.
For a business service, all alerts on CIs in the

business service are also hidden from the Alerts
tab. The entire business service is shown in green
on the impact tree. For a host with an active change
request, the host applications are considered as
one unit. All child applications are treated in the
same manner as the host until the change request
is no longer active. For additional information, see
How alerts work with CIs in maintenance on page
1001.
Network paths To account for network redundancy, Event

Management uses a separate impact calculation.
You can see network topology or path changes
in the business service. The following impact
calculation flow operates for alerts where a network

path is affected. Event Management performs the

following steps:
1. Create a business service map for the affected
network.
• Use the host ID and target IP information
from the alert and the network path from the
Network Paths [sa_network_paths] table.
• Use the elements in the network path that
inherit from the Configuration Item [cmdb_ci]
table. Also, use the elements that are
associated to the path, from the Infra Path
To Elements [sa_infra_path_assoc] table.
• Set the relationships. The application CI has
a Depends on::Used by relationship on an
element in the path that is defined in the
CI Relationship [cmdb_rel_ci] table. In the
relationship, the application CI is the parent
and the element in the network path is the
child.
2. Calculate a separate severity for each regular

element in the path. Each regular element
in the path contributes its own severity to its
ancestors up to the application CI where the
path originated from.
3. Calculate all redundant elements in the path
with the redundancy rule by reducing the
severity on the impacted CIs by one level.
For example, if the severity is Critical, the
redundancy rule decreases severity by one
level to Major.
100% down.
Storage paths To account for storage device redundancy, Event

Management uses a separate impact calculation.
You can see impact tree updates when the network
storage topology changes from the business
service. Event Management performs the following
steps for alerts that contain storage CIs:
1. Create a business service map for the affected
storage device:
• Use the storage device in the
sa_fs_to_storage_path table. The storage
device definition uses the file system
information in the path.
• Use the elements in the storage path that
inherit from the Configuration Item [cmdb_ci]
table. Also, use the elements that are

associated to the path from the Infra Path

To Elements [sa_infra_path_assoc] table.
• Set the relationships. The application CI has
a Depends on::Used by relationship on an
element in the path that is defined in the
CI Relationship [cmdb_rel_ci] table. In the
relationship, the application CI is the parent
and the element in the storage path is the
child.
2. Calculate a separate severity for each regular

element in the path. Each regular element
in the path contributes its own severity to its
ancestors up to the original application CI the
path.
3. Use the redundancy rule to calculate redundant
elements in the path by reducing the severity
on the impacted CIs by one level. For example,
if the severity is Critical, the redundancy rule
decreases by one level to Major.
100% down.
Related CIs As alerts generate for a CI, additional impact

calculations run for related CIs. For example
additional impact calculations run for a business
service dependency to a CI that is not actually
part of the business service. These related CIs
are not discovered as part of the service. Instead,
the related CIs are specified by an infrastructure
relationship definition.
The following impact calculation flow operates for
alerts with CIs that have a dependency to related
CIs which are considered outside the business
service. Event Management performs the following
steps:
1. Derive relationships between the business
service CIs and related CIs. Use the
relationships, impact rules, and other
data from the Infrastructure Relations
[em_impact_infra_rel_def] table.
2. Add related CIs to the impact tree and alert list
on the Event Management dashboard.
• Use data from the Infrastructure
Relationship [em_impact_infra_rel_def]
table to show containment links to the host.

• Use the Impact Status [em_impact_status]

and Alert History [em_alert_history] tables to
determine the status.
Impact calculation properties
These properties are available in the Event Management > Settings > Properties module.
Enable alert group support Enables alert group creation.

(evt_mgmt.impact_calculation.alert_group_support)
Minimum time in seconds for checking Determines how often the system checks
CI maintenance: checks both the whether a CI is in maintenance. The system
Status field on the CI and any checks both of these options to see if the CI is in
change request schedule for the CI. maintenance:
(evt_mgmt.impact_maintenance.sleep_time_sec)
• The Status field on the CI record.
• If any change request is scheduled on the CI.
Impact rules
Impact rules, which are used for impact calculation, estimate the magnitude or severity of an outage based
on affected CIs. The Impact Rule [em_impact_rule] table contains impact rules that show the applicable
CIs, business services, and settings for impact. The following default impact rules are available:
Application Cluster Member Determines how application cluster members affect

the overall impact of the cluster. For example, if a
three-member cluster requires 70% Influence to
set the severity for the entire cluster to Major, each
member has 23% Influence (70% divided by 3).
The severity of the entire cluster can only change
to Major when all three members have a severity of
Major.
Inclusion Determines the impact on entities with a Contains
relationship. This rule is read-only.
Infrastructure Dependencies Determines the definition of impact propagation for
CIs in infrastructure relationships.
CI Business Service Determines how impact applies to parent or child
entities that are part of a business service.
CI Impact Applies to manual services. Determines the
relationship between service members. The impact
from child to parent CIs is always 100%. For
example, the parent impact severity is derived from
the child CI with the highest severity.
CI Parent in Application Sets impact only on the parent entity.

Network Path Determines how impact applies to parent or child

entities that are part of a traditional network.
OS Cluster Member Determines how host cluster members affect the
overall cluster status based on a percentage or
number of cluster members. For example, if a three-
host cluster requires 50% Influence to set the
severity of Major, each member has 17% Influence
(50% divided by 3). The severity of the entire cluster
can only change to Major when two or more cluster
members have a severity of Major. The entire
cluster is also considered to be down.
Storage Path Determines how impact applies to parent or child
entities that are part of a storage network.
Adjust impact rules for a CI

Configure impact rules to customize the impact calculation. The impact rules update the overall alert and
show the impact on related CIs. When you change impact rules, the updates apply to alert severity in
places such as the Event Management alerts console and dashboard.
You can view and adjust the impact rules of CIs from the business service map of a service.
1. Open the business service map from either the Event Management dashboard or the Manual Services
list.
Option Description
From the Event Management dashboard 1. Navigate to Event Management >

Dashboard.
2. Double-click the tile of the service.
From the Manual Services list 1. Navigate to Event Management > Manual
Services.
2. Click View Map next to the service.
2. On the business service map, click a CI.

3. Below the map, click the Impact tab and then adjust the impact rules accordingly.

Table 426: Impact Rules
Field Description
Name The name of the impact rule.

• Application Cluster Member:
Determines how application cluster
members affect the overall impact of the
cluster. For example, if a three-member
cluster requires 70% Influence to set the
severity for the entire cluster to Major,
each member has 23% Influence (70%
divided by 3). The severity of the entire
cluster can only change to Major when
all three members have a severity of
Major.
• CI Business Service: Determines how
impact applies to parent or child entities
that are part of a business service.
• CI Impact: Applies to manual services.
Determines the relationship between
service members. The impact from
child to parent CIs is always 100%. For
example, the parent impact severity is
derived from the child CI with the highest
severity.
• CI Parent in Application: Sets impact
only on the parent entity.
• Inclusion: Determines the impact on
entities with a Contains relationship. This
rule is read-only.
• Infrastructure Dependencies:
Determines the definition of impact
propagation for CIs in infrastructure
relationships.
• Network Path: Determines how impact
applies to parent or child entities that are
part of a traditional network.
• OS Cluster Member: Determines how
host cluster members affect the overall
cluster status based on a percentage
or number of cluster members. For
example, if a three-host cluster requires
50% Influence to set the severity of
Major, each member has 17% Influence
(50% divided by 3). The severity of the
entire cluster can only change to Major
when two or more cluster members have
a severity of Major. The entire cluster is
also considered to be down.
• Storage Path: Determines how impact
part of a storage network.

Field Description
Impact On The valid type of service for this impact rule.

• Business Service: The impact rule
applies to a business service.
• Parent: The impact rule applies to the
parent CI.
Influence The value to allow the impact rule to set

on the parent. Set a value on the parent
and each child. This field works with the
Influence Units field.
Influence Units The unit of measurement to show impact
on the parent. Set the highest value on the
parent CI. Set lower values on each child
CI. When alerts occur for several child CIs,
Event Management calculates the sum of
the Influence Units of each affected child.
If the sum exceeds the parent Influence
Units value, the parent receives the highest
severity in the set. This field works with the
Influence field.
• Percent: When the percentage exceeds
the Influence value, apply the impact on
the parent.
• Number: When the number exceeds the
Influence value, apply the impact on the
parent.
For example, you can set the parent
Influence Units to 100% and the child
CIs to these values:
• Child 1: 40%
• Child 2: 40%
• Child 3: 40%
• Child 5: 70%
When alerts for Child 3 and Child 5 have

the Critical severity, the severity of the
parent is set to Critical because the sum
is greater than 100% (40% + 70% =
110%).

Field Description
Impact when Critical The alternative impact to use when the

calculated severity is Critical. If the column
to the right of Impact when Critical has
a higher severity, update all right-most
columns with the same or a lower severity
as Impact when Critical. To make sure
the topology and impact tree accurately
show impact, always update each column
accordingly.
• Critical: Red (highest severity).
• Major: Orange.
• Minor: Yellow.
• Warning: Blue (lowest severity).
Impact when Major The alternative impact to use when the

calculated severity is Major. If the column
to the right of Impact when Major has
a higher severity, update all right-most
columns the same or a lower severity
as Impact when Major. To make sure
the topology and impact tree accurately
show impact, always update each column
accordingly.
• Major: Orange.
• Minor: Yellow.
Impact when Minor The alternative impact to use when the

calculated severity is Minor. Controls the
field values to the right of this field. If the
Impact when Warning column has a higher
severity, use the Impact when Minor value
for both fields. To make sure the topology
and impact tree accurately show impact,
always update each column accordingly.
• Major: Orange.
• Minor: Yellow.

Field Description
Impact when Warning The alternative impact to use when the

calculated severity is Warning. To make
sure the topology and impact tree accurately
show impact, make sure that the columns to
the left have higher severities.
• Major: Orange.
• Minor: Yellow.
Review the changes on the impact tree. For example, if you changed a number or percentage influence for
child CIs, review the impact tree updates accordingly.
Create an infrastructure relationship for related CIs

Infrastructure relationships show CIs that are connected to a business service but are not necessary parts
of the service. Infrastructure relationships are only available for business services.
When you create a CI infrastructure relationship, the information is stored in the Infrastructure Relations
[em_impact_infra_rel_def] table. When alerts generate, the related CI accompanies the business service
information on the Event Management dashboard and in the impact tree. Additional information for the
related CIs only appears on a related dependency view map for the business service. The following default
infrastructure relationships are available.
Table 427: Default infrastructure relationships
Infrastructure relationship Impact rule Description
cmdb_ci_appl OS Cluster Member Shows alert impact between

hardware and software
applications.
cmdb_ci_esx_server Infrastructure Dependencies Shows alert impact between
VCenter and ESX clusters.
cmdb_ci_kvm Infrastructure Dependencies Shows that alert impact on
Linux Kernel-based Virtual
Machine (KVM) connectivity.
cmdb_ci_vm_zones Infrastructure Dependencies Shows alert impact on the
Solaris VM zones.
For example, based on of the cmdb_ci_vm_zones Infrastructure relationship definition, Event Management
adds ZoneServer@mmp1 to the business service. The Containment rule manages impact severity on
alerts.

Figure 176: Related CIs appear on the BSM
1. Navigate to Event Management > Settings > Infrastructure Relations.

2. Click New.
Table 428: Infrastructure Relations form
Field Description
Child Type The table that contains data about the child
entity.
Parent Type The table that contains data about the
parent entity.
Relation Type The relationship between the child and
parent entities.

Field Description
Impact Direction The impacts direction to show on the

business service map.
• From Child to Parent: When an alert is
regarding a child, show the impact on the
parent.
• From Parent to Child: When an alert is
regarding a parent, show the impact on
the child entity.

Field Description
Impact Rule The impact rule to calculate infrastructure

relationships:
• OS Cluster Member: Determines how
host cluster members affect the overall
cluster status based on a percentage
or number of cluster members. For
example, if a three-host cluster requires
50% Influence to set the severity of
Major, each member has 17% Influence
(50% divided by 3). The severity of the
entire cluster can only change to Major
when two or more cluster members have
a severity of Major. The entire cluster is
also considered to be down.
• Application Cluster Member:
Determines how application cluster
members affect the overall impact of the
cluster. For example, if a three-member
cluster requires 70% Influence to set the
severity for the entire cluster to Major,
each member has 23% Influence (70%
divided by 3). The severity of the entire
cluster can only change to Major when
all three members have a severity of
Major.
• Infrastructure Dependencies:
Determines the definition of impact
propagation for CIs in infrastructure
relationships.
• CI Business Service: Determines how
impact applies to parent or child entities
that are part of a business service.
• CI Parent in Application: Sets impact
only on the parent entity.
• Inclusion: Determines the impact on
entities with a Contains relationship. This
rule is read-only.
• Network Path: Determines how impact
part of a traditional network.
• Storage Path: Determines how impact
part of a storage network.
• CI Impact: Applies to manual services.
Determines the relationship between
service members. The impact from
child to parent CIs is always 100%. For
example, the parent impact severity is
derived from the child CI with the highest
severity.

4. Click Submit.
Alert management
As alerts generate, you can view more information about them, acknowledge them, and take action to
resolve them. You can also manually create alerts to track issues that did not generate an event or alert.
You can respond to an alert in the following ways:
• Manually remediate the alert.
• Acknowledge an alert that requires attention.
• Create an incident or security incident.
• Close the alert.
• Resolve any incident that is related to the alert.
• Reopen the alert.
Note: Business rules that are written for alert tables [em_alert] must be highly efficient or they may
result in performance degradation.
View alert information

View a list of all alerts for business services and manual services, and then manage individual alerts as
necessary.
Multiple related events may correlate into a single alert. Event Management only creates alerts when one
or more events meet the conditions defined in event rules, alert rules, and alert configuration settings.
1. Navigate to Event Management > All Alerts.
2. To view or manage an alert, click the alert number.
3. Review the information on the Alert form.
You can click tabs on the form for additional information.
• To view flapping information, click the Flapping tab.
• To view alert history, click the History tab.
Table 429: Alert form
Field Description
Number If an alert was created as a result of the

alert.
100.

Field Description

Resource Node resource that is relevant to the event.
For example, Disk C, CPU-1, the name
of a process, or service. This field has a
Configuration Item JSON string that represents a configuration
item. For example, {"name":"SAP
ORA01","type":"Oracle"}. CI
identifier that generated the event appears
in the Additional information field. This
field has a maximum length of 1000.
Task The corresponding task for the alert, such
as an incident, change, or problem.
Description The alert description.
Severity The severity of the event. The value for this
field is copied from the event unless the
event closes the alert, in which case the
previous severity is retained for reporting.
occurred.
still functional.
alerts are closed.
State The state of the alert.

• Open: The alert requires user action.
• Reopen: The previously closed alert
requires additional user action.
• Flapping: The alert is receiving a high
frequency of identical events from the
same source which causes many alert
reopenings after a close had been made.
User action is required.
• Closed: The alert is closed and no
further user action is required.

Field Description
Category Manner in which an alert derives from one

or more events. If the alert was upgraded
from Fuji, all alert updates have the Regular
category.
• Default: Alert that does not derive from
any alert rule or event rule transform.
• Threshold: Alert that derives from an
event rule threshold.
• Regular: Alert that derives from an alert
rule.
Acknowledged A check box that shows whether a user

acknowledged an alert.
Maintenance A check box that shows whether the
resource affected by the alert is in
maintenance.
Updated The most recent time that the alert
information was updated.
Knowledge Article The knowledge article associated with the
alert, if any.
Description Reason for event generation. Shows
extra details about an issue. For example,
a server stack trace or details from a
monitoring tool. This field has a maximum
length of 4000.
Source instance The name of the machine or software
that generated the event. For example,
SolarWinds on 10.22.33.44.
1024.

Field Description
Additional Information A JSON string that gives more information

is successful"}.
User name and role The user and role of the person who made
the most recent alert updates.
Acknowledged The Acknowledged check box value after
the most alert recent update.
• True: The Acknowledged is selected.
• False: The Acknowledged check box is
cleared.
Severity The Severity: Value of the most recent alert

update.
State The State: Value of the most recent alert
update.
Correlated Alerts section The secondary alerts that are correlated
with this alert, where this alert is the primary
alert. For more information, see Alert
correlation rules on page 1006.
Primary Alerts section The primary alert that is correlated with this
alert, where this alert is a secondary alert.
For more information, see Alert correlation
rules on page 1006.
Flapping tab

Field Description
Flap count The number of times the alert has flapped

—that is, has fluctuated between a closed
and a non-closed state—within the flap
interval since the start time in the Flap start
window.
Flap start window The initial start time to measure the flapping
occurrences.
Flap last update time The last time flapping occurred. This time
is the ServiceNow processing time, not the
source system time.
Flap last state The state before the alert entered the
flapping state.
History tab
Initial event time The time the event that generated the alert
first occurred. This time is the ServiceNow
processing time, not the source system
time.
Last event time The last time the event that is linked to the
alert occurred. This time is the ServiceNow
time.
Created The alert creation time.
Parent The parent alert, if any—that is, any related
alerts that have occurred earlier.
Work notes The additional notes about the alert.
You can respond to the alert in the following ways:
Table 430: Alert response options
Option Description
Submit Save the modifications made to the form and

return to the Alerts list.
Acknowledge the alert. Click Acknowledge. If the alert is reopened, this
button reappears so you can reacknowledge the
alert.
Create an incident. Click Create incident. For more information,
see Manually create an incident from an alert on
page 982.
Create a security incident response, if Security Click Create Security Incident.
Incident Response is activated.
Designate that the alert is in maintenance. Select the Maintenance check box. For
more information, see View all alerts by the
maintenance status on page 977.

Option Description
Close the alert. Click Close. For more information, see Close an
Event Management alert on page 983.
View alerts in the flapping state

You can view alerts that are specifically in the flapping state.
Before starting this procedure, ask your administrator to configure alert flapping properties.
Flapping condition occurs when the event source continues to generate events even after its associated
alert has been closed. Flapping causes the status of the resource to repeatedly fluctuate between an Info
Severity and another severity that requires attention (such as Critical).
The frequency of events from an identical source within a given time interval determines whether an
alert is in a flapping state or a new issue has occurred. Based on the evt_mgmt.flap_frequency and
evt_mgmt.flap_interval property values:
• If the same issue is recurring, Event Management associates the new event with the existing alert and
the state of the alert is set to Flapping.
• If the issue occurs after the time interval expires, Event Management creates an alert.
For example, you can respond to an alert by rebooting a problematic server. After no events are generated
for several minutes, it is assumed that the issue is fixed and the alert is closed. If the reboot did not actually
fix the issue, this server can generate more events later. Then additional alerts are generated for the same
issue.
2. Click the number of an alert that is in the Flapping state.
3. On the alert, click the Flapping tab.
Table 431: Flapping tab on Alert form
Field Description
Flapping tab
window.
occurrences.
source system time.
flapping state.
4. If the Parent field is empty, address this alert as a new issue.

View all alerts by the maintenance status

The Maintenance status indicates that the CI is under maintenance. For example, there is a software
upgrade, and the issues can result from that activity, therefore all maintenance alerts are discarded.
The alert maintenance status can change due to any of these reasons:
• A user selected the Maintenance check box on the alert, or selected the alert from the list view, and
then clicked the Maintenance UI action.
• A new alert that had been bound to a CI whose status is in maintenance status on the CMDB table.
• If all previous events associated with the alert are in maintenance, the alert Maintenance field can
automatically be set to true showing maintenance is in progress. However, if an alert Maintenance
field is false but the related CI status is changed to In Maintenance after the alert was created, any
subsequent events do not put the alert into maintenance. For example, if an alert is generated for a
router and later the router is taken down for maintenance, it is still assumed that there was a problem
before maintenance started and the issue must not be ignored.
Note: If a maintenance flag was set on an alert in Geneva, after upgrading to Helsinki it affects the
impact as a regular alert. However, it is seen in the alert console only when a new event arrives.
1. Navigate to Event Management > All alerts.

2. Review the Maintenance column for each alert.
A value of true indicates that the CI is under maintenance.
Note: If the Maintenance field is not visible on the Alert form, personalize the list to add the
field. For more information, see Personal lists.
Put an alert into maintenance

You can manually put any alert into maintenance to hide it from the alert console and the Alerts tab.
Role required: evt_mgmt_admin, evt_mgmt_operator
Putting the alert in maintenance does not put the CI into maintenance. The Status field on the CI record
remains the same.
2. Perform one of the following actions:
Option Description
To put multiple alerts into maintenance Select the check boxes next to each alert, and
then click the Maintenance UI action at the top of
the list.
To put one alert into maintenance Open the alert, and either select the
Maintenance check box and click Update, or
click the Maintenance UI action at the top of the
list.
Collaborate from within an alert

You can collaborate with colleagues and write work notes while working in an alert.

You can select to work either in a compact view of Connect that overlays the standard user interface or in
a full-screen workspace. The conversations are not copied into the alert.
2. Click the required alert.
3. In the alert screen, click Follow.
The label of the button changes to Following, showing the current connection to collaboration status.
4. To view the Connect sidebar in a full window, click the down arrow in the Follow button and select
Open Connect Full.
You can write text in the Worknote field. This text is not copied into the alert.
5. To collaborate with colleagues or with support, click the Add User icon.
6. To conclude the Connect collaboration session, click Following.
Manually create an alert

An alert can be automatically generated or you can manually create an alert. After creating the alert, an
event is also created in the Event [em_event] table. Alerts that are manually created are useful for testing
purposes.
1. Navigate to Event Management > All Alerts
2. Click New.
Table 432: Alert form
Field Description
Number If an alert was created as a result of the

alert.
100.
Resource Node resource that is relevant to the event.
For example, Disk C, CPU-1, the name
of a process, or service. This field has a

Field Description
Configuration Item JSON string that represents a configuration

ORA01","type":"Oracle"}. CI
identifier that generated the event appears
in the Additional information field. This
field has a maximum length of 1000.
Location The physical location of the CI.
Incident The corresponding incident for the alert.
1024.
Additional Information A JSON string that gives more information
is successful"}.

Field Description
Severity Mandatory. The severity of the event. The

value for this field is copied from the event
unless the event closes the alert, in which
case the previous severity is retained for
reporting.
occurred.
alerts are closed.
still functional.
State The state of the alert.

• Open: The alert requires user action.
• Reopen: The previously closed alert
requires additional user action.
• Flapping: The alert is receiving a high
frequency of identical events from the
same source which causes many alert
reopenings after a close had been made.
User action is required.
• Closed: The alert is closed and no
further user action is required.
Category Manner in which an alert derives from one

or more events. If the alert was upgraded
from Fuji, then all updated alerts have the
Regular category.
• Default: Alert that does not derive from
any alert rule or event rule transform.
• Threshold: Alert that derives from an
event rule threshold.
• Regular: Alert that derives from an alert
rule.
Acknowledged A check box that shows whether a user

acknowledged an alert.
Maintenance A check box that shows whether the
resource affected by the alert is in
maintenance.

Field Description
Updated The most recent time that the alert

information was updated.
Knowledge Article The knowledge article associated with the
alert, if any.
Flapping tab
window.
occurrences.
source system time.
flapping state.
History tab
Initial event time The time the event that generated the alert
first occurred. This time is the ServiceNow
time.
Last event time The last time the event that is linked to the
alert occurred. This time is the ServiceNow
time.
Created The alert creation time.
Parent The parent alert, if any—that is, any related
alerts that have occurred earlier.
Work notes The additional notes about the alert.
4. Click Submit.
You can respond to the alert in the following ways:
Table 433: Alert response options
Option Description
Submit Save the modifications made to the form and

return to the Alerts list.
Acknowledge the alert. Click Acknowledge. If the alert is reopened, this
button reappears so you can reacknowledge the
alert.

Option Description
Create an incident. Click Create incident. For more information,

see Manually create an incident from an alert on
page 982.
Create a security incident response, if Security Click Create Security Incident.
Incident Response is activated.
Designate that the alert is in maintenance. Select the Maintenance check box. For
more information, see View all alerts by the
maintenance status on page 977.
Close the alert. Click Close. For more information, see Close an
Event Management alert on page 983.
Manually create an incident from an alert

When an alert or alert group requires additional work, you can open an incident for it. If Security Incident
Response is activated, a security incident can be created.
You can manually create incidents and security incidents from the Alert form. To prevent duplicate tasks,
the system checks the conditions of all task templates before creating an incident.
You can customize the created incident using the
EvtMgmtCustomIncidentPopulator.populateFieldsFromAlert script include. The customization includes
mapping fields from the alert to the incident or aborting the incident creation according to customized
conditions.
You can populate incident fields using custom alert fields values that where populated from additional
information fields. Use the EvtMgmtCustomIncidentPopulator script include to copy the values to the
incident after copying the data to the alert. For more information, see Custom alert fields on page 931.
Note: If Security Incident Response is activated, the base system includes an alert rule called
Create security incidents for critical alerts. This alert rule creates security incidents when critical
security events are reported.

2. Click the alert Number.
3. To create an incident:
• To create an incident, click Create Incident.
• To create a security incident, click Create Security incident.
4. Click Update.
The created incident appears in the Task field of the Alert form.
Resolve an incident related to an alert

When you resolve an incident that is associated with an alert, the alert can also close according to the
evt_mgmt.incident_closes_alert property.
When you close an incident by clicking Resolve Incident on an open incident, the corresponding alert is
closed, resolved, or left alone as specified by the evt_mgmt.incident_closes_alert system property.

Launch web application from alert

You can launch a web application from an alert that matches the conditions set in an alert rule.
Create an alert rule that is configured to prepare a URL when the conditions that you stipulate are met. For
example, based on the results when the alert parameters are resolved, this feature can open a Knowledge
Base article or construct a URL.
1. Navigate to Event Management > Alerts Console.
2. Right-click the required alert and select Launch Application.
A window appears with a list of available web applications that were configured in the alert rule and
the filter that matches the alert. To see the target URL, point to the cursor over the application name.
Note: If one or more of the alert rule parameters cannot be resolved, the related application
name appears in black. When the alert parameters are resolved, then the application name
becomes a link.
3. Click the name of an application to open the URL in another tab or window in your browser. The
common use case is launch in context to the source management system. Other examples of use is to
search in the knowledge base, not just ServiceNow, but external as well, or any URL base action that
can utilize the alert parameters
Example
A common use case is launch in context to the source management system. Other examples include to
search in knowledge bases, not only within ServiceNow, but externally as well. Any URL-based action can
utilize the alert parameters and the URLs can refer to wikis, messaging services, REST APIs, and so on.
Close an Event Management alert

Close an alert by an event or a user action. Closing an alert also closes any related incident that is not
already resolved or closed.
By closing an alert, any related incident that is not already resolved or closed is closed. This default
behavior can be configured by changing the value of the evt_mgmt.alert_closes_incident property.
1. You can close an alert from the Alert form or the Event Management dashboard.
• To close an event from the Alert form, navigate to Event Management > All Alerts . In the All
Alerts list, click the required alert.
• To close an event from the Event Management dashboard, navigate to Event Management >
Dashboard. In the Alerts panel, click the required alert.
2. In the Alert Properties view, click Close .

When you click Close , the alert is closed without confirmation.
If the alert has any resolved or closed incidents, a work note is added to the incident indicating that the
related alert was closed.
If the alert has an open incident that is not related to any other open alerts, the incident is closed,
resolved, or left alone as specified by the evt_mgmt.alert_closes_incident property.
Reopen an alert
Additional events can cause reopening of alerts, or you can reopen an alert by changing its state. When an
alert reopens, any associated incidents can also be updated or reopened according to the incident state
and the evt_mgmt.alert_reopens_incident property.


When an alert is reopened, the related incident is processed as follows:
• If the incident is not Resolved or Closed, a work note is added to indicate that the related alert was
reopened.
• If the incident is Resolved or Closed, the incident is reopened, a new incident is created, or nothing is
done, depending on the evt_mgmt.alert_reopens_incident property value.
• If the incident is reopened, work notes are added to the incident.
• If a new incident is created, any matching alert rule and task template applies to the incident. If there
is no matching alert rule or template, fields from the existing incident are copied to a new incident.

2. Search by alert number.
3. In the State field, click Reopen.
4. Click Update.
Alert and CI remediation

Alert and configuration item (CI) remediations help troubleshoot and resolve underlying problems that
generate alerts. Remediation is based on Orchestration workflows that can be scripted to perform
remediation tasks such as gathering system information or rebooting a server.
Event Management provides a framework for configuring and implementing a system-wide remediation
plan to resolve, minimize, or prevent problems that generate events and alerts. Configure alert rules to
remediate alerts and CI remediation rules to remediate a set of CIs.
Alert remediation
Use alert rules to associate specific alerts with a remediation workflow. You can apply a workflow to alerts
manually. Alternatively, you can configure the alert rule that executes a workflow automatically for alerts
that match the rule criteria. The workflow can also be scripted to request user approval before executing
subsequent workflow tasks. The workflow is paused for user approval, even if it was automatically
triggered.
CI remediation
Configure remediation more comprehensively by creating CI remediation rules to manually apply

remediation to specific CIs.
Remediation tasks
When a remediation workflow is executed, a remediation task is created to capture details such as the time
that the workflow started to run, the alert that triggered the remediation workflow (if relevant), and the CI
that was remediated. View these tasks to track remediation activities in the organization.
Apply alert remediation
If an alert meets the criteria of an alert rule that enables manual remediation, you can manually apply
remediation to resolve the alert.
Ensure that the alert matches an alert rule that enables manual remediation.

When an alert is initially created, you can select which remediation to run from a list of all applicable
remediations.
1. Find the alert that you want to remediate.
Option Description
From the Event Management dashboard Navigate to Event Management > Dashboard.
You have these options for selecting an alert:
• Select an alert from the list at the bottom of
the dashboard.
• Click a business service tile and select an
alert from the list at the bottom of the service
map.
• Click a technical service tile and select an
alert from the technical service object list, or
select an alert from the Alerts tab.
From the Alerts Console 1. Navigate to Event Management > Alerts

Console.
2. Select an alert from the list.
2. Right-click the alert, and select Run remediation.

3. In the Remediation options dialog box, select the remediation workflow that you want to apply and
click Run.
Create or edit CI remediation

Create a CI remediation rule that lets users manually apply an Orchestration workflow for resolving issues
with specific CIs associated with alerts. Define these CIs in the CI filter conditions of the rule.
Create the workflow to remediate CIs. In the workflow settings, select Remediation Task
[em_remediation_task] in the Table field.
Then submit the workflow definition, and add the following conditions to the workflow properties:
• [Run Remediation][is][true]
• [Workflow][is][<name of the new workflow that you just created>]
For example, if the name of the workflow is CI remediation, add this condition:
[Workflow][is][CI remediation]
After you finish configuring the workflow, make sure that you publish it. For more details, see Create a
workflow.
A CI remediation rule associates a set of CIs that might experience problems with a remediation workflow.
The remediation workflow can either resolve the underlying problem or help troubleshoot the problem that
generated the alert. For example, you can proactively configure a workflow with the appropriate response
actions for predictable alerts. For more details, see the Event Management Remediation short video.
1. Navigate to Event Management > Rules > CI Remediations.
2. Click New, or select a CI remediation to edit.
3. Fill in the fields, and click Submit or Update.

Table 434: CI remediation form
Control Description
CI filter Conditions to match the CIs that you want to

apply this remediation to.
Orchestration workflow The remediation workflow to apply to CIs
that match the filter conditions.
In service maps that are opened from the Event Management dashboard, this remediation can be applied
to any CIs that match the filter conditions. For more information, see Apply CI remediation on page 986.
Apply CI remediation
You can apply remediation to a CI that matches the conditions in a CI remediation rule. The specified
remediation workflow is then executed to perform tasks that help resolve or troubleshoot a problem that the
CI is experiencing.
Ensure that the CI matches a CI remediation rule.
1. Navigate to Event Management > Dashboard.
2. Double-click the tile of the service that includes the CI.
3. On the service map, right-click the CI and select Remediation options.
4. In the Remediation options dialog box, select the remediation that you want to apply and click Run.
The remediations list includes remediations in which the CI matches the filter of a CI remediation rule,
and remediations configured in alert rules for which alerts that are associated with the CI, match the
filter.
View remediation tasks

Event Management automatically creates a remediation task to capture every remediation that was applied
to a CI or to an alert. It gives you an overall view of remediation activities in the organization.
Role required: evt_mgmt_user
Navigate to Event Management > Remediation Tasks.
Column Description
Number Number assigned to this task.

Configuration item Item or service affected by this task.
Priority Priority that was assigned to this task, based
on impact and urgency.
State State of the task, which can be open or
closed.
Assigned to Person that this task was assigned to.
Short description Description for the task.
Task type This task type is a remediation task.

Alert monitoring
Alert generation and remediation can be monitored from the Event Management dashboards, alert
console, and alert timeline.
• The Alerts Console shows incoming alerts for discovered business services, manual services,
technical services, alert groups, and correlated alert groups.
• The Event Management Dashboard displays the health of services. It consolidates alert information
about discovered business services, manual services, technical services, and alert groups. Additional
information is available on the business service map, impact tree, and timeline. If Service Analytics is
activated, additional information about automated alert groups is also available.
• The Overview dashboard displays reports on active alerts. You can drill down to individual alerts from
these reports.
Monitor service health

On the Event Management dashboard, you can view alerts by business service, manual service, technical
service, and alert group. For services, you can also open a business service map to view relationships
between CIs in the service.
Ask an administrator to create at least one business service, manual service, technical service, or alert
group if these do not exist.
The dashboard tiles represent a service, alert group, or CI. Tile sizes correspond to the selection in the
Prioritize by field in the dashboard. A larger tile size represents the severity of the alerts. The tile color
represents the overall alert severity.
You can learn about the Event Management basic components from the following video tutorial:
The following tile icons are available:
Table 435: Dashboard tile icons
Icon Meaning
Represents the status of a discovered business

service.
Represents the status of a manual service.
Represents the status of an Alert group with a

set of corresponding open alerts.
Represents the status of a technical service.
Each tile represents the highest severity of an alert for the service, alert group, or CI. For example, a tile
appears in red if an alert is critical. A green tile indicates either information alerts or no currently active
alerts. As the alert severities change, the dashboard updates accordingly. The following severities are
available:
• Red: Critical severity (highest severity). Immediate action is required. The resource is either not
functional or critical problems are imminent.

• Orange: Major severity. Major functionality is severely impaired or performance has degraded.
• Yellow: Minor severity. Partial, non-critical loss of functionality or performance degradation occurred.
• Blue: Warning severity (lowest severity). Attention is required, even though the resource is still
functional.
• Green: Informational. No severity. An alert is created. The resource is still functional.

2. Do one of the following:
• To view alerts by business service, manual service, technical service, or alert group, click
Services.
• To view alerts in your business group only, click Groups.
3. Do one or more of the following:

Task Action
Prioritize alerts Above the tile area:

1. Click Prioritize by list.
2. Select Severity, Business criticality, or
Cost.
The filter values use the Dashboard

filter dictionary attribute from the
cmdb_ci_service_auto.list to prioritize alerts.
View alert details for a service or group In the tile area:

1. Click the service or group tile.
2. Review the list of corresponding alerts under
the Alerts tab.
3. To view the properties of an alert, double-
click it.
Show or hide alerts by severity In the dashboard header, click the icon of the
lowest severity that you want to view in the
dashboard.
You can also move the slider to the left of the
icon. The dashboard displays only the severities
that are to the right of the slider. For example,
move the slider to the left of the red icon if you
want to view only alerts with critical severity.

Task Action
View the properties of an alert Click Alerts or Correlated Alerts , then double-
click the required alert number.
Note: Alerts of type A (analytic alert

group) do not show in the bottom alerts
panel when the Correlated Alerts is not
selected.
View alerts from another service or group In the dashboard header, click the down arrow,
and then select the service or group name.
Show active alerts for a group In the dashboard header, click Service. Then
click the group name and review the alerts listed
for it under the Alerts tab.
Show alert CI relationships or bindings in a On the dashboard, double-click a tile for the
business service map service. For more information on the business
service map, click View alert impact on CIs in a
business service map on page 995.
Show an aggregation of correlated alerts for Below the dashboard tiles, click Correlated Alert.
services and alert groups
Remediate an alert Under the Alerts tab, right-click the alert and then
select Run remediation.
4. To reduce the number of alerts that display in the alerts panel, enable Correlated Alerts.
The alerts panel displays alert groups and alerts that have not been grouped.
Note: The Correlated Alerts toggle also displays in the Alerts Console. When either the
Alerts Console or the dashboard is opened, the Correlated Alerts toggle opens in the setting
that was last selected.
Create a customized dashboard view

You can create a customized dashboard view and save it as a favorite link in the navigation tree.

You can filter business services and save the customized dashboard view as a favorite link.
1. Navigate to Event Management > Settings > Dashboard Views.
2. In the Dashboard Views screen, click New.
3. In the Name field, enter a descriptive name for the dashboard view.
4. Select Active.
5. Specify the filter conditions and click Submit.
6. Click the options menu in the title next to Dashboard Views.
7. In the context menu, click Create Favorite.
8. In the Create Favorite screen, the name that you specified for the view is displayed. You can
optionally edit the name. Select a symbol and its color for displaying to the left of the dashboard view
name.
9. Click Done. The dashboard view name and its symbol appear in the navigation tree.
10. In the navigation tree, click the required dashboard view name to display the customized dashboard.
Monitor and manage alerts

Alerts can be monitored and managed from the alerts console.
You can perform the following activities:
• The Alerts Console shows incoming alerts for discovered business services, manual services,
technical services, alert groups, and correlated alert groups.
• The Event Management Dashboard displays the health of services. It consolidates alert information
about discovered business services, manual services, technical services, and alert groups. Additional
information is available on the business service map, impact tree, and timeline. If Service Analytics is
activated, additional information about automated alert groups is also available.
• The Overview dashboard displays reports on active alerts. You can drill down to individual alerts from
these reports.
Monitor incoming alerts

In the Alerts Console, you can review the status of alerts. For example, you can view and filter all active
alerts by severity.
You can learn about Event Management basics, including the Alerts Console, from the following video.
Navigate to Event Management > Alert Console.
Number Unique ID generated by Event Management

to identify the alert.

Group An entry in this column indicates that the

associated alert is a member of a correlated
alert group. Alerts that do not have an entry
in this column are ungrouped alerts.
• CMDB: CIs without historical data that
were correlated by Service Analytics
based on CI relationships in the CMDB.
• Manual: This is a correlated alert group
that is formed when right-clicking an
alert and setting it as secondary to the
selected primary alert.
• Secondary: This alert is a component
of a correlated alert group. The alert at
the head of the group is a known as the
primary alert. When Correlated Alerts
is selected, the secondary alerts that are
under the primary alert do not display,
making the Alerts Console less cluttered
and easier to review.
• Blank: This is an ungrouped alert. To
make an ungrouped alert become a
member of a group, right-click it and
select in the topic Add to Groups. Select
the alert and click Add Selected.
• Automated: Correlated automatically by
Service Analytics. A virtual alert is added
to the group as the primary alert of the
group.
• Rule: Alert group created as a result of a
user configured correlation rule.
Severity The severity of the event. The value for this

field is copied from the event unless the
event closes the alert, in which case the
previous severity is retained for reporting.
occurred.
still functional.
alerts are closed.


the event, for example, SolarWinds
or SCOM. Optionaly, you can enter a
description, for example, Group Alert.
Configuration item JSON string that represents a configuration
ORA01","type":"Oracle"}. The CI identifier
that generated the event appears in the
Additional information field. This field has
a maximum length of 1000.
100.
Task The corresponding task for the alert, such as
an incident, change, or problem.
Impacted Services Indicates the number of business services
affected by this alert group. For example, an
alert with a severity status of Major, might
affect eight business services. Whereas, an
alert with a severity status of Critical, might
affect one business service.
Last remote time Date and time of the flow of information from
the external source device.
If ITOM Metric Management is activated, you can right-click an alert and click View Metrics to open the
integrated Metrics Explorer and Dependency Views map for the CI that is associated with the alert.
Monitor alerts for a manual service
If you want to view information for only manual services, navigate to the Manual Services list. From this list,
you can open business service maps to view and manage alerts for the CIs in each service.
1. Navigate to Event Management > Manual Services.
2. Click View Map.
3. Do one or more of these actions:
Option Action
View alert details for a CI In the business service map:

1. Click a CI tile.
2. Below the map, click the Alerts tab and
review the listed alerts.

Option Action
View impact on the CI parent In the business service map:

1. Click a CI tile.
2. Below the business service map, click the
Impact tab and review the listed impact
rules.
3. Adjust the impact rules as necessary.
Change the map display, map layout, or map In the business service map header:
indicators
1. Click the menu icon.
2. Configure the appropriate settings.
Navigate to another manual service In the business service map header:

1. Click the down arrow next to the service
name or the folder icon for all services.
2. Search for and select another manual
service ( ).
The icon color represents the highest impact or

severity for active alerts on the manual service.
• Major: Orange.
• Minor: Yellow.
View properties for a CI In the business service map:

1. Click a CI tile.
2. In the side pane, click the Properties tab
and review information about the CI.
3. If you want to view more detailed information,
scroll to the end of the pane and click
Detailed Properties.
View the alert timeline

Identify outage trends over a period of time by viewing the alert timeline.
You can view the alert timeline to visualize the number of alerts by severity by month, quarter, or year. If
there are no alerts for the period, the lane is blank.
This video shows the basic components of Event Management, including the alert timeline.
1. Navigate to Event Management > Alert Timeline.
2. To view a set of alerts, click a month, quarter, or bubble for a particular day.

If there are no alerts during a selected period, nothing appears.
Under each month, an indicator displays the number and severity of alerts in a period.
3. Use the following keys to move forward and backward through the timeline:
Option Description
To move forward Press the Up or Leftarrow key.

To move backward Press the Down or Rightarrow key.
4. To change the labels and colors for the timeline:
a) Click Settings and then click Configure.
b) In the Personalize Timeline dialog box, select conditions, labels, and colors for the lanes and
panels.
c) Click Submit.
Manage alerts in the Alerts Console

In the Alerts Console you can manage individual alerts, as needed.
1. Navigate to Event Management > Alert Console.
2. To manage an alert, right-click it and select any of the following options.

Option Description
Copy URL to Clipboard The URL is copied to your clipboard. For

more information about the URL, see
Launch web application from alert on page
983.
On some browsers, you are prompted to
manually copy the URL to the clipboard.
The ServiceNow platform frame around the
dashboard is not included in the link.
Copy sys_id The SYSId of the alert is copied to the

clipboard.
Launch Application Launch a web application from an alert that
matches the conditions set in an alert rule.
Run remediation Displays a list of remediations that can be
executed for the alert. If no options are
available, the alert does not match any
alert rules that enable remediation. After
remediation is executed, a remediation task
is created with a reference to the alert.
Assign Tag Create and assign tags to specific records to
group and organize alerts.
Acknowledge Selects the Acknowledge check box on
the Alert form to indicate that the alert is
acknowledged.
Add to groups Select the alerts that you want to manually
group. For more information, see Add alert
to an alert group on page 1006.
Close Marks the alert as closed to indicate that
the alert is resolved and requires no further
action.
View Metrics Opens a dependency views map in metrics
mode for the CI that is associated with the
alert. The metrics data of the CI is displayed,
and you can use the Metrics Explorer to
build metric charts.
Maintenance Selects the Maintenance check box on the
Alert form to indicate that the related CI is
receiving maintenance. Selecting this check
box does not change the Status field of the
CI.
View alert impact on CIs in a business service map

The business service map shows active alerts for CIs and the relationships between CIs. The business
service map is available for both discovered services and manual services.

A business service map shows alerts with impacted CIs and CI interdependencies. For example, changes
to a connection between a host and hypervisor appear on the business service map. As the business
service map definition or the statuses of alerts change, the business service map, alert, and impact
information updates accordingly. You can open a business service map from these places:
• From the Manual Services list, you can view business service maps for manual services.
• From the Event Management dashboard, you can view business service maps for discovered services
and manual services.
The following icons are used in business service maps. The icon shapes are slightly different for manual
services.
Table 436: Business service map icons
Icon Description
The application server icon represents

applications such as Microsoft IIS or SQL
servers.
The call server icon represents physical and VM
computers and servers.
The entry point icon represents the network

starting point. For example, Layer 3 devices
appear toward the top of the map, and
connected software and services appear near
the end of the map.
The redundancy arrow shows the number of
redundant CIs.
The load balancer icon.
The grey connector shows a relationship

between CIs.
Each box represents a network CI. A grey box

represents a CI with no active alerts. Information
about the CI is hidden.
The redundancy icon hides multiple CIs that are

designated as redundant.

Icon Description
An impacted CI displays the color that

represents the severity of the alert associated
with the CI.
• Critical (red): Immediate action is required.
The resource is either not functional or critical
• Major (orange): Major functionality is
severely impaired or performance has
degraded.
• Minor (yellow): Partial, non-critical loss of
occurred.
• Warning (blue): Attention is required, even
• Info (green): An alert is created. The
resource is still functional.
• No color: No active alerts.
The storage icon represents fiber channel, hard

drives, or other data storage devices.
The web server icon represents related web

services for the network such as NGINX or
JBoss.
1. Open the business service map for the service from either the Event Management dashboard or the
Manual Services list.
Option Description

Dashboard.
Services.

Option Action
View alerts for a CI by type and severity In the business service map:
1. Click a CI tile.
2. Below the map, click the Alerts tab and
review the listed alerts.

Option Action
View changes to a CI in a discovered service In the business service map:

1. Click a CI tile.
2. Below the map, click the Changes tab.
Show alert bindings to CIs In the business service map:

1. Click a CI tile.
2. Click the menu icon, and turn on the
Affected CI's indicator.
3. Below the map, click the Affected CI's tab.
View CI properties In the business service map:

1. Click a CI tile.
2. In the side pane, click the Properties tab
and review information about the CI.
3. If you want to view more detailed information,
scroll to the end of the pane and click
Detailed Properties.
Show impact rules for a CI In the business service map:

1. Click a CI that has a severity.
2. Below the business service map, click the
Impact tab and review the listed impact
rules.
Show alert details for networks or storage for In the business service map:
a business service
1. Right-click a path between CIs.
2. Select Show network path or Show
storage path.
Display additional information for CIs In the business service map header:
1. Click the menu icon.
2. Turn on the Map Indicators for the
additional information that you want to view.
Remediate a CI In the topology, right-click the CI, and then select

Remediation options.
View discovered service history

The discovered service history shows the frequency of discovered services for a particular time period.

You can view the discovered services history by business service . The discovered services history is
not available for manual services. The discovered services history appears only when there are multiple
discovered services that occur over a period. A discovered service is a business service that is discovered
by Service Mapping. If no discovered services are generated for a particular business service, the
discovered services history is hidden. The color corresponds to the discovered services severity, and the
length of the bar in each color corresponds to how long the discovered services stayed at that severity.
Figure 177: Discovered services history

2. Double-click a business service tile.
3. On the business service map, click a CI that has a severity color.
4. To change the information that appears on the discovered services history, click a history icon.
• Calendar icon: Show information for currently active discovered services.

• H: Show information for discovered services that occurred in the past hours.
• D: Show information for discovered services that occurred in the past 24 hours.
• W: Show information for discovered services that occurred in the past week.
• M: Show information for discovered services that occurred in the past month.
View the impact tree

The impact tree shows the relationships between CIs and the relative percentage impact for each child CI.
This information is available for both discovered services and manual services.
The impact tree shows the result of impact rules on CI parent and child relationships. The tree represents a
business service map with CIs from the Service Configuration Item Association [svc_ci_assoc] table. When
related CIs are connected but not part of the business service map, the impact for the related CIs can also
appear in the impact tree.
The numbers or percentages on a parent CI summarize overall severity based on alerts from child CIs. The
parent severity is based on impact rule computations.
You can also learn about the impact tree from the following video tutorial.

Figure 178: Impact Tree
1. Open the business service map for the service from either the Event Management dashboard or the
Manual Services list.
Option Description

Dashboard.
Services.
2. On the business service map, click a CI that has a severity color.

3. Click the Impact tab.
4. From the Impact Tree tab in the side pane, expand the parent CI and click the CI that generated
alerts.
5. Use the severity color to locate CIs that contain alerts:
• Critical (red): Immediate action is required. The resource is either not functional or critical
• Major (orange): Major functionality is severely impaired or performance has degraded.
• Minor (yellow): Partial, non-critical loss of functionality or performance degradation occurred.
• Warning (blue): Attention is required, even though the resource is still functional.
• Info (green): An alert is created. The resource is still functional.

Option Description
Adjust impact rules 1. Click the Impact tab.

2. Review and adjust the impact rules as
necessary.
Remediate an alert 1. Click the Alerts.

2. Right-click the alert and select Run
remediation.
How alerts work with CIs in maintenance

When a CI is in maintenance, the impact tree, the business service map, and Alerts tab are updated based
on various factors.
A CI is in maintenance when:
• A change request is scheduled for the CI.
• The Status field on the CI record is set to In Maintenance.
Note: To customize how alerts work with CIs in maintenance, see Create maintenance rules on
page 952.
You can learn about how alerts work with CIs from the following video tutorial.

How CIs in Maintenance appear in Event Description and the optimal time to resolve the
Management alert
An active change request has the following

values:
• The State is Scheduled or Implement.
• The current time is between the Planned start
date and Planned end date on the change
request.
OR
• The current time is between the Actual start
date and Actual end date on the change
request.
You can monitor the progress of the change

request. Wait until the change request moves
to the Review or Closed state. Then you can
address all alerts for the affected CI and any
alerts that generated between start and end
dates. Use the impact tree, topology, and Alerts
tab to show the calculated impact severity.
Figure 179: CI with an active change request
Note: As of the Helsinki release, the
If an active change request is scheduled for the Maintenance check box for an alert
CI or if the Status of the CI is In Maintenance, is selected when the Status field on
all alerts on the affected CI are excluded from the CI record is In Maintenance. This
impact calculation. The Alerts tab and Alert Maintenance check box indicates that
console also temporarily hide all corresponding the alert must be hidden from the Alerts
alerts. The impact tree shows the CI in green tab and Alert console.
with a note of (In Maintenance). The impact tree
and the business service map temporarily show
CIs in green.
Note: When a child CI is put in

maintenance, it puts the parent CI in
maintenance as well.
For a business service, all alerts on CIs in the

business service are also hidden from the Alerts
tab. The entire business service is shown in
green on the impact tree. For a host with an
active change request, the host applications are
considered as one unit. All child applications are
treated in the same manner as the host until the
change request is no longer active.

How CIs in Maintenance appear in Event Description and the optimal time to resolve the
Management alert
An inactive change request has the following

values:
• The State is New, Assess, Authorize,
Review, Close, or has no changes at all.
• The State is Scheduled or Implement.
However, the current time is before or after
the planned or actual date ranges on the
change request.
You can monitor the progress of the change

request. When a CI has an inactive change
request, you can address the corresponding
alerts as appropriate.
Figure 180: CI with no active change request

and not in maintenance
When there is no active change request for

a CI and when the CI is not in maintenance,
impact calculation resumes. The impact tree, the
business service map, and Alerts tab show the
calculated impact severity for alerts.
Use the Event Management overview dashboard

From the Overview dashboard for Event Management, you can view and edit reports on active alerts, such
as the state of current alerts, the CIs with the most alerts, and alert incidents by severity.
Note: The Event Management Overview dashboard does not display information on alerts for CIs
that are in maintenance. If you want to view the status of alerts for CIs in maintenance, see the
Event Management > All Alerts list.
By default, the Overview dashboard displays these reports for active alerts:
Table 437: Overview dashboard reports
Report Description
Top Configuration Items with the most Alerts The CIs with the most alerts by severity.
Alert State The state of any open alerts.
Alert Incidents by Severity The number of incidents associated with any
open alerts. If there are no incidents associated
with alerts, this report is empty.
Services Affected by Alerts The number of alerts by business service.

Report Description
Alerts (last 7 days) A list of the most recently opened alerts.
1. Navigate to Event Management > Overview.

2. Perform any of the following actions.
Option Description
See the information represented by a chart Point your cursor to the segment to see a tooltip
segment with the details.
See a list of alerts with the severity Click the chart segment. A list of the alerts opens.
represented by a chart segment
The color of the segment represent the alert
severity.
• Critical (red): Immediate action is required.
The resource is either not functional or critical
• Major (orange): Major functionality is severely
• Minor (yellow): Partial, non-critical loss of
occurred.
• Warning (blue): Attention is required, even
• Info (green): An alert is created. The resource
is still functional.
Save the chart as an image file If a menu icon appears when you point your
cursor to a chart, you can click the icon to export
the chart to an image file.
Alert group types

Alerts are correlated, or grouped, either automatically or manually into (R)ule-based, (A)utomated,
(M)anual, or (C)MDB alert groups. Grouping alerts enables you to narrow down problems by focusing on
the primary alerts in the correlated group.
You can view all correlated alert groups by navigating to Event Management > Alert Console. The icon in
the Group column denotes the alert group type. Alerts that do not have an entry in the Group column are
not correlated with any group.
Table 438: Alert group types
Type Icon Description More information
Rule-based R Related alerts that have been grouped according to Create an alert
compliance with alert correlation rules. Alert correlation correlation rule on
rules are used to group alerts that are related. page 1009
Automated A Groups that are correlated automatically by Service Service Analytics
Analytics. A virtual alert is added to the group as the automated alert
primary alert of the group. groups on page
1019

Type Icon Description More information
Manual M Alerts that have been manually grouped. To manually group

open alerts:
1. Right-click an
ungrouped alert
and select Add
to groups.
2. In the Select
Primary Alerts
screen, select
the alerts
that must be
grouped and
click Add
Selected.
CMDB C Based on CI relationships in the CMDB, for CIs without CMDB alert groups
historical data that could have been used to group on page 1021
alerts.
Double-click the Group column for an alert group to open its Grouped Alerts dialog box, where you can:
• Display all alerts in the group.
• Provide feedback about the usefulness of the group.
• Manually add or remove alerts from the group.
View timeline for alert groups

A timeline format that displays alerts and alert groups that correspond to the alerts and alert groups
currently visible in the list view in the alerts console.
A line of blue dots at the top of the timeline view represent all the alerts displayed in the list view, and all
the alerts that are included in the alert groups displayed in the list view. Alert groups and alert bubbles are
displayed underneath across a timeline, according to the update time of the alerts.
2. Enable Group Timeline and do any of the following:
• Double-click a group name in an alert group in the timeline view to display the set of alerts within
the group. For details about the alert form, see View alert information on page 971.
• Hover over a blue dotted alert, or over an alerts bubble in a group to display further details.
• Zoom into alert groups to change the time granularity of the timeline. Drag the mouse over a
collection of alert groups or blue dotted alerts to highlight the area of the timeline to zoom into.
• Use one of the time presets to display alerts from a certain period such as alerts from the past 7
days.
• Click an alerts bubble to open the Grouped Alerts dialog box which displays the individual alerts in
the group. This view is equivalent to clicking a group in the list view.
• Page through the list view to display the timeline for another set of alerts and groups.

Add alert to an alert group

After viewing the individual alerts in an alert group, you might conclude that an alert should be added to an
alert group. Manually add that alert to an existing alert group so the group is more complete and useful in
troubleshooting an incident.

2. Click the alert group to which you want to add alerts.
3. In the Grouped Alerts dialog box click Add Secondaries.
4. In the Add Alerts dialog box, select the alerts that you want to add, and then click Add Selected.
The Add Alert to This Group dialog box lists all open alerts which are not included in any alert group.
5. To remove an alert, click Actions on selected rows, and then click Remove.
After viewing the individual alerts in an alert group, you might conclude that an alert should be
removed from the group. Manually remove that alert from an existing alert group so the group is more
accurate and useful in troubleshooting an incident.
If an alert group is left with one or no alerts after all alerts are removed, the group is deleted and
no longer displays in alert group lists. The virtual primary alert that was added when the group was
created, is closed.
On the Alert form, verify that the newly added alerts appear in the Alerts tab.
Provide feedback for an alert group

As you view the details of an automated alert group, you can provide feedback about the accuracy and
usefulness of the group. This feedback can help future analysis, and over time, accumulated feedback
continues to improve the accuracy of alert aggregation.
To ensure that the feedback is used for aggregation of automated alert groups, the property
sa_analytics.agg.query_customer_feedback_enabled must be set to true.
To create Service Analytics automated alert groups, aggregation algorithms rely partly on historical data in
the alert knowledge base from similar past events. As alerts continue to be generated and processed, data
is collected and incorporated into the alert knowledge base for future analysis.
Feedback provided on the accuracy and helpfulness of an automated alert group will be incorporated
into future analysis. Service Analytics tracks manual addition and removal of alerts from automated alert
groups for which feedback was provided. The next time that the same types of alerts are encountered with
similar time correlation - this feedback is taken into account and Service Analytics automatically repeats
the addition or removal actions that were previously applied manually.
2. Locate the group for which you want to provide feedback, and double-click the link in its Group
column to open the Grouped Alerts dialog box.
3. Examine the alerts that are included in the group.
4. Based on your analysis of the accuracy and helpfulness of this group, respond Yes or No to the
question Was this group helpful?.
Alert correlation rules

Alert correlation rules enable you to manually classify alerts into primary and secondary, and establish a
relationship between them. Use alert correlation rules to group alerts that are related.

For example, if a server in your organization goes offline, you do not need to see additional alerts that
show that the virtual machines or applications running on the server are also down. Instead, these
additional alerts, or secondary alerts, are grouped under the root alert called the primary alert. You can see
these grouped alerts in the alert console.
Note: Service Analytics provides alert groups for an automated correlation of events and alerts.
These alert rules give you full manual control of alert correlation. For more information on the
service analytics feature, see Service Analytics automated alert groups on page 1019 .
Primary and secondary alerts
• A primary alert identifies the root cause of an event.

• A secondary alert is another alert that the same event generates, but is considered less important than
the primary alert.
The purpose of specifying secondary alerts is to identify which alerts to suppress, so you can reduce the
amount of alert noise and focus on the primary alert. You are able to see both types of alerts, but the
secondary alerts are grouped under the primary alert in the alert console view.
Figure 181: Correlated alerts grouped under the primary alert (Alerts Console)
How primary and secondary alert rules work
Primary and secondary alert rules are simply filters that specify which kinds of alerts are classified as
primary and which kinds are classified as secondary. The filter criteria runs against the Alert [em_alert]
table.
An alert can belong to more than one group, but only one level of secondary alerts is allowed under a
primary alert. For example, if secondary alert A is grouped under secondary alert B, both alerts become
secondary alerts under the same primary alert. See alert hierarchy for more information.
Alert relationships
Alert correlation rules enable you to specify what type of relationship the primary and secondary alerts
must have for the rule to match. These relationships depend on the relationships between the CIs in the
CMDB:
• None: Ignores the relationship between the primary and secondary alerts.
• Same CI: Both alerts need to be related with the same CI. If the CI field is blank, then the alerts need to
have the same Node value.
• Parent to Child: The relationship between the primary and secondary alert is a parent-child CI
relationship in the CMDB (in the CI Relationships table [cmdb_rel_ci]).

• Child to Parent: The relationship between the primary and secondary alert is a child-parent CI
relationship in the CMDB (in the CI Relationships table [cmdb_rel_ci]).
When correlation rules run
Alert correlation rules run when an alert is created or reopened. The alert is checked to determine if it
matches being primary or secondary.
When the primary alert severity is changed to Closed, the secondary alerts are also set to Closed unless
they are part of other groups where the primary alert is not yet set to Closed.
Alert hierarchy
Only one level of secondary alerts is permitted. In situations where a secondary alert has its own
secondary alert, the Event Management application flattens the hierarchy to preserve only two levels.
For example, assume alert A is the primary alert and alert B is the secondary alert. If alert C becomes a
secondary alert for alert B, the application flattens the hierarchy so that A remains the primary and B and C
become sibling secondary alerts, one level below A.
As another example, assume that there are three correlation rules that produce the following results:
• Rule 1 (with an Order value of 1): B becomes a primary alert for A.
• Rule 2 (with an Order value of 2): A becomes a primary alert for C and D.
• Rule 3 (with an Order value of 3): E becomes a primary alert for A.
When alerts B, C, D, and E are triggered, they all appear in the console separately because there are no
correlations between them.
When alert A is triggered:
1. Rule 1 makes A a secondary alert under alert B.
2. Rule 2 makes both C and D secondary alerts under alert A.
3. Rule 3 makes A a secondary alert under E, giving alert A two primary alerts above it in the hierarchy.
Therefore, if all alerts are triggered, only B and E appear in the alert console indicated as primary alerts.
Note: A secondary alert can be correlated with more than one primary alert, and vice versa.
View correlated alerts

You can view primary alerts on the alert console and see correlated alerts on a primary alert record.
The Group column contains an icon indicating that an alert is a primary alert that has one or more
secondary alerts correlated with it.
2. Ensure that Correlated Alerts is selected.

The Alerts Console displays grouped alerts and ungrouped alerts.
3. Click the primary alert number to open the record for the primary alert.
The Correlated Alerts section shows a list of all the secondary alerts that are correlated with this
primary alert.
Figure 182: Correlated alert example
Create an alert correlation rule

Create an alert correlation rule to specify a primary alert and a related alert that is of secondary
importance.
1. Navigate to Event Management > Rules > Correlation Rules.
2. Click New.
4. Click Submit.
Field Description
Name A descriptive name to identify the correlation

rule.
Order The priority for rule evaluation. Rules with
lower order values are given priority. An
alert is checked against every alert rule until
a match is found.
Description A description of the rule.
Active Select to activate the rule.
Advanced Select to display the script field. This option
enables you to script the event correlations.

Field Description
Primary Alert The filter condition to identify the alert that

is the primary alert, or most important alert,
in a set of related alerts. Configure the filter.
See an example.
Secondary Alert The filter condition to identify the alert that
is related to the primary alert but is of lesser
importance. Configure the filter. See an
example.
Relationship Type Specify the type of relationship between the
primary and secondary alert:
• None: Ignores the relationship between
the primary and secondary alerts.
• Same CI: Both alerts need to be related
with the same CI. If the CI field is blank,
then the alerts need to have the same
Node value.
• Parent to Child: The relationship
between the primary and secondary alert
is a parent-child CI relationship in the
CMDB (in the CI Relationships table
[cmdb_rel_ci]).
• Child to Parent: The relationship
between the primary and secondary alert
is a child-parent CI relationship in the
CMDB (in the CI Relationships table
[cmdb_rel_ci]).
Time Difference in Minutes The minutes between which the primary

and secondary event must occur in order to
match this rule.
Note: The value for this entry

cannot exceed 1440 minutes (one
day).

Field Description
Script Custom script that you can modify to return

a JSON string that specifies the primary
and secondary alerts. Select Advanced
to display this field. The currentAlert is a
GlideRecord of the alert that was opened/
reopened and matched the filter. The return
JSON can have both primary and secondary
arrays. In the following example script, the
current alert is saved as secondary alert to
all other alerts in the Alerts table.
(function
findCorrelatedAlerts(currentAlert)
{
var res = {
'PRIMARY': []
};
var gr = new
GlideRecord('em_alert');
gr.addQuery('message_key',
'!=',
currentAlert.getValue('message_key'));
gr.query();
while (gr.next()) {
res['PRIMARY'].push(gr.getUniqueValue());
}
return JSON.stringify(res);
})(currentAlert);

Figure 183: An example alert correlation rule filter
If you delete a correlation rule, the existing correlation groupings on the alert console are not removed.
Service Analytics
ServiceNow® Service Analytics enhances Event Management with alert data analysis and alert aggregation
for technical services, manual services, and alert groups. It also provides root cause analysis (RCA) for
business services discovered by Service Mapping and for manual services.
With Service Analytics, you can do the following:
• Aggregate alerts.
Correlate alerts according to timestamps and CI identification creating automated alert groups. This
helps organize incoming real-time alerts, and reduce alert noise. An operator can then easily identify
related issues across the data center, in the context of services.
• Apply RCA to identify the root cause CI and associated discovered business services or manual
services that the initial root alert was generated for.
Service Analytics identifies root cause CIs for discovered business services and for manual services,
and then aggregates similar alerts from the root cause CI and from its related CIs into an automated

alert group. An operator can drill down and determine which CIs and alerts are affecting discovered
business service and manual service health.
• Correlates alerts based on CIs' relationships in the CMDB, creating CMDB alert groups.
• Visualize the correlation between alerts, services, and root cause CIs for discovered business services
and for manual services in a service map.
Components installed with Service Analytics

The Service Analytics plugin adds tables, system properties, Mid-Server capabilities, and scheduled jobs.
Tables installed with Service Analytics

Service Analytics adds the following tables.
For additional tables that are shared between Service Analytics and Event Management, see Tables
installed with Event Management on page 831.
Table Description
SA RCA Status Information (such as IDs) for the latest

messages that were sent to the ECC Queue for
[sa_rca_status]
a service during RCA.
SA RCA Output RCA learner output data.
[sa_rca_output ]
SA RCA Group Automated alert groups for the RCA query.

[sa_rca_group]
SA Analytics Alert Staging Staging table for alerts used for analytics.
[sa_analytics_alert ]
SA RCA Input Input data for the RCA learner.

[sa_rca_input]
SA Analytics Status Last run information to be used for alert

aggregation and RCA.
[sa_analytics_status]
SA RCA Group Alert Alerts associated with automated alert groups.

[sa_rca_group_alert ]
SA RCA Service Configuration Item Association Associations between CIs and services.
[sa_rca_svc_ci_assoc]
SA RCA SMC Config Base State Model Configuration base.

[sa_rca_smc_config_base] User defined RCA configurations. Each
configuration is associated with one or
more rules in the SA RCA SMC Rule Base
[sa_rca_smc_rule_base] table, if applies.

Table Description
SA RCA SMC Rule Base Service Analytics (SA) Root Cause Analysis
(RCA) State Model.
[sa_rca_smc_rule_base]
Individual rules that are associated with RCA
configuration in the SA RCA SMC Config Base
[sa_rca_smc_config_base] table.
SA RCA SMC Config RCA Configuration revisions table.

[sa_rca_smc_config] Snapshots of RCA configurations generated
during configuration comparisons.
SA RCA SMC Rule Service Analytics (SA) Root Cause Analysis

(RCA) State Model.
[sa_rca_smc_rule]
Snapshots of the rules associated with RCA
configurations from the SA RCA SMC Config
[sa_rca_smc_config] table.
SA RCA SMC Deployment Information about the current revision of the

RCA configuration that is in effect, and the RCA
[sa_rca_smc_deployment]
configuration that is set to be deployed at the
next daily run cycle of the Learner.
SA RCA SMC Run RCA SMC (State Model Configuration) Run
table.
[sa_rca_smc_run]
All comparisons between two RCA
configurations that the user ran.
SA Alert Aggregation Learned Pattern Learned patterns from alert aggregation.

[sa_agg_pattern]
SA Alert Aggregation Learned Pattern Elements CI/Metric Name pairs associated with learned
patterns.
[sa_agg_pattern_element]
SA Alert Aggregation Query Group Patterns Relationships between groups discovered in

alert aggregation queries and patterns found in
[sa_agg_group_pattern]
learning.
SA Alert Aggregation Query -- Staged (Recent) A staging table for alerts that have not yet been
Alerts associated with any automated alert group.
[sa_agg_group_alert_staging]
SA Value Report Details for the Value Report. Trending

information about alert coverage rate, alert
[sa_value_report table]
compression rate, and user feedback on alert
groups.
SA Agg Pattern Attribute CI/alert attributes to be used for finding patterns
for alert aggregation.
[sa_agg_pattern_attribute table]
SA Alert Attribute Populator Status State and statistics for attribute populator job.
[sa_alert_attribute_populator_status table]

Properties installed with Service Analytics
Service Analytics adds the following properties.

the navigation filter. And, updating these properties, requires the evt_mgmt_admin role.
Property Usage
Enable root cause analysis for business services Enables RCA for alerts associated with business
services and manual services, to identify root
sa_analytics.rca_enabled
cause CIs.
• Location: Service Analytics > Properties
Enable alert aggregation Enables aggregation of correlated alerts for

services and alert groups.
sa_analytics.aggregation_enabled
Include CIs associated with business services, in • Type: true | false

alert aggregation • Default value: true
sa_analytics.aggregation.include_service • Location: Service Analytics > Properties
Time interval (in seconds) criteria for grouping Interval that alerts must be created in, to be
alerts included in a group.
sa_analytics.rca.learner_group_interval_secs • Type: integer
Length of time period (in seconds) from which to The interval that the learner uses to chunk the
include alerts for analysis alert data for processing.
sa_analytics.rca.learner_query_interval_secs • Type: integer
Confidence score % threshold, above which The confidence score that must be met by the
correlated alert groups will be displayed in identified root cause CI for the associated alerts
the Event Management dashboard and Alerts to be displayed.
Console
• Type: integer
sa_analytics.rca.query_probability_threshold • Default value: 0

Property Usage
Purge staging tables (in days) Number of days that RCA input is kept before it
is purged.
sa_analytics.rca.input_purge_days
• Type: integer
sa_analytics.rca.output_purge_days Number of days that RCA output is kept before it

is purged.
• Type: integer
table
Generate event when MID Server file system When the file system of the MID Server exceeds
usage space exceeds limit (0-100%) the percentage threshold, an event is generated.
sa_analytics.rca.mid_max_allowed_space • Type: integer
CMDB property to be used for grouping the A property from the cmdb_ci table that can be
alerts used in alert aggregation used to group alerts by. The alert aggregation
Learner then learns those alerts with respect to
sa_analytics.agg.learner_group_by_property
the grouping.
When left empty, the alerts are learned together
without being grouped.
• Type: string
• A column that is not a reference from the
cmdb_ci table such as po_number.
• A column that is a reference to another
table such as location.name (the name
field in the location table which is
referenced from cmdb_ci)

Property Usage
sa_analytics.agg.learner_domain_level Sets the level of the domain to be used by the

alert aggregation learner.
For optimal analysis, it is recommended that
this is set to a domain level such that all the
CIs that impact the services are contained
within the domain, and that there are no shared
infrastructures across domains.
• Type: integer
table
Enable CMDB Correlation for Alert Aggregation Enables alert correlation based on CMDB CIs
and relationships.
sa_analytics.agg.query_cmdb_correlation_enabled
CMDB Groups: Relation level Levels of CMDB relations to be considered while

forming CMDB groups during alert aggregation.
sa_analytics.agg.query_cmdb_graph_walk_nodes
• Type: integer
Enable Mutual Information Graph Aggregator Enables Mutual Information aggregator for Alert
Aggregation Learner.
sa_analytics.agg.mi_graph_enabled
Use customer feedback in forming new Alert Incorporate customer feedback while forming
Aggregation Groups automated alert groups.
sa_analytics.agg.query_customer_feedback_enabled
Scheduled jobs installed with Service Analytics
Service Analytics adds the following scheduled jobs.
Name Description
Service Analytics Purge Old Observation Data - Cleans the staging data.
Daily

Name Description
Service Analytics Prepare RCA Learner Input Prepares RCA input data. Stores and probes
Data - Daily MID server to learn statistical information about
alerts.
Service Analytics group alerts using RCA/Alert Applies RCA and alert aggregation to open
Aggregation alerts and prepares automated alert groups.
Service Analytics Alert Aggregation Learner - Learns information about existing alerts and
Daily groups new open alerts.
Service Analytics RCA Configuration Configures root cause analysis.
Service Analytics Check File System Space on Checks disk usage on the dedicated
Analytics MID -Daily MID Server, and generates an event
if it exceeds the threshold set in the
sa_analytics.rca.mid_max_allowed_space
property.
Service Analytics Gather Value Report Data - Gathers data for the Value Report.
Daily
Service Analytics - Update virtual alerts for Update the virtual alerts that were created to
aggregation groups represent alert aggregation groups, with any
changes to alerts belonging to that group. Runs
every minute.
Service Analytics Attribute Populator for Populate attributes used in feature identifier for
Historical Alerts historical alert data using event rules. Runs on
demand.
Create an event rule for automatic alert aggregation

Automatic analysis of alerts by Service Analytics requires the use of identifier attributes (metric_name by
default). You need to create an event rule to ensure that these attributes are populated properly.
2. Click New.
3. Fill in the Name, Source, Order, and Filter fields.
5. In the Event Match Fields list, enter the event fields to use to populate the identifier attributes.
For example, to populate the default metric-name attribute, specify:
Field Regular expression Mapping

event_metric_name (.*) metric_name
6. Click Submit.
Specify and manage pattern identifier attributes for alert aggregation

Service Analytics alert aggregation learns the alerts and then forms patterns based on a set of alert and
CI attributes. You can specify the set of CI and alert attributes that will be used as the pattern identifier
attributes for learning patterns, that will result in alert groups that are meaningful in your environment.

The default attribute used for forming patterns is metric_name. Navigate to Service Analytics > Manage
Pattern Identifier to view which pattern identifier attributes are currently in effect, to choose a different set
of attributes to deploy, or to define a new set of pattern identifier attributes.
To ensure that the specified pattern identifier attributes used for forming patterns is effective, a sufficient
number of alerts must have the respective attributes populated. Therefore, if you specify a new set of
pattern identifier attributes, you should do the following to ensure meaningful analysis:
• Create an event rule that populates the respective attributes.
• If a large number of existing alerts do not have values for the new set of pattern identifier attributes,
ensure to run the Service Analytics Attribute Populator for Historical Alerts job which will use the
appropriate event rule to populate attributes in historical alerts. Properties originating from the CMDB CI
using dot walking – are not populated.
• Choose effective identifiers:
• The set of pattern identifier attributes should not be too unique (for example, the date field is unique
for every alert), because it will be impossible to identify any pattern.
• The set of pattern identifier attributes should not be too common, because it will not be possible to
create distinct groups.
Only one set of pattern identifier attributes can be active at a time. A new set of pattern identifier attributes
is not automatically implemented until you deploy it. When you deploy a new set of attributes, the current
set of attributes that is in effect, becomes inactive. Subsequent queries use the active pattern identifier
attributes to perform alert aggregation.
1. Navigate to Event Management and click Manage Pattern Identifier.
2. On the SA Alert Aggregation Pattern Attributes page click New.
3. Click the Feature Identifier Attributes icon and in the slush bucket, move attributes from the
Available list to the Selected list. You can select the Configuration Item class, and click the '+' sign to
display and select its attributes.
4. Click Submit.
5. Optionally, activate the newly specified pattern identifier attributes by selecting the pattern identifier
attributes that you want to activate and clicking Deploy.
After specifying a new set of pattern identifier attributes, ensure that a matching event rule exists that
populates the respective alert attributes. Also, run the Service Analytics Attribute Populator for Historical
Alerts job to populate the respective attributes of historical alerts, if values are missing in existing alerts.
Service Analytics automated alert groups

Service Analytics correlates alerts into automated alert groups that represent the underlying event data.
Automated alert groups are displayed in the alerts console and in the Event Management dashboard.
If the Domain Support - Domain Extensions Installer plugin is activated, then alert aggregation is applied at
the domain level that is specified by the sa_analytics.agg.learner_domain_level property. By default, this
property is set to 2, which is the second domain level in the domain hierarchy.
Alert aggregation
Alerts are grouped based on the CI that is associated with the alerts. Service Analytics groups alerts that
are very similar, but not necessarily identical, and also based on how close in time the alerts were created.
Alerts for technical services, manual services, and alert groups are not associated with a service model
and do not undergo RCA. Other than being correlated by time and CI, these alerts are not necessarily
related by the same underlying problem.

Alert aggregation has these components:
Alert Aggregation Learner An offline job that runs once a day to process past
alerts. The Alert Aggregation Learner identifies
patterns of related alerts using a combination
of pattern-based and probabilistic techniques. If
the sa_analytics.agg.learner_group_by_property
property is set, then before processing starts, the
Alert Aggregation Learner groups alerts by the
specified CMDB property.
Real Time Query A scheduled job that runs every minute and updates
alert aggregation groups. It tries to match real-
time alerts with alert patterns stored in the alert
knowledge base.
RCA for discovered business services and manual services
Service Analytics applies root cause analysis (RCA) algorithms if one of the CIs in an automated alert
group belongs to a discovered business service or to a manual service, in order to identify root cause CIs.
For a discovered business service and for a manual service, an automated alert group contains alerts that
were generated by the root cause CIs and by related CIs.
View Service Analytics automated alert groups

View Service Analytics automated alert groups from the Event Management dashboard, the alert console,
or a business service map. Automated alert groups are displayed in a list view, and are included in the
timeline view in the alert console. When displaying an automated alert group that is associated with
services, the impacted services are displayed and you can view the root cause CI if applicable.
In the alert console, from each automated alert group in the list view or in the timeline view, you can
drill down to view all the alerts that are included in that group. The overall severity of an automated alert
group corresponds to the highest alert severity within the alert group. The color that is associated with a
automated alert group represents its severity.
The Event Management dashboard does not let you drill down to view further details of an automated alert
group.
1. To display all automated alert groups:
a) Navigate to Event Management > Alert Console.
In the list view, automated alert groups are noted by an icon in the Group column, and the
value is Automated.
b) Click Automated to drill down to an automated alert group.
c) Click the link in the Number column in the list view, to display the individual alerts within the
group. For details about the alert form, see View alert information on page 971.
2. To display automated alert groups that are associated with the services displayed on the Event
Management dashboard:
a) Navigate to Event Management > Dashboard.
b) Enable Correlated Alerts.

c)
In the list view, automated alert groups are noted by an icon in the Group column.
• In the alerts console, after you open the Automated Grouped Alerts dialog box, you can provide
feedback about the accuracy and helpfulness of an automated alert group, and add or remove alerts
from the group.
• In the Event Management dashboard, view impacted services (if there are any) and root cause CI if
applicable, by double-clicking a service on the map, and then clicking Root Cause CI.
CMDB alert groups

Service Analytics groups alerts by using different methods of correlation. For CIs without historical data,
Service Analytics correlates alerts based on CIs' relationships in the CMDB. CMDB alert groups are
displayed in the alert console and in the Event Management dashboard.
To correlate alerts into groups, Service Analytics relies on historical alert data. Analyzing historical
data, Service Analytics learns patterns of alerts, and then attempts to match new alerts with these
patterns to correlate alerts and create alert groups. However, in some situation such as with a new
implementation, or with a new set of CIs, there is no historical data to learn from. In these situations, if the
sa_analytics.agg.query_cmdb_correlation_enabled property is set to 'true', Service Analytics automatically
correlates alerts based on relationships between the respective CIs that are defined in the CMDB. For
example, a server that is hosting a computer, or processes that are running on a certain server - the alerts
for the CIs in these relationships can be correlated into a CMDB alert group.
The relationships that are used for CMDB-based grouping are hosting and containment but only if the
number of connections between the CIs is small. If two CIs are related through many connections, the
connection is considered to be too weak for CMDB-based grouping.
Root cause CIs

For alerts associated with discovered business services or manual services, Service Analytics implements
root cause analysis (RCA) to identify the CI that is the underlying root cause in an automated alert group.
If the Domain Support - Domain Extensions Installer plugin is activated, then RCA is domain aware. Alerts
are analyzed within the context of the domain that business services or manual services belong to, and
RCA for a business service or manual service runs on the MID Server that is in the same domain as the
business service or manual service. If there is no MID Server for a specific domain, then the MID Server
from the global domain is used.
Root cause analysis
The ongoing operations of an application can generate a large number of events and alerts which
can become overwhelming when problems arise. If the system is experiencing a problem, the manual
process of assessing the impact of the alerts and identifying the underlying cause might require extensive
resources and might be lengthy.
To identify underlying problems, RCA algorithms prioritize alerts, group them in the context of impacted
services, and identify root cause CIs. The root cause CI is a CI from which the root alert for an incident
originated and which subsequently triggered other alerts to be generated.
RCA has these components:
RCA Learner An offline job that runs once a day to process past
alerts. It collects information about frequent alert

patterns within a service context, and stores this

information in the alert knowledge base. Based
on past alerts and on the impact model, the RCA
Learner creates a probability model that can be
used to answer cause and effect queries.
Real Time Query A scheduled job that runs every minute to group
alerts and to update root cause CIs. It queries past
lists of root cause recommendations to get the
probability score for real-time alerts with respect to
other open alerts within the service.
For discovered business services and for manual services, the Learner collects and analyzes data from
past alerts. For new alerts, the Learner applies existing knowledge from similar past alerts, and continues
to capture and analyze data from new alerts. As more alerts are encountered and resolved, the alert
knowledge base grows and the precision of diagnosing the root cause CI improves.
Business services are discovered by Service Mapping and represented internally in the system by a
service model. The service model of the business service is used for identifying CIs related to the root
cause CI.
When the root cause CI is known, operators can create a single incident ticket and engage only the
needed IT operator to expedite remediation. The IT operator can direct troubleshooting efforts to remove
the root cause problem, and stop the recurrence of undesirable events.
Setting RCA properties
By default, RCA is not applied. You can enable RCA and modify other RCA-related behavior by changing
the settings of the sa_analytics.aggregation.include_service and sa_analytics.rca_enabled properties for
Service Analytics.
RCA configurations
RCA uses an RCA configuration that filters and scopes the alerts to be analyzed. The base system
includes pre-defined RCA configurations, but those might not be optimal in every environment. See RCA
configurations on page 1023 for more information.
Confidence score
To help you decide how to invest troubleshooting efforts, RCA algorithms calculate a confidence score
for the identified root cause CI. The confidence score is based on the Learner data and expresses the
confidence in the identification. For example, a confidence score of 75% means that there is a certainty of
75% in the identification of the root cause CI. If more than one cause is possible, you can investigate the
most likely root cause before investigating less likely root causes.
By default, RCA groups with any confidence scores are displayed. To limit what groups are displayed,
change the sa_analytics.rca.query_probabality_threshold property to a percentage that the RCA group
confidence score must meet to be displayed. If a root cause CI has a confidence score that is lower than
the specified percentage, Service Analytics does not treat that CI as the root cause.
Viewing root cause CIs
You have these options for viewing root cause CI, if applicable.

UI access Description
Event Management dashboard - root cause CI Displays root cause CIs highlighted in a business
service map, and the relationships between the
root cause CI, alerts, and related CIs in business
services.
From a correlated alert group Displays all automated alert groups and lets
you drill down to view details about the alerts
in the group, and the root cause CI if it exists.
Double-click a group, and then click the Impacted
Services tab to display the services and root cause
CIs if applicable.
RCA configurations
Service Analytics uses an RCA configuration to determine which alerts to include in its root cause analysis.
The RCA configuration is used in learning the conditional probability of how a particular state of CI impacts
other CIs. Multiple RCA configurations can be defined, but only a single configuration is in effect at any
point of time for a given domain.
There are two types of RCA configurations, and the base system includes a pre-defined RCA configuration
for each type:
• Rule-based model: Considers the severity of the alert, and maps any severity level (Critical, Major,
Minor, Warning) into a state. For example, a binary-state configuration maps into two possible states:
• 0 – No alert for the CI
• 1 – Alerts exist for the CI
Each configuration consists of one or more rules that define the set of alerts to be included in the RCA,
such as all alerts with the severity of critical. You can define custom RCA configuration using the rule-
based model, adding rules to map alerts according to CI and alert attributes to various states.
The base system includes the predefined RCA configuration Default Binary Model Config, which is the
default RCA configuration.
• Multi-state model: Based on the combination of the Resource and the Metric Name alert columns to
learn the model, and it is not associated with any rules. The multi-state model combines the Metric
Name and Resource alert columns into a string, and then aggregates such strings from multiple alerts
into a single state string. The number of resulting states is determined by the number of unique state
strings for a particular CI.
The base system includes the predefined RCA configuration Default Multi State Config, which you can
use in a comparison test of RCA configurations. There are no variations for this default configuration,
and therefore you cannot create a custom RCA configuration that is based on the multi-state model.
There is no single RCA configuration that is the most optimal in every environment. Therefore, in addition
to the default configurations, you can create custom rule-based RCA configuration. A custom RCA
configuration can use additional CI and alert attributes, such as a location attribute to scope the analysis to
a specific data center. User can add rules that define how to map alerts for different CIs to various states.
You can compare the RCA results on actual business data, between any two RCA configurations allowing
you to select the optimal configuration in your environment. A comparison simulates analysis on historical
data, and the RCA Configs Comparison report displays the results of the comparison.
Create an RCA configuration
Service Analytics uses an RCA configuration to determine which set of alerts from the sa_analytics_alert
table to use for RCA. You can create a custom rule-based RCA configuration, compare it with another RCA
configuration and decide how efficient and helpful it is. You can then choose the RCA configuration that is
most suitable in your environment, and configure RCA to use that configuration in its analysis.


Each rule-based RCA configuration consists of one or more rules. If an RCA configuration has multiple
rules, then the rules' filters are applied to alerts according to their priority order.
If the Domain Support - Domain Extensions Installer plugin is activated, then alerts are processed
according to the domain of the associated business service.
1. Navigate to Service Analytics > RCA Configs
2. Click New, and fill out the SA RCA SMC Config Base form.
Table 439: RCA Configuration form
Field Description
Name Configuration name.

Description Descripton for the configuration.
Domain Domain that this configuration applies to.
Config deployed Read-only field, which is automatically
computed by the system. It is selected (true)
if at least one version of the configuration
has been deployed.
Created Date and time that this configuration was
created.
Created by User that created this configuration.
Updated Date and time that this configuration was
updated.
Updated by User that updated this configuration.
Model The model to use for the configuration.
Typically, the model that is used for a
custom RCA configuration is Rule Based.
3. Right-click on the form title, and click Save.

4. Add rules to a rule-based RCA configuration:
a) Click SA RCA SMC Rule Bases at the bottom of the form.
b) Click New, and fill out the form.
Table 440: RCA Configuration form
Field Description
Name Name of the RCA configuration

rule.
Description Description of the RCA
configuration rule.
Configuration id The RCA configuration that this
rule is associated with.

Field Description
Order An integer that represents the

priority of the rule within the rest
of the rules for the configuration.
Lower numbers have higher
priority.
Created by User name.
Created Time created.
Updated by User name.
Updated Time updated.
Domain Domain that this rule applies to.
% Alert Coverage System generated
percentage of alerts in the
sa_analytics_alert table that
match the rule's filter.
Rule filter Conditions to filter alerts for this
rule.
5. Select the check box for the new rule and click Alert Coverage to calculate the rule's % Alert
Coverage.
• Compare the new RCA configuration with another configuration, and decide which configuration is most
helpful and should be deployed in the next RCA Learner cycle.
• After modifying a configuration, or when there is a significant number of new alerts, select any rules and
click Alert Coverage. This recalculates the % Alert Coverage for the selected rules.
Compare and deploy RCA configurations

Compare the results of root cause analysis between two RCA configurations on actual alerts, then choose
the optimal configuration in your environment, and deploy it.
Select any two RCA configurations and a business or a manual service for the comparison. The
comparison simulates analysis on historical data from the business or manual service, while applying the
two RCA configurations. The RCA Config Comparison report displays the comparison results.
When you compare one RCA configuration to another RCA configuration, Service Analytics stores
a current snapshot of the definitions of the RCA configurations that are being compared. An RCA
configuration can end up having several versions, each one created when it is used in a comparison.
Review the comparison results, and decide which RCA configuration is most efficient, and then deploy
that configuration. The deployment request is registered, and will take effect at the next cycle of the RCA
Learner. The version of the configuration that was used for the comparison will be deployed.
1. Navigate to Service Analytics > RCA Configs.
2. Click on one of the two configurations that you want to compare, and on the configuration form click
Run Comparison.
3. In the Run Comparison dialog box, select a second configuration for the comparison from the
Compare with Configuration list.
4. Select a business or a manual service from the Run comparison on list to use for the comparison.
5. Click Run.

6. Navigate to Service Analytics > Reports > RCA Configs Comparsion, and select a comparison to
review. Ensure that the status of the comparison is Completed.
7. Decide which configuration you want to deploy, and click the configuration link in the comparison that
you are reviewing.
8. On the configuration form, click Deploy.
View root cause CIs in a business service map

For alerts associated with discovered business services or manual services, you can view root cause CIs
in a business service map on the Event Management dashboard.
When you select a root cause CI, the business service map displays the business or manual services that
are impacted by the root cause CI.
2. Double-click the tile of the business or manual service for which you want to view root cause CIs.
3. Underneath the map, click Root Cause CI and select a root cause CI to highlight in the business
service map.
The list of root cause CIs associated with the selected business service displays the following details:
Table 441: Root Cause CI details
Field Description
Root Cause CI The CI that is determined to be the root

cause in this alert group.
Related Alerts The number of alerts in this alert group.
Other Impacted Services The number of additional services that are
impacted.
Confidence Score The confidence score in the identification of
the root cause CI.
4. Double-click a root cause CI to display the alerts within this alert group.
5. Select any alert to highlight the CIs that it is associated with, and view additional details about the
alert.
Reports
Service Analytics generates several reports, to help you assess the efficiency and depth of analysis.
You can access Service Analytics reports by navigating to Service Analytics > Reports.
RCA Config Comparison Report

This report displays the results of a comparison between two RCA configurations defined for Service
Analytics root cause analysis. Evaluate and score the comparison results. Then choose the RCA
configuration that appears most efficient in your environment, and deploy it.
In addition to the default RCA configurations, you can create custom rule-based RCA configurations,
and you can compare any two configurations (ConfigA and ConfigB). For each configuration that is being
compared, RCA algorithms are applied using real historical alerts from the past 7 days. The RCA Config

Comparison Report displays the RCA results for each configuration, if it would have been used during the
past 7 days. Once you start a comparison, wait for the report to show that the status is Completed.
To display the report, navigate to Service Analytics > Reports > RCA Configs Comparison, which
requires the evt_mgmt_admin role. The report has 3 sections, each section provides further details for a
selected item in the previous section.
Comparison summary list
This section lists summaries of recent comparisons, with the following details:
Column Description
Start time Time the comparison started.

Run Name System created unique ID for the comparison
run, prefixed by 'RUN'.
Status Status of the comparison, ensure it is completed
before reviewing the details.
Config (A) The first RCA configuration used in the
comparison.
Config (B) The second RCA configuration used in the
comparison.
Score (A) Sum of user assigned scores for all automated
alert groups analyzed by Config (A).
Score (B) Sum of user assigned scores for all automated
alert groups analyzed by Config (B).
Service Discovered business service or manual service
for which alerts were used in this comparison.
Actions:
• Select a comparison for which to display further details about RCA results for Config (A) alongside
Config (B).
• Deploy an RCA configuration:
1. Click the link for the RCA configuration that you want to deploy in the Config (A) or Config (B)
column.
2. On the configuration form, click Deploy.
RCA results for Config (A) and Config (B) per comparison
This section displays a comparison of root cause analysis for Config (A) and Config (B), for the selected
comparison in the previous section. Displaying the following details:
Column Description
Grouping Time Time that the group was created.

Column Description
Root Cause Comparison of the root cause CI being identified

by Config (A) and Config (B). Both configurations
have either identified the Same root cause CI, or
a Different one.
Score (A) User assigned score of RCA results for this
automated alert group, as it was analyzed by
Config (A).
Score (B) User assigned score of RCA results for this
automated alert group, as it was analyzed by
Config (B).
Probability % (A) Confidence in the accuracy of the root cause CI
identified by Config (A).
Probability % (B) Confidence in the accuracy of the root cause CI
identified by Config (B).
Group Name (A) Automated alert group created by Config (A).
Group Name (B) Automated alert group created by Config (B).
Related Alerts (A) Summary of alerts within the automated alert
group created by Config (A), broken down by
alert severity.
Related Alerts (B) Summary of alerts within the automated alert
group created by Config (B), broken down by
alert severity.
Actions:
• Select a automated alert group to display further details about all the alerts within that group.
• Score results:
1. Select the group and the configuration that you want to score, in either Score (A) or Score (B)
column.
2. Double-click the score value, enter a numeric score, and then click the green check-mark. The
new group score value is aggregated into the summary score for Score (A) or Score (B) in the
comparison summary row for this comparison.
• Toggle between different display options for the automated alert groups:
• Same: Displays only the automated alert groups for which RCA results for Config (A) and Config (B)
are identical.
• Different: Displays only the automated alert groups for which RCA results for Config (A) and Config
(B) are different.
• All: Displays all automated alert groups for which there are RCA results for either Config (A) or
Config (B).
Correlated alert group details per config
This section displays details of all related alerts within a automated alert group selected in the previous
section. Displaying the following details for both Config (A) and Config (B):

Column Description
Number Alert ID.

Severity Severity of the alert.
Description Description of the alert.
Configuration Item CI that the alert is associated with.
Updated On Last time that the alert was updated.
Value Report
The Service Analytics Value Report consists of three sections, displaying metrics about alert coverage
in data analysis and its efficiency in terms of alert group correlation. You can use that data to determine
which incidents need to be created.
Actions:
• Select a preset time period for the report.
• Drag the time slider to select the period of time for the report. Or, use the right or left handle of the time
slider to extend or shorten the time period for the report.
• Hover over a report to display more data about a specific point of time in the report.
Alert Coverage
Displays the total number and percentage of alerts that are grouped into automated alert groups. Based
on that, you can evaluate the number and percentage of alerts that were left out, and not included in
any automated alert group. Higher percentage rates indicate a more efficient analysis in which higher
percentage of alerts are found to correlate with each other, likely generated due to the same problem.
The formula for this report is: Grouped Alerts/Total Number of Alerts
Alert Group Compression
Displays the effectiveness of grouping alerts into automated alert groups, calculating the number of groups
being formed in relation to the number of alerts that were not grouped. Higher compression rates indicate
an efficient correlation of alerts, and a more accurate mapping of automated alert groups to incidents.
Higher compression rates indicates a smaller total number of automated alert groups, and fewer incidents
to be created.
The formula for the report is: (1 – ((No. of Groups + No. of Ungrouped Alerts) / Total No. of Alerts))
Alert Group Feedback
Displays a summary of feedback that was provided for automated alert groups. The report displays the
total number of groups for which positive and negative feedback was provided, and the number of groups
for which no feedback was provided.
Learned Patterns Report

This Service Analytics report displays metrics associated with learned patterns such as the frequency
of occurrence and the number of occurrences of the pattern identifier attributes in learned patterns (CI/

MetricName by default). You can sort the learned patterns by pattern score, pattern frequency, and pattern
size. This report helps you identify higher-frequency occurring alert patterns.
For each alert, alert aggregation combines the associated pattern identifier attributes that represent the
alert. It then groups all the pattern identifier attributes for alerts that occur together, to create a learned
pattern. The same combination of pattern identifier attributes can exist in multiple learned patterns.
Typically, a learned pattern would indicate a single problem. The report displays metrics in a tile format
broken by learned patterns.
To display the report, navigate to Service Analytics > Reports > Learned Patterns.
You can use this report to:
• Allocate resources to the higher frequency occurring alerts to reduce the time for closing a large
number of alerts.
• Allocate resources to larger learned patterns of lower frequency.
Actions:
• Select a tile to display further details about all the pattern identifier attributes that are associated with
the selected tile.
Column Description
Configuration Item The configuration item used for the combined

pattern identifier attributes.
Metric Name The metric name used for the combined
pattern identifier attributes.
Frequency The number of times that the combined
pattern identifier attributes occurs in the data
set.
• Hover over the pattern number to see the pattern size, pattern frequency, and pattern score details for
the pattern.
• Sort the report by:
• Pattern Size: The number of combined pattern identifier attributes occurrences in a learned pattern.
• Pattern Frequency: The number of times that a learned pattern occurs in the data set.
• Pattern Score: Combined calculation of frequency and size, using the formula:
Frequency * (Size + 1)
• Click on a CI link in the Configuration Item column to display the CI form.
Operational Metrics
Operational Metrics learns from historical metric data, and builds standard statistical models to project
expected metric values along with upper and lower control bounds. Operational Metrics then uses these
projections to detect statistical outliers and to calculate anomaly scores. Operational Metrics is available
when you activate the ITOM Metric Management (com.snc.sa.metric) plugin.
Metric data is collected by various data sources. For example, SCOM is a monitoring system that collects
metric data from the source environment regularly. Operational Metrics captures the raw data from these
monitoring systems, and uses event rules and the CMDB identification engine to map this data to existing
CIs. Operational Metrics then analyzes the data to detect anomalies and to provide other statistical scores.
By default, Operational Metrics is already partially configured for using the SCOM data source.

After processing, metrics statistics and charts are displayed in the Metric Explorer, and the Anomaly Map
displays correlated scores for CIs with the highest anomaly scores, across a timeline.
Terms used with Operational Metrics
Source metric type A metric such as '% Free Space' or 'Current

Bandwidth' that can be measured by a data source
for a CI. For each data source, you can choose
which of all possible metrics will be processed. By
default, there are about 380 source metric types
that are active for the SCOM data source.
Statistical model Processes on the Metric MID Server learn statistical
models for each metric from past metric data
(up to four weeks old). Each statistical model is
used to project the expected average behavior of
metric for the next 24 hours, to calculate upper and
lower control bounds for the metric, and to identify
anomalies.
Anomaly Data that is outside the control bounds is
considered a statistical outlier. These outliers are
used to compute an anomaly score, which is a
value between 0–10 that indicates the degree to
which the metric appears unlikely. Outliers are
monitored, and when an anomaly score is above a
minimum threshold, an anomaly alert is generated.
Anomaly alerts are reported separately from the
system's regular alerts.
Operational Metrics MID Server
Operational Metrics uses a dedicated MID Server to process the raw data, to build a statistical model,
and to detect anomalies. The MID Server is configured with extensions that enable it to independently
transmit metric data to the instance. The MID Server transmits the statistical model and anomalies above a
specified score (4 by default) to the instance where it is accessible to users.
Metrics to CI mapping
The data that is collected on the MID Server is raw and does not relate to any specific CI in the CMDB. To
be useful, the data goes through a normalization process that uses CMDB identification rules and event
rules to uniquely identify CIs, and to map them to the raw data.
Records for mapping of raw data to CIs are automatically generated and remain in effect for a specified
length of time determined by the properties:
• sa.metric.map.with.ci.expiration.sec: If the mapping to the CI was found. Set by default to be valid for
five days.
• sa.metric.map.without.ci.expiration.sec: If mapping to the CI was not found. Set by default to be valid for
24 hours.
When similar metric data arrives within that time period, the existing mapping is used to match the data to
CIs. At the end of the time period, metric-to-CI records expire. Also, a change in the event rules triggers an
immediate expiration of the respective metric-to-CI records. Next time that raw metric data arrives, it will be

normalized again. When Discovery adds or removes CIs, mappings are adjusted to reflect these changes
at the next cycle.
Get started with Operational Metrics

Complete the following setup and initial configuration steps to start using Operational Metrics.
Raw metric data, collected by data sources (such as SCOM) needs to reach the Operational Metrics MID
Server, where Operational Metrics can process and analyze it. You can set up Operational Metrics so that
raw data is either pulled by the Operational Metrics MID Server from the external data source, or pushed
from the external data source to the Operational Metrics MID Server.
Using either method requires the configuration of the ITOA MetricExtension MID Server extension. The
main roles of this extension are to normalize the raw data, and to detect any anomalies. The normalized
data and anomalies (if above the specified threshold), are then transmitted to the instance.
Some steps for setting up Operational Metrics must be completed regardless of the method used. Other
steps depend on the method used for transmitting data between the data source and the MID Server:
Pulling This method requires using a connector that is

configured to pull data from the specific data source
that is collecting the raw data. Use the pre-defined
SCOM connector (which was previously defined
for pulling events from SCOM), or configure a
new custom connector specifically for the external
source that is used in your environment.
Pushing This method uses web service APIs and is based

on client-side tools that push the raw data from the
external source to the MID Server. This method
requires that the ITOA MetricExtension extension is
configured with the Enable REST Listener option
enabled.
You also need to configure the Web Server
extension, which starts a Web Server on the MID
Server. Request handlers are added on the Web
Server that listen to any incoming metric data
that was pushed from the external source. The
configuration of the Web Server extension includes
two important settings:
• Authentication type, which can be set to the
more advanced option - Keybased.
• Secure Connection, which lets you choose
whether incoming and outgoing data is secured
when transmitted. If you choose the more
advanced secured option, it requires that you
obtain a certificate from a well known certificate
authority, and then provide the Keystore
Certificate Alias and the Keystore Password.
1. Activate the ITOM Metric Management plugin.

2. Configure a MID Server for Operational Metrics: Set up the MID Server with the required hardware
and with the ITOM Metric capability from ITOM Metric Management. It is possible to use the same MID
Server that is being used for Service Analytics, as a dedicated MID Server for Service Analytics and

Operational Metrics. If the default SCOM connector is used, then the same MID Server that is used to
collect events, should be used for Operational Metrics.
3. Configure the Operational Metric extension on page 1036.
4. To configure for pulling:
a) Create a connector definition on page 867 (For a SCOM connector - this is already defined for
pulling events from SCOM).
b) Configure a connector instance on page 863 (For a SCOM connector - see Configure the
SCOM connector instance on page 884).
5. To configure for pushing:

a) Configure the MID Web Server extension on page 1039.
b) In the ITOA MetricExtension extension, ensure that the Enable REST Listener option is enabled,
and that the MID Web Server Extension is set.
c) Create the client scripts that push the raw data from the external source to the MID Server.
6. Create or configure metric type registration on page 1046.

7. Choose and configure metrics to monitor on page 1047.
8. Create event rules to map raw data to specific CI types to bind metrics to CIs.
Request ITOM Metric Management

The ITOM Metric Management plugin (com.snc.sa.metric) requires a separate subscription and must be
activated by ServiceNow personnel. This plugin includes demo data and activates related plugins if they
are not already active.
Role required: none




3. Click Submit.
Configure a MID Server for Operational Metrics

To use Operational Metrics, you need to configure at least one dedicated MID Server with ServiceAnalytics
as a supported application, and with the ITOA Metrics capability. To ensure uninterrupted services,
consider to also configure a failover MID Server cluster for Operational Metrics.
If Domain Support - Domain Extensions Installer is activated, then you can configure a dedicated MID
Server with the ITOA metrics capability, per domain. In this case, metrics for a business service are
processed on the MID Server that is in the same domain as the business service. Otherwise, a MID Server
from the global domain is used.
Table 442: Hardware requirements (scaled for 2,500 CIs, with 20 metrics per CI)
Component Requirement
Memory • Minimum: 4 GB
• Recommended: 8 GB
Processor • Minimum: Either of the following processors:

• Core 2+
• Xeon processor with a speed over 2 GHz
• Recommended: Quad-core
Disk space (for 100 discovered services) • Minimum: 16 GB

• Recommended: 24 GB
Table 443: Software requirements
Software Supported versions Additional requirements
Windows 32-bit and 64-bit versions: 32-bit version of the MID Server
• Windows 2008 R2
Linux (supported only for • Red Hat Enterprise Edition 32-bit or 64-bit version of the
pushing) Linux 6.6 or later MID Server
• CentOS Linux 6.6 or later

Software Supported versions Additional requirements
PowerShell (required only with Version 3.0 or later. Powershell Execution policy
the SCOM connector) must be Unrestricted or Remote
Use Get-Host to check the
PowerShell version. Signed.
• Use Get-
ExecutionPolicy to see
the security level.
• Use Set-
ExecutionPolicy
Unrestricted.
• Or, use Set-
ExecutionPolicy
RemoteSigned.
For PowerShell errors, see

https://technet.microsoft.com/
library/hh847748.aspx.
Table 444: Configuration requirements
Configuration Requirement
MID Server service logon user (required only for Must be set to a user with read access to the
pulling) SCOM database (OperationsManagerDW).
1. On the MID Server, open the MID Server
Properties dialog box.
2. Click the Log On tab.
3. Select This account, and enter credentials
for a user with the required access.
4. Click Apply.

The Operational Metrics MID Server supports the Operational Metrics feature by processing data and
detecting anomalies. The statistical model is calculated on the Metric MID Server, which is then transmitted
to the instance. Anomaly alerts are generated and scored on the Metric MID Server. The MID Server
transmits batches of processed data to the instance every 15 minutes. If an anomaly is detected, then
information about the anomaly along with the raw data is sent immediately to the instance, regardless of
the regular 15-minute cycle.
By default, the MID Server is set up as a dedicated MID Server for Operational Metrics, and an attempt
to add additional supported applications to the same MID Server is prevented. It is recommended
that Service Analytics RCA is also implemented with its own dedicated RCA MID Server. These
recommendations ensure high level of performance. However, if needed, you can modify this default
behavior and configure the Operational Metrics MID Server or the RCA MID Server with additional
supported applications. For information about modifying the behavior of the ALL option when selecting
supported applications, see Configure applications included in ALL Applications .
1. Ensure that the MID Server is validated.
For more information, see Validate a MID Server.

2. Navigate to MID Server > Servers.

3. Double-click the MID Server that you want to configure as an Operational Metrics MID Server, or click
New to create a new MID Server.
4. Add the ServiceAnalytics application:
a) At the center of the MID Server form, click Supported Applications.
b) In the Supported Applications section click Edit.
c) In the slushbucket select ServiceAnalytics and click the > add button.
d) Click Save.
If the MID Server needs to support ServiceAnalytics as well as one or more other applications, you
can modify the definition of the ALL option to include these applications, and then select ALL in the
slushbucket. ALL is the only option to which it is valid to add the ServiceAnalytics option. Performance
might be compromised with these settings.
5. Add the ITOA Metrics capability:
a) At the center of the MID Server form, click Capabilities.
b) In the Capabilities section click Edit.
c) In the slushbucket select ITOA Metrics and click the '>' add button.
d) Click Save.
6. Click Update.
Create a failover cluster for Operational Metrics. In this cluster, add the MID Servers that were configured
for Operational Metrics. For more information, see MID Server cluster configuration.
Configure the Operational Metric extension

Configure the MID Server Operational Metric Manager Context to enable the MID Server to pull raw
metrics from external systems, to detect anomalies and report anomalies to the instance along with raw
data. This MID Server Operational Metric extension is required and must be running in order for your
system to be able to collect Operational Metrics data.
Deploy and start a MID Server.
The MID Server Operational Metric extension normalizes the raw data and then transmits the data to
the instance. If the extension detected any anomalies above a specified threshold, they are sent to the
instance. The extension runs for as long as it is enabled. This provides a persistent connection to the MID
Server to constantly listen for raw Operational Metrics data from external systems.
The MID Server Operational Metric extension:
• Receives raw metric data, batches them and sends them to the instance at specified intervals.
• Detects anomalies and sends a report to the instance.
• The information that is sent to the ServiceNow instance is relevant for Operational Metrics, so data
processing is efficient.
The MID Server Operational Metric extension does not provide any API calls. However, when the Enable
REST Listener option is selected, the extension adds a handler for the supported REST APIs.
Note:
• After the initial configuration, the first metric is not included in the metrics data.

• There is a delay of one minute in receiving metric information from the synchronization of the
instance with the MID Server.
1. Navigate to MID Server > Extensions > Operational Metrics.

2. In the Operational Metric Manager Contexts list, click New.
Field Description
Name A unique name for this extension for easy

identification.
Short description A description of this extension.
Extension Specify ITOA MetricExtension.
Status This field is auto-populated with the status
of the extension. The field is blank until
the extension is started. After issuing a
command to the extension, one of the
following values is displayed:
• Error: The extension failed with an error
(the error message is displayed in Error
Message).
• Warning: A run-time exception has
occurred. The extension continues to
work.

This field appears when the value in the
Status field is Error and also when the
value in the Status field is Warning.
Execute on Location for running this extension.
The possible options are Specific MID
Server or Specific MID Server Cluster.
When configuring this option for use with
Operational Metrics, specify the MID Server
that has the Service Analytics application
configuration and Operational Metrics
capability.

Field Description
MID Server Depending on your selection in Execute on,

the name of the designated MID Server, or
MID Server cluster respectively:
• If you selected Specific MID Server, the
name of the designated MID Server.
• If you selected Specific MID Server
Cluster, the name of the designated
MID Server cluster. This option is not
recommended for Operational Metrics
when used in a PUSH configuration.
If you selected the MID Server cluster

option, an algorithm determines which
server in the cluster runs the extension.
the MID Server is down. If the user stops the
extension, this field is empty.
4. When using the Push method for collecting Operational Metrics, the MID Server Operational Metric
extension must be configured with the Enable REST Listener enabled. This option enables a listener
so that a REST endpoint can receive raw metric data. The raw metric data is then placed in the
regular data flow where the data is sent to the instance and the anomaly detector looks for anomalies.
When selected, it adds a handler to the web server to listen for any metrics that are pushed to the
MID Server. When this option is selected, the Web Server extension, which starts a Web Server on
the MID Server, must also be configured. For more information, see Configure the MID Web Server
extension on page 1039.
5. Right-click the form heading and select Save.
6. Under Related Links click Start to save the Operational Metrics data in this extension and start the
extension.
Table 445: Commands available in the MID Server Operational Metric extension
Start Starts the extension on the configured MID

Server if it is currently not running.
Stop Stops the running extension on the
Restart Stops, then starts the extension on the
configured MID Server.
Test The test is not relevant to Operational
Metrics. Parameters are not tested or
validated when Test is run.
Update parameters Sends the latest saved parameters to the
extension.

Configure the MID Web Server extension

The MID Web Server extension enables external clients to push metric data to the MID Server. This
extension is used to listen for raw metric data and it provides options for authentication and data security.
The raw data that is collected is transmitted to the instance.
Deploy and start a MID Server.
The Enable REST Listener option must be selected in the ITOA MetricExtension. For more information,
see Configure the Operational Metric extension on page 1036.
If the Secure Connection option is going to be selected, first obtain a server certificate. For more
information, see Setup certificate for secure connection on page 1043.
The MID Web Server extension runs for as long as it is enabled. The extension starts a web server on the
MID Server that can serve web requests from external systems. The
Raw data can be pushed to the extension from a client or using customized script.
The Web Server extension configuration includes these important settings:
• Authentication type, which can be set to the more advanced option - Keybased.
• Secure Connection, which lets you choose whether incoming and outgoing data is secured when
transmitted. If you choose the more advanced secured option, it requires that you obtain a certificate
from a well-known certificate authority, and then provide the Keystore Certificate Alias and the
Keystore Password.
1. Navigate to MID Server > Extensions > MID Web Server.

2. In the MID Web Server Contexts list, click New.
Field Description
Name A unique name for this MID Web Server

extension for easy identification.
Short description Enter a brief, meaningful description of this
extension.
Extension Specify MID Web Server.
Status This field is auto-populated with the status
of the extension. The field is blank until
the extension is started. After issuing a
command to the extension, one of the
following values is displayed:
• Error: The extension failed with an error
(the error message is displayed in Error
Message).
• Warning: A run-time exception has
occurred. The extension continues to
work.

Field Description
HTTP/HTTPS Port Port number on which you want to listen to

incoming requests.
Authentication Type Select one of the following:
Keybased
• Create an authentication token that is
sent with each request.
• Send this authentication token in the
request header Authorization.
To create an authentication token:

1. The user must construct a string using
defined elements of the HTTP/HTTPS
request.
2. Create a Hash Message Authentication
Code (HMAC) of the string, that is, sign
the string generated in previous step
with the auto-generated secret key.
The key is unique per context. See the
example.
Note: A valid timestamp (using

the HTTP Date header) is required
for the authenticated request. In
addition, the timestamp must be
within 15 minutes of the time on the
MID Server.
Basic
• The user must provide a username and
password. The same username and
password must be provided for every
request.
• On the instance, the password is stored
encrypted and it is sent also to the MID
Server encrypted.
• In the MID Server, the password is saved
in memory.
• When the request is received, the
password is decrypted and matched with
the password provided in the request.
Secret Key [Read-Only] The value that is generated

when keybased authentication is selected
for the Authentication Type field.
This field only appears when the value in the
Status field is Error.

Field Description
Execute on Location for running this extension. The

available options are Specific MID Server
or Specific MID Server Cluster.
MID Server Depending on your selection in Execute on,
the name of the designated MID Server, or
MID Server cluster respectively:
• If you selected Specific MID Server, the
name of the designated MID Server.
• If you selected Specific MID Server
Cluster, the name of the designated MID
Server cluster.
If you selected the MID Server cluster

option, an algorithm determines which
server in the cluster runs the extension.
the MID Server is down. If the user stops the
extension, this field is empty.
4. Select Secure Connection to provide extra protection, if required. When selected, enter the values for
these fields:
a) In the Keystore Certificate Alias field, enter the name of the keystore certificate.
b) In the Keystore Password field, enter the keystore password.
5. Click Save to save the Operational Metric data.

6. Under Related Links click Start to start the extension.
Table 446: Commands available in the MID Web Server extension
Start Starts the web server if it is currently not

running.
Stop Stops the web server. No action is taken if
Restart Stops, then starts the web server.
Test The test is not relevant to Operational
Metrics. Parameters are not tested or
validated when Test is run.
Update parameters Stops and then starts the web server with
new parameters. If none of the parameters
were modified, no update is made.

Example describing how to create an authentication token to be sent with each

request.
Method: Create a token by constructing a string using defined elements of the HTTP/
HTTPS request. Then create an HMAC(Hash Message Authentication Code) of the string
by signing the generated string with the auto-generated secret key that is displayed in the
Secret Key. This key is unique per context. Send this authentication token in the request
header Authorization.
Data for the example:
Table 447: Keybased authentication data
Item Value
Path to a web service API for https://<instance>/api/

sending raw data mid/sa/metrics For example:
https://mid1.service-now.com/
api/mid/sa/metrics
Request type POST
Date format
yyyy-MM-
dd'T'HH:mm:ss.SSS'Z'
For example:
2016-06-08T20:54:58.917Z
Content-Type application/json
Use the following request elements to generate the required string: HTTP-Verb, Content-
Type, Date, and request path. Specify these elements and place them in the following
order:
• HTTP-Verb + "\n" +
• Content-Type + "\n" +
• Date + "\n" +
• Request-Path
For the above example, the request string is:

POST\napplication/json\n2016-06-08T20:54:58.917Z\n/api/mid/sa/
metrics
For the time stamp requirement, a valid time stamp that uses HTTP date header is
required for authenticating the request. Ensure that the timestamp is within 15 minutes of
the MID Server.
Example, using Java, that describes how to generate HMAC of the string that uses
defined elements of the HTTP/HTTPS request.
package sample;
import com.glide.util;
import java.security.SignatureException;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;

public class AuthUtil {
private static final String HMAC_SHA1_ALGORITHM = "HmacSHA1";
/***
* Generates base64-encode the HMAC(Hash Message Authentication
Code) of input data
*
* @param data
* @param key
* @return
* @throws java.security.SignatureException
*/
public static String signData(String data, String key) throws
java.security.SignatureException {
String result;
try {
// get an hmac_sha1 key from the raw key bytes
SecretKeySpec signingKey = new SecretKeySpec(key.getBytes(),
HMAC_SHA1_ALGORITHM);
// create hmac_sha1 Mac instance and initialize with the

signing key
Mac = Mac.getInstance(HMAC_SHA1_ALGORITHM);
mac.init(signingKey);
// compute the hmac on input data bytes

byte[] rawHmac = mac.doFinal(data.getBytes("UTF-8"));
// base64-encode the hmac

result = Base64.encode(rawHmac);
} catch (Exception e) {
throw new SignatureException("Failed to generate HMAC : " +
e.getMessage());
}
return result;
}
}
Setup certificate for secure connection

To use a secure connection, obtain and configure a server certificate.
You must import the server certificate before you can add it to the Java KeyStore.
1. Add a server certificate to the Java KeyStore.
Option Description
If you have the RSA private key in the Java keytool -import -alias keyname -
Keystore and generated the certificate from file server.cert –storetype JCEKS –
that key. keystore webserver_keystore.jceks –
storepass pwd
If you have a PKCS12 file that contains the keytool -importkeystore
RSA key and the certificate. -destkeystore
webserver_keystore.jceks -
deststoretype jceks -srckeystore
<PKCS12 filename> -srcstoretype
pkcs12

Ensure that the private key password is the same as the Java Keystore password.
To change the password, use this command:
keytool -keypasswd -keystore webserver_keystore.jceks -alias <key

alias>
For testing, you can use this command to generate a self-signed certificate.
keytool -genkeypair -alias webserver -dname cn=localhost -validity 365 -

keyalg RSA -keysize
1024 -keypass mykeypass -storetype jceks -keystore
webserver_keystore.jceks -storepass
mykeypass
2. Save the webserver_keystore.jceks file under the /keystore directory.
The user must provide the certificate alias and password when configuring the MID Web Server extension.
For more information, see Configure the MID Web Server extension on page 1039.
Installed with Operational Metrics

Several types of components are installed with Operational Metrics.
Properties installed with Operational Metrics
Operational Metrics adds the following properties.

the navigation filter.
Property Usage
sa.metric.map.with.ci.expiration.sec Length of time (in seconds) that records for

mapping of raw data to CIs remains in effect if
the mapping to CI is found.
• Type: numeric
table
• Learn more: Operational Metrics on page
1030
sa.metric.map.without.ci.expiration.sec Length of time (in seconds) that records for

mapping of raw data to CIs remains in effect if
the mapping to CI is not found.
• Type: numeric
table
• Learn more: Operational Metrics on page
1030
Tables installed with Operational Metrics

Operational Metrics adds the following tables.

Table Description
Metric Time Series Model Statistical models built for metric data.
[sa_time_series]
Alert Anomaly Anomaly alerts that were created from anomaly

events that were sent by Service Analytics
[em_alert_anomaly]
so users can review. Anomaly alerts are kept
separately from regular system alerts.
Metric Anomaly Score Stores anomaly scores for the metric.
[sa_metric_anomaly_score]
Metric Storage Definition Metadata table used internally to define the

archiving strategy for the metric data being
[sa_metric_definition]
collected.
Metric To CI Mapping Deleted SysIds SysIds of expired metric-to-CI mapping records.
[sa_metric_map_deleted]
Metric To CI Mapping Mappings currently in effect of metric types to

CIs.
[sa_metric_map]
SA Metric Type Registration Details about metric type registration.

[sa_metric_registration]
Metric Type Registration Deleted SysIds SysIds of records that were deleted from the SA
Metric Type Registration [sa_metric_registration]
[sa_metric_registration_deleted]
table.
Metric Schema Definition Map of metrics being received based on CI
class. It is used to optimize the metric data
[sa_metric_schema_definition]
payload being sent from the MID Server to the
instance.
Metric Type Metric type source.
[sa_metric_type]
Monitoring System Metric Type Deleted SysIds SysIds of deleted monitoring system metrics.
[sa_source_metric_type_deleted]
Monitoring System Metric Type Metric types per CI class, active/inactive status,
and metric source.
[sa_source_metric_type]
Scheduled jobs installed with Operational Metrics

Operational Metrics adds the following scheduled jobs.
Name Description
Operational Metrics - Metric Learner job Runs daily and builds the statistical models used
for anomaly detection.
Operational Metrics - Purge old metric schemas Cleans up the sa_metric_anomaly_score and
and anomaly scores the sa_metric_schema_definition tables.

Name Description
Operational Metrics - Purge RRD Definitions for Clean up metric data to reflect CIs that were
deleted CIs deleted.
Operational Metrics – Sync metric schema to Synchronizing the metric schema table
mid sa_metric_schema_definition.
Operational Metrics – Sync tables with mid Synchronizing tables.
Operational Metrics – Table cleanup Cleaning up tables related to various deletion
operations.
Create or configure metric type registration

Operational Metrics uses various data sources to collect raw metric data which is later processed and
analyzed. These data sources must be registered in the system. For example, you can configure the pre-
defined SCOM data source registration to control some aspects of how it processes raw data, or register a
new data source.
If raw data is pushed from a data source that is not registered, Operational Metrics automatically registers
that source and adds a record in the SA Metric Type Registration table. By default, Registration Mode
is set to Active, Type Default Mode is set to Active, and Generate Missing CIs is set to false in the new
record.
1. Navigate to Event Management > Operational Metrics > Metric Registration.
All existing registered metric sources are displayed.
2. Configure an existing data source registration, or click New to create a new one.
Column Description
Registration Mode Determines how to process an unknown

metric that is detected in raw data:
• Active: A new metric is automatically
generated based on the unknown metric.
• Inactive: The unknown metric is
discarded.
For SCOM, value is set to Inactive by

default.
Type default mode Determines if a metric that is automatically

generated by the system, is set to be active
or inactive.
For SCOM, value is set to Inactive by
default.

Column Description
Generate Missing CIs Determines how to process CIs in the raw

data that could not be mapped to existing
CIs:
• true: Generate a new CI that is based on
the raw CI that could not be mapped.
• false: Discard the raw CI.
For SCOM, value is set to false by default.

For more information about Event
Management automatically creating CIs,
see Enable automatic CI creation on page
859.
Choose and configure metrics to monitor

Operational Metrics uses data sources that can be monitoring hundreds of metrics for all CIs. Choose
for each data source type which details are important for which CIs, and then activate or deactivate the
respective monitor type to control the amount of data that is being processed.
The SCOM data source, available by default, collects about 400 metric types from discovered devices such
as '% Available Memory' and '% of Free Space'. Processing data from all metric types can overload the
system and impact performance. It might be necessary to deactivate selected metric types for selected CIs
to reduce that load.
Operational Metrics scales as follows:
• Processing of up to 10,000 CIs, with up to 20 metrics per CI, per minute.
• An overall maximum of 200,000 active metrics.
Note: The Active setting (true or false) for a metric in the Monitoring System Metric Types
[sa_source_metric_type] table takes precedence over the setting for the corresponding metric in
the Metric To CI Mappings [sa_metric_map] table. If a metric type in the Monitoring System Metric
Types [sa_source_metric_type] table is disabled, all records related to the corresponding metrics
are removed from the Metric To CI Mappings [sa_metric_map] table.
1. Navigate to Event Management > Operational Metrics > Metric Types.

The Monitoring System Metric Types displays the metric types that are being collected per data
source, per CI type.
2. Review the Monitoring System Metric Types list, and set the value in the Active column to false or
true as necessary.
Column Description
Source Data source monitoring the metric type.

Source Metric Type Metric such as '% Free Space' that is being
monitored for the CI type.
Monitored Object Type CI type that is being monitored.

Column Description
Active Determines whether the metric data is

processed by Service Analytics metrics.
Unit Unit type that is associated with the source
metric type, displayed in the Operational
Metric reports.
Disable a metric for a CI

Operational Metrics can be configured to collect significant amounts of data, some of which might not be
necessary. To improve performance, you can disable a specific metric for a specific CI to stop processing
data related to the specified metric and CI.
Metric to CI Mappings records are automatically generated and remain in effect for 24 hours (by default,
if mapping to the CI is not found), or for 5 days (by default, if mapping to the CI is found). Later, if within
that time period raw data arrives for a metric/CI pair that already has a record, the existing mapping is used
to match the data to an existing CI. After Metric to CI Mappings records expire, incoming new raw data
requires re-mapping. These records expire when:
• The 24-hour or 5-day cycle ends.
• An event rule has changed - This triggers an immediate expiration of the respective mapping record.
Adjusting mappings to reflect the addition or removal of CIs by Discovery, takes effect only upon the
beginning of the next cycle.
Operational Metrics supports up to 200,000 active metrics.
Note: The Active setting (true or false) for a source metric in the Monitoring System Metric Types
[sa_source_metric_type] table takes precedence over the setting for the corresponding metric in
the Metric To CI Mappings [sa_metric_map] table. If a source metric type in the Monitoring System
Metric Types [sa_source_metric_type] table is disabled, all records related to the corresponding
metrics are removed from the Metric To CI Mappings [sa_metric_map] table.
1. Navigate to Event Management > Operational Metrics > Metric to CI.

Metric to CI Mappings displays all metrics per each CI based on event rules. If appropriate, This
breakdown of some metric types is included. For example, a 'disk space' metric for a CI with multiple
disks, breaks down to two metrics collected for the CI: 'Disk C - disk space' and 'Disk D- disk space'.
2. Locate the record for the metric/CI that you want to disable, and set its Active column to false.
Configure Operational Metrics anomaly score thresholds

Operational Metrics scores anomalies on a range 0-10. This range is broken down to the five levels of
event severities, each represented by a different color in the Metric Explorer and in the Anomaly Map. You
can configure the anomaly score threshold for each level of severity.
Anomaly score thresholds are defined in the table Anomaly Score to Event Severity Map
[sa_metric_anomaly_score_to_event_severity_map]. For example, by default, anomaly scores from 8

through 9 are severity 2 (Major), and are displayed by dark orange color in the Metric Explorer and in the
Anomaly Map.
1. Navigate to Event Management > Settings > Anomaly Score to Severity Mapping.
2. On the Metric Anomaly Score to Event Severity Maps page, double-click the event severity that you
want to modify.
3. Modify the range of anomaly scores that map to the respective event severity.
4. Click Update.
View metric values in the Metrics Explorer

Operational Metrics calculates aggregations and statistics for CIs metric data. The Metrics Explorer
displays these metric values as metric charts for the CIs in the CMDB. The Metrics Explorer lets you
overlap any metrics for any CIs in a single chart to create a multi-layered view of metric values across a
time range.
The Metrics Explorer provides a canvas to which you can drag various metrics for CIs and create charts.
You can place single metrics, each individually on the canvas. Or, you can layer several metrics for a
single CI or for different CIs to create a multi-metric chart, each metric displaying in a unique color. This
layering lets you compare metric values across CIs within the same time range. The Metrics Explorer
provides a quick access to the 10 most anomalous CIs. However, you can add any CI from the CMDB that
has metric data, and then add these CI metrics to the canvas.
As you create charts, a legend for the chart is automatically built underneath the chart. For a single-metric
chart, the legend has entries for the aggregations in the chart. For a multi-metric chart, the legend has
entries for the metrics in the chart.
Modifications in the Metrics Explorer remain during the session, and once the Metrics Explorer is refreshed
it returns to its initial state.
1. Navigate to Event Management > Operational Metrics > Metric Explorer.
2. Click a CI to drill down to its associated list of metrics ordered by their most recent anomaly scores.
For each metric, a sparkline displays metric values for the CI for the last hour. Point to the sparkline to
display the metric value at each point of time.
3. Drag a metric to the Drop Metric To Create Chart area on the canvas. Point to the chart to display
the exact metric value at each point of time. The metric chart displays data for the specified time
period, according to the chart settings. By default, raw data is displayed, unless the time period is
longer than a week or earlier than the last week, in which case average data is displayed instead.
When you drag the second and then a subsequent metric, you can drop it on the canvas as follows:
• In the Drop Metric To Create Chart area on the canvas so it is displayed individually in a new
chart.
• Onto an existing chart, in the Replace Chart highlighted block to overwrite the existing chart.
• Onto an existing chart, in the Add Metric highlighted block to overlap it with the existing metrics in
the chart.
When you display multiple metrics in a single chart, the same aggregation selection applies to all
the metrics, and statistics settings are not available. For example, if Average is selected in the
Chart Settings, then averaged values are displayed for all the metrics in the chart.
4. Click the Chart Settings icon to toggle the display of statistics and aggregations on the chart.
Enabling or disabling an item to add or to remove metrics from a chart, also updates the chart's legend
to reflect the change.

Chart Setting Description
Show Bounds Displays a computed upper and lower

bound for the metric based on learning of
past values. The upper and lower bounds
always display together.
Show Anomaly Scores Display anomaly scores on a virtual
axis of 0-10. Color code is based on the
score thresholds that are defined in the
Anomaly Score to Event Severity Map
[sa_metric_anomaly_score_to_event_severity_map]
table.
Average Display aggregated average metric values
calculated per one hour periods.
Aggregated averages are displayed as
follows:
• For data that is up to 28 days old:
Displays 15-minutes aggregation
windows.
• For older data: Displays 1-hour
aggregation windows.
Minimum Display aggregated minimum metric values

calculated per one hour time periods.
Aggregated minimum values are displayed
as follows:
windows.
Maximum Display aggregated maximum metric values

calculated for one hour time periods.
Aggregated maximum values are displayed
as follows:
windows.
Raw Display the raw, unaggregated metric

values. These values are kept only for the
last week.
5. Point to a legend item and click its 'X' icon to remove the corresponding metric from the chart, or to
disable the corresponding series from the Chart Settings.

• Click Add Configuration Item to add to the Metrics Explorer any CI that is not displayed by default.
• Click the Remove icon on a CI to remove it from the Metrics Explorer.
• Zoom in or out by changing the Time Range selection. Select one of the preset time periods to display
anomaly scores for the last 6 Hours or the last 1 Day for example, or specify a custom time period for
up to 90 days back.
Highlight a section of a chart by pointing to the upper left corner of the section and dragging the mouse
device to the lower right corner of the section, to zoom in. This operation changes the time range
of the chart, and if there are other charts on the canvas, they are all automatically synchronized to
display data for the same time range. On the Time Range bar, the custom dates are also automatically
updated with the new time range.
• Add a filter to display only a specific set of CIs out of the CIs that are displayed.
• Click the Export icon to download a chart as a .png or .svg image, or as a .pdf document.
View Operational Metrics Anomaly Map

The Anomaly Map generated by Operational Metrics, displays the 10 CIs with the highest metric anomaly
scores across a time period. The map lets you drill down into each CI to display anomaly scores for each of
the CI's metrics. Anomaly scores are color coded to help you isolate problem areas at a glance.
Operational Metrics monitors metric data for CIs and detects anomalies when values are out of
bounds according to the statistical model. Anomalies are scored on a scale of 0-10, and mapped
into color codes based on score thresholds defined in the Anomaly Score to Event Severity Map
[sa_metric_anomaly_score_to_event_severity_map] table.
1. Navigate to Event Management > Operational Metrics > Anomaly Map. In the Anomaly Map, point
to a colored anomaly box to display the details of the CI, instance, and the time period for the anomaly
scores.
The color of each anomaly box represents the highest anomaly score of all metrics for the CI for the
time period.
2. Click a CI to display a breakdown of all the metrics for the CI with their respective anomaly scores
across the time period. Point to an anomaly box to display its precise anomaly score.
The color coded anomaly score next to the metric represents the latest metric value for the CI.
• Click Add Configuration Item to add to the map a CI that has anomalies and that isn't included in the
top 10 anomalies.
• Click the Remove icon on a CI to remove it from the map.
• Zoom in or out by changing the Time Range. Select one of the preset time periods or display data for
example for the last 6 Hours or the last 3 Days, or specify a custom time period up to 90 days back. Or,
click the timestamp at a column heading to drill into the time period between the current column and the
column to the right.
• Add a filter to display only a specific set of CIs out of the CIs that are displayed.
View Operational Metrics anomaly alerts

View anomaly alerts generated by Operational Metrics. Anomaly alerts indicate deviation from projected
metric values for monitored CIs. Anomaly alerts are separate from the regular Event Management alerts,
and are not displayed in the Alert Console. You can define an event rule to generate a regular alert that is
based on anomaly alerts.

The statistical model is used to calculate standard deviations, upper and lower bounds, and statistical
outliers which are then used to detect anomalies. An anomaly is when metric values are out of the
projected values according to the statistical model. The system monitors the frequency and persistence of
statistical outliers across time to compute a score between 0-10 that indicates how abnormal a deviation is.
Operational Metrics constantly generates anomaly alerts whenever the anomaly score is above zero. If
there is a score that is above 4 which has changed from the previous score - it is sent to the instance so
the entire sequence of deviations over time can be displayed in the Metric Explorer.
1. Navigate to Event Management > Operational Metrics > Anomaly Alerts.
2. In the Alerts Anomalies list view, double-click on an alert that you want to view.
• You can create an event rule that examines the anomaly alerts, and generates a regular system alert
that is based on anomaly alerts. Create an event rule, and specify:
• Filter: Add filter conditions such as [CI identifier] [is] [CI SysId], or [Metric Name] [is] [metric]. To
select anomaly alerts add the filter condition [Classification] [is] [Anomaly].
• On the Transform tab, add an entry to Event Compose Fields where Field is classification
and Composition is 0.
• Right-click an alert, and then click View Metrics to open the integrated Metrics Explorer and
Dependency Views map for the CI associated with the alert.
Push metrics to the MID server

You can use REST messages to send operational metric information to the operational-metrics-MID
server.
See Get started with Operational Metrics for information on setting up the MID server. See Configure the
MID Web Server extension for information on authentication requirements.
mid - POST /mid/sa/metrics

Push raw Operational Metrics data from an external source to the MID Server.
URL format
This request goes to the Operational Metrics MID Server, not the instance. The MID Server must have
the operational metric extension setup with Enable REST endpoint set to true. See Get started with
Operational Metrics for more information.
The URL of the request is the form http[https]://mid1.servicenow.com/api/mid/sa/metrics,
where mid1.servicenow.com is the FQDN or IP address of the MID Server.
Versioned URL: api/mid/sa/metrics
Default URL: api/mid/sa/metrics
Supported request parameters
Table 448: Parameters
None

Headers
Table 449: Request headers
Header Description
None
Table 450: Response headers
Header Description
None
Status codes
The following status codes apply to this HTTP action. For a list of possible status codes used in the REST
API, see REST response codes.
Table 451: Status codes
Status code Description
200 Request completed successfully. If a valid query

returned no results, the response body contains
only an empty result array.
Request body
The API accepts these JSON or XML elements in the request body.
Table 452: Elements accepted in the request body
Element Description
metric_type Name of the metric.

resource Information about the resource for which metric
is being collected. In the example below, C:\ is
the resource for which metric data is collected.
node IP, FQDN, name of the CI or host. In the
example below, the name of the Linux server
where the disks are installed.
value Value of the metric.
timestamp Epoch timestamp of the metric in milliseconds.
ci_identifier List of key-value pairs to identify the CI.

Element Description
source Data source monitoring the metric type.
Request payload example
[{
"metric_type": "Disk C: % Free Space",
"resource": "C:\\",
"node": "lnux100",
"value": 50,
"timestamp": 1473183012000,
"ci_identifier": {
"node": "lnux100"
},
"source": "Splunk"
}]
Cloud Management
With the ServiceNow® Cloud Management application, you can use a single ServiceNow interface to
define, administer, and measure workflows for provisioning cloud resources. You can also manage
the life cycles of those resources. Cloud Management is integrated with both private and public cloud
management providers, including Amazon Web Services, Microsoft Azure, and VMware offerings.
Cloud Management is available as a separate subscription from the rest of the ServiceNow platform. You
must also request activation from ServiceNow personnel.
It also requires Orchestration, which is available as a separate subscription from the rest of the platform.

• Cloud Management release • Request Cloud Management • Cloud administrator actions on
notes on page 1057 page 1111
• Upgrade to Istanbul • Determine whether your • Cloud operator actions on
• Cloud Management product instance has Orchestration on page 1190
overview on page 1055 page 1062 • Cloud Management reports on
• How Cloud Management • Configuring Amazon AWS page 1244
works on page 1106 Cloud on page 1062
• Cloud user groups on page • Getting started with Microsoft
1059 Azure Cloud on page 1093
• Configuring VMware Cloud on
page 1098

• Cloud user actions on page • Developer training • Errors and Troubleshooting on
1204 • Developer documentation page 1282
• Ask or answer questions in the
IT Operations Management
community
• Search the HI knowledge base
for known error articles

• Contact ServiceNow Support
Cloud Management product overview

In addition to provisioning virtual resources, the Cloud Management application fully integrates the life-
cycle management of virtual resources into standard ServiceNow data collection, management, analytics,
and reporting capabilities.
Cloud Management Provider Integration
VM users request and manage their cloud assets using the familiar ServiceNow service catalog interface.
Cloud Management provides process and service automation with orchestration, approvals, and service
catalog capabilities. The system can package and deliver infrastructure elements, such as servers,
networks, and storage to end users through the service catalog. The system auto-provisions the cloud
resources that a user requests and manages using a self-service portal.
The Cloud Management application offers the following capabilities:
• Abstraction of virtualization systems: Because the requesters of virtual resources are not required to
know the details of the specific virtualization system, the system uses a single interface to manage
virtual resources in public and private clouds.
• Reuse of virtual machine configurations: The system uses the templates provided by the third-party
vendors (for example, Azure templates, VMware templates, and Amazon images) to create reusable

catalog items, typically with a wide range of capability sets. Using the service catalog, the user selects
from the resulting resource templates.
• Service catalog interface: Requesting the right virtual resource for the job from the catalog is quick and
easy for the user.
• Role-based access: Role-based security ensures that users have the proper privileges for viewing,
creating, and managing virtual resources.
• Dedicated service portals: ServiceNow users view their virtual resources and request changes on a
dedicated portal. Administrative and operational users manage virtual machines, provisioning tasks,
and SLAs from portals that grant role-based access to virtual resources.
• Controlled lease duration: The system applies default end dates to all virtual machine leases. Lease
duration controls prevent unused virtual machines from persisting past their intended use date.
• Fully integrated with the ServiceNow platform: Approvals, notifications, security, asset management,
and compliance capabilities are all integrated into virtual resource management processes.
Note: The Cloud Management application was called Cloud Provisioning in earlier versions.
• Approvals: You can make any request subject to approvals, allowing you to develop complex and
business-critical processes.
• Discovery of VMs: Use the Discovery application or the standalone capability to discover virtual
resources and their relationships in their environments (for example, relationships between VMware
components in the vCenter instance).
• Capacity: Because the Discovery process returns basic capacity information for VMs, a cloud operator
can determine the best virtualization server for a VM.
• Schedule Labs: Schedule a lab framework to manage multiple groups of virtual resources for a common
purpose, such as training. Schedule lab termination date and time to shut down virtual resources as
soon as they complete their function.
• Modify VMs: Request modifications to existing VM images, for example increased memory. Workflows
can require approvals for each modification or can auto-create a change request.
• Notifications: The system delivers notifications during the virtual resource life cycle to provide
information and set expectations for system users.
• Prices: Price calculations and an integration of managed virtual machines with asset management
provide a cost-based component to Cloud Management.
• Information about requests: The system collects notes and guest customization information and
attaches the data to the provisioning request.
• Automated provisioning: A cloud administrator can configure the system to apply automatic or manual
provisioning to virtual resource requests:
• Fully automatic: Rules make all configuration decisions and processing goes directly from the
request to provisioning.
• Manual: Rules make all configuration decisions but a cloud operator can modify and approve the
request before continuing.
• Schedules: The system specifies a lease duration when creating a virtual resource. The schedule
includes start and end times, a grace period, and automatic stop/terminate actions. The system notifies
the user of lease status.
• SLAs: The system tracks SLAs and OLAs for Cloud Management requests.
• Workflows: Each action employs customizable workflows that allow business processes to include
Cloud Management as a step.
• Zero-click provisioning: Fully automated provisioning enables IT departments to respond quickly to
customer requests.
• Security: All workflows, business rules, and scripts in the base system are locked. The system restricts
cloud management actions to users with particular role.

Request Cloud Management

Cloud Management requires a separate subscription and must be activated by ServiceNow personnel.
Role required: none



3. Click Submit.
Overview: Configuring Cloud Management

Overview of steps to configure Cloud Management.
Users, roles, and groups

Set up user personas and groups to administer, Cloud user groups on page 1059
order, and maintain resources from ServiceNow.
Determine the cloud admin user who will perform Cloud admin tasks
cloud registration and discovery.
Cloud registration

Set up the credentials to connect to your cloud AWS:

service and identify the authentication method to
Configure AWS credentials on page 1079
use.
Azure:
Collect the Azure Client ID and Tenant ID on
page 1093
Configure the Azure Enterprise Agreement (EA)
credentials on page 1096
VMware:
Configure VMware credentials on page 1100
Discovery
Discover existing resources. AWS:
Discover and view AWS resources
Azure:
Configure and run Discovery for your Azure
subscription
VMware:
Discover vCenter resources
Determine the images to use for catalog creation AWS:

and approve them.
Approve images for use as catalog items
Azure:
Approve images to use as the basis for Azure
catalog items
Catalog creation
Use approved images to create catalog items AWS:
and customize any variables on these items.
Set up an AWS catalog offering on page 1113
Azure:
Set up an Azure catalog offering on page 1133
VMware:
Create a catalog item for VMware on page 1151
Provisioning
Configure provisioning rules Define provisioning rules on page 1182
Templates
Configure any templates for stacks or resource AWS stacks:
groups.
Create a CloudFormation template on page
1123

Azure resource groups:

Define an ARM template on page 1138
Billing
Set up billing download schedules. Define the schedule for downloading billing data
Reporting
View virtual assets and billing reports. Viewing and managing your virtual assets
Cloud Management reports
Cloud user groups

The three types of personas in the Cloud Management application are cloud administrator, cloud operator,
and cloud user. Cloud administrators configure and set up the system. Cloud operators perform the day-
to-day activities including management and provisioning. Cloud users (typically in IT) request virtual
resources.
The privilege to perform a particular task is granted by a user role. A user is assigned a role when an
admin adds the user to a user group that includes the role.
To enable admins to manage security, the Cloud Management application adds a number of user groups
to the system. Each user group is associated with a user role. When an admin adds a user to one of the
groups, the user is granted the role that is assigned to the group. To manage Cloud Management security,
an administrator adds a user to the appropriate group or removes a user from the group.
To implement security for a user who must play multiple roles, good practice is to add the user to multiple
groups. If the predefined groups do not provide enough granularity, you can create a custom group or grant
a particular role directly to an individual user.
User groups are described here in order of increasing privileges.
Cloud user group
Cloud users can request virtual resources from the service catalog and can perform the following actions
only on VMs assigned to them.
• Modify VM (Azure and VMware only)
• Update Lease End
• Pause VM
• Stop VM
• Start VM
• Cancel
• Terminate
• Take Snapshot
• Restore from Snapshot
• Delete Snapshot

Table 453: Cloud User user group
User group Contains the following user role Privileges
Virtual Provisioning Cloud cloud_user Request virtual resources from

Users the service catalog and use
the My Virtual Assets portal to
manage virtual resources that
are assigned to them.
Cloud Approvers groups
Cloud Approvers can approve or reject requests for virtual resources. Approvers have no technical
responsibilities.
Table 454: Cloud Approver user groups
Azure Approvers itil Approve or reject requests

for Azure virtual resources.
This includes requests for
new virtual machines, state
changes (start/stop) to existing
virtual machines, and lease
extensions.
EC2 Approvers itil Approve or reject requests for
Amazon EC2 virtual resources.
This includes requests for new
virtual machines, state changes
to existing virtual machines, and
lease extensions.
VMware Approvers itil Approve or reject requests
for VMware virtual resources.
This includes requests for new
virtual machines, modifications
to existing virtual machines, and
lease extensions.
Cloud Operator user groups
Cloud operators use the Cloud Operations portal to perform the day-to-day work of cloud provisioning
and management. Cloud operators are typically assigned to particular virtualization providers and must
be technically adept with the products they support. Users with the cloud_operator role can perform the
following actions on any virtual machine:
• Pause VM
• Stop VM
• Start VM

• Cancel
• Terminate
• Take Snapshot
• Delete Snapshot
Table 455: Cloud Operator user groups
Virtual Provisioning Cloud cloud_operator Fulfill provisioning requests

Operators from users by completing
tasks that appear on the Cloud
Operations Portal.
This group also includes all
members of the child groups
that are noted in this table.
EC2 Operators ec2_operator Fulfill Amazon EC2 provisioning

requests from users by
(child group of Virtual
completing tasks that appear
Provisioning Cloud Operators)
on the Cloud Operations
Portal. Users in the group are
members of Virtual Provisioning
Cloud Operators parent group.
Azure Operators azure_operator Fulfill Azure provisioning
Portal. Users in the group are
members of Virtual Provisioning
Cloud Operators parent group.
VMware Operators vmware_operator Fulfill VMware provisioning
Portal. Users in the group
are members of the Virtual
Provisioning Cloud Operators
parent group.
Cloud Administrator user group
Cloud Administrators own the Cloud Management environment and are responsible for configuring the
virtualization products that are supported by the Cloud Management application on your instance. Admins
receive both the cloud_admin and the cloud_user roles. Admins can perform the following actions only on
VMs assigned to them:
• Pause VM
• Stop VM

• Start VM
• Cancel
• Terminate
• Take Snapshot
• Delete Snapshot
• Define vCenters
• Define catalog offerings
• Set pricing for the offerings
• Define provisioning rules
• Define change control parameters for a virtual machine
• Approve change requests associated with virtual machine modifications
• Set properties applicable to cloud management
• Set up networking information for VMware guest customization
• Monitor requests and key metrics related to requests surrounding virtual machines
Table 456: Cloud Administrator user group
User group Contains the following user roles Privileges
Virtual Provisioning Cloud cloud_admin, cloud_user, itil Cloud administrators can

Administrators monitor the Cloud Management
environment using the Cloud
Admin Portal.
Determine whether your instance has Orchestration

Cloud Management requires Orchestration.
Role required: cloud_admin, aws_admin, sn_azure.admin, vmware_operator
Orchestration is available as a subscription separate from the rest of the platform. To purchase an
Orchestration subscription, contact your account executive.
1. Navigate to Workflow > Activity Definitions.
2. Locate the Run Probe activity.
If this activity is present on your instance, Orchestration is installed. If this activity is not present,
contact your ServiceNow account representative.
Configuring Amazon AWS Cloud

Users who are members of the Virtual Provisioning Cloud Administrators group can create one or more
AWS accounts and then configure the system to communicate with those AWS accounts.
Collect the following information about your AWS accounts for use while configuring the instance to
communicate with the accounts:
• Account number
• Access Key ID
• Secret Access Key

MID Servers
The discovery of Amazon Web Services cloud is based on account information rather than IP addresses.
MID Servers are not used in this type of discovery. To perform host-based discovery of the virtual hosts
contained within an AWS Virtual Private Cloud (VPC), you need a MID Server.
To set up and configure a MID Server, see:
• MID Server installation
• MID Server configuration
Installed with Amazon AWS Cloud

The Amazon Web Services (com.snc.aws) plugin is activated automatically when you subscribe to Amazon
AWS Cloud.
Plugins
Amazon AWS Cloud adds or modifies the following plugins.
Table 457: Amazon AWS Cloud plugins
Name Description
com.snc.aws The primary Amazon AWS Cloud plugin.

com.snc.aws.activities Amazon AWS Cloud activities.
com.snc.aws.common Amazon common.
com.snc.aws.core Components common to Amazon AWS Cloud.
com.snc.discovery.aws Probes and sensors for discovering infrastructure components in AWS,
including VPCs, subnets, VMs, availability zones, regions, volumes, and
so on.
com.snc.ec2_v2 Support for provisioning Amazon VMs from images (AMIs). Includes a
service catalog entry for ordering an instance running Windows or Linux.
com.snc.orchestration.activities.ec2
Uses workflow technology to issue Amazon EC2 activities that will
execute the commands on Amazon cloud.
Tables
Table 458: Amazon AWS Cloud tables
Table Description
ec2_account Contains account details for the Amazon EC2 account being used for
provisioning or terminating instances.
ec2_approved_images
Contains images approved by a cloud_administrator for provisioning user
requests.

Table Description
ec2_image Contains a list of all EC2 images from all regions in which region settings are
defined.
ec2_keypairs Contains the keypairs for all the regions for the account.
ec2_region_settingsContains data associated with an account. This table contains the region and
the keypair to use when provisioning instances in a region.
ec2_region Contains the 5 current SOAP endpoints to Amazon's five datacenters (regions).
sc_ec2_os_selectionContains the OS types that appear in the service catalog, as defined by the
cloud_administrator.
sc_ec2_type_selection
Contains the types that appear in the service catalog. The base system
includes Small and Large, which correspond to Amazon's m1.small and
m1.large classification, respectively.
ec2_shared_image_account
Contains the names and numbers of the accounts that provide shared EC2
images.
User roles
Modules in the Amazon AWS Cloud application are accessible to users as described in User roles installed
with Amazon AWS Cloud on page 1065.
User groups
Table 459: Amazon AWS Cloud user groups
Group Description
Virtual Provisioning Cloud Administrators Members of this group own the Cloud
Management environment and are responsible
for configuring the Amazon EC2 environment.
Virtual Provisioning Cloud Operators Members of this group fulfill provisioning
requests from users. This group also contains
the EC2 Operators group.
EC2 Operators Members of this group are responsible for the
technical operation of the Amazon EC2 virtual
provisioning environment.
EC2 Approvers Members of this group approve requests for
Amazon VMs.
Virtual Provisioning Cloud Users Members of this group can request virtual
machines from the service catalog and request
changes to virtual machines assigned to them.

Script includes
Table 460: Amazon AWS Cloud script includes
EC2Util Updates the database with instance and image

information received from an Amazon EC2
account.
Plugins installed with Amazon AWS Cloud

Amazon AWS Cloud adds or modifies these plugins.
Plugins
Table 461: Amazon AWS Cloud plugins
Name Description
com.snc.aws The primary Amazon AWS Cloud plugin.

com.snc.aws.activities Amazon AWS Cloud activities.
com.snc.aws.common Amazon common.
com.snc.aws.core Components common to Amazon AWS Cloud.
com.snc.discovery.aws Probes and sensors for discovering infrastructure components in AWS,
including VPCs, subnets, VMs, availability zones, regions, volumes, and
so on.
com.snc.ec2_v2 Support for provisioning Amazon VMs from images (AMIs). Includes a
service catalog entry for ordering an instance running Windows or Linux.
com.snc.orchestration.activities.ec2
Uses workflow technology to issue Amazon EC2 activities that will
execute the commands on Amazon cloud.
User roles installed with Amazon AWS Cloud

Amazon AWS Cloud adds or modifies user roles for administration, provisioning (operator), and requesters
(cloud users).
User roles
Table 462: Amazon AWS Cloud user roles
Role Contains roles Description
aws_admin aws_user, Has full access to common AWS configurations.

discovery_admin
aws_operator aws_user, itil, Responsible for the technical administration and
ec2_operator operation of the AWS provisioning environment.

Role Contains roles Description
aws_user none Has access to the AWS application menu.

cloud_admin workflow_admin, Has full access to the overall operation of the virtual
credential_admin, provisioning cloud environment.
aws_admin, itil,
cloud_user
cloud_user aws_user Can request and control individual virtual assets,
but has no control over how/where those assets are
provisioned.
cloud_operator cloud_user, aws_operator, Performs technical administration and operation of
ec2_operator the environments used by the Amazon AWS Cloud
application.
ec2_operator itil Performs technical administration and operation of the
EC2 provisioning environment.
Tables installed with Amazon Web Services

Amazon AWS Cloud adds or modifies these tables.
Tables
Table 463: Amazon AWS Cloud tables
Name Description
AWS Tags Defines the tags used for tagging Amazon resources.
[aws_tag]
AWS Tag Rules Defines the rules for automatically attaching values to tags.
[aws_tag_rule]
AWS CI Tag Value Maps a CMDCI to a tag name and tag value.
[aws_ci_tag_value]
AWS Custom Tag Value Maps a tag to a static string value.

[aws_custom_tag_value]
AWS Resource Tag History Maps an Amazon resource ID to an Amazon tag.

[aws_rsrc_tag_history]
AWS Resource Tag History Maps an aws_rsrc_tag_history reference to a tag name and tag
Mapping value.
[aws_rsrc_tag_history_mapping]
AWS Job Configuration Represents an AWS bill download.

[aws_job_config]

Name Description
AWS Billing Report Type Defines how to parse a downloaded Amazon billing .csv file.
[aws_billing_report_type]
AWS Report Download Log Represents a log item created during an AWS billing download.
[aws_report_download_log]
AWS Billing Rollup Defines which field to sum from on the hourly and daily billing tables.
Aggregate
[aws_billing_rollup_aggregate]
AWS Billing Rollup Pivot Defines which field to roll up on the hour and daily billing tables.
Point
[aws_billing_rollup_pivot]
AWS Billing Report Filter Inserts all unique resource IDs that are used in Amazon cost reports.
Point
[aws_billing_report_filter]
AWS Billing Hourly with Contains records corresponding to an Amazon line item with hourly
Tags data and tag mapping relationship. Keeps data less than 30 days old.
[aws_billing_hourly_with_tags]
AWS Billing Chart Definition Contains cost and usage report selections.
[aws_billing_chart_definition]
AWS Billing Rollup Daily Created from aws_billing_hourly_with_tags records table, for a 1 day
duration. Only keeps data less than 180 days old.
[aws_billing_rollup_daily]
AWS Billing Rollup Monthly Created from the aws_billing_hourly_with_tags table, for a 1 month
duration. Keeps only data less than one year old.
[aws_billing_rollup_monthly]
AWS Optimization Rule Contains rules for Amazon Elastic Block Store resources. This table
EBS is a child of the opt_rule_attached_storage table.
[aws_opt_rule_ebs]
AWS Optimization Rule Contains rules for Amazon EC2 resources. This table is a child of the
EC2 opt_rule_attached_storage table.
[aws_opt_rule_ec2]
AWS Optimization Rule Contains rules for Amazon Elastic Load Balancing. This table is a
ELB child of the opt_rule_attached_storage table.
[aws_opt_rule_elb]
CloudFormation Contains rules for Amazon Elastic Load Balancing. This table is a
Provisioning Rules child of the opt_rule_attached_storage table.
[aws_cldfrm_provisioning_rules]

Name Description
AWS CloudFormation Stack Contains an editable draft of stack changes. The records are created
Change Definition when modifying a stack.
[aws_cldfrm_stack_change_definition]
AWS CloudFormation Stack Contains an editable draft of stack parameters. The records are
Change Parameters created when modifying a stack.
[aws_cldfrm_stack_change_params]
AWS CloudFormation Stack Contains a list of stack resources.

Resource
[aws_cldfrm_stack_change_definition]
AWS CloudFormation Script Contains a script mapping table used to resolve scripts dynamically.
Mapping
[aws_cloudformation_script_mapping]
AWS CloudFormation Stack Contains a list of stack outputs.

Output
[aws_cloudformation_stack_output]
AWS CloudFormation Stack Contains a list of stack parameters.

Parameter
[aws_cloudformation_stack_parameter]
AWS Console Access Contains either a URL or link to generate tokens for Amazon console
Request access.
[aws_console_access_request]
CloudFormation Contains a list tables that are not applicable for CloudFormation
Parameters Reference Parameters Reference Table lookup.
Table Exclusions List
[cldfrm_param_ref_table_excl]
CloudFormation Template Contains a list of CloudFormation template parameters. The records

Parameters are created when a template is saved.
[cloudformation_template_parameter]
CloudFormation Variable Contains mapping for CloudFormation template and variable sets.
Set for Template
Parameters
[cloudformation_template_to_variableset]
AWS CloudFormation Stack Contains a list of CloudFormation stacks from all Amazon regions.
[cmdb_ci_cloudformation_stack]
CloudFormation Template Contains a list of CloudFormation templates.

[cmdb_ci_cloudformation_template]

Name Description
AWS Security Token Contains the catalog item for AWS security tokens.
Catalog Item
[sc_aws_security_token_cat_item]
CloudFormation Catalog Contains a catalog item for a CloudFormation stack.

Item
[sc_cloudformation_cat_item ]
AWS Auto Scaling Group Contains a list of launch configurations from all regions.
Launch Config
AWS Policy Contains a list of policies that can be applied to security tokens for
federated access.
[aws_policy]
AWS Security Token Contains security tokens for federated access.

[aws_token]
AWS Security Token for Contains the mapping for a user and a security token.
User
[aws_user_token]
AWS Auto Scaling Group Contains a list of autoscaling groups from all regions.
[cmdb_ci_aws_asgrp ]
Amazon Web Services Contains algorithms, API version, and other meta data needed to
make API call for different Amazon Web Services.
[amazon_web_service]
AWS Datasource Type Contains mappings between discovered attributes and a variable in a
Mapping normalized object created on the fly.
[aws_datasource_type_mapping]
Normalized Object to DB Contains mapping between variables in normalized object to field in

Mapping tables.
[normalizedobject_db_mapping]
AWS Region Endpoint Contains a list of endpoints for all AWS regions.
[aws_region_endpoint]
AWS Region Contains a list of all AWS regions.

[aws_region]
AWS Resource Type Contains a list of AWS resource type.

[aws_resource_type]
AWS Service Endpoint Contains metadata to calculate a service endpoint.

[aws_service_endpoint]

Name Description
AWS Resource Contains a reference to the specific resource record.

[cmdb_ci_aws_resource]
AWS Account Contains account details for Amazon accounts such as username
and ID.
[aws_account_admin]
AWS Actions Contains actions for AWS API calls.

[aws_action]
AWS Availability Zone Contains a list of availability zone from all regions.
[aws_availability_zone]
AWS Credentials Contains access credentials for AWS accounts, like security keys and
access keys.
[aws_credentials]
AWS Elastic Block Store Contains a list of snapshot from all regions.
Snapshot
[aws_ebs_snapshot]
AWS Elastic Load Contains a list of back-end servers.

Balancer Backend Server
Description)
[aws_elb_backend_server]
AWS Elastic Load Balancer Contains a list of load balancer policies from all regions.
Policy
[aws_elb_policy]
AWS Noun Contains nouns to create probe actions such as image and instances.
[aws_noun]
AWS Verb Contains verbs to create probe actions such as get and describe.
[aws_verb]
AWS Resource to Contains a mapping between a generic AWS resource and an

Availability Zone Mapping availability zone.
[aws_resource_to_availzone]
AWS EBS Volume Contains a list of volumes from all regions.

[cmdb_ci_aws_ebs_volume]
AWS Elastic Load Balancer Contains a list of ELB listeners from all regions.
Listener
[cmdb_ci_aws_elb_listener]
AWS Subnet Contains a list of subnets from all regions.

[cmdb_ci_aws_subnet]

Name Description
AWS VPCs Contains a list of VPCs from all regions.

[cmdb_ci_aws_vpc]
EC2 Virtual Machine Contains a list of virtual machine instances from all regions.
Instance
Subnet Contains a list of ELBs from all regions.

[cmdb_ci_subnet]
Virtual Private Cloud Parent table for cmdb_ci_aws_vpc.

[cmdb_ci_vpc]
AWS Probe Contains a list of AWS probes.

[discovery_aws_probe]
Probe Parameter Override Contains overrides for request parameter of probes.

[dscy_probe_parameter_override]
AWS VPC Security Group Contains a list of security group rules.

Rule
[aws_vpc_security_group_rule]
AWS VPC Security Group Contains a list of security groups.

AWS VPC Security Group Contains a list of security group rule traffic types (name, protocol
Rule Traffic Type number, from_port, and to_port).
[aws_vpc_sg_rule_traffic_type]
EC2 Approved Image Contains images approved by a cloud_administrator for provisioning

user requests.
[ec2_approved_images]
EC2 Image Attribute Contains list of attributes specifying properties of images for spinning
up VMs.
[ec2_image_attribute]
EC2 Image Criteria Contains a list of filter names used to filter VM types and sizes.
[ec2_image_critera]
EC2 Criteria Attribute Contains list of mapping between criteria and image attribute used for
filtering VMs types and sizes.
[ec2_criteria_attribute_m2m]
EC2 Image Contains a list of all EC2 images from all regions.
[ec2_image]
EC2 Keypairs Contains the keypairs for all the regions for the account.
[ec2_keypairs]

Name Description
EC2 Provision Rules Contains rules to auto-select provisioning variables such as account,
VPC, and subnet.
[ec2_provision_rules]
EC2 Region Size Exclude Contains a list of mappings between region and sizes that are not
supported in that given region.
[ec2_region_size_exclude_m2m]
EC2 Shared Image Account Contains the names and numbers of the accounts that provide shared
EC2 images.
[ec2_shared_image_account]
EC2 Size Criteria Contains a list of mappings between image criteria and EC2 sizes
used for filtering VMs types and sizes.
[ec2_size_criteria_m2m]
EC2 Size Contains list of supported EC2 sizes from all regions.
[ec2_size]
Internet Protocol A list of standard internet protocol numbers and names.

[internet_protocol]
ICMP Message A list of ICMP control messages

[ip_icmp_message]
IP Message Mapping Contains mappings between an IP protocol number and a translator

script include.
[ip_message_mapping]
EC2 Catalog Item Contains catalog items for VMs.

[sc_ec2_cat_item]
Catalog EC2 Element Price Contains mappings between an EC2 element and the catalog price.
[sc_ec2_element_price]
EC2 Key Pair Catalog Item Contains catalog item for AWS keypairs.
[sc_ec2_key_pair_cat_item]
EC2 Catalog Offering Contains the OS types that appear in the service catalog, as defined
by the cloud administrator.
[sc_ec2_os_selection]
Properties installed with Amazon AWS Cloud

Amazon AWS Cloud adds or modifies these properties.
Properties
Table 464: Amazon AWS Cloud properties
Name Description
aws.token.provisioning.duration Provisioning token duration (in minutes).

Name Description
aws.cldfrm.template.s3_bucket The S3 bucket for large CloudFormation

templates.
aws.cldfrm.template.size_threshold Threshold (in bytes) for large CloudFormation
templates.
cloud.rerc.opt.enabled Status of resource optimization report scheduled
job.
cloud.rerc.opt.wf_time_out The maximum time (in seconds) a resource
optimization analysis is allowed to run before
self-termination.
Demo data for AWS Cloud

To illustrate the use of Amazon Web Services, the system provides demonstration data and samples of
data types.
Note: To prevent conflict with production data, load demo data only on a development or test
instance.
AWS demo data: Groups and users

To illustrate the use of Amazon Web Services, the system provides demo data and samples of the data
types.
instance.
Three user groups and four users are created as demo data.
• The Infrastructure and Service groups are children of the Cloud Operation group.
• Users Adam Alba and Bob Brown are in the Infrastructure group.
• User Cindy Cyrus is in the Service group.
• User Dan Daniels is in the Cloud Operation group.
• All of the users have the cloud_admin role.

Figure 184: Demo groups
Note: A note indicates neutral or positive information that emphasizes or supplements important
points of the main text. A note supplies information that may apply only in special cases. Examples
are memory limitations, equipment configurations, or details that apply to specific versions of a
program.
AWS demo data: CloudFormation templates

types.
instance.
The table maps each demo template to its demo stack:
Table 465: Demo CloudFormation templates
Template Name CloudFormation Stack Name

AD-usesPrivateSubnet AD-usesPrivateSubnet
LAMPstack-usesVPC-PubPrivSubnet-RDS LAMPstack-usesVPC-PubPrivSubnet-
RDS, LAMPstack-usesVPC-PubPrivSubnet-
RDS-RetailPort, LAMPstack-usesVPC-
PubPrivSubnet-RDS-PeopleSoft
LAMPstack-usesVPC-PubSubnet LAMPstack-usesVPC-PubSubnet, LAMPstack-
usesVPC-PubSubnet-RetailPortal
POS-includesVPC POS-requiresVPC

VPC-PubPrivSubnet VPC-PubPrivSubnet
VPC-PubSubnet VPC-PubSubnet
AWS demo data: CloudFormation service catalog items

types.
instance.
The demo service catalog item names follow the pattern of "CloudFormation Stack – " plus the name of
CloudFormation template. For example, one item name is CloudFormation Stack – AdwithPrivateSubnet.
All of the demo catalog items use a demo account named AWS Account and U.S. West (Oregon) Region.
In each catalog item, you can specify input parameters to provision stacks. For example, you can specify
which public and private subnets to use for the CloudFormation Stack – LAMPstack-VPC-PubPrivSubnet-
RDS catalog item.
To help the end users to validate input parameters before actual provisioning, the order form uses dynamic
input validation client scripts.
AWS demo data: CloudFormation stacks and tags
types.
instance.
Each demo stack has been assigned with five standard tag values, as listed in the table.
Each stack comes from a completed-stage catalog item request, which is also showing as demo data in
the Amazon Assets portal page. To support some of the tag values, the following extra demo records have
been created in the corresponding tag table:
• For the Application tag: Active Directory, Community, Retail Portal, Shopping Cart and PeopleSoft
• For the Cost Center tag: Retail
• For the Project tag: Athens and Berlin
Table 466: Demo CloudFormation stacks and tags
Count Stack Name Service Application Cost Center Project User Name
1 ADwithPrivateSubnet
IT Services Active IT Athens Adam Alba
Directory
2 LAMPstack- IT Services Community IT Berlin Adam Alba
VPC-
PubSubnet
3 LAMPstack- Retail SAP WEB01 Retail Athens Adam Alba
VPC-
PubPrivSubnet-
RDS
4 VPC- Retail SAP WEB01 Retail Athens Adam Alba
PubPrivSubnet

5 VPC- Retail Retail Portal Retail Berlin Adam Alba

PubSubnet
6 LAMPstack- Retail Retail Portal Retail Athens Bob Brown
VPC-
PubPrivSubnet-
RDS-
RetailPortal
7 LAMPstack- Retail Retail Portal Retail Berlin Bob Brown
VPC-
PubSubnet-
RetailPortal
8 POS-VPC Retail POS Shopping Retail Berlin Cindy Cyrus
Cart
9 LAMPstack- PeopleSoft PeopleSoft Human Athens Cindy Cyrus
VPC- CRM Resources
PubPrivSubnet-
RDS-
PeopleSoft
AWS demo data: CloudFormation stacks and CI resources

types.
instance.
Each demo stack contains multiple CI resources. In the My Amazon Assets portal page, you can see all
available CI resources, including VPC, subnet, VM, ELB, ELB listener, and Auto Scaling Group, as well as
CloudFormation stacks that belong to the login user. The table shows the relationship between stacks and
the different types of CI resources in the demo data .
Table 467: Demo stacks and CI resources
Stack VPC Subnet Auto VM ELB ELB EBS

Name Scaling Listener Volume
Group
ADwithPrivateSubnet
vpc-3e47875b
subnet-248f5041
n/a ip-172-31-46-96
n/a n/a vol-
a55a24a4
LAMPstack- vpc- subnet-729e6305
n/a ip-10-0-0-7 n/a n/a vol-88057b8d
VPC- eb46868e
PubSubnet
LAMPstack- vpc-3e47875b
subnet-248f5041,
LAMPstack- ip-10-0-2-200,
LAMPstack- LAMPstack- vol-
VPC- subnet-565c4110,
VPC- ip-10-0-1-14 ElasticL1VPC10XDXFCD2
ElasticL1VPC10XDXFCD2:HTTP:80
ff007efa,
PubPrivSubnet- subnet-9d9e63eas
PubPrivSubnet- vol-0f552b0e
RDS RDS-
WebServerGroup-
INVN3ZCQ2TUW2

Stack VPC Subnet Auto VM ELB ELB EBS

Name Scaling Listener Volume
Group
subnet-248f5041,
n/a ip-172-31-46-96
n/a n/a vol-
VPC- subnet-565c4110, a55a24a4
RDS
VPC- vpc-3e47875b
subnet-248f5041,
n/a n/a n/a n/a n/a
PubPrivSubnet subnet-565c4110,
subnet-9d9e63eas
VPC- vpc- subnet-729e6305
n/a n/a n/a n/a n/a
PubSubnet eb46868e
LAMPstack- vpc-3e4787bsubnet-248f5041,
LAMPstack- ip-10-0-2-21,LAMPstack- LAMPstack- vol-
VPC- ip-10-0-1-248Elastic- Elastic- c2502ec3,
PubPrivSubnet- LK5MUGT7Z7XK2
LK5MUGT7Z7XK2:HTTP:80
vol-507c0255
RDS- RDS-
RetailPortal RetailPortal-
WebServerGroup-
AYPR44QQUQ9B
LAMPstack- vpc- subnet-729e6305
n/a ip-10-0-0-254n/a n/a vol-28017f2d
VPC- eb46868e
PubPrivSubnet-
RetailPortal
POS- vpc-9e4a8afbsubnet-3c59447a,
POS- ip-10-0-2-56,POS- POS- vol-9c453b9d,
requiresVPC subnet-189a676f,
requiresVPC-ip-10-0-1-104requi- requi- vol-
subnet-928c53f7
WebServerGroup- ElasticL-1UYP73LCE5UQ6
ElasticL-1UYP73LCE5UQ6:HTTP:80
ba750bbf
ZHW2UHSZ0OS
subnet-248f5041,
LAMPstack- ip-10-01-1-139,
LAMPstack- LAMPstack- vol-3fd333e,
VPC- ip-10-0-2-188ElasticL-19C6S0C8YIBNG
ElasticL-19C6S0C8YIBNG:HTTP:80
vol-647b0562
PubPrivSubnet-
RDS- RDS-
PeopleSoft PeopleSoft-
WebServerGroup-1KN737LA7PO1T
Create a user record for AWS Cloud activities

An administrator can create specific users and assign them to designated groups.
Role required: cloud_admin
Table 468: User list
Username Group
Cloud User Virtual Provisioning Cloud Users

Cloud Admin Virtual Provisioning Cloud Administrators
Cloud Operator EC2 Operators

Username Group
EC2 Approver EC2 Approvers
1. Navigate to Users and Groups > Users.

2. Click New.
3. Enter a Username for the user. Refer to the table for all required users.
4. Click Submit.
5. Open the new user record and then click Edit in the Groups related list.
6. Select the group for the user. Refer to the table for group assignments by user.
7. Click Save.
Add the AWS account to the ServiceNow instance

Once you create an AWS account on the Amazon site, you can create an account record on the
ServiceNow instance with information about the AWS account, including the AWS credentials.
1. Navigate to Amazon AWS Cloud > Configuration > Accounts.
2. Click New.
3. Enter a unique Name for the account.
4. Enter the Account ID number.
5. Click Submit.
View AWS account details

You can view AWS account details in related lists.
Role required: cloud_admin, aws_admin
2. Select the AWS account to view.
The following details are listed:
• AWS Credentials
• Discovery Schedules
• AWS Billing Managements
• EC2 Key Pairs
• EC2 Images
• EC2 Approved Image
• Shared Image Accounts
• EC2 Virtual Machine Instances
• AWS VPCs
• AWS VPCs Security Group
• AWS Subnets
• AWS CloudFormation Stack
• AWS Elastic Load Balancers
• AWS Auto Scaling Group
• AWS Auto Scaling Group Launch Config
• AWS Elastic Block Store Volumes
• AWS Elastic Block Store Snapshots

• AWS Resources
Note: You must run Discovery to see data in a related list.
Configure AWS credentials

AWS credentials are used to connect to an Amazon Web Services account.
1. Navigate to Amazon AWS Cloud > Configuration > Accounts and select an AWS account.
2. In the AWS Credentials related list, click New and fill in the form, as appropriate.
Table 469: AWS Credentials
Field Description
Name A unique and descriptive name for this

credential. For example, Amazon Web
Service.
Active Check box to enable or disable the
credential.
AWS Account Master AWS account to which this
credential belongs.
Access Key ID Access key ID generated from the AWS
Management console.
Secret Access Key Secret access key generated from the AWS
Management console.
3. Click Submit.
External credential storage for AWS

You can store credentials used for AWS discovery and operation in an external credential repository,
instead of directly in a credentials record on your ServiceNow instance. The instance maintains a unique
identifier for each credential.
The MID Server obtains the credential identifier from the instance, and then uses a customer-provided JAR
file to resolve the identifier from the repository into a usable credential. Currently, the instance supports the
use of the CyberArk vault for external credential storage.
To start out, configure access to external credential storage for AWS and then configure AWS credentials
on a CyberArk vault.
Note: When AWS credentials are configured on an external credential storage site, AWS
billing download is not supported. To download billing data, credentials must be configured on
an instance. AWS discovery, AWS EC2 life cycle operations, CloudFormation, and resource
optimization download will work with external credential storage.
Regions
AWS regions are the geographic locations of AWS datacenters, accessed though SOAP endpoints.
After you configure an AWS account in ServiceNow, you can create EC2 instances in any of these regions.
The AWS regions are:
• Asia Pacific (Singapore) Region

• Asia Pacific (Sydney) Region

• Asia Pacific (Tokyo) Region
• EU (Ireland) Region
• South America (Sao Paulo) Region
• US-East (Northern Virginia) Region
• US-West (Northern California) Region
• US-West (Oregon) Region
Update AWS regions

The list of AWS regions is populated when you activate AWS Cloud.
Amazon provides multiple regions so that you can launch instances in locations that meet your
requirements. For example, you can launch instances in Europe to be closer to your European customers
or to meet legal requirements.
Each region is a separate geographic area and is designed to be completely isolated from the other
Amazon regions. This design achieves the greatest possible fault tolerance and stability.
1. To see the list of available regions, navigate to Amazon AWS Cloud > Administration > Regions.

Note: You must have an AWS GovCloud account to access the AWS GovCloud (US) region.
You can update the list with any new regions that Amazon might add or restore the list, as needed.
You do not need to update regions if the region in which you want to create VMs already appears in
the AWS Regions list.
To update the AWS Regions list, run Discovery for the AWS account.

2. Select the region to view.
Configure AWS federated access

To configure federated access, define AWS policies and security tokens.
Create an AWS security token
AWS security tokens allow you to provide trusted users with temporary, limited access to your AWS
resources.
1. Navigate to Amazon AWS Cloud > Reports > Security Tokens.

2. Click New.
3. Fill in the fields as described in the table.
4. Click Submit.
Table 470: AWS Security Token form fields
Field Description
Access key ID The access key ID that identifies the

temporary security credentials.
Arn Amazon resource number that is used to
identify the federated user associated with
the credentials.
Account [read-only] The account used to generate a security
token.
Expiration The date on which the current credentials
expire.
Federated user ID The user ID for the federated user
associated with the credentials.
Packed policy size A percentage of the allowed value indicating
the size of the policy in packed form.
Secret access key The secret access key that can be used to
sign requests.
Session token The token that users must pass to
the service APU to use the temporary
credentials.
Assign an AWS security token to a user

After you create an AWS security token, assign the token to a user.
1. Navigate to Amazon AWS Cloud > Reports > User Security Tokens.
2. Click New.
3. Fill in the fields as described in the table.
4. Click Submit.

Table 471: AWS Security Token form fields
Field Description
Token link close time Date and time the link to use the security token will expire.
Token link open time Date and time the link to generate the security token will
open.
Policy AWS policy associated with the token.
Purpose Description of the security token purpose.
Request item Indicates whether the token is explicitly requested by a user
or is generated by other processes.
State State of the user token link. It can be scheduled, active, or
closed.
Token AWS security token that is tied to the record.
User User to assign the security token to.
Define AWS policies

To assign permissions to an AWS account, create a policy that specifies permissions. A Super Admin
Policy is enabled by default.
1. Navigate to Amazon AWS Cloud > Administration > Policies.
2. Click New.
3. Enter a unique Name for the policy.
4. Specify the policy parameters in JSON format.

5. Click Update.
Customize an image permission

How to customize image permissions.
1. If the owner of a different AWS account has granted you permission to access images (AMIs) in their
account, configure your account to receive these images. Make sure you have the AWS account
number that has the shared images.
1. In the Shared Image Accounts related list, click New.

2. Enter a unique and descriptive name for the new shared account and provide Amazon EC2
account number of the shared account.
3. Click Submit.
4. Repeat this procedure for additional shared accounts.
2. Click the Update Images related link to populate the EC2 Images related list with images provided by
Amazon.
AWS permissions
While configuring ServiceNow to connect to Amazon, you can supply credentials for a user. The user
permissions in AWS determine which AWS tasks the user can perform in the ServiceNow instance.
The Administrator role provides all privileges available in AWS. This includes access to every operation
that ServiceNow supports plus all of the features that ServiceNow does not use. Using the Administrator
role is a simple way to grant a ServiceNow instance full power.
It is possible to define permissions for a user that provide the ServiceNow instance enough access to
perform Discovery or Cloud Management operations without granting full Administrator privileges.

Discovery operations
AutoScaling DescribeAutoScalingGroups
DescribeLaunchConfigurations
CloudFormation DescribeStacks
GetTemplate
ListStackResources
ListStacks
EC2 DescribeAccountAttributes
DescribeAvailabilityZones
DescribeImages
DescribeInstanceStatus
DescribeInstances
DescribeKeyPairs
DescribeRegions
DescribeSecurityGroups
DescribeSnapshots
DescribeSubnets
DescribeVolumes
DescribeVpcs
Elastic Load Balancing DescribeLoadBalancers
Cloud Management operations
CloudFormation CreateStack
(When using templates, include permissions for DeleteStack
the operations required within the templates for
the specific resources and services contained.) DescribeStacks
GetTemplate
ListStackResources
ListStacks
UpdateStack
ValidateTemplate
CloudWatch GetMetricStatistics
EC2 AttachVolume
CreateKeyPair
CreateSnapshot
CreateTags

Cloud Management operations
DeleteSnapshot
DeleteTags
DescribeImages
DescribeInstanceStatus
DescribeInstances
DescribeKeyPairs
DescribeSecurityGroups
DescribeSnapshots
DescribeSubnets
DescribeTags
DescribeVolumeStatus
DescribeVolumes
DescribeVpcs
DetachVolume
RebootInstances
RunInstances
StartInstances
StopInstances
TerminateInstances
S3 DeleteObject
GetObject
ListBucket
PutObject
GetBucketLocation
Elastic Load Balancing DescribeLoadBalancers
SNS ConfirmSubscription
CreateTopic
Subscribe
STS GetFederationToken
Discover and view AWS resources

After you create AWS accounts, run Discovery to discover AWS accounts and associated resources.
Discovery of Amazon Web Services cloud is based on account information rather than an IP range. MID
Servers are not used in this type of discovery.
Role required: aws_admin or cloud_admin

Amazon Web Services account credentials

In AWS, a web service account is a master account that has many subscriptions, where each subscription
is a set of login credentials. Each subscription has views into the resources available in the master account
to that subscription. To discover the entire web service account, you must have the credentials for each
subscription.
A Discovery schedule can discover one or more AWS accounts. To perform host-based discovery of the
virtual hosts contained within an AWS Virtual Private Cloud (VPC):
• A MID Server must be installed and configured on a node within the VPC.
• Each VPC that is discovered must have a separate Discovery schedule for the IP addresses in the
VPC.
Note: Running multiple scheduled jobs at one time can cause significant performance degradation.
When possible, schedule cloud discovery, billing data download, and resource optimization jobs
to run a few hours apart instead of overlapping. To view scheduled jobs, navigate to System
Definition > Scheduled Jobs.
1. Navigate to the account to discover: Either: Amazon AWS Cloud > Configuration > Accounts or
AWS Discovery > Accounts.
2. Select the account to discover and click the Create Discovery Schedule related link.
3. On the Discovery Schedule page, click the Discover now related link.
The system performs the Discovery process and lists the results in the Discovery Status list.
Discovered resources are listed on the Account page, grouped by type on separate tabs.
The current state of the resource, if applicable, is updated accordingly (for example, EC2 virtual
machine instances, AWS VPCs, AWS subnets, etc.).

Amazon Web Services Billing

The detailed billing reports of the Amazon Web Services Billing application allow you to monitor costs and
visualize your AWS spending.
Prerequisites

Role required:
• Users with the aws_admin role can configure, execute and view billing reports.
• Users with the aws_user role can only view reports.
AWS Billing offers a set of billing reports on your AWS usage based on hourly usage. You can view charts
of the data on the Cost reports page. The report details list tags associated with the resources. You can
categorize VMs by tagging the instances.
Note: To receive the reports, you must have an Amazon S3 bucket available in your AWS
account.
Configure a schedule to download AWS billing data

Scheduled jobs fetch the data that the system uses to generate Amazon S3 billing reports.
Configure AWS Cost and Usage reports on the Amazon console:
For AWS Cost and Usage Reports procedures, go to AWS Documentation and follow the procedure to turn
on detailed billing reports with these settings:
• Under Preferences, the Receive Billing Reports check box must be selected.
• The Amazon S3 bucket where you want AWS to publish your detailed billing reports must be
designated. In addition, the credential used to access this report must have permissions to this S3
bucket.
• Under Report, the Detailed billing report with resources and tags check box must be selected for
EC2 usage reports.
• If you use tags to manage reporting information, click Manage Report Tags and select the desired tags
to include in the report under Cost Allocation Tags.
The billing file generated needs to be at the root directory of the bucket defined on the report schedule in
this format:
<your-acct-num>-aws-billing-detailed-line-items-with-resources-and-tagsXXX
If this file is not available when the report is run, a NoSuchKey error may occur.
Note: If a billing report job is deleted, all associated scheduled jobs are deleted.
1. Navigate to Amazon AWS Cloud > Administration > Report Schedule.

2. Select an existing report job, or click New and fill in the fields as appropriate.
Field Description
Job Name Name of the scheduled job that will run the
report.
AWS Account Name of the AWS account to run the billing
report on.
Credential AWS account credentials.
Bucket The S3 bucket of the AWS account that
contains the data.
Scheduler [read-only] Name of the script that generates the report.
Last Execution [read-only] Completion timestamp of the most recent
run.

Field Description
Last Successful Execution [read-only] Completion timestamp of the most recent

run that has a State of success.
Last Executed State [read-only] State of the job that ran most recently.
Current Job Status Status of the currently running report. This
field appears when you click Execute Now.
3. Click Submit.
AWS asset management

Tasks for setting up a cloud product, provisioning virtual resources, and requesting virtual machines from
the service catalog depend on the user group to which you belong.
Installing the AWS plugin creates a new model and model category called EC2 Instance. The instance
creates a new asset for the model when Cloud Management fulfills a virtual machine request, and then
creates an EC2 configuration item (CI). The new asset appears in the requester virtual plugin. When the
virtual machine is terminated, asset management retires the asset.
Custom service catalog offerings: Amazon EC2

The cloud administrator builds on the basic Cloud Management configuration by providing additional
options for the virtual machines requested through the default Amazon VM service catalog item.
The cloud administrator can configure a price structure based on hardware selections that the system
uses to calculate the price of a virtual machine. At this level of customization, approvals are required and
provisioning tasks must be completed manually.
Note: Ensure that the basic configuration tasks are complete before attempting to add a price
structure to your virtual resources.
Pricing can be used to integrate Cloud Management with asset management model categories. The
catalog price is calculated by the system as multiples of a unit price. Change the price per unit for EC2
images in the price factor record. This price is used to calculate the price for each EC2 image provisioned
from a specific instance.
Configure AWS Config integration

Integrate AWS Config with a ServiceNow instance to receive near real-time Simple Notification Service
(SNS) notifications from AWS. To process AWS events, you must configure AWS Config and SNS on the
Amazon console.
Role required: aws_integration
Configure AWS Config on the Amazon console:
For AWS Config procedures, go to AWS Documentation and navigate to Management Tools > AWS
Config > Developer Guide > Getting Started > Set Up AWS Config Using the Console.
Note: AWS Config is region-specific, therefore you must create one SNS topic per region of
interest.
SNS notifications for all supported AWS resource types are processed. For supported AWS resource
types, go to AWS Documentation and navigate to Management Tools > AWS Config > Developer
Guide > What Is AWS Config > Supported Resources, Configuration Items, and Relationships.
The ServiceNow instance parses the SNS notification and updates the CMDB.

SNS notification behavior:

• If the SNS notification is changeType: CREATE, a new record is created in the CMDB for that
resource, if it is not already discovered.
• If the SNS notification is changeType: UPDATE for a particular resource, the corresponding resource
gets updated with the changes, OR if that resource is not present or is not discovered, a new record is
created to reflect the changes.
• If the SNS notification is changeType: DELETE for a particular resource, the corresponding resource is
not deleted from the CMDB, instead the state of that resource is marked Terminated.
1. Once an SNS Topic is created on the AWS console, create a new subscription for it.
a) Select the Topic ARN from the topic that you created.
The Amazon Resource Name (ARN) is necessary for binding an AWS Config SNS to the CI.
b) Set the Protocol to https.
c) Set the Endpoint to: https://<user_id>:<password>@<instance.domain>/
aws_evt_mgmt_proc.do.
Where user_id and password are the user ID and password of the user with the
aws_integration role, and instance.domain is the domain of the ServiceNow instance.
2. Wait until the subscription goes from Pending to Confirmed and the subscription ARN is populated.
3. A user with the admin role can add the applicable property for the desired feature to the
sys_properties table of the ServiceNow instance.
The AWS Config processor processes three types of messages:
• ConfigurationItemChangeNotification
• ConfigurationHistoryDeliveryCompleted: You can enable this property by setting
itom.aws.processConfigHistory to true.
• ConfigurationSnapshotDeliveryCompleted: You can enable this property by setting
itom.aws.processConfigSnapshot to true.
itom.aws.logEvent When this property is enabled, SNS
responses sent by AWS can be viewed in the
aws_sns_event table.
Default is off.
itom.aws.processConfigHistory When this property is enabled, the

ServiceNow instance processes the
AWS SNS messages sent for history:
ConfigurationHistoryDeliveryCompleted.
Default is off.
itom.aws.processConfigSnapshot When this property is enabled, the

ServiceNow instance processes the
AWS SNS messages sent for snapshot:
ConfigurationSnapshotDeliveryCompleted.
Default is off.

Getting started with Microsoft Azure Cloud

To prepare ServiceNow Cloud Management to work with Azure, you must perform several one-time
configuration tasks. The modules that support the tasks appear under Microsoft Azure Cloud >
Administration.
Before you begin to configure the ServiceNow instance to work with Azure, your organization must have a
Microsoft Azure subscription.
Microsoft Azure Cloud is available as a separate subscription for the ServiceNow platform and it
requires the Microsoft Azure Management Application plugin (com.snc.azure) that must be requested.
For information about purchasing a subscription, see your ServiceNow account manager or sales
representative.
To configure the ServiceNow instance to communicate with your Azure account, you need to:
• Have either cloud_admin or sn_azure.admin role
• Determine which Azure application/service principal to use to manage your subscription.
• Obtain values for Tenant ID, Client ID, and Key fields.
For instructions on how to create your Active Directory application, go to the Microsoft Azure website and
search for the document Create Active Directory application and service principal using portal. Make
a note of the Azure Tenant ID, Client ID, and Key for use later in the configuration.
Note: You must grant the service principal the Contributor role for each subscription that you
want to manage.
Roles
Cloud administrators are members of the Virtual Provisioning Cloud Administrators group. The Virtual
Provisioning Cloud Administrators group has or inherits these roles:
• itil
• cloud_admin
• cloud_operator
• cloud_user
Collect the Azure Client ID and Tenant ID

You must specify the Azure Client ID and Tenant ID while configuring the ServiceNow instance.
Permission required: cloud_admin, sn.azure_admin
1. Log in to the Azure portal, navigate to Active Directory, and then select the directory that you work in.
2. Click the application that you are working on and then click Configure.
Copy the following information into a text file, or paste it directly onto the Service Principal form on the
ServiceNow instance.
3. Collect the Tenant ID and the Client ID. Client ID: Scroll down and copy the Client ID value into the
text file.
4. Collect the Tenant ID: Click View Endpoints to open the App Endpoints window.
In any of the URLs, the Tenant ID is the text that is in the form of a GUID.
For example, https://login.windows.net/d85131e4-1763-42d6-b9c7-b6bad64b3a51

Declare your Azure service principal

A service principal is the automated process, application, or service that the Azure admin configured to
access the subscription that the admin specifies. Provide the credentials for your Azure service principal to
the instance so that the instance can discover the Azure subscriptions for your organization.
Role required: cloud_admin or sn_azure.admin
The Contributor role is required by the service principal in the Azure cloud.
In this procedure, you create a service principal on the Azure portal and then submit a form with the service
principal information on the instance. You then direct the instance to run the Discovery process to access
your organization's Azure resources in the subscription.
1. Create a new Azure Service Principal on the Azure portal as described in the Azure Resource
Manager documentation.
2. Navigate to Microsoft Azure Cloud > Configuration > Credentials (Service Principals).
3. Click New and then specify the following values.
Field Value
Name Enter the name of the service principal to register
with the ServiceNow instance.
Tenant ID and Client ID Copy/paste the values that you obtained from the
Azure portal.
Authentication method Select Client secret.
Note: Client assertion is not supported.
Secret key Paste the secret key that was generated while
creating the Azure Service Principal.
This field appears when Authentication method
is Client secret.

5. Grant Service Principal permission to the subscriptions that you want to manage as described in the
Azure Resource Manager documentation. Useful instructions also appear in related blogs.
6. Click the Get Subscriptions related link.
The ServiceNow instance discovers your organization's Azure subscriptions and makes them available
to you in the next procedure.
Note: This discovery process discovers only which subscriptions the Service Principal has
access to. The process does not discover other resources. You schedule resource Discovery
in a later step.
Configure Azure regions

This is an optional procedure to specify the geographical regions to which the Azure system can provision
resources for each subscription.
1. Open the Azure Subscriptions form:
• From the related list on the Service Principal form

• Navigate to Microsoft Azure Cloud > Configuration > Accounts (Subscriptions).
2. On the Azure Subscriptions form, click the subscription to configure.

3. Click the Azure Regions related link.
4. Delete the regions that users should not select for this subscription.
Configure and run Discovery for your Azure subscription

Specify the subscriptions to manage and configure the Discovery schedule for discovering resources in the
subscriptions.
You use the Subscriptions form to:
• View the list of subscriptions that the service principal can access.
• From the list, specify which subscriptions that you, the cloud_admin, want to administer.
Note: Running multiple scheduled jobs at one time can cause significant performance degradation.
When possible, schedule cloud discovery, billing data download, and resource optimization jobs to
run a few hours apart instead of overlapping.
1. Open the Azure Subscriptions form. Either:

• From the related list on the Service Principal form
• Navigate to Microsoft Azure Cloud > Configuration > Accounts (Subscriptions).
2. On the Azure Subscriptions form, click the subscription to configure.

3. Click the Create Discovery Schedule related link.
4. On the Discovery Schedule form, specify the schedule for Discovery. For example, you can schedule
Discovery to run every day at 3:00 AM for a total of 365 days.
Note: Do not modify the values in the remainder of the fields. These values are populated
automatically during discovery.
Field Value
Name Name of the Azure subscription that uses the
Discovery schedule that is defined on this page.
Discover Type of resources to discover.
MID server MID server that will manage the Discovery
process.
Active Check box to activate this schedule.
Max run time Overall time period over which the schedule
applies. For example, enter 365 days if you want
this schedule to be used for one year. Specify a
period less than a day using hh:mm:ss format.
Run The options are described in the following step.
5. Specify the Run option.
6. Click Submit.

Discovery runs and populates your CMDB (configuration management database) and images that you
can later approve to offer to cloud users in the catalog. The current state of the resource, if applicable,
is updated accordingly (for example, Azure virtual machine instances, Azure virtual networks, Azure
subnets, etc.). The Cloud admins use the Accounts (Subscriptions) module to specify which subscriptions
to manage and to configure the Discovery schedule for subscriptions.
Azure subscriptions
Cloud admins use the Accounts module to specify which subscriptions to manage, and to configure the
Discovery schedule for subscriptions.
Cloud admins use the Accounts (Subscriptions) module to:
• View the subscriptions that the service principal can access.
• Specify which subscriptions you, the cloud_admin, want to administer.
• Configure the ServiceNow Discovery schedule that maintains the database of Azure resources in the
subscription.
Configure the Azure Enterprise Agreement (EA) credentials

When your organization became an Azure Enterprise Agreement customer, Microsoft provided you with
enrollment and access information. To optionally enable your instance to integrate with the Azure billing
and reporting system, provide the EA access information on the Billing Credentials form.
1. Navigate to Discovery > Credentials.
2. Create a new Azure Enterprise Agreement Credential and specify the following values:
Table 472:
Field Value
Name Enter the name of the EA agreement that

was provided by Microsoft.
Enrollment number Enter the enrollment number that was
provided by Microsoft.
Access key Enter the Usage API Access Key that is
listed on the EA Portal under Accounts.
3. Click Submit.
Configure rules using the Azure alert API

All resource state and configuration changes on Azure can be tracked using events via the Azure alert API.
ServiceNow® receives the events and updates the resources accordingly. The cloud admin configures the
rules to tell Azure where to send the event.
Role required: cloud admin.
An Azure subscription and at least one resource group must be created.
Enter one rule per subscription and check that the rule is active by verifying that the Active checkbox is
selected.
1. Navigate to Cloud Management > Microsoft Azure Cloud > Alert Rules Configurations.
2. Choose New.
3. Set the Target Subscription.
4. Enter the Resource Group.

5. Choose a user to authenticate the request.

The user must have the sn_azure.integration role.
6. Choose Submit.
Every resource state and configuration change to the Azure subscription is now captured and processed in
ServiceNow®. Azure sends an alert to the ServiceNow instance where you have configured Azure alert.
If a new virtual machine is created in the Azure subscription directly on the Azure portal, Azure will send
an alert about this change and Cloud Management will process the event and create a new entry for the
virtual machine on the Azure portal. The benefit of this is that you do not have to wait for Discovery to run
until the new instance entry is created in the ServiceNow database.
If you want the events to be logged in the Azure alerts events table, then navigate to Microsoft Azure
Cloud > Properties and select the Yes checkbox under Log events from Azure alert. By default, it is set
to No.
Note:
Azure Alert API is a preview feature and contains the following limitations:
• There is a fifteen minute time delay in event generation.
• Basic authentication is not supported. You need to disable authentication to be able to use the
API.
Supported resources and operations for Azure Alert API

The following are supported resources and operations for the Azure Alert API:
Microsoft.Compute/virtualmachines write, deallocate, start, restart, stop, delete

Microsoft.Compute/availabilitySets write, delete
Microsoft.Network/loadBalancers write, delete
Microsoft.Network/networkInterfaces write, delete
Microsoft.Network/publicIPAddressesResource write, delete
Group
Microsoft.Network/virtualNetworks write, delete
Microsoft.Storage/storageAccounts write, delete
Resource Group Update resource group, delete resource group
Microsoft.Resources/deployments write
Disable authentication for Azure Alert API

Basic authentication is not supported for Azure Alert API. You need to disable authentication to be able to
use the API.
Role required: system administrator
1. Navigate to System Web Services > Scripted REST APIs.
2. Click Azure Alert record.
3. Click Alert on Azure Audit Logs record in the Resources related list.
4. De-select the Requires authentication check box on the Security tab.

Configuring VMware Cloud

VMware Cloud requires the Orchestration - VMware Support plugin, which is available as a separate
plugin. It uses Orchestration, which is also available as a separate subscription.
Role required: none



3. Click Submit.
Installed with VMware Cloud

Several tables, workflows, workflow activities, and MID Server probes are installed with VMware Cloud.
These components are added with VMware Cloud:
Tables
Table 473: VMware Cloud tables
Table Description
cmdb_ci_vm_instance Contains virtual machine instances.

cmdb_ci_vmware_instanceContains VMware instances.
vm_allocatable_ip Contains IP addresses available for a given network.

Table Description
vm_linux_config Contains specific information used to configure Linux virtual machines.

vm_net_config Contains network configuration information used to configure new virtual
machines.
vm_win_config Contains specific information used to configure Windows virtual
machines.
Workflow activities
The following workflow activities are installed with the Orchestration - VMware Support plugin. For
additional details about these activities, see Orchestration VMware Activities.
Table 474: VMware Cloud workflow activities
Activity Table Description
Change State global Sends commands to vCenter to control the state of a given VMware
virtual machine (powers the VM on or off).
Check VM Alive global Uses the VMware API to determine if a newly configured VM is
alive. The virtual machine is alive if its state is powered on and if it
uses the same IP address with which it was configured.
Clone global Sends commands to vCenter to clone a given VMware virtual
machine.
Configure Linux global Sends commands to vCenter to set the identity and network
information on a given VMware virtual Linux machine.
Configure Windows global Sends commands to vCenter to set the identity and network
information on a given VMware virtual Windows machine.
Workflows
Table 475: VMware Cloud workflows
Name Description
VMware - Provision Main workflow that clones, configures, and then powers on the virtual
machine. This workflow uses the VMware - Wait for VM to start subflow,
closes the task as complete or incomplete. Requesters receive an email
if the provisioning was successful, and the Virtual Provisioning Cloud
Operators group receives an email if the provisioning fails.
VMware - Wait for VM Subflow that queries the virtual machine using VMware Tools for its state
to start and IP address to determine if it has powered up after its configuration
changes.

MID Server Probes
Table 476: VMware Cloud MID Server probes
Name Purpose
VMware - Clone Clones a virtual machine or virtual machine template.

VMware - Change State Powers on or powers off a virtual machine.
VMware - Configure Linux Sets the configuration specification for Linux.
VMware - Configure Sets the configuration specification for Windows.
Windows
VMware - Get Guest Info Returns the state and IP address, used to determine if the virtual
machine is up after configuration.
Requirements for VMware Cloud

VMware Cloud requirements include proper credentials, and access to a VMware ESX Server.
• All virtual machine templates must contain VMware Tools.
• For Windows VMs, check the VMware site at kb.vmware.com to determine whether Microsoft Sysprep
is required on the vCenter instance.
• The vCenter user must have proper credentials for cloning, customization, and powering on the virtual
machine.
• On Windows 2003 templates, the password for an Administrator must be blank on the base image.
• To provision VMware virtual machines, you must have access to a VMware ESX Server with vCenter
installed. You need the IP address and administrator credentials for this server. Contact your vCenter
administrator for more information.
Configure VMware credentials

VMware credentials manage access to VMware.
1. Navigate to VMware Cloud > Configuration > Credentials.
2. Click New and fill in the form, as appropriate.
Table 477:
Field Description
Name A unique and descriptive name for this

credential. For example, VMware Atlanta.
Active Check box to enable or disable the
credential.
User name User name associated with this credential, if
any.
Password Password for the user name. This password
is not visible as you enter it and is stored in
encrypted form.

Field Description
Applies to Specifies whether this credential applies

to all MID Servers or only specified MID
Servers.
Order The order in which the credential is
attempted to be used. Smaller numbers are
attempted first.
3. Click Submit.
Prerequisites for VMware Cloud

Before configuring your instance for VMware Cloud, you must activate the plugin, install a MID Server, and
install vCenter.
Activate the Plugin
For instructions on activating the Orchestration - VMware Support plugin, which requires a separate
subscription, see Configuring VMware Cloud on page 1098. Activating this plugin also activates the
Orchestration and web service Consumer plugins if they are not already active.
Install a MID Server
Install a ServiceNow MID Server on a suitable machine in your network and configure it to communicate
with the instance. Ensure that the MID Server version is compatible with the ServiceNow instance version.
• MID Server system requirements
• MID Server installation
• Configure MID Server credentials from the credentials table
Install vCenter
Install the vCenter management application from VMware. Create the Windows and Linux templates on
your ESX Server that the system can use to create virtual machines from service catalog requests. Refer
to VMware product documentation for vCenter and the ESX Server for details about these procedures.
Configure the MID Server to access your ESX Server
Install a MID Server on the same network as the ESX Server.
1. Navigate to Orchestration > MID Server Properties.
2. Set the Default MID Server to use for Orchestration Activities to the new MID Server.
3. Navigate to MID Server > IP Ranges.
4. Click New.
5. Enter a Name for the IP range. Enter the IP Range that contains your ESX Server.
6. Click Submit.
7. Return to the list of MID Servers.
8. Select the MID Server you just installed.

9. In the IP Ranges related list, select the new IP range.
Confirm that your instance can connect to the MID Server

You must ensure that the MID Server that you installed is connected to your instance.
1. On the instance that the MID Server is connected to, navigate to MID Server > Servers. If Discovery
is installed, navigate to Discovery > MID Servers.
All MID Servers connected to the instance are listed.
2. Make sure that the Status of the MID Server that you installed is Up.
VMware Cloud configuration

Users who are members of the Virtual Provisioning Cloud Administrators group (cloud_admin role) can
configure VMware accounts in the ServiceNow instance.
vCenter and the ESX Server
vCenter is the VMware management console that manages the activities of ESX Servers. ESX Servers
contain the virtual server templates and hosts running virtual machines. Refer to VMware product
documentation for instructions about installing and configuring vCenter and ESX Servers. Observe the
following requirements when setting up the system to interact with vCenter and the ESX Server:
• Ensure that all VMware products that are advertised in the service catalog have corresponding
templates on the ESX Server. The names of the templates on the ESX Server should be descriptive
enough to simplify selection during the manual phase of provisioning.
• The MID Server probe's user must log in to vCenter with the proper VMware role to execute the probe’s
action.
• The ServiceNow instance supports Cloud Provisioning on vCenter versions 4.1 through 6.0. Using
Cloud Management with other versions of vCenter may cause unexpected results.
Selecting a role for the VMware vCenter integration

While configuring ServiceNow to connect to vCenter, you can supply credentials for a vCenter user. The
user permissions in vCenter determine which VMware tasks the user can perform in the ServiceNow
instance. Based on the role that you select, you can implement one of a variety of levels of permission.
Administrator role in VMware

The Administrator role provides all privileges available in vCenter. This includes access to every operation
that ServiceNow supports plus all of the features that ServiceNow does not use. Using the Administrator
role is a simple way to grant a ServiceNow instance full power.
Full access
It is possible define a role that provides the ServiceNow instance enough access to perform all supported
operations without granting full Administrator privileges. This role should include the following permissions:
vCenter Permissions
Datastore Allocate space

Browse datastore

vCenter Permissions
Network Assign network

Resource Assign virtual machine to resource pool
Virtual Machine Configuration Add new disk
Add or remove device
Advanced
Change CPU count
Change resource
Memory
Modify device settings
Rename
Reset guest information
Settings
Interaction Device connection
Power off
Power on
Reset
Suspend
Inventory Create from existing
Remove
Provisioning All
Snapshot management All
With this role, ServiceNow users can run Discovery, view all resources, perform all operations (Start, Stop,
Pause, Snapshot, Terminate, VM Modifications), and provision new VMs (including guest customization).
Read-only user
The "Read-only" role allows a user limited read access to the system without any other privileges. The role
allows ServiceNow users to run Discovery and view resources.
The role does not have permission to provision new VMs or to run any VM operations.
Discover vCenter resources

Several templates are available by default with Cloud Management. Discovering vCenter makes the
templates available for configuration as catalog items.
Role required: cloud_admin, vmware_operator

Several templates are available by default with Cloud Management. Discovering vCenter makes the
templates available for configuration as catalog items. To create additional virtual machine templates,
contact your vCenter administrator.
1. Navigate to VMware Cloud > vCenter and click New.
2. Enter the IP address of your vCenter instance in the URL field. The URL is filled in after discovery.
Note: The Create Discovery Schedule link is only visible when a valid IP address is entered.
3. Fill in the form, as needed.

5. Click Create Discovery Schedule and fill in the form, as needed.

Figure 185: Discover vCenter UI action
6. On the scheduled job, click Discover Now.

7. Wait for the system to discover the detailed information. If your user record has an email address, the
system sends an email notification when the discovery finishes.
Note: Running multiple scheduled jobs at one time can cause significant performance
degradation. When possible, schedule cloud discovery, billing data download, and resource

optimization jobs to run a few hours apart instead of overlapping. To view scheduled jobs,
navigate to System Definition > Scheduled Jobs.
Integration with the Asset Management module

The My Assets plugin creates a new model and model category called VMware Instance.
The system creates a new asset for this model when Cloud Management fulfills a virtual machine request,
and then creates a VMware configuration item (CI). The new asset appears in the requester My Assets
portal. When the virtual machine is terminated, asset management retires the asset.
How Cloud Management works

Cloud Management tasks are performed by users who are members of virtual provisioning groups.
The entire process from configuration to provisioning, and eventually to service catalog requests for virtual
resources, is controlled by members of the groups. This diagram shows the process flow:

All required tasks within Cloud Management are performed by members of these groups:
• Virtual Provisioning Cloud Administrator: Cloud administrators own the cloud provisioning environment
and are responsible for configuring the virtualization providers that are used by Cloud Management.
Cloud administrators can create service catalog items, approve requests for virtual machines, and
monitor the Cloud Management environment using the Cloud Admin Portal.
• Virtual Provisioning Cloud Approver: Cloud Approvers can approve or reject requests for virtual
resources. Approvers have no technical responsibilities.

• Virtual Provisioning Cloud Operator: Cloud operators fulfill provisioning requests from users. Cloud
operators perform the day-to-day work of Cloud Management by completing tasks that appear in the
Cloud Operations Portal. Cloud operators are assigned to specific Cloud Management Providers and
must be technically adept with the providers they support.
• Virtual Provisioning Cloud User: Cloud users can request virtual machines from the service and use the
My Virtual Assets portal to manage any virtual machines that are assigned to them.
Amazon Web Services (AWS) Cloud

You can communicate with and manage Amazon Web Services (AWS) using Amazon AWS Cloud.
The ServiceNow Amazon AWS Cloud application allows you to manage the following AWS products and
services:
• Amazon VMs
• Amazon Elastic Block Stores (EBS)
• Amazon Virtual Private Clouds (VPCs)
• Amazon CloudFormation
• Amazon Tagging
• Amazon Billing

Figure 186: Amazon AWS Cloud integration
Microsoft Azure Cloud

The Microsoft Azure Cloud application integrates with Azure to expose virtual machine and managed
services management to ServiceNow users. The application enables users to request Azure virtual
resources through the service catalog and provides flexible reporting for Azure admins.
The Microsoft Azure Cloud application provides the following fundamental services:
• Life-cycle management for individual VMs
• Life-cycle management for resource groups
• Cost and Usage reports of Azure data using ServiceNow report modules

Figure 187: Common operations on Azure
VMware Cloud
The VMware Cloud application integrates with VMware vCenter to expose virtual machine and
infrastructure management to ServiceNow users. The application enables users to request VMware virtual
resources through the service catalog and provides flexible reporting for VMware admins.
Orchestration integrates with the vCenter API and adds VMware workflow activities to the existing
Workflow application. The activities enable Orchestration to clone new VMs from templates, configure
VMs, and power VMs on and off.
VMware modules appear in the ServiceNow navigator under VMware Cloud and Administration >
VMware Cloud. When a user requests a virtual server, Orchestration executes preconfigured approval and
provisioning tasks. If the request is approved, Orchestration automatically creates a virtual server from a
stored template, configures the virtual machine, and then starts the server.

VMware Cloud is a feature of Orchestration and is available as a separate subscription from the rest of
the ServiceNow platform. For information on purchasing a subscription, see Configuring VMware Cloud on
page 1098.
Cloud administrator actions

Cloud administrators have two primary responsibilities: Configure the Cloud Management service and
monitor and manage the services.
Cloud administrators are members of the Virtual Provisioning Cloud Administrators group. Perform the
following tasks to prepare the Cloud Management service:
• Install and configure the Cloud Management application for the provider (for example, AWS, Azure, or
VMware)
• Set properties for Cloud Management
• Run Discovery on the cloud resources and define Discovery schedule for recurring Discovery job.
• Obtain templates and approve some templates to be used to create catalog items
• Define catalog items for both VMs and more complex offerings
• Configure default lease settings
• Set pricing for the catalog items
• Define and activate provisioning rules
• Define and activate tagging rules
• Define change control parameters for cloud resources
• Customize the user experience: Provisioning rules and UI policies
• Define the schedule for downloading billing data
Typical day-to-day tasks of a cloud administrator:

• Approve change requests associated with modifications to cloud resource
• View pending approvals for cloud resources
• View and analyze summary data on cloud resource deployments
• Monitor requests and key metrics for cloud resources
The Virtual Provisioning Cloud Administrators group has or inherits these roles:
• itil
• cloud_admin
• cloud_operator
• cloud_user
Cloud Operations portal

Cloud administrators and operators (cloud_admin, cloud_operator role) can access the Cloud Operations
portal to view a role-based graphical view of all cloud resources. Cloud admins and operators can perform
life-cycle operations on the resources using the list view.
Navigate to Cloud Management > Cloud Operations Portal. The following tabs appear:

Overview Graphical reports on VMs, Volumes, and Stacks

along with an Underutilized Resources report
and Lease Expiration report. Interactive filters for
Location, Account, and Provider are available,
and the reports on the page have built-in filters
for Assigned to, Assignment group, and state
(not empty, Terminated, or Cancelled).
Resources Displays an overview of all cloud resources, with

each resource type displaying an up-to-date total
that links to more detailed list view.
Requests Lists of request items (not filtered by user) and a
list of change requests.
Missing Tags Reports on the resources missing tag value

assignments.
Note:
If you are upgrading from Helsinki:
If you are activating Cloud plugins for the first time after upgrading from Helsinki, then you may
see a completely blank page on both the Cloud Operations portal as well as the Cloud Resources
portal. To resolve this, please contact ServiceNow Technical Support and request that the
glide.cms.enable.responsive_grid_layout system property be enabled. This step is not
necessary if you already had Cloud plugins activated before moving to the Istanbul release.
AWS Cloud administrator actions

The primary responsibilities of a cloud administrator are to configure the Cloud Management service, and
to monitor and manage the services.
Approve images for AWS catalog items

After you establish the Amazon account and configure Amazon Web Services on the instance, retrieve
the list of available images to approve for use as templates for service catalog offerings. You can use only
approved images to create catalog offerings.
There are two types of catalog items:
• Image-specific: A catalog item must be created from a chosen approved image for it to be available to
users.
• Generic: The offering is associated with the generic out-of-box catalog item.
This procedure is for image-specific catalog items.

1. Navigate to Amazon AWS Cloud > Available Images.
2. Select an image from the list and review its configuration.
3. Click Approve. The image is not yet available to users and must be configured as a service catalog
offering by the cloud administrator.
The image is approved and you can use it to create AWS catalog items.

To customize the automated naming scheme used for VMs created from this image, seeCreate a custom
VM naming script on page 1255
Set up an AWS catalog offering

The administrator must link the approved images to the offerings offered to users in the service catalog.
Important: Ensure that users are assigned to the following groups before offering Amazon VMs in
the service catalog.
• EC2 Approvers: Approve or reject all instances requested through the service catalog for provisioning.
• EC2 Operators: Select the Amazon EC2 account, region, and image to fulfill approved requests from
1. Navigate to Amazon AWS Cloud > Sizes and click New.

2. Enter a descriptive Name that conveys the size of the image, and enter the value of the corresponding
Amazon EC2 size in the API field. For example, a High-Memory Double Extra Large virtual machine
uses an API value of m2.2xlarge. See the EC2 catalog items for a list of Amazon EC2 size values.
3. Click Submit.
4. Navigate to Amazon AWS Cloud > Offerings and click New.
5. In the Offering field of the Offering form, enter the offering label. This is the name that is presented to
users requesting a VM from the service catalog.
6. Click Submit.
7. Create a separate offering record for each offering type offered.
8. Click an offering record to add an approved image mapping.
9. In the Approved Images related list, click New to add an approved image offering mapping. An
approved image can be associated to more than one offering.
10. Select an approved image from the list.
11. Optional: Check the Default check box to automatically choose this offering image for this account,
region, and offering.
There can only be one unique offering mapping for a given account, region, and offering. The first
unique offering created is marked as default. If a new unique offering is subsequently marked as
default, the previous default offering is overridden.
12. Click Submit.
Amazon images for creating catalog items

An administrator can create catalog items for virtual servers from Amazon EC2 images and present the
items to users in the service catalog.
These catalog items minimize requester involvement by simplifying the process of selecting the appropriate
virtual server. An administrator can create virtual machines with different specifications that are built from
the same image and presented to users in the service catalog by size (or EC2 type).
The following tables are used for this feature.
Table 478: Catalog items tables
Table Description
Virtual Machine Template Contains virtual machine templates from

[cmdb_ci_vm_template] Amazon EC2 and VMware.

Table Description
EC2 Approved Image [ec2_approved_images] Contains only the EC2 images approved for
provisioning through the service catalog. This
table extends the Virtual Machine Template
[cmdb_ci_vm_template] table.
EC2 Image [ec2_image] Contains all the EC2 images in the system,
including approved images. This table
extends the Virtual Machine Template
EC2 Size [ec2_size] Contains all the EC2 size (type) definitions. This
table extends VM Size Definition [vm_size] table.
Create an Amazon catalog item

Amazon images that are approved for provisioning from the service catalog are contained in the EC2
Approved Image [ec2_approved_images] table.
To view catalog items, navigate to Amazon AWS Cloud > Maintain Catalog Items.
To create a service catalog item from an approved image:
1. Navigate to Amazon AWS Cloud > Approved Images.
2. Select the image to use as the basis for a catalog item.
3. Under Related Links, click Create Catalog Item.
The VM Catalog Item form opens with the following fields pre-populated.
Table 479: VM catalog item form
Field Description
Name EC2 Instance - <size> - approved image name.

Short description By default, this value is the same as the name.
Description Description of the specified size.
Price The price of the size selected. In the base system, this value
is calculated from the hourly cost of each size in the most
expensive, allowed region, multiplied by a default lease
duration of 60 days. If you change the default lease duration
time, you must recalculate the price manually. These price
estimates might be higher than corresponding prices offered
for EC2 virtual machines in your service catalog.
VM template The approved image from which this catalog item was
created.
VM size The smallest ordered size for the image from which this
catalog item was created.
4. Complete the form as described in Defining Catalog Items.

5. Select the virtual machine size in the VM size field.
By default, the price is determined by the selection in the VM size field. If the size changes, or the
price of the size changes, the system recalculates the price automatically.

6. To override the price calculation manually, clear the Calculate check box and enter a new price for
this item.
7. Clear the Skip approval check box to require an approval for this item from a user in the EC2
Approvers group.
By default the system skips the approval process. Skipping this approval does not affect other
approvals that may apply to requests through the service catalog.
8. Select the appropriate Task automation mode:
Table 480: Task automation mode
Mode Description
Fully automatic [Default] This selection enables automatic

provisioning. No catalog task is assigned to
cloud_operators.
Manual A catalog task for specifying provisioning
information is assigned to cloud_operators
with no automatic selections. The
cloud_operator user can review the settings
before closing the task.


9. Click Update.
Example cloud configurations

Cloud administration tasks are divided into one of three configurations.
Basic service catalog offerings Use ServiceNow presets to test cloud provisioning
in your environment and to determine how you want
to customize service catalog offerings.
Custom service catalog offerings Build on the basic configuration by adding features
to the provisioning workflow. Give users more
choices and apply prices to your catalog items.
Advanced service catalog offerings Customize your catalog offerings, allowing users
to request special configurations or allowing
provisioners to skip approvals and automate
provisioning tasks.
Configure Amazon basic service catalog offerings
Link offerings associated with Amazon EC2 images to the default Amazon EC2 Instance item in the service
catalog.
Users requesting virtual machines from this source can specify the offering, the number of virtual machines
to create, and the size (provided by Amazon). Perform the following steps in the order listed.
1. Link the approved EC2 images to the service catalog offerings (operating systems).
2. Open the service catalog and click the Amazon VM link under Virtual Resources to request a virtual
machine.
3. Specify your parameters.
• Offering: The operating system you want.
• Number of instances: The number of instances to provision.
• Size: The predefined EC2 size.
When you order the virtual machine from the basic configuration, the system creates manual approvals
and provisioning tasks.
Configure Amazon advanced service catalog offerings
The cloud administrator builds on the basic catalog offerings configuration and the custom catalog offerings
configuration to provide advanced customization to the service catalog, and to the offerings.
The cloud administrator creates the catalog items and configures them for approval and task automation.
Ensure that the basic and custom catalog offerings configurations are complete before attempting to add
customizations.
1. Create catalog items from approved EC2 images.
These are the images that are available to users in the service catalog.
2. Edit the lease duration and grace period.
The default length of a lease in the base system is 60 days. The maximum lease duration permitted is
90 days.
3. Edit the checkout redirect property.
This property redirects users either to the Order Status form or the My Virtual Assets portal after they
check out.
4. Configure the system to create change requests for specific modifications requested for EC2 virtual
machines.

Examples of modifications that generate change requests are lease extensions, requests for additional
memory, and requests to terminate a virtual machine.
Configure the categories in the service catalog

Before you create a catalog item from an EC2 image, configure the categories in the service catalog,
determine the appropriate setting for the check-out redirect property, and define the virtual machine sizes.
Categories
See Service Catalog Categories for instructions on creating categories and sub-categories for catalog
items. The category hierarchy determines the category path for locating EC2 virtual machines in the
service catalog.
Checkout redirect property
The One-step checkout redirect property (glide.vm.checkout_redirect) controls the view presented
to virtual machine requesters in the service catalog. By default, this property is set to false, which redirects
the view to the Order Status form when the requester clicks Order Now. When this property is set to
true, the system redirects the requester to the My Virtual Assets portal. This property is located in Cloud
Management > Administration > Properties.
Size definitions
The system includes a full range of current Amazon EC2 sizes. The prices shown for these sizes are
arbitrary and do not reflect any realistic price structure. These prices are calculated from the price per unit
defined in the EC2 Element Price record.
Some examples of the EC2 sizes are:
• M3 Double Extra Large
• M2 High-Memory Extra Large
• M2 High-Memory Double Extra Large
• M2 High-Memory Quadruple Extra Large
• C1 High-CPU Medium
• C1 High-CPU Extra Large
Add new sizes manually

When Amazon provides a new size, you must manually add the size to the catalog.
1. Navigate to Amazon AWS Cloud > Sizes.
2. Click New.
3. Provide the required information.
Table 481: Sizes table
Title Description
Name Friendly name that has some indication of

the actual size of the virtual machine.

Title Description
API name Official Amazon EC2 name for the size.
4. Click Submit.
Change the price of an existing Amazon size

When you change the price of an existing Amazon size, the system immediately calculates the new price in
the size record.
1. Navigate to Amazon AWS Cloud > Sizes.
2. Customize the list to show the Price factor column.
Price factor is an arbitrary value that the system multiplies by the unit price from the Price factor record
to determine the price of each image size.
3. Update the Price factor value for the image size.
Price Amazon catalog items

The base system contains the Price factor record that defines the unit price that is applied to all VMs
provisioned from this instance.
The price in the Price factor record is an arbitrary value and might not reflect the price structure in your
organization. To change the price structure for the service catalog offerings, edit the existing record.
Caution: Do not delete the Price factor record. This action sets all EC2 image prices to zero.
1. Navigate to Amazon AWS Cloud > Prices.

2. Open the Price factor record.
3. Change the value in the Service catalog price field.

This is the amount charged to the user per unit as defined in the size record. A good practice is to
modify the price per unit rather than changing the value in the Elements per unit price field.
4. Click Update.

Field dependencies for image sizes

Values in the pre-populated fields of the VM Catalog Item form such as name, short description, price, and
description are based on the size of the image you select.
If you change the image size, but no other values, the pre-populated data adjusts according to the
parameters of the new size. However, if you change a value in a pre-populated field before changing
the size, the field value you changed is not updated when the size changes. This behavior allows you to
change the price, name, or description of specific sized images.
Example
The default name of a service catalog item is EC2 Instance - T1 Micro - ami-vpc-nat-1.0.0-beta.i386-ebs.
You change the size to M1 Medium without modifying the Name field. The system changes the name to
EC2 Instance - M1 Medium - ami-vpc-nat-1.0.0-beta.i386-ebs. If you edit the Name field before changing
the size, the item name is not changed.
Each of the four pre-populated fields behaves the same and is independent of the others. For example, if
you change the name of the item but not the short description before selecting a new size, the name value
is unaffected, but the short description adjusts to match the requirements of the new size.
AWS Virtual Private Clouds (VPCs)

A Virtual Private Cloud (VPC) is a logically isolated section of the Amazon Web Services (AWS) cloud in
which you can launch AWS resources such as VMs within a virtual network.
Each VPC is dedicated to an AWS account and region. Each VPC also specifies a set of IP addresses to
be used for a subnet associated with the VPC.
VPCs enable you to build a virtual network in the AWS cloud. VPNs, hardware, or physical datacenters are
not required. You can define your own network space and control how your network, and the Amazon EC2
resources inside your network, are exposed to the Internet.
When requesting (provisioning) an instance, you can select the VPC and subnet that the EC2 belongs to.
View the details of a VPC
You can view the details and state of a VPC.
Role required: ec2_operator, cloud_operator, aws_admin, cloud_admin, or admin

2. Select the desired AWS account.
3. In the AWS VPCs related list, select a VPC.
View the details of a VPC subnet

You can view the details and state of a VPC subnet.

3. In the AWS Subnets related list, select a subnet.
View the details for a VPC security group

To view a list of the VPC security groups, you must first provision a VM.
A security group acts as a virtual firewall for an instance to control inbound and outbound traffic.

When you launch a VM in a VPC, up to five security groups can be assigned to the instance. Security
groups act at the instance level, not the subnet level. Each instance in a subnet in your VPC, therefore,
could be assigned to a different set of security groups. When provisioned, an instance is automatically
assigned to the default security group for the VPC.
Each security group has a set of rules that control the inbound traffic to instances, and a separate set of
rules that control the outbound traffic.
Note: Amazon EC2-Classic is not supported.

3. In the AWS VPC Security Group related list, select a security group.
Table 482: VPC security group details
Field Description
Name Name tag of the VPC security group.

Group ID ID number of the VPC security group.
Group name Name of the VPC security group.
VPC Name of the AWS VPC.
Description Short description of the security group.
Amazon Elastic Block Store (EBS)

Amazon Elastic Block Store (Amazon EBS) provides persistent block level storage volumes for use with
VMs in the Amazon Web Service (AWS) Cloud.
Each AWS EBS volume is automatically replicated within its Availability Zone to protect you from
component failure, offering high availability and durability. You can run discovery on both your EBS
volumes and EBS snapshots. AWS Elastic Block Store requires the Amazon Web Services plugin.
Discover an EBS volume
You can run discovery on both your EBS volumes and EBS snapshots.
An Amazon EBS volume is a durable, block-level storage device that you can attach to a single VM. You
can use Amazon EBS volumes as primary storage for data that requires frequent updates, such as the
system drive for an instance or storage for a database application.
Amazon EBS volumes persist independently from the running life of a VM. After a volume is attached to
an instance, you can use it like any other physical hard drive. Amazon EBS provides the following volume
types: General Purpose (SSD), Provisioned IOPS (SSD), and Magnetic.
1. Navigate to Amazon AWS Cloud > Administration > Accounts.
2. Click an account.
3. Click Update Volumes.
A message indicates that volumes are being updated.
View an EBS volume

You can view an EBS volume to update.
1. Navigate to Amazon AWS Cloud > Managed Resources > EBS Volumes.

2. Click a volume.
Discover an EBS snapshot

You can run Discovery on both your EBS volumes and EBS snapshots. Discovery can be full or targeted.
Snapshot ID or Volume ID should be provided to do targeted discovery.
Amazon EBS provides the ability to create snapshots (backups) of any Amazon EC2 volume and write a
copy of the data in the volume to Amazon S3, where it is stored redundantly in multiple Availability Zones.
The volume does not need be attached to a running instance to take a snapshot. As you continue to
write data to a volume, you can periodically create a snapshot of the volume to use as a baseline for new
volumes. These snapshots can be used to create multiple new Amazon EBS volumes, expand the size of
a volume, or move volumes across Availability Zones. Snapshots of encrypted Amazon EBS volumes are
automatically encrypted.
A new volume created from a snapshot is an exact copy of the original volume at the time the snapshot
was taken. Amazon EBS volumes that are restored from encrypted snapshots are automatically
encrypted. By optionally specifying a different volume size or a different Availability Zone, you can use this
functionality to increase the size of an existing volume or to create duplicate volumes in new Availability
Zones. You can share snapshots with specific AWS accounts or make snapshots public. When you create
snapshots, you incur charges in Amazon S3 based on the volume's total size. For a successive snapshot
of the volume, you are charged only for additional data beyond the volume's original size.
1. Navigate to Amazon AWS Cloud > Administration > Accounts.
2. Click an account.
3. Click Update Snapshots.
A message indicates that snapshots are being updated.
View an EBS snapshot

You can view an EBS snapshot to update.
1. Navigate to Amazon AWS Cloud > Managed Resources > Snapshots.

2. Click a snapshot.
CloudFormation
Amazon Web Services (AWS) CloudFormation enables developers and systems administrators to create
and manage a collection of related AWS resources, and provision and update them in an orderly and
predictable fashion.
AWS CloudFormation enables you to use a template file to create and delete a collection of resources
together as a single unit called a stack. With CloudFormation, you no longer need to figure out the order for
provisioning AWS services or the details of making those dependencies work. After the AWS resources are
deployed, you can modify and update them in a controlled and predictable way. This allows you to apply
version control to your AWS infrastructure the same way you do with your software.
To provision an AWS CloudFormation stack, admins perform the following tasks:
• Configure an AWS Account
• Define a CloudFormation template
• Create a Catalog Item for the template
Users can then request AWS CloudFormation stacks.

Activating AWS CloudFormation

AWS CloudFormation requires you to activate the Amazon Web Services plugin.
Create a CloudFormation template
You can define a template that describes the AWS resources, and any associated dependencies or
runtime parameters required to run your application
Role required: cloud_admin or admin
1. Navigate to Amazon AWS Cloud > CloudFormation > Templates.
2. Click New.
3. Enter a Name and Description for the template.
4. CloudFormation template parameters enable you to pass values into the template at stack-creation
time. Parameters let you create templates that can be customized for each stack deployment. To use
a JSON template that contains parameters to include in the template, click Use JSON and then enter
the template code in the text box.
5. Optional. Enter the URL of an existing template in the Amazon S3 Template URL text box. The URL
should point to an S3 bucket containing a CloudFormation template in JSON format.
6. Click Submit.
CloudFormation templates
You can create CloudFormation templates or use an existing Amazon template to describe the AWS
resources and any associated dependencies or runtime parameters required to run your application.
You can add a template that you define as a catalog item in the Service Catalog. The system can then use
the template to create and launch stacks.
In addition, you can configure CloudFormation template parameters that enable you to pass values into the
template at stack-creation time.
Configure parameters for a CloudFormation template
Parameters let you create templates that can be customized for each stack deployment. When creating a
stack from a template that contains parameters, you can specify values for the parameters.
If you specified a JSON template that contains parameters, the template parameters appear on the
CloudFormation Template Parameters tab and the variable set appears in the CloudFormation
Variable Set for Template Parameter tab.
The following example shows the KeyPairName and InstanceType parameters:
"Parameters" : {
"KeyPairName": {
"Description" : "Name of an existing Amazon EC2 key pair for RDP
access",
"Type": "String",
},
"InstanceType": {
"Description" : "Amazon EC2 instance type",
"Type": "String",
}
}
Each parameter name must be alphanumeric and unique among the parameters in the template. You
can declare a parameter as any of the following data types:
Note: An error message appears if you attempt to submit a template with an invalid parameter
type.

Option Description
Data Type Description

String String of numbers or letters.
Number An integer. If you use the parameter elsewhere in
the template, then the parameter value becomes
a string.
List<Number> An array of integers that are separated by
commas. If you use the parameter elsewhere in
the template, the parameter values becomes a
list of strings.
CommaDelimitedList An array of strings that are separated by
commas.
AWS::EC2::KeyPair::KeyName (AWS-specific An Amazon EC2 key pair name.
data type)
AWS::EC2::SecurityGroup::Id (AWS-specific A security group ID number.
data type)
AWS::EC2::Subnet::Id (AWS-specific data A subnet ID number.
type)
AWS::EC2::VPC::Id(AWS-specific data type) A VPC ID number.
List<AWS::EC2::VPC::Id> (AWS-specific data An array of VPC ID numbers.
type)
List<AWS::EC2::SecurityGroup::Id> (AWS- An array of security group ID numbers.
specific data type)
List<AWS::EC2::Subnet::Id> (AWS-specific An array of subnet ID numbers.
data type)
Configure the NoEcho parameter

A parameter value with NoEcho set to true is masked from the requester and is not visible while ordering
the catalog item. If the NoEcho parameter is set to false or is removed from the template, then the actual
plain text value of the parameter is shown.
If the parameter has NoEcho set to true and a change is requested, then the change definition form has an
empty parameter field to signify that the previous value is masked and the actual value cannot be verified.
If it is set to false, the text value of the parameter is shown in the change definition form.
Note: While a CloudFormation stack is performing an update request, the NoEcho field for a
parameter can only be modified through the template definition.
Define the NoEcho parameter by setting NoEcho to true in a stack template parameter definition..

Catalog items based on CloudFormation templates

An administrator can create catalog items for CloudFormation stacks and present the items to users in the
service catalog. Catalog items that are based on templates minimize requester involvement by simplifying
the process of selecting the appropriate CloudFormation stack configuration. An administrator can create
multiple stack specifications in the service catalog.
Table 483: Tables used to manage catalog items from CloudFormation templates
Table Description
Virtual Machine Template Contains virtual machine templates from
[cmdb_ci_vm_template] Amazon EC2 and VMware.

EC2 Approved Image [ec2_approved_images] Contains only the EC2 images approved for
provisioning through the service catalog. This
table extends the Virtual Machine Template
EC2 Image [ec2_image] Contains all the EC2 images in the system,
including approved images. This table
extends the Virtual Machine Template
EC2 Size [ec2_size] Contains all the EC2 size (type) definitions. This
table extends VM Size Definition [vm_size] table.
Perform the following operations to prepare to create a catalog item from a CloudFormation template:
• Configure the categories and sub-categories for catalog items. The category hierarchy determines the
category path for locating CloudFormation templates in the service catalog.
• Determine the appropriate setting for the One-step checkout redirect
(glide.vm.checkout_redirect) property.
• Configure the CloudFormation templates for catalog items.
Create a catalog item from a CloudFormation template

You can create a CloudFormation stack as a service catalog item based on a CloudFormation template
that you approved for provisioning.
CloudFormation stacks that are approved for provisioning from the service catalog are contained in the
CMDB CloudFormation [cmdb_ci_cloudformation_template] table.
1. Navigate to Amazon AWS Cloud > CloudFormation > Templates.
2. Select the template to use as a catalog item.
Note: Values in the pre-populated fields are based on the CloudFormation template that you
select. If you change the template, but no other values, the pre-populated data updates to
the parameters on the new template. However, if you change a value in a pre-populated field
before changing the template, the field value you changed is not updated when the template
changes. This behavior allows you to change the price, name, or description of stacks.
3. Click the Create Catalog Item related link.

The CoudFormation Catalog Item form opens with the following fields pre-populated:
Note: To view current catalog items that were created based on the current template, click the
View Catalog Items related link.
Table 484: Fields on the CoudFormation Catalog Item form
Name CloudFormation stack name.

Category The catalog item category for the request.
Workflow The workflow used to complete the request.
Short description By default, this value is the same as the
name.
Description A description of the template.

Price The price of the selected stack.

VM template The approved template from which this
catalog item was created.
4. Complete the form as described in Create or edit a catalog item.

By default, the price is determined by the selected template. If the template changes, the system
recalculates the item's price automatically.
this item.
6. Clear the Skip approval check box to require an approval for this item from the CloudFormation
Approvers group.
By default, the catalog item skips the approval. When you skip approvals, other approvals that apply to
requests through the service catalog are still required.
7. Select the appropriate Provisioning mode:
Option Action
Automatic [Default] Automatic provisioning: No catalog task

is assigned to the CloudFormation Operators
group.
Manual A catalog task for specifying provisioning
information is assigned to the Cloud Operators
group with no automatic selections. The cloud
operator can review the settings before closing
the task.
8. Click Update.
Create catalog item variables based on a CloudFormation template

After you have fully defined all parameters in a template, you can use the parameter settings to generate
the variables that appear in catalog items for requesters of virtual resources. If the variable already exists,
you can use this procedure to refresh the variable with the updated settings.
The ServiceNow instance adds the following variable sets to each catalog item:
• Terms and conditions
• VM Provisioning variables (includes Assignment group, Business purpose, Lease start/end, and CMDB
relationship tags, Application and Business service)
• Cloud auto-tagging variables (includes Cost Center and Project by default)
The template contributes the Template Parameters set (unique for each template; variables that were
generated from the template parameters)
1. Navigate to Amazon AWS Cloud > Maintain Catalog Items > CloudFormation Items and select the
template.
2. Click the Refresh Variables from Parameters related link.
If the variables do not exist, the system generates them. If the variables already exist, the system refreshes
them with the updated attribute settings.
Verify the path to a CloudFormation catalog item
After you create a catalog item and category path, verify the configuration in the Service Catalog.


1. Open the Cloud Resource Catalog to follow the category path that you created to the CloudFormation
catalog item.
The top level category might look like this:
2. Click the stack and provide the requested information.

See Configure the lease duration for a CloudFormation catalog item on page 1130 for information
on configuring the properties that control the lease start and end date defaults. Enter the name of a
business service or application that depends on the stack.


3. Click Update.
View catalog items created from CloudFormation templates

CloudFormation stacks that are approved for provisioning from the service catalog are contained in the
CMDB CloudFormation [cmdb_ci_cloudformation_template] table.
Navigate to Amazon AWS Cloud > Maintain Catalog Items > CloudFormation Items.
Configure the lease duration for a CloudFormation catalog item

The default setting for a lease period and the maximum allowed duration of a virtual server lease are
controlled by property settings. The system applies the specified values to both Amazon and VMware
resources.
Note: These are the instructions for configuring the default settings for requested items. For
instructions on configuring lease start and end times for individual virtual machines, see Configure
the lease duration for a CloudFormation catalog item on page 1130.
Navigate to Cloud Management > Administration > Properties.

Default lease duration Action
Group by the type of change from the This property (glide.vm.lease_duration) controls
baseline. the length of the lease period that is configured
for all Amazon resource requests. The default
duration is 60 days from the lease start time,
which begins on the current date and time of the
request. The actual time of the lease is calculated
from the time the resource is provisioned, after
any approvals.
Max lease duration This property (glide.vm.max_lease_duration)
controls the maximum length of the lease period
permitted for a resource. The default maximum
duration is 90 days from the lease start time.
This property prevents resources that have been
ignored from running indefinitely.
Discover a CloudFormation stack

You can discover and store any of the CloudFormation stacks that belong to an AWS account, including
stacks that were deleted in the last 90 days.
Role required: cloudformation_operator, cloud_operator, cloud_admin, aws_admin, or admin. Users with
the cloud_admin or cloudformation_operator role can view the stack data.
Along with the stack information, the following data points are discovered for each stack and stored on the
ServiceNow instance:
Table 485: Discovered data
Field Description
Resources The resources belonging to the stack and their

current state, ID, and other information.

Field Description
Template The JSON version of the template the stack was

provisioned with. If the stack was provisioned
using a template URL, the JSON snapshot
of the template used to provision the stack is
displayed. This template is used when stack is
updated.
Parameters The parameters and values that are used to
provision the stack. The output values that are
described by the template to provision the stack.
Tags Displays any billing tags that are associated with
the stack.
1. Navigate to Amazon AWS Cloud > Administration > Account and select an account.
2. Click the Create Discovery Schedule related link to open the Discovery Schedule page.
3. Click the Discover Now related link to start the .
When Discovery finishes, the Account page lists all discovered Amazon resources. You can also click
Amazon AWS Cloud > CloudFormation > Stacks to display the resources.
Checkout redirect property for CloudFormation

A property called One-step checkout redirect (glide.vm.checkout_redirect) controls the service
catalog view presented to CloudFormation stack requesters.
By default, the property is set to false, which redirects the view to the Order Status form when the
requester clicks Order Now. When the property is set to true, the system redirects the requester to the My
Virtual Assets portal.
The property is located in Cloud Management > Administration > Properties.
ReferenceType metadata for parameters in AWS CloudFormation templates
Cloud administrators can define ServiceNow (SNC) metadata using AWS CloudFormation templates.
Each parameter with ReferenceType metadata references a ServiceNow Resource Type table entry.
On the catalog ordering page, the variable type for these parameters becomes a Reference. This feature
makes AWS stack catalog ordering less error-prone.
This allows the template author to tie together parameters within an existing ServiceNow table. For
example, if you are using Region as one of the parameters in your CloudFormation templates and you
want to tie the Region field of your template to an existing AWS region table, you can achieve this using
ReferenceType metadata.
The following is an example to define ReferenceType metadata for the parameter KeyName in an AWS
CloudFormation template.
"Parameters": {
"KeyName": {
"Description": "Describe key name",
"Type": "AWS::EC2::KeyPair::KeyName",
"ConstraintDescription": "must be the name of an existing EC2
KeyPair.",
"MinLength": 8,
"MaxLength": 35,
"AllowedPattern": "[0-9a-zA-Z]+"}
},
"Metadata": {
"AWS::CloudFormation::Designer": {
"3088fe53-c967-4b4b-8d0d-fcdfb5ea7a23": {

"size": {
"width": 60,
"height": 60 },
"SNC::Parameter::Metadata": {
"KeyName":{
"ReferenceType":"AWS::EC2::KeyPair::KeyName"
}
}
}
}
To define a password parameter, use the NoEcho parameter. In this example, if the user sets the NoEcho
parameter to true, the ReferenceType is ignored and the corresponding catalog variable has the
Reenter text box on the catalog order page.
When the admin creates ReferenceType metadata, the following table is created to associate a
reference for the given type.
Table 486: Template Parameter Type
Name Description
Name Matches the ReferenceType in the template

metadata. Example: user name.
Resource Type Reference to cloud resource type table pointing
to appropriate resource type record. Example:
region.
Table Field Populated based on template parameter in the
resource type table. Example: size.
Resource Table Populates the name of the table derived from
the Resource Type field. The cloud user does
not see this field: if the specified Resource Type
does not exist in the cloud resource type, then
the cloud user must explicitly fill in this field on
the order form. Example: user name, region,
size.
Azure Cloud administrator actions

Approve images, set up Azure catalog offerings, and define Azure resource group catalog items.
Approve images for Azure catalog items

After you establish the Azure account and configure it on the instance, retrieve the list of available images
to approve for use as templates for service catalog offerings. You can use only approved images to create
catalog offerings.
Role required: sn_azure.admin, cloud_admin
1. Navigate to Microsoft Azure Cloud > Available Images.
2. Select an image from the list and review its configuration.
3. Click Approve.

After approval, you can either create a catalog item from this image, or you can add this image to any
catalog offerings and then select it from the Azure VM Instance -- Advanced catalog item.
Set up an Azure catalog offering

The administrator must link the approved images to the operating systems offered to users in the service
catalog.
Role required: cloud_admin, sn_azure.admin
Important: Ensure that users are assigned to the following groups before offering Azure VMs in
• Azure Approvers: approve or reject all instances requested through the service catalog for provisioning.
• Azure Operators: select the Azure account, region, and image to fulfill approved requests from the
service catalog.
1. Navigate to Microsoft Azure Cloud > Sizes and click New.

2. Enter a descriptive Name that conveys the size of the image, and enter the value of the corresponding
Azure size in the API field. For example, a virtual machine with 32 cores and 448GB memory uses an
API value of Standard_G5. See the Azure catalog items for a list of Azure size values.
3. Enter a Description for the VM size.
4. Select a currency and Price for the VM size.
5. Check the Active check box to activate the size.
6. Check the Obsolete check box if the size is obsolete.
7. (Optional) Enter the CPUs label.
8. (Optional) Enter the Data disk size label.
9. (Optional) Enter the Max Data Disks.
10. (Optional) Enter the Memory label.
11. Click Submit.
12. Navigate to Microsoft Azure Cloud > Offerings and click New.
13. In the Offering field of the Azure Catalog Offering form, enter the operating system. This is the name
that is presented to users requesting a VM from the service catalog.
14. Click Submit.
15. Repeat Steps 13 and 14 to create a separate offering record for each operating system offered.
16. For each offering created, click the offering record to add an approved image mapping.
17. In the Approved Images list, click New to add an approved image offering mapping. An approved
image can be associated to more than one offering.
18. Select an approved image from the list.
19. Optional: Check the Default check box to automatically choose this offering image for this account,
region, and offering.
There can only be one unique offering mapping for a given account, region, and offering. If a new
unique offering is subsequently marked as default, the previous default offering is overridden.
20. Click Submit.
Create a standard Azure catalog item

You can create a catalog item based on an image that you have approved for provisioning, then add that
item to the service catalog to offer to cloud users.


Microsoft provides families of images (many variations on a standard image), but you can use any
approved image as the starting point for multiple catalog items with slightly different settings. Creation of a
standard catalog item requires the cloud user to configure every piece of information about the requested
VM. See Create a simplified catalog item on how to offer pre-configured catalog items to cloud users.
1. Navigate to Microsoft Azure Cloud > Approved Images.
2. Click the name of the desired image.
3. On the form, verify the Name and Label for the item and then click the Create Catalog Item link in the
Related Items section. Specify the following settings:
Table 487: Azure VM Catalog Item form
Name Name for this VM catalog item. Change

the name as needed to make it useful for
requesters of VMs.
Category Category that includes this catalog item.
Azure: Azure Virtual Machines.
Workflow Workflow for the request that is used to
provision the VM. Azure: Virtual Machine
Request.
Icon Image that represents the item in the service
catalog.
name. Update as needed.
Price The system calculates the price based on
the VM size.
Omit price in cart Select the check box to not display the price
of the item while the user is configuring the
VM to request.
Billable Select the check box to cause the resource
to generate billing data.
Active Select the check box to cause the item to
appear in the catalog. Clear the check box
to not list the item in the catalog.
Description Description of the VM to be ordered. If the
requester selects a VM size, the system
populates the Description with CPU,
memory, and disk size.
Picture PNG format file that represents the item
to requesters who view the list of catalog
items.

Subscription Subscription that this catalog item should be

a part of.
Note: If you specify a value, then

the requester cannot choose a
value while requesting a VM.
VM template Approved template that this catalog item

was created from.
VM size Size for the VM that includes specifications
for CPU, memory, and OS disk size.

Skip approval Select the check box to not require

approval of a request by a user in the Azure
Approvers group for this item (Virtualization
Provider > Azure VM in the Approver
Group list).
Note: Other approvals that apply to

requests through the service catalog
are still required.
Provisioning mode • Automatic: No catalog task is assigned

to the Cloud Operators group. The
system selects provisioning information
and places the request into the
provisioning workflow.
• Manual: A catalog task for specifying
provisioning information is assigned
to the Cloud Operators group with no
automatic selections. The cloud operator
can review the settings before closing
the task.
4. When you have configured all settings and the catalog item is ready for consumption, click Publish.
5. You can verify that the item behaves as you expect through the ordering and provisioning processes.
Click Try It to go through the process of configuring, ordering, and then validating the VM.
Cloud users can request the item using the Virtual Assets portal.
Create a simplified Azure catalog item

Cloud admins can create simplified, pre-configured VM offerings to simplify and standardize the methods
used by a cloud user to order a VM.
The standard VM ordering process requires that the cloud user supply information regarding the
deployment and provisioning that they may not know or care about. Simplified VM catalog offerings

eliminate many of these steps, since the offerings are already pre-configured with certain key provisioning
information such as subscription and region.
1. Navigate to Maintain Catalog Items > ARM Template Items.
2. Click on the Azure VM Instance - Advanced item.
3. From the "Related Links" section, select Duplicate Catalog Item.
4. On the new form, modify the Name and specify the following settings as desired:
Table 488: Azure Simplified VM Template Catalog Item form
Field Description
Name Name for this VM catalog item.

Category Category that includes this catalog item.
Azure: Azure Virtual Machines.
Workflow Workflow for the request that is used to
provision the VM. Azure: Virtual Machine
Request IP0.
Icon Image that represents the item in the service
catalog.
name. Update as needed.
Price The system calculates the price based on
the VM size.
Omit price in cart Select the check box to not display the price
of the item while the user is configuring the
VM to request.
Billable Select the check box to cause the resource
to generate billing data.
Active Select the check box to cause the item to
appear in the catalog. Clear the check box
to not list the item in the catalog.
Description Description of the VM to be ordered. If the
requester selects a VM size, the system
populates the Description with CPU,
memory, and disk size.
Picture PNG format file that represents the item
to requesters who view the list of catalog
items.
Subscription Subscription to which this catalog item is
charged.

Region Azure region where the resource group is

located.

Field Description
VM template Base template from which this catalog item

was derived.
approval of a request by a user in the Azure
Approvers group for this item (Virtualization
Provider > Azure VM in the Approver
Group list).

are still required.
Allow deployment to existing group Allow deployment of new VM into an

existing Resource Group. If left unchecked,
then a new Resource Group is created.
the task.
Provider Azure: Azure Template.

VM location Region in Azure where the VM is to be
deployed.
5. In addition to these entries, you can opt to pre-configure additional variables that aid in the
provisioning of requested virtual machines. These variables are available from the Variable Sets tab,
located below the Related Links section. There are seven Variable Sets available for configuring:
Table 489: Available Variable Sets
Name Description
Terms and Conditions Your company-specific terms and conditions

for deployment.
Azure Template Provisioning Variables Variables related to configuring a VM in
Azure. Example: resource groups.
Cloud Resource Provisioning Variables Variables related to creating a VM instance.
Example: lease start and end times.
Cloud Management Auto Tagging Variables Variables used to create tags for VM cost
management. Example: cost center.
Provisioning Rules Log Provisioning information.

Name Description
Azure Single VM Variables* Variables containing VM image

specifications. Example: deployment region.
Single Advanced Template Parameter* Variables used by Azure for deployment.
Example: virtual network name.
Note: Changes made by the cloud admin to the last two Variable Sets (Azure Single VM
Variables, Single Advanced Template Parameter) apply to ONLY the particular catalog item
from which the change was made. Changes made to all other Variable Sets apply to all catalog
items made from the same VM template.
6. When you have configured all settings and the catalog item is ready for consumption, click Publish.
7. You can verify that the item behaves as you expect through the ordering and provisioning processes.
Click Try It to go through the process of configuring, ordering, and then validating the VM.
Cloud users can order the item from their Cloud Resources page.
Define Azure resource group catalog items

A resource group is a container that holds related resources for an application. With Azure Resource
Manager (ARM), you can create a template that defines deployment and configuration for an application.
Based on the ARM template, you can create a catalog item for the resource group that end users can
request.
A resource group could include all of the resources for an application, or only those resources that are
logically grouped together. You can decide how to allocate resources to resource groups based on what
makes the most sense for your organization.
Define an ARM template
An Azure Resource Manager (ARM) template defines the set of resources (for example database server,
database, and website) that is needed for an application. ARM templates also specify deployment
parameters that enable a user to configure settings for resources while requesting the resources.
In this procedure, you provide the information that defines an ARM template in your ServiceNow instance.
Note: For information on authoring an ARM template, see the Azure documentation at https://
azure.microsoft.com and search for Azure Resource Manager Templates.
You have the following options for defining an ARM template:

• Paste the text of the template file directly into the ServiceNow form.
• Specify the URLs of the template file and the parameter file.
1. Navigate to Microsoft Azure Cloud > ARM Templates.

2. Click New and specify a Name for the template and optionally a Description of the purpose of the
template.
3. Specify the template:
Paste the text of the template file directly into the form: Select the Use template body check box and
then paste the content of the template file into the Template body text box. The content must include
the parameters and resources sections. Click Submit and skip the remainder of this procedure.

Once the ARM template is created, the system converts the parameter settings to template parameters, as
listed in the ARM Template Parameters list.
• You can further configure each template parameter with additional attributes. For example, you can
specify the type for the parameter (string, Boolean, array, table reference, and so on).
• After all parameters are fully defined, you can apply the parameter settings to generate the variables
that will appear to requesters in catalog items.
Assign additional attributes to an ARM template parameter

The ServiceNow system enables you to specify attributes for a parameter that give end-users greater
power to configure virtual resources. For example, to ensure a consistent list of options for a configuration
setting, you can specify that the user can choose from values in an existing table.
Once you have defined the attributes for a parameter, you can generate the variable that appears in the
catalog item.
1. Navigate to Microsoft Azure Cloud > ARM Templates and then select a template.
2. In the ARM Template Parameters list, click an existing template parameter.
3. Specify the following attributes for the parameter:
Field Value
Name Name of the parameter. For existing parameters,
the name is already specified. For new
parameters, the name must be alphanumeric and
unique among the parameters in the template.
Template Source template for the parameter that defines
this variable.
Description Description of the variable that gets generated
from this parameter.
4. Specify the Type of the variable that the system is to generate from this parameter.
If the variable offers the values in an existing table as choices, select a Type of String and then:
1. Specify a System type of Reference.
2. Select the Table and the Column that holds the allowed values.
Attributes for the types are described in the next step.
Table 490: Template parameter types
Type Description
String Any valid JSON string.

Secure string Any valid JSON string. Displayed on the
catalog item as a masked variable.
Note: Use the secureString type

for all passwords, keys, and other
secrets. Template parameters with
the secureString type cannot be
read after resource deployment.

Type Description
Int Any valid JSON integer.

Boolean Any valid JSON Boolean.
Array Any valid JSON array. Displayed on the
catalog item as multi-line text with each line
representing one value of the array.
Object Any valid JSON object. Displayed on the
catalog item as a multi-line text-free form
field that has some basic JSON validation in
5. Specify the attributes of the variable that the system is to generate from the parameter.
Table 491: Attributes of variable types
Default value Default value for the variable.

Constraint description Text that appears in the field whenever
the requester enters a value that is not
an allowed value or that is formatted
incorrectly. This text is highlighted to notify
the user that the value is not accepted,
and ought to prompt the requester with
the correct format. Recommendation is to
include example content that the user is to
enter into the field. Example: "Enter 8 to
10 alphanumeric characters. For example,
'ABC123456'".
Allowed values Set of allowed values for the variable (if
appropriate).
Allowed pattern Regular expression that defines the allowed
pattern of the value (if appropriate). For
example, [\w]+
Min value / Max value Minimum and maximum value for integer
type (if appropriate).
Min length / Max length Minimum and maximum character count for
the value (if appropriate).
Now that the parameter is fully defined, you can use the parameter settings to generate the variables
that appears in catalog items for requesters of virtual resources.
6. Repeat the process for all parameters in the template.
Update catalog item variables from template parameters

After you have fully defined all parameters in an ARM template, you can use the parameter settings to
generate the variables that appear in catalog items for requesters of virtual resources. If the variable
already exists, you can use this procedure to refresh the variable with the updated settings.

The ServiceNow instance adds the following variable sets to each catalog item:
• Terms and conditions
• VM Provisioning variables (includes Assignment group, Business purpose, Lease start/end, and CMDB
relationship tags, Application and Business service)
• Cloud auto-tagging variables (includes Cost Center and Project by default)
An ARM template contributes the following variable sets to a catalog item:

• Azure Template Provisioning variables (Resource Group name, Subscription, Deployment name, and
Region)
• Template Parameters set (unique for each template; variables that were generated from the template
parameters)
1. Navigate to Microsoft Azure Cloud > ARM Templates and select the template.
2. Click the Refresh Variables from Parameters related link.
If the variables do not exist, the system generates them. If the variables already exist, the system refreshes
them with the updated attribute settings.
Create an Azure catalog item based on an ARM template
After you are satisfied with the settings and the generated variable set for an ARM template, you can use
the template to generate a resource group catalog item.
1. Navigate to Microsoft Azure Cloud > Maintain Catalog Items > ARM Template Items.
2. In the Azure ARM Templates list, click the template. On the form, verify the Name and content for the
item and then click the Create Catalog Item related link. If needed, specify or update the following
settings:
Table 492: Azure VM Catalog Item form
Price Price of the items in the template.

Description Practical description of the template.
Subscription Subscription that this catalog item should be
a part of.


approval of a request by a user in the Cloud
Operators group for this item.

are still required.
Allow deployment to existing group Allows the user to choose to deploy into an
existing Resource Group. If left unchecked,
then a new Resource Group is required.


the task.
3. When you have configured all settings and the catalog item is ready for use by Cloud users, click
Publish.
The system adds the ARM template item to the catalog.
referenceType metadata for parameters in Azure ARM template

Cloud administrators can define referenceType metadata in an Azure ARM template. Each parameter
with referenceType metadata references a ServiceNow Resource Type table entry. On the catalog
ordering page, the variable type for these parameters becomes a Reference. This feature makes Azure
resource group catalog ordering less error-prone.
The following is an example to define referenceType metadata for each parameter in an Azure ARM
template.
"parameters": {
"vnetName": {
"type": "string",
"defaultValue": "testdummyvnet",
"minLength": 9,
"maxLength": 39,
"metadata": {
"description":"...",
"constraintDescription":"Please provide a valid vnetName",
"referenceType":"Microsoft.Network/virtualNetworks",
"allowedPattern":"[0-9a-zA-Z]+"}
}
},
"password": {
"type": "securestring",
"defaultValue": "testfordummy",
"minLength": 8,
"maxLength": 25,
"metadata": {
"constraintDescription":"Please provide a valid password",
}
},
"storagedisksize": {
"type": "int",
"defaultValue": "testfordisksize",
"minValue": 3,
"maxValue": 9,

"metadata": {
"constraintDescription":"Please provide a valid disk size",
"referenceType":"storage:disksize",
"allowedPattern":"[0-9]+"}
}
},
"virtualnetworkname": {
"type": "array",
"defaultValue": "testfornetworkname",
"minLength": 1,
"maxLength": 10,
"metadata": {
"referenceType":"Microsoft.Network/virtualNetworks",
}
}
}
To define a password parameter, use the secureString parameter. In this example, if the admin sets the
type as secureString, then referenceType is ignored and the corresponding catalog variable has
the Reenter text box on the catalog order page.
When the admin creates referenceType metadata, the following table is created to associate a
reference for the given type.
Table 493: Template Parameter Type
Name Description
Name Matches the referenceType in the template

metadata. Example: user name.
Resource Type Reference to cloud resource type table pointing
to appropriate resource type record. Example:
region.
Table Field Populated based on template parameter in the
Resource Type table. Example: size.
Resource Table Populates the name of the table derived from
the Resource Type field. The cloud user does
not see this field: if the specified Resource Type
does not exist in the cloud resource type, then
the cloud user must explicitly fill in this field on
the order form. Example: user name, region,
size.
To reference an Azure image using referenceType metadata, the publisher, offer, and SKU for that
image must always be specified. If the version is not also specified, then the last known will be used.
Cloud admins can employ these templates to create an image variable containing these parameters. This
variable automatically populates the provided information for a requested VM, thus simplifying the ordering
process for a cloud user.

The following is an example to define image referenceType metadata in an ARM template, and creates
a group variable called image1.
"imageOffer": {
"type": "string",
"metadata": {
"description": "image offer",
"groupKey":"image1",
"referenceType" :"Microsoft.Compute/Images::Offer" }
}
},
"imagePublisher": {
"type": "string",
"metadata": {
"description": "image publisher",
"groupKey":"image1",
"referenceType" :"Microsoft.Compute/Images::Publisher" }
}
},
Metadata for image resource type must contain both referenceType and groupKey to utilize image
reference. Parameters with groupKey are hidden on the catalog order page. If the parameter metadata
contains only referenceType, then a group variable is not created and the variable shows on the catalog
order page. Removing all parameters with the groupKey metadata removes the group variable.
If you encounter a template validation error, then make sure that:
• The groupKey value differs from the name of its parameter. These two values must not be identical.
• The prefix used in referenceType (the part before the ::) is the same for all parameters that have
the same groupKey value.
VMware Cloud administrator actions

Configure membership in VMware groups

Add users to the VMware Approvers and VMware Operators groups.
Activating the Orchestration - VMware Support plugin installs the following groups:
• VMware Approvers: approve requests for VMware instances.
• VMware Operators: are responsible for the technical operation of the VMware Cloud Management
environment.
To add users to these groups:

1. Navigate to User Administration > Groups.
2. Open VMware Cloud Management Operators from the list of groups.
3. Go to the Group Members related list and click Edit.
4. Select one or more users from the list and click Save.

Figure 188: VM approval group
5. Repeat this process to add members to the VMware Approvers group.
Add IP pools to VMware networks

vCenter contains VMware networks that Discovery and the Discover vCenter Data utility add to the
CMDB as VMware CIs. A VMware network record names the network and identifies one or more IP pools
assigned to it.
An IP pool is a collection of IP addresses that are available for provisioning virtual machines.
Note: If your organization does not use ServiceNow Discovery, and you will run the Discover
vCenter Data utility to collect network data from vCenter, you must create the IP Pools for your
system before running the utility.
When you provision a new virtual machine (VM) through vCenter, select a VMware network (Select
Datacenter, Network, and Folder Orchestration activities). Orchestration assigns an available IP
address from the VMware network's IP pool to the new virtual machine. If the VMware network contains
multiple IP pools, Orchestration selects an IP address from the pool with the most available addresses.
1. Navigate to Configuration > VMware Cloud > Networks.
2. Select a network from the list.
3. In the IP Pools related list, click Edit to add an existing IP network to the network.

4. Add additional IP pools to the list.
5. Click Save.
The new IP pool appears in the related list in the VMware vCenter Network form.
Configure an IP pool
An administrator must ensure that there are IP pools associated with all active VMware networks, and that
the IP pools contain enough IP addresses to meet the demand for new VMs.
Role required: cloud_admin, vmware_operator, cloud_operator, vmware_operator, admin

IP pools are collections of IP addresses that can be or have been assigned to newly-provisioned virtual
machines (VMs). Each IP pool can be associated with one or more VMware networks. When the Select IP
Address activity runs, it identifies the IP pools associated with the VMware network selected for the virtual
machine (generally by the Select Datacenter, Network, and Folder activity), chooses the one with the
most available IP addresses, and allocates an IP address to the virtual machine from that pool.
Associate VMware networks with an IP pool by editing the VMware Network related list on the IP Pool
form. When you provision a new virtual machine through vCenter, select a VMware network. Orchestration
assigns an available IP address from the VMware network's IP pool to the new virtual machine. If the
VMware network contains multiple IP pools, Orchestration selects an IP address from the pool with the
most available addresses.
Note: vCenter contains VMware networks that Discovery (including DiscoverNow) adds to the
CMDB as VMware CIs.
To add a new IP pool:

1. Navigate to VMware Cloud > Administration > IP Pools and click New.
2. Enter the specifics of the network in which virtual servers will be created. An optional Alternate DNS
Server IP can be specified.
3. Save the record.

4. To add IP addresses to the pool, click Add Allocatable IPs under Related Links.
5. Add ranges, networks, or individual addresses in a comma separated list.


6. Click Allocate IP Addresses.

The system lists each IP address separately in the related list and marks them as not in use. When a
VMware instance is provisioned, Orchestration marks the address as In use and associates the virtual
machine name with the IP address in the IP pool record.
Figure 189: VM IP pool 2

Enable extended IP address selection for VMware VMs

You can offer a requester the choice of IP address for the requested VM from an IP address pool on an
external system.
You can offer the choice of IP address when a provisioned VM is being customized through guest
customization and is being configured with a static IP address.
1. Create a customization specification as described in the related links. Perform the following additional
steps while creating the customization specification:
a) In the Network section, for Configure networking through, select IP Pool.
b) The system uses the IP Pool field to select the pool using the IP pool tables in the base system.
Leave the IP Pool field blank.
c) Click Update to save the specification.
2. Open the VMware catalog item to customize and then select the Apply guest customization check
box.
3. For Customization Specification, select the specification that you created in the earlier steps.
Note: Alternatively, you can use a provisioning rule to select the customization specification.
4. Define the workflow logic that selects the IP address -- the IP selection workflow.
The workflow that you create is called as a subflow from the VMware VM Provision workflow and
can take any inputs that can be passed from VMware VM Provision. For example, the subflow can
take the sys_id of the VMware network that was selected by provisioning rules. The subflow can also
take requester answers at request time because VMware VM Provision takes as input the sys_id
(sc_req_item) of the request item record so you can look the actual record up and access its variables
object. The subflow must return a JSON string that represents an object with the following fields:
• status: Success or failure.
• ip: String version of the IP address to assign to the VM.
• netmask: The netmask for the network that the IP is on.
• dns: The IP address of the DNS server.
• dns2: Optional: The IP address of a secondary DNS server.
• gateway: The gateway for the network that the IP is on.
• error_message: Optional: To add a failure message, add a field called error_message with a
string value that describes the failure.
For example: {"status": success", "ip": "10.0.10.55",

"netmask":"255.255.255.0", "dns":"10.0.10.15", "dns2":"8.8.8.8",
"gateway":"10.0.10.1"}
5. Cause the VMware VM Provision workflow to call the IP selection workflow by updating an extension
point.
For the extension point in the table vm_extension_point with key VMWareNetworkSelectionSetup,
replace the workflow.scratchpad.networkSelectionWorkflow object with your object that contains:
• name: the name of the subflow that you created.
• inputs: a Javascript object with name:value pairs that represent the inputs to pass to the subflow.
6. Update an extension point with information on releasing the IP address when the VM is terminated.
In vm_extension_point, there is a key VMWPostProvision with a description of Set up ip. Update
the script to: current.ip_address = workflow.scratchpad.provisionResult.ip; The
base system script attaches the provisioned VM record to the record in the base system IP Pool table.
Because you are replacing the selection logic and not using the base system IP Pool table, you must

remove this logic, but the IP address to be set on the VM instance must remain (so the system knows
which IP address to release when the VM is terminated).
7. Define the logic that releases the IP address -- the IP address release workflow.
The workflow that you create is called as a subflow from the VMware Termination workflow and can
take any inputs that can be passed from VMware Termination. The return should be a JSON string
with a key of status and a value of success or failure. For example, {"status":"success"} or
{"status":"failure"}.
8. Cause the VMware Termination workflow to call the IP release workflow: Modify the extension point in
vm_extension_point with key VMWareReleaseIPWFSelection to point at the IP address release logic
subflow that you created.
Create a vCenter template

Create the Windows and Linux templates within vCenter or use existing templates. The system uses the
templates when creating VMs.
Refer to VMware product documentation for vCenter and the ESX Server for details on creating templates.
Create a catalog item for VMware

Provision VMware virtual machines using vCenter from the ServiceNow instance.
1. Navigate to VMware Cloud > Maintain Catalog Items > Available Images (Templates).
2. Select the template to use as a catalog item.
3. Click the Create Catalog Item related link to create a new item from this template.
The VM Catalog Item form opens with the following fields pre-populated based on the default size.
Table 494: VM catalog item form
Field Description
Name VMware Instance - <size> - template name

Catalog Offering The operating system for this catalog item.
Short description A brief description of the item. By default, this value is the same
as the name.
Description The description of the VM size.
Price The price of the VM size. Sizes and prices of demonstration data
are arbitrary and not the result of any calculation.
VM template The template from which this catalog item was created.
VM size The smallest available size for the VM template.
4. Complete the form as described in Defining Catalog Items.

5. Select the virtual server size in the VM size field.
By default, the price is determined by the selection in the VM size field. If the size changes, or the
price of the size changes, the system recalculates the item price automatically.
this item.
7. Select Skip approval to allow requests for this item to bypass an approval from the VMware
Approvers group.

Other approvals that apply to requests through the service catalog are still required.
8. Select the appropriate Task automation mode:
Table 495: Task automation modes
Mode Description
Fully automatic [Default] Provisioning happens automatically based on selections

made by the provisioning rules. No catalog task is assigned to the
VMware Operators group unless the rules could not determine all
the necessary provisioning inputs automatically.
Semi automatic The system assigns a catalog task for specifying provisioning
information to the VMware Operators group with selections
determined by the provisioning rules. The VMware Operators
group can verify the selections before closing the task that
provisions the instance.
Manual A catalog task for specifying provisioning information is assigned
to the VMware Operators group with no automatic selections. The
VMware operator must supply all the necessary information for
provisioning to proceed.
9. Select Guest customization if any operating system-specific customizations will be applied to the
newly provisioned virtual machine. This option is only allowed for Linux and Windows virtual resources
and not for custom templates with other offerings.
10. Select a Customization specification that contains all the settings to be applied to the newly
provisioned virtual resource. This option is only available if Guest customization is selected.

Figure 190: VM catalog item from template

11. Click Update.

By default the new catalog item is placed into the VMware Virtual Machines category. Catalog items
created from VMware templates are listed in VMware Cloud > Maintain Catalog Items > Virtual
Machine Items.
Values in these pre-populated fields are based on the size of the image you selected.
• Name
• Short description
• Price
• Description
If you change the image size, but no other values, the pre-populated data adjusts according to the
parameters of the new size. However, if you change a value in a pre-populated field before selecting
the new size, the field value you changed is not updated when the size changes. This behavior allows
you to change the price, name, or description of specific sized images.
Example:
The default name of a service catalog item is VMware Instance - Small - Red Hat 6 Server. You
change the size to Medium without modifying the Name field. The system changes the name to
VMware Instance - Medium - Red Hat 6 Server. If you change the Name field to Dev Red Hat 6 Server
- Small before changing the size, the name of the item is not changed.
Each of the four pre-populated fields behaves the same and is independent of the others. For
example, if you change the name of the item but not the short description before selecting a new size,
the name value is unaffected, but the short description adjusts to match the requirements of the new
size.
Types of catalog offerings for VMware
You can use several base configurations to create cloud resource offerings.
• Basic service catalog offerings: Use the base system presets to test cloud provisioning in your
environment and to determine how you want to customize service catalog offerings. This is the easiest
and quickest procedure for configuring Cloud Management.
• Custom service catalog offerings: Build on the basic configuration by adding features to the
provisioning workflow. Give users more choices and apply prices to your catalog items.
• Advanced service catalog offerings: Customize your catalog offerings, allowing users to request
special configurations, or to skip approvals during provisioning and automate provisioning tasks.
Configure a VMware catalog offering

Typically, the offering selections contain the operating system and some version information, for
exampleWindows Server 2003 or CentOS 6.
1. Navigate to VMware Cloud > Offerings and click New.
2. Enter the virtual server's Offering name and Description as it should appear in the service catalog.
3. Click Submit.
Catalog items are based on VMware templates

An administrator can create catalog items for virtual servers from VMware templates and present the items
to users in the service catalog.
Before you create a catalog item from a VMware template, configure the categories in the service catalog,
determine the appropriate setting for the check-out redirect property, and define the virtual machines sizes.

These catalog items minimize requester involvement by simplifying the process of selecting the appropriate
virtual server. An administrator can create virtual machines with different specifications that are built from
the same template and presented to users in the service catalog by size.
The following tables are used for this feature.
Table 496: Catalog item tables
Table Description
Virtual Machine Template Contains virtual machine templates from Amazon EC2 and
[cmdb_ci_vm_template] VMware.
VM Catalog Item [sc_vm_cat_item] Contains virtual machine catalog items created from VMware
templates. This table extends the Catalog Item [sc_cat_item]
table.
VMware Size Definition Contains size definitions (specifications) for the VMware
[vmware_size] offerings. This is the parent table to the Catalog VM Class
Selection [sc_vm_class_selection] table.
Link a catalog offering to a template

After you run Discovery on vCenter, you can link a service catalog offering to a template. This process links
the operating system selection that a user makes in the service catalog with the appropriate template.
Catalog offerings are operating systems that are available for the requested virtual machine. The system
provides a Windows and Linux catalog offering by default. When you create a catalog item from a VMware
template, the system attaches the value in the Catalog Offering field to the service catalog item. Cloud
Management uses the same template for a preconfigured class for the selected offering that it uses for a
custom configuration by replacing the specified components with those selected by the user.
1. Navigate to VMware Cloud > Maintain Catalog Items > Available Images (Templates) and then
select a VM template record.
2. Enter or select an available offering in the Catalog offering field.
3. Click Update.
VMware templates and offerings

VMware templates are created on the ESX Server and linked with ITSA Suite catalog offerings to fulfill
virtual machine requests.
Orchestration clones these templates to create virtual machines automatically from a system
managed by vCenter. Template records describe computer hardware features, such as hard disk
size and RAM. The ITSA Suite automatically populates the VMware Virtual Machine Template
[cmdb_ci_vmware_template] table with available templates when you run Discovery or the Discover
vCenter Details utility on the vCenter machine.
Configure size selections for VMware catalog items
Create virtual machine offerings with different specifications, or sizes, based on a single VMware template.
For example, a CentOS 5.3 Linux template might come in three sizes (large, medium, and small) based on
the number of CPUs, memory, and disk space offered.
1. Navigate to VMware Cloud > Sizes.
2. Click New.
3. Complete the form:

Table 497: VMware Size Definition form
Field Description
Name Enter a name that contains an indication of the size, such as

Large or Standard.
Order Logical order of the size.
Price Calculated cost of size.
CPUs, Memory, and Enter the label for each element that appears in the service
Data disk size labels and catalog. For example, enter 2 GB for the Memory label or 15
Values GB for the Data disk size label.
Enter the Value in megabytes (MB) for each element. For
example, a data disk size with a label of 15 GB has a Value of
15,360 (in MB).
Data disk not desired Select to opt out of an additional data disk.
Description Description for the size.
4. Click Submit.
Offer a specialized template on each vCenter environment

Some organizations clone templates to all of their vCenter environments and then configure each copy of
the template in a way that is specialized for the environment.
You can configure the system to respond to provisioning requests by fetching a specialized template
from the target vCenter instead of the vCenter that hosts the template. For example, you might choose to
configure one memory setting on the template on the development environment and a different memory
setting on the template on the production environment.
1. Copy templates to all vCenter environments. Each template must retain its original name. You have
the option to modify template settings as needed.
2. Navigate to VMware Cloud > Administration > Properties.
3. Select the When provisioning a template to a vCenter environment ... check box. This is the
default setting. To provision only from the hosting vCenter, clear the check box.
Configure CPU selections for VMware catalog items

You can customize service catalog hardware selections so that users can request the number of CPUs
for a virtual server. The service catalog shows the CPU option only when the user declines the choice of a
predefined virtual server size.
1. Navigate to VMware Cloud > CPU Selections and click New.
2. In the CPUs label field, enter a description of this CPU selection to be displayed in the service catalog.
3. In the Value field, enter the quantity for this CPU selection.
Be sure the CPU label quantity matches the number in the Value field. The system calculates the cost
for each CPU quantity based on the configured price per unit.
4. Click Submit.
Configure data disk selections for VMware catalog items

You can customize service catalog hardware selections so that users can request the virtual server data
disk size.
The service catalog shows the data disk size option only when the user declines the choice of a predefined
virtual server class.
1. Navigate to VMware Cloud > Data Disk Size Selections and click New.
2. In the Data disk size label field, enter the name to be displayed in the service catalog.
This field typically includes a number and size abbreviation, such as 20GB.
3. In the Value field, enter the number of megabytes of disk space this option represents.
In the following example, the data disk has a value of 20,480. The system calculates the cost for the
disk size selected based on the configured price per unit.
Figure 191: VM disk size select
4. Click Submit.
Configure memory selections for VMware catalog items

You can customize service catalog hardware selections so that users can request a specific amount of
memory for a virtual server.
The service catalog shows the VM memory option when the user declines the choice of a predefined virtual
server size.
1. Navigate to VMware Cloud > Memory Selections and click New.
2. In the Memory label field, enter the memory quantity to be displayed in the service catalog.
This field typically includes a number and size abbreviation, such as 4 GB.
3. Enter the Value for this memory selection as an integer representing the total number of MB.
In the following example, 4 GB of memory would have a value of 4,096. The system calculates the
cost for the amount of memory selected based on the configured price per unit.
Figure 192: VM memory select

4. Click Submit.
Checkout redirect property for VMware

A property called One-step checkout redirect (glide.vm.checkout_redirect) controls the view
presented to virtual machine requesters in the service catalog.
By default, the property is set to false, which redirects the view to the Order Status form when the
requester clicks Order Now. When this property is set to true, the system redirects the requester to the My
Virtual Assets portal.
The property is located in Cloud Management > Administration > Properties.
Configure a basic service catalog offering for VMware
Link offerings associated with VMware templates to the default VMware Cloud Management Instance
request item in the service catalog.
Users requesting virtual machines from this source can select only machine size or specifications such as
CPU count, memory, and data disk size. For the basic configurations, default sizes already exist as demo
data or as custom sizes from an upgraded instance.
1. Use Discovery to discover vCenter and the templates that it contains.
Discovering the templates makes them available for configuration as catalog items.
2. Create the catalog offerings (operating system selections) that are presented to users in the service
catalog or use the offerings provided in the base system.
3. Open each template record in the ServiceNow instance and link the template to a catalog offering.
This links the operating system selection that a user makes in the service catalog with the proper
template.
4. Open the service catalog and click the VMware Instance link under Virtual Resources to request a
VMware instance.
You can select from a list of predefined sizes or customize the virtual machine by selecting the number
of CPUs, quantity of memory, and the storage disk size. When you order the virtual machine from the
basic configuration, manual approvals and provisioning tasks are required.
Configure a custom service catalog offering for VMware

You can enhance basic resource configuration by offering a price structure based on hardware selections
and a pool of IP addresses for provisioning. The customizations require approvals and the cloud operator
must complete the provisioning tasks manually.
Note: Complete the basic configuration before adding the customizations discussed here.
1. Configure these virtual machine specifications:

• Size definitions: Create virtual machine offerings with different specifications, or sizes, based on
a single VMware template. For example, a CentOS 5.3 Linux template might come in three sizes
(large, medium, or small) based on the number of CPUs, memory, and disk space offered.
• CPU selections: Customize service catalog hardware selections so that users can request the
number of CPUs for a virtual server.
• Memory selections: Customize service catalog hardware selections so that users can request a
specific amount of memory for a virtual server.
• Data disk size selections: Customize service catalog hardware selections so that users can
request the virtual server's data disk size.

Note: Prices for these specifications are calculated automatically from amounts configured
in the Prices module.
2. Define prices for each hardware element: CPU, memory, and data disk size.
The catalog price is calculated by the system as multiples of a unit price. All prices on the
VMware Size Definition [vmware_size] table and the hardware selection tables for CPU,
memory, or data disk size are calculated from prices defined in the Catalog VM Element Price
[sc_vm_element_price] table. Pricing can be used to integrate Cloud Management with asset
management model categories. For instructions on setting prices for hardware elements, see Pricing.
3. Assign collections of IP addresses or IP pools to one or more VMware networks.
When a virtual machine is provisioned from that network, the workflow identifies the IP pool associated
with the network and selects an IP address from the pool for the newly-provisioned machine.
4. Create custom specifications for the catalog item, based on the different versions of Windows and
Linux operating systems that your organization offers.
This value appears in the Operating System choice list for the catalog item. The user's selection tells
the provisioning task which configuration information to use.
Configure an advanced service catalog offering for VMware

These procedures build on the basic catalog offering configuration and the custom catalog offering
configuration to provide advanced customization to the service catalog and to the offerings.
The cloud administrator configures the catalog items for guest customization and task automation.
Note: Ensure that the basic and custom configurations are complete before attempting to add the
customizations provided by these procedures.
1. Configure these fields, as appropriate.

• Checkout redirect: [Optional] Configure the checkout redirect property to redirect the view after
checkout to the My Virtual Assets portal of the user rather than to the Order Status form.
• Size definitions: Create virtual machine offerings with different size definitions, based on a single
VMware template.
2. [Optional] Reconfigure the defaults for the duration of a virtual server lease in the appropriate
properties.
The default length of a lease in the base system is 60 days. The maximum lease duration permitted is
90 days.
3. Configure the provisioning rules.
Provisioning rules enable you to select which vCenter resources (datacenter, network, and folder) are
used to provision virtual machines for a specific category, such as Dev, QA, or Prod. Use provisioning
rules to organize multiple vCenters around the types of virtual machines they support.
4. Create catalog items for virtual servers from VMware templates and present the items to users in the
service catalog.
These catalog items minimize a requester's involvement by simplifying the process of selecting
the appropriate virtual server. A cloud administrator can create virtual machines with different
specifications that are built from the same template. Some of the options you can configure in the
VMware catalog item record are:
• Skip approval: Allow requests for this item to bypass an approval from the VMware Approvers
group.

• Task automation: Select the automation level for this item: Fully automatic, Semi automatic, or
Manual.
• Guest customization: Select the settings to be applied to the newly provisioned virtual resource
when guest customization is enabled.
5. [Optional] Configure the system to create change requests when users request modifications to their
VMware machines from the My Virtual Assets portal.
Examples of modifications that generate changes are lease extensions, requests for additional
memory, and requests to terminate a virtual machine.
Price a VMware component

All prices for virtual servers or modifications to virtual servers are calculated from the per-unit price for
CPU, Memory, and Data disk size.
The Catalog VM Element Price [sc_vm_element_price] table stores the prices for VMware
components included in the base system. Each component has a single record that defines the units and
the price per unit. You can access the records to change the unit price for each component.
To change the price for a component:
1. Navigate to VMware Cloud > Prices.
2. Select a component.
3. For Service catalog price, enter the new price per unit in .
Figure 193: VM price
4. Click Update.
The system recalculates the price for all items in the service catalog that use this Element type.
Edit prices for VMware resources

If a requester changes the desired size when ordering a virtual machine, or an administrator changes the
price of the size, the system recalculates the instance price.
By default, the price of an instance is determined by the selection in the VM Size field in the VMware
Catalog Item form. You can make price changes by modifying the specifications of the instance in the
VMware Size Definition form or by overriding the calculated price in the VMware Catalog Item form when
creating a service catalog item. You cannot adjust instance size prices by editing quantities in the VMware
Size Definitions list view.
1. Navigate to VMware Cloud > Sizes.
2. Select a size.
3. Change the quantity of CPUs, the memory, or the data disk size.
4. Click Update.

The system calculates the price of the modified size.
Guest customization
Guest customizations are operating system-specific customizations for virtual machines.
Configure a customization specification for VMware Linux VMs
Customization specifications for Linux VMs. Specify configuration settings that the system applies after a
user submits a request.
1. Navigate to VMware Cloud > Customization Specifications > Linux and click New.
2. Enter a unique and descriptive Name that includes the operating system.
The Name appears in the Operating System choice list for the catalog request item. The selection
tells the provisioning task which configuration information to use.
3. Enter the DNS name in the Domain field.
4. Choose whether to use IP Pool or DHCP in the Choose networking through field.
5. Click Submit.
Configure a customization specification for VMware Windows VMs

Customization specifications for Windows VMs. Specify configuration settings that the system applies after
a user submits a request.
1. Navigate to VMware Cloud > Customization Specifications > Windows and click New.
2. Enter a unique and descriptive Name that includes the operating system.
The Name appears in the Operating System choice list for the catalog request item. The selection
tells the provisioning task which configuration information to use.
3. Enter the registered user's name and organization.
4. Enter the Product key, select the License mode, and, if the selected license type is Per server, enter
the maximum number of Concurrent connections.
5. Enter the Administrator password.
6. Choose a Membership option, either Domain or Workgroup. If you choose Workgroup, enter the
workgroup name. If you choose, Domain, enter the domain name and login credentials.
7. [Optional] Add any number of Windows commands, each listed on a new line, to the Run once field.
8. In the Choose networking through field, choose whether to use IP Pool or DHCP.
9. If appropriate, configure extended IP address selection.
10. Click Submit.
Configure VMware vCenter datastores

You can modify recently provisioned space and reserved space fields in VMware vCenter datastores
to manually adjust space usage. You can also block VM provisioned space or reserve extra space for
specified datastores.
1. Navigate to VMware Cloud > Datastores.
Current information on each datastore is displayed in the table.
2. To set availability for a datastore, double-click the Availability for provisioning field and select
Include or Exclude.

Table 498: Datastore configuration fields
Field Description
Name The name of the datastore.

Capacity The total storage capacity of the datastore.
Free space (GB) The free space available for VM provisioning on the datastore.
Recently provisioned The space requested by recent VM provisioning requests
space (GB) since the most recent discovery. Whenever a datastore is
rediscovered and updated accordingly, the amount of recently
provisioned space is reset to 0. If a VM was terminated, the
provisioned space may be a negative number.
Reserved space (GB) The amount of space reserved on the datastore for scheduled
VM provision requests and extra disk space requests for modify
VM requests. The Reserved space for the requested VM
must be less than Free space - ('Recently provisioned space
+ Reserved space) - Minimum free space in order for that
datastore to be used by the VM.
Availability for Indicates whether the datastore is available (Include) or
provisioning unavailable (Exclude) for provisioning. For newly discovered
datastores, the default value is Include. Running Discovery
does not change this field.
Configuring and managing datastores

Datastores represent storage locations for virtual machine files. The VM vCenter Datastores form shows
the most recent datastore availability and capacity information for the datastores, and allows you to
manage how storage space is handled when provisioning VMs.
Use the VM vCenter Datastores form to make the most efficient use of space, reducing the amount of
wasted space.
How Datastore Space Is Allocated
By allocating reserved space when a VM is requested and accounting for recently provisioned space, the
user can be assured that sufficient space will still be available for provisioning when the request is fulfilled.
To accomplish this, space on the datastore is processed as follows:
• When a VM is requested, the amount of reserved space is incremented to account for the requested
disk size (template size plus additional disk size). If the reserve space request fails because of
insufficient space after discovery, a task to fix the issue is created for the cloud operator. If the VM
request is canceled, the reserved space is decremented to remove requested disk space.
• For automated provisioning, the datastore with the least disk space, but sufficient for the VM request, is
automatically selected.
• When the VM is provisioned, the reserved space is decremented to remove provisioned disk size, and
recently provisioned space is updated to provisioned disk size.
• Whenever a datastore is rediscovered and updated accordingly, the amount of recently provisioned
space is reset to 0. When a VM that was provisioned from a ServiceNow instance is terminated, the
provisioned space is released and the free space is incremented. If the workflow is canceled before the
VM is provisioned, the reserved space is updated to remove not provisioned disk size.

• When a VM is modified, the requested amount of space is reserved, and the reserved space field is
updated. When the Modify VM workflow finishes, the reserved space is updated to decrease the disk
size added and the recently provisioned space is increased. When the VM is terminated (Terminate
VM), the recently provisioned space in all affected datastores is released.
When a catalog task is created and a cloud operator chooses a datastore, only those datastores with the
enough space to continue are shown in the choice list.
Set the minimum free disk space for VMware datastores
You can set the minimum free disk space on datastores to ensure that the vCenter functions correctly.
Navigate to Cloud Management > Administration > Properties.
Table 499: Minimum free disk space table
Minimum free disk space on each VMware The amount of free disk space required on a
datastore (MB) datastore. The default value is 1024 MB.
[glide.vmware.provisioning.datastore.reserved_space]
Change Control for Cloud Management

A cloud administrator can configure the system to create change requests for specific modifications to
virtual machines.
The administrator can specify which virtual machine categories and types of modifications require approval
through a change request. For example, an organization might require project manager approval before
a user can extend the lease end date or change the state of a development server. Change request
approvals created in this manner are independent of the approvals required by the user who provisions
and manages the virtual resources being requested.
The cloud administrator can configure change control for these actions performed on a virtual machine:
• Extend the duration of a lease
• Start a virtual machine
• Stop a virtual machine
• Terminate a virtual machine
• Pause a virtual machine
• Modify the specifications of a VMware server
• Take a snapshot
• Revert to a snapshot
Roles Required
Members of these groups can configure change control for virtual machine modifications:
• Virtual Provisioning Cloud Administrators
• Virtual Provisioning Cloud Operators

Configuring change conditions

Cloud Management uses preconfigured condition builders to determine if a change request is required for
specific user requests, such as those for state changes or memory increases.
The change request launches a workflow that executes an approval task and then waits for the requester
to commit or cancel the change. You can deactivate change conditions or edit them to create different
approval conditions.
Tables
These tables are used in change control processing.
Table 500: Change Control Processing tables
Table Name Contains
Change Condition Records that define the conditions for creating a change
[vm_instance_change_condition] request.
VM Instance Action Records that define the type of change (action) that requires
[vm_instance_action] an approval, such as additional CPUs or an increase in the
data disk size.
Change conditions
The following change conditions in the base system require change approvals for actions performed on
production environments:
Table 501: Change conditions
Name Description Action
Create production VM A user requests a snapshot for a virtual create_snapshot

snapshot machine.
Delete an existing VM A user requests to delete an existing delete_snapshot
snapshot snapshot for a virtual machine.
Extend production A user requests to extend the lease for a update_lease_end
Resource Group lease Resource Group.
Extend production A user requests to extend the lease for a update_lease_end
Stack lease virtual machine instance.
Extend production VM A user requests an extension to the lease update_lease_end
lease duration for a virtual machine running a
production instance.
Modify production VM A user requests changes to the modify
specifications of a VMware production
server, such as an increase in the number of
CPUs.
Pause production VM A user attempts to pause a virtual machine pause
running a production instance.

Name Description Action
Restore snapshot A user attempts to restore a snapshot for a restore_snapshot

virtual machine.
Start production VM A user attempts to start a virtual machine start
Stop production VM A user attempts to stop a virtual machine stop
Terminate production A user attempts to delete a resource group terminate
Resource Group running on a production instance.
Terminate production A user attempts to delete a stack running on terminate
Stack a production instance.
Terminate production A user attempts to terminate a virtual terminate
VM machine running a production instance.
Update production A user attempts to update a stack on a modify
Stack production instance.
Update resource A user attempts to update a resource group modify
group on a production instance.
Editing change conditions

You can edit existing change conditions to create different approval conditions.
1. Navigate to Cloud Management > Administration > Change Conditions.
2. Select a change condition from the list.
3. Make sure the change condition is in an active state.
Tip: By default, Active is selected for all change conditions.
4. Edit the condition statement appropriately.

For example, you might add a condition requiring a change request for lease extensions on any virtual
machine used for Demonstration.

Figure 194: Change Condition example
5. Click Update.
Creating a change request for a VM

You can request a change, such as additional memory, for example, for a VMware virtual machine. This
procedure is not available with Amazon EC2 Cloud Management.
1. A user requests a specific change to a VMware virtual server.
ServiceNow displays a message informing the requester that this modification is subject to change
control.

Figure 195: Change Control pop-up
2. Click OK.
The system creates the change record with data from the original request and displays the record.
If the change request specifies an item that is a service catalog offering, such as a lease extension,
then a message appears at the top of the form containing a link to the request number. The requested
modification is noted in the Description field. The provisioning workflow begins but waits for change
request approval.

Figure 196: Change Request Form
3. An approver approves the change request.

The system sends the requester a notification that contains a link to the virtual machine record.
4. The requester opens the virtual machine record from this link.
5. Under Related Links, the requester clicks Proceed with Change to confirm the changes, or click
Cancel Change to stop the change process.

Figure 197: Related Links Example
• If the requester clicks Proceed with Change, the provisioning workflow completes and makes the
requested modification.
• If the requester clicks Cancel Change, the workflow exits without making any modifications to the
virtual machine.
After either selection, the system returns the requester to the source portal from which the request was
made. The asset view shows the state of the virtual machine.

Service level management for Cloud Management

When activated, the Orchestration plugins for Amazon EC2, VMware, and Microsoft Azure create service
level agreements (SLA) and operational level agreements (OLA) for Cloud Management.
Required Roles
• System Administrator (admin role): Users with this role are permitted to add, edit, or delete SLAs and
OLAs.
• Virtual Provisioning Cloud Administrators group (cloud_admin role): Users in this group can view lists of
breached SLAs and access requested items in a breached state.
• Virtual Provisioning Cloud Operators group (cloud_operators role): Users in this group can view lists of
breached OLAs in the Cloud Operations Portal and access provisioning tasks in a breached state.
Operators group response OLAs

The virtualization plugins create operational-level agreement (OLA) records with a default duration of one
day.
• EC2 Operators group response
• VMware Operators group response
When a task is assigned to one of the operator groups, The system creates an OLA. If an error occurs
during provisioning, the system assigns a task to one of the operator groups and triggers an OLA.
Members of the Virtual Provisioning Cloud Operators group can view a list of breached OLAs in the Cloud
Operations Portal.
To change the default duration of an OLA:
2. Open the OLA record appropriate for your virtualization product.
3. Change the value in the Duration field or select a preconfigured Duration type, and then click Update.

Figure 198: VM OLA Record

Virtual server requests SLA

The Virtual Server Requests SLA record for Cloud Management has a default duration of one day.
When a user requests a virtual machine, this SLA is activated. If the virtual machine's start date is in the
future, the Virtual Server Request SLA is paused from the time the configuration item (CI) is created (when
the requested configuration is entered into the system) until the time provisioning actually begins. Members
of the Virtual Provisioning Cloud Administrators group can view a list of breached SLAs in the Cloud Admin
portal.
The virtual machine CI is created by one if these actions:
• The EC2 or VMware Operators group closes the task and provides the information necessary to fulfill
the request.
• A fully automatic process applies all the rules successfully.
To change the default duration of the SLA:

2. Open the Virtual Server Request record.
3. Change the value in the Duration field or select a preconfigured Duration type, and then click Update.

Figure 199: VM SLA Record © 2018 ServiceNow. All rights reserved. 1173
Tags improve reporting for cloud resources

Cloud admins can enrich tracking and billing data for cloud resources by configuring the system to auto-tag
resources when they are provisioned. For example, when resources are tagged with a Cost Center tag, the
reports can present the billing data segregated by cost center.
• Tagging resources creates metadata in the system billing line item records that allows cloud
administrators to categorize costs into bins. The tag metadata is a key/value pair, for example, Cost
Center=Retail.
• Because a cloud resource can have multiple tags, you can view cost items from multiple perspectives.
• The system tags resources during provisioning either automatically using provisioning rules or manually
when the requester provides tag values while requesting the resource.
• Bulk tagging can be used to alter the values.
• ServiceNow supports bulk-tagging of resources. You typically use bulk-tagging to apply tags to
resources that were created outside ServiceNow Cloud Management.
The system generates a unique Tag Set ID number and applies the ID to a resource when the resource
is provisioned. Along with the other tags for the resource, the system pushes the ID to the cloud provider
as the value for the Tag Set tag. Tag key/value mappings are stored in the instance as references as soon
as the CI is created (pre-provision). When pushed to the provider, they will use the display names of the
referenced values.
Tagging allows you to track resources in several dimensions:
• Ownership
• Cost management
• Business service/application relationships
• Audit and compliance
• Monitor account/subscription proliferation
ServiceNow Cloud Management provides the following default tags:

• Application
• Cost Center
• Project
• Service
• User Name
A tag can have any of the following value types:

• Constant value
• Reference to a field of an sc_req_item
• Service catalog variable
• Script
CloudFormation administrators can categorize and assign metadata to cloud resources by tagging them.
Define a tag for a cloud resource

The system tags resources during provisioning either automatically using provisioning rules, or manually
when the requester provides tag values while requesting the resource.
1. Navigate to Cloud Management > Administration > Tags.

2. Click New, specify the following values, and then click Submit:

Caution: Do not select a cloud resource in a list and select Tag in the related list. When you
do so, the system generates a ServiceNow system tag instead of the desired cloud metadata
tag on the resource.
Field Value
Name Unique name for the tag.
Category • Standard: Provided with the base system and
determined during provisioning. By default,
includes Application, Cost Center, Project,
Service, User Name
• Other: Tags that you specify.
Amazon supports bulk-tagging for Standard tags.

You typically use bulk-tagging to apply tags to
resources that were created outside ServiceNow
Cloud Management. Azure does not support
bulk-tagging.
Table Table to refer to when obtaining values.
Description Text that describes the tag.
Mandatory Select the check box to require that the tag must
be assigned during provisioning.
Value type Select the type of value to use for the tags. You
specify the value in the next step.
• Constant value
• Variable: Service catalog variable.
• Reference (to a field of an sc_req_item)
• Script
3. After you specify the Value type, you specify the value for the tag.
Option Description
Constant Value to use for the tag. If a table is specified, the

tag value should be the sys_id of a record in the
specified table. If no table is specified, the string
value of the field is used.
Variable You must specify which Variable to use to tag
the resource. The system uses the value of the
specified variable for the tag. A particular variable
cannot be used for more than one tag rule.
Reference value Reference to a field on the requested item
(sc_req_item) for the provisioned resource. If the
field is another reference, then the assignment
uses the sys_id as the value for the tag,
otherwise the string value is used.
Script The tag value is the variable answer (var answer)
from the specified script.

Restrictions on tagging AWS VMs and CloudFormation stacks

CloudFormation Administrators must follow the Amazon guidelines when defining a tag to assign metadata
to a VM or CloudFormation stack.
• Maximum key length: 127 Unicode characters
• Maximum value length: 255 Unicode characters
• Maximum number of tags per resource: 10
• Do not assign the reserved prefix aws:
AWS-assigned tag names and values are assigned the aws: prefix. AWS-assigned tag names do not
count toward the tag limit of 10. User-assigned tag names have the user: prefix in the Cost Allocation
report.
• Use each key only once for each resource. If you attempt to use the same key twice on the same
resource, the request is rejected.
• You cannot tag a resource at the same time as you create it. Tagging requires a separate action after
the resource is created.
• You cannot backdate the application of a tag.
• Allowed characters are letters, whitespace, and numbers representable in UTF-8, plus the following
special characters: + - = . _ : /
To use characters outside this set, encode the tag using standard base-64.
For information on tag restrictions, see the Amazon Web Services documentation at http://
docs.aws.amazon.com
View the tags for a cloud resource

After the resource is provisioned, you can view the tag settings. Values can be added or changed using
bulk tagging.
Role required: cloud_admin, cloud_operator, or cloud_user
1. Open the list of resources and select the resource.
2. View the list of tags on the Cloud Management Resource Tag tab.
Auto-assign tags to outside resources for bulk tagging

Bulk tagging enables you to update the standard tag values for resources that were created outside of the
ServiceNow instance. This process ensures consistent meaningful reporting.
Role required: cloud_admin, cloud_operator, cloud_user.
Cloud admins, operators, and users can use bulk tagging to apply multiple tags to their cloud resources
using a single screen. Multiple resources across AWS, Microsoft Azure, and VMware can have cloud
management tags assigned using the same UI. There are two types of tagging: on-instance and on-
provider.
• On-instance: For any supported CMDB configuration type, cloud admins, operators and users can visit
a list of records or the form for a single record and assign standard cloud management tags individually
or in bulk from within ServiceNow.
• On-provider: For individual configuration types, a workflow can be defined to take the tag values that
were assigned on-instance and send them to the provider to be saved there as well.
On-instance and on-provider tagging

1. Navigate to a resource in Cloud Management.
2. Select a resource or multiple resources that you want to assign tags to.
3. Choose Actions on selected rows > Assign Standard Cloud Management Tags

• This page is common to all types and allows a user to set values for any of the defined cloud
management tags in the “Standard” category.
4. Select the tags and enter the values. Submitting the page starts a job that will set the specified tag
values in ServiceNow for all resources selected.
5. For on-provider tagging, an entry must be added to the task_action_workflow table mapping the
"tag_resources" operation to the workflow for the relevant CI table. This is only supported for one type:
EC2 instances on AWS.
View which resources are missing tags

Using the new Missing Tag Report, cloud admins and operators can see a tabular view of all resources
that are missing tags.
Role required: cloud_admin or cloud_operator.
You can view a tabular report of all cloud resources with missing tags.
1. Navigate to Cloud Management > Cloud Operations Portal.
2. To view the missing tags report, select the tab Missing Tags.
A tabular view of all resources that are missing tags is displayed. From here, you can drill down to a
list, select a one or more resources, and assign any missing standard cloud management tags.
Define the schedule for downloading billing data

To obtain the data that appears on billing reports, a job (scheduled script) downloads the billing data from
the provider to the ServiceNow database.
Running multiple scheduled jobs at one time can cause significant performance degradation. When
possible, schedule cloud discovery, billing data download, and resource optimization jobs to run a few
hours apart instead of overlapping.
To view scheduled jobs, navigate to Cloud Management > Administration > VM Snapshot Scheduled
Jobs.
Note: When you delete a job definition, all associated scheduled jobs are deleted.
1. For your provider; Amazon AWS Cloud or Microsoft Azure Cloud: Navigate to Administration >
Report Schedules.
2. Select an existing job or click New and then specify the following values:
Field Value
Job name Name of the scheduled job that will download the
billing data to the ServiceNow database.
EA credential Select the appropriate Enterprise Agreement
credential.
Note: You can configure only one

scheduled job for each EA credential.
Scheduler [read-only] Name of the script that downloads the data.

Field Value
Note: While you are creating a new

job, leave this field blank. While you are
updating an existing job, you can modify
the scheduler settings (for example, days
of the week to run or time to run).
Table 502: Read-only information on runs of the job
Field Description
Last run Completion timestamp for the most recent

job run.
Last successful run Completion timestamp for the most recent
job run that has a State of success.
Last run state State of the job that ran most recently.
Current job status Status of the currently running job. This field
appears when you click Execute Now.
3. Click Submit.
The job definition is complete. Jobs will run on the specified schedule. You have the option to update
the scheduler that controls the interval that the download repeats at.
Download billing data on demand

By default, the jobs that download billing and cost data from the provider are scheduled to run on a daily
basis. However, you can run a job on demand. You can start a job manually only when the job is not
currently running.
Note: By default, the job downloads billing and cost data for the current month from the provider.
To download data from another specified time period, modify the job scheduler before running the
job.
1. For your provider; Amazon AWS Cloud or Microsoft Azure Cloud: Navigate to Administration >
Report Schedules.
2. Select a scheduled job.
3. Click Run now to download the most recent billing and cost data from the provider.
Modify a scheduler (for downloading billing data)

A scheduler defines the schedule for the job that downloads billing data. While you are updating an existing
job, you can update the scheduler settings for the job (for example, specify how often to download the
data).
You can modify the scheduler only for existing jobs. You cannot modify the scheduler while you are
defining a job.
1. For your provider; Amazon AWS Cloud or Microsoft Azure Cloud: Navigate to Billing > Report
Schedules.

2. Select an existing job and then click in the Scheduler field.

3. For Repeat interval, specify the interval in Days and Hours between runs of the job.
Configure default lease settings

Properties specify the default lease period and maximum allowed duration of a virtual server lease for all
cloud providers.
You can configure a lease duration to define the length of time cloud users can access a virtual resource.
At the end of the lease, access is terminated. You can also configure a grace period for the lease end.
1. To configure duration, navigate to Cloud Management > Administration > Properties and specify
the following values:
• Default lease duration
This property (glide.vm.lease_duration) controls the length of the lease period automatically
configured for a virtual server request. The default duration is 60 days from the lease start time,
which begins on the current date and time of the request. The actual time of the lease is calculated
from the time the instance is provisioned, after any approvals.
• Max lease duration
This property (glide.vm.max_lease_duration) controls the maximum length of the lease period
permitted for a virtual server. The default maximum duration is 90 days from the lease start time.
This property prevents virtual resources that have been ignored from running indefinitely.
2. Configure the Lease is expiring notification time. Specify the number of days in the Time prior to
lease end to notify requester property (glide.vm.lease_end_notification).
The ServiceNow instance sends the following system notification to the user on the specified number
of days before lease end:
Virtual instance <name> will be terminated in <n> days.

3. Configure the grace period.

A configurable grace period enables an administrator to delay the termination of a virtual machine
when the lease end date expires. When the lease ends, the virtual machine is powered off, but is
available for use until the end of the grace period.
To change the default grace period of 7 days, navigate to Cloud Management > Administration >
Properties and edit the value in the Grace period after lease end until VM termination property
(glide.vm.grace_period).
When the lease ends, the platform runs the Amazon EC2 End of Lease workflow, which powers off the
virtual machine and notifies the requester that the lease has expired. The Amazon EC2 End of Lease
workflow evaluates the glide.vm.grace_period property to determine when the Terminate Amazon
EC2 Instance workflow should run. The requester is notified when the virtual machine is terminated (or
when termination has failed).
4. To configure a different workflow to run when a lease is terminated, in the application navigation filter,
enter task_action_workflow.list.
1. Select end_of_lease in the Action field.
2. Select the appropriate table in the Table field.
• For an AWS VM instance: [cmdb_ci_ec2_instance] table.
• For an Azure VM instance: [cmdb_ci_azure_instance] table.
3. Select a different workflow in the Workflow field.

4. Click Update.
Requesters of virtual resources can configure lease start and end times for individual virtual machines.
Configure the lease grace period

A configurable grace period enables an administrator to delay the termination of a virtual machine when
the lease end date expires.
When the lease ends, the virtual machine is powered off, but is available for use until the end of
the grace period. To change the default grace period of 7 days, navigate to Cloud Management >
Administration > Properties and edit the value in the Grace period after lease end until VM termination
property (glide.vm.grace_period).

When the lease ends, the platform runs the VMware End of Lease workflow, which notifies the requester
that the lease has expired, and then powers off the virtual machine. The VMware End of Lease workflow
evaluates the glide.vm.grace_period property to determine when the VMware Termination workflow
should run. The requester is notified when the virtual machine is terminated, or if termination failed.
To configure a different workflow to run when a lease is terminated:
1. In the application navigation filter, enter task_action_workflow.list.
2. Select the end_of_lease action for the VMware Virtual Machine Instance
[cmdb_ci_vmware_instance] table.
Figure 200: VM lease end workflow
3. Select a different workflow to run in the Workflow field.

4. Click Submit.
Define an eviction policy for VM snapshots

To conserve disk space, you can define an eviction policy that deletes existing snapshots when the count
of snapshots equals the specified snapshot limit setting, and when a scheduled job attempts to take a new
snapshot.
1. Navigate to Cloud Management > Administration > VM Snapshot Eviction Policy and then click
New.
2. Configure the settings as shown in the table and then click Submit.
Table 503: Catalog item form
Field Description
Policy name Name for the eviction policy.

Application Provider for the VM.
Description Description for the policy.

Field Description
Script Script that specifies the snapshot to delete.

The script sets the value of the result
variable to the sys_id of the snapshot to
delete.
Define provisioning rules

Provisioning rules auto-configure cloud resources. When a user requests a cloud resource, each
provisioning rule (in the specified order) compares the requested resource against the conditions in the
rule. If the request meets all conditions, then the system assigns a value to the variables that are specified
in the rule.
There are two components to a provisioning rule:
• Assignments
Assignments specify the variable to configure and the value to set for the variable. Provisioning rules
typically include several assignments.
• Conditions
Conditions that are compared to the request to determine when to apply the rule and perform the
assignments.
Note: When any rule is triggered, no additional rules are evaluated.
Define an assignment for provisioning rules

Provisioning rules include assignments that specify the values to assign to variables during provisioning.
Before you create a provisioning rule, configure all of the assignments of which the rule may make use.
Any number of provisioning rules can use a particular assignment. For a rule to succeed, it must provide a
value for each required variable in the requested resource.
1. Navigate to your provider; Amazon AWS Cloud or Micorosoft Azure Cloud or VMware Cloud and
click Administration > Provisioning Rule Assignments.
2. Click New, specify a unique Name and Description for the assignment, and then configure the
following settings:
Field Value
Applies to items of type The type of ordered catalog items that the
rule applies to. For example, VMware VMs (in
the sc_vmware_cat_item table) or Amazon
EC2instances (in the sc_ec2_cat_item table).
A rule can include only those assignments that
match the Applies to items of type setting in the
rule.
Order The system uses the Order value to determine

the sequence for performing the assignments.
Assignments with lower Order values are

Field Value
performed before assignments with higher
values.
This is a standard ServiceNow Order field.
An assignment runs in the order that appears
in the related list in the rule. You can modify the
settings from the list view.
Value type Described in the next step.

3. The Variable to assign field appears after you specify the Value type (except for the Script type).
The process for configuring the Variable to assign settings depends upon the Value type that you
specify.
Option Description
Reference Specify the Reference item. The assignment

assigns the sys_id of the Reference item to the
variable that is specified in Variable to assign.
Constant Value to assign to the variable.
Script A script makes assignments to the assignments
object and has access to the following data:
• The requested resource (sc_req_item record).
• Values that were set by previously-run
assignments (in the assignments object).
• Variables that use a temporary, in-memory,
object to hold values for use by subsequent
assignments. The script should add values
needed by subsequent assignments to the
rule_variables object.
• Loggers to log messages in the same way as
the provisioning rule engine logs messages.
For VMware, the base system includes several

example assignments. For instance, one example
assignment filters networks for a cluster and
assigns the network sys_ids to a rule variable
named networkIds for use by any subsequent
rule (as described in the instructions for the Set
by filter assignment type).
Set by Filter Set by Filter assigns the sys_id of the first record
that matches a specified condition.
4. Save the assignment definition.
Configure a Set by Filter assignment

This assignment assigns the sys_id of the first record that matches a specified condition.
1. While configuring an assignment, specify a Value type of Set by Filter and then configure the following
settings:

Field Value
Provisioning rule variable Specifies an array of sys_ids (for records
in the specified Table) that is defined in a
scripted provisioning rule assignment to apply
the condition against. The condition should
be designed to select one item from the list.
Otherwise the first rule variable that is returned
from the query is picked.
If Provisioning rule variable is blank, then the
filter runs against all records in the Table that you
specify.
See the Script assignment type.
Table The Table is based on the Variable to assign

field. The table should be automatically assigned
to the type of the variable in the Variable to
assign field.
Condition The Condition field is a standard ServiceNow
condition builder against the Requested Item
table (sc_req_item).
In the following example, the networkIds array is populated by an assignment that will run before
this assignment (the Order is lower for the assignment that will run earlier). networkIds is an array of
sys_ids to records in the cmdb_ci_vcenter_network table. The Network variable is being assigned to
the first record in networkIds that has a tag with value of non-PII. non-PII is a standard ServiceNow tag
that you can apply to any record in the system.
Figure 201: Set by Filter example

2. Save the assignment definition.
Specify the conditions for a provisioning rule

After you have configured all of the assignments that will implement a provisioning rule, you can create the
rule, name the rule, specify the conditions that apply the rule, and then add the assignments that should be
made when the rule is triggered.
1. Navigate to your provider; Amazon AWS Cloud or Micorosoft Azure Cloud or VMware Cloud and
click Administration > Provisioning Rules.
2. Click New, specify a unique Name and Description for the rule, and then configure the following
settings:
Field Value
Applies to items of type The type of resource that the rule applies to, for
example, Azure VMs, Amazon EC2instances,
VMware VMs, and so on. (The types are held in
the sc_<provider>_cat_item tables.)
Note: For this rule, you can add only

assignments that match the Applies
to items of type value that you specify
here.
Applies only to item Only consider this rule if the specified catalog
item is ordered. The list is filtered based on the
Applies to items of type selection.
If this field is left blank, then the rule applies to
any catalog item where the type matches the
Applies to items of type value.
Conditions on request item [Configured in the following step.]

Order The system uses the Order value to determine
the sequence for evaluating the rules. Rules with
lower Order values are evaluated before rules
with higher values.
Note: When any rule is triggered, no

additional rules are evaluated.
This is a standard ServiceNow Order field. By

carefully specifying order values for provisioning

Field Value
rules, you can ensure that provisioning rules with
more specific conditions are evaluated before
(low values) provisioning rules with more general
catch-all conditions (high values).
Active Select the check box to cause the rule to

be evaluated when a user requests a cloud
resource.
3. For an AWS VPC, if the rule condition is met, then the VM is provisioned into a VPC and a VPC
security group. Use the Provision request filter to set the conditions.
4. Specify the Conditions on request item. The conditions that must be met for the rule to apply to the
requested cloud resource. The field is a standard ServiceNow condition builder against the Requested
Item table (sc_req_item).
You can filter on variables that are part of the request as follows:
1. Select Show Related Fields and then select Variables.
2. Either leave the Select Item text box empty or match the Applies only to item value.
3. The Select Variable text box lists all catalog variables . There are no reference qualifiers on the
condition builder.
Figure 202: Example of filtering on variables that are part of the request
5. Save the rule definition.

The Provisioning Rule Assignments related list appears at the bottom of the rule. The assignments
that you add to the rule perform the process of configuring the variables in the requested resource.
6. In this step, you select the assignments that implement the rule. In the Provisioning Rule
Assignments related list, click Edit, select the appropriate assignments from the slushbucket and
then click Save.
Note: For automated provisioning, create a rule to configure a value for each required variable
in the requested resource. When a required value is not set, a cloud operator must set the
missing value.
For Amazon EC2 VMs, the required variables are:

• image
• account
For Amazon CloudFormation stacks, the required variables are:

• account
• stack name
• template

For Azure VMs, the required variables are:

• region
• subscription
• resource group
• public IP
• computer name
• virtual network
• admin name
• admin password
• container
• storage
• nic
For Azure resource groups, the required variables are:

• subscription
• region
• resource group
• deployment name
For VMware, the required variables are:

• datacenter
• cluster
• datastore
• network
• folder
• clone_name
• template
The Provisioning Rule Assignments related list now displays the assignments in the order of the
assignment Order settings.
Note: To update the Order setting for any assignment, click the value in the list.
Create a provisioning rule for VMware

Provisioning rules enable an administrator to select which vCenter resources (datacenter, network, and
folder) are used to provision virtual machines for a specific virtual machine category (such as Dev, QA, or
Prod) or for any category if the Category field in the rule is left empty.
Role required: itil role (in the VMware approvers group) or cloud_admin role (in the Virtual Provisioning
Cloud Administrators group), vmware_operator, admin
Rule Order
Each rule has an Order field that defines the sequence for evaluating the rules. The rules are evaluated by
the Select Datacenter, Network, and Folder activity.
When that activity runs, it finds all the provisioning rules that apply to a particular vCenter instance and
category (rules with a blank category match any category), and then uses the provisioning rule with the
lowest order value. By carefully choosing order values for provisioning rules, you can ensure that rules for
specific categories are evaluated before (low order values) provisioning rules for any category (high order
values).

Weight
You may want more than one datacenter, network, or folder to be used for virtual machines on a particular
vCenter instance and category. For example, you have a vCenter containing two datacenters, and you'd
like to provision 75% of the virtual machines to one datacenter, and 25% to the other.
You can do this by creating two provisioning rules for the particular vCenter and category with the same
order value for each. Multiple rules with the same vCenter, Category, and Order values trigger this
special behavior. Give each provisioning rule a Weight value proportional to the percentage of the time
you want the rule to be used. For this example, you might choose Weight values of 300 and 100. Any
other numbers in the same proportion would also work, like 3 and 1. To check the percentage for any given
rule, calculate the Weight value of that rule divided by the sum of the Weight values for all the rules with
the same vCenter, category, and order value. In the example, the calculations would be 300 / (300 + 100)
= 75%, and 100 / (300 + 100) = 25%, which meets the goal.
Creating a Provisioning Rule
1. Navigate to VMware Cloud > Rules > Provisioning Rules.
2. Click New and then create a unique Name for this rule.
3. Select a Category.
If you do not select a category, the rule applies to any category.
4. Select the vCenter to use for this category.
The Datacenter field appears.
5. Select a datacenter from the list of datacenters available for this vCenter.
The Network and Folder fields appear.
6. Select an appropriate network and a folder.
7. Enter an Order value to establish the order in which this rule is evaluated.
8. If you create multiple rules with the same Category, vCenter, and Order, select an appropriate Weight
to determine which virtual machines, by proportion, are provisioned with this rule.
9. Click Submit.
Examples of provisioning rule assignments

The VMware base system includes several example assignments. For example, one example assignment
filters networks for a cluster and assigns the network sys_ids to a variable named networkIds for use by
any subsequent rule (as described in the instructions for the Set by filter assignment type).
Example assignments are listed in Cloud Management > Administration > Provisioning Rule
Assignments.
Terminate a cloud resource

A cloud admin can configure the system to generate a change request whenever a user requests the early
termination of a resource. When an instance reaches the end of its lease (or its grace period), the system
auto-terminates the resource and notifies the user.
Role required: cloud_user who owns the VM, cloud operator, or cloud_admin
Caution: Termination deletes the resource and all associated data. You cannot restart a
terminated resource. Be sure to capture all needed data before terminating.
1. Open the list of VMs by navigating to Cloud Management > Cloud Resources and clicking the
Compute tab.
2. Click the VM name.

3. lick Terminate VM related link.

If the resource Used for setting is Production, then the system creates a change request that must
be approved by a cloud operator or cloud admin. If approval is not required, the system immediately
terminates the VM. If approval is required, there may be a delay while an admin approves the change.
You receive email when the admin approves. After the admin approves, return to the VM Instance
form and click the Proceed with Change related link.
The State of the VM becomes Terminated and the VM will no longer be visible in the My Virtual
Assets portal.
Important: AWS: The system does not delete volumes for terminated resources. Use the
AWS console to delete volumes.
Extension point format:
// To run customer workflow, replace the following code

// with pushing a subflow to workflow.scratchpad.after_subflows
which
// needs to have properties for wfname and inputs
var subflow = {};

subflow.wfname = 'After Deprovision WF';
subflow.inputs = { 'u_sys_id': '' + current.sys_id };
workflow.scratchpad.after_subflows.push(subflow);
Any script or logic can be invoked. You can also populate any custom workflows to
execute before the termination or after the termination.
Add all workflows to the workflow.scratchpad.before_subflows or
workflow.scratchpad.after_subflows variables in the appropriate extension
points. A return value of successindicates if the extension point was successful or not.
The termination workflows run the custom deprovision workflows one at a time and if any
of them have errors, a task is created for the operator to manually resolve, and either
proceed with termination if Before Deprovision fails, or just exit the termination workflow
if After Deprovision fails.
Delete stale VM data

To prevent your ServiceNow instance from becoming overloaded with unused or expired resources,
maintain your resource list by scheduling automated cleanup of stale VM data.
When a stack or resource is terminated, no data pertaining to the resource is actually deleted from
the ServiceNow instance. The data is kept to record all instances and resources that have ever been
instantiated on the cloud provider accounts linked to Cloud Management. When a resource is terminated,
the status of that resource and its related underlying items is changed to one of the following statuses:
Terminated Deleted through the ServiceNow Cloud

Management interface.
None Deleted directly through with the cloud provider,
and found via Discovery.

To delete these stale resources, you can configure properties to enable automatic pruning (permanent
deletion) of stale records after a set number of days.
1. Navigate to Cloud Management > Administration > Properties.
2. Change the following properties:
Enable automatic pruning of cloud records Activates the scheduled job which triggers
cleaning of records. This property is disabled by
default.
Number days for pruning cloud table records Sets number of days at which to delete a record.
(Days) Default value is 396.
3. Click Save.
View a cloud resource in the BSM map

The Discovery workflow discovers all virtual resources. You can view virtual resources in the CMDB
Business Service Management Map (BSM map) as a network of related resources.
Role required: cloud_user, cloud_operator, or cloud_admin
Compute tab.
2. lick VM name.
The VM’s relationships to other CIs appears in the Related Items section. The view includes Business
Services and Applications referenced by tags on the VM or its parent resource group.
3.
Click the BSM icon.
The BSM map appears in a separate window.
Cloud operator actions

By default, users with the cloud_operator role can perform operator actions on any virtual resource.
Cloud operators perform the following tasks:
• If catalog item is set for manual approval, then a cloud operator approves or rejects change requests
that are associated with requests from users to provision cloud resources.
• Resolve errors that occur during provisioning or when modifying an existing virtual machine.
• Perform activities on behalf of cloud users: Change the state of a cloud resource to start, stop, or
pause; terminate VMs; take and restore snapshots.
Cloud Operations portal

Cloud administrators and operators (cloud_admin, cloud_operator role) can access the Cloud Operations
portal to view a role-based graphical view of all cloud resources. Cloud admins and operators can perform
life-cycle operations on the resources using the list view.
Navigate to Cloud Management > Cloud Operations Portal. The following tabs appear:


Location, Account, and Provider are available,
Resources Displays an overview of all cloud resources, with

each resource type displaying an up-to-date total
that links to more detailed list view.
Requests Lists of request items (not filtered by user) and a
list of change requests.
Missing Tags Reports on the resources missing tag value

assignments.
Note:
If you are upgrading from Helsinki:
If you are activating Cloud plugins for the first time after upgrading from Helsinki, then you may
see a completely blank page on both the Cloud Operations portal as well as the Cloud Resources
portal. To resolve this, please contact ServiceNow Technical Support and request that the
glide.cms.enable.responsive_grid_layout system property be enabled. This step is not
necessary if you already had Cloud plugins activated before moving to the Istanbul release.
VM provisioning overview
The process of provisioning a virtual machine involves a combination of automated and manual tasks.
1. Cloud operators fulfill provisioning requests from users.
Provisioning procedures and responsibilities are described in these pages:
• Amazon EC2 Approvals and Provisioning for Cloud Provisioning
• Approving and Provisioning VMware Requests for Cloud Provisioning
2. Fulfill user requests for modifications to existing virtual machines, such as increased memory or data
disk size, and for lease extensions.
Tip: Cloud operators also can change the state of a virtual machine to start, stop, or pause;
terminate virtual machines; and take and restore to snapshots.
3. Resolve errors that occur during provisioning or when modifying an existing virtual machine.
4. [Optional] Configure the system to create change requests for specific modifications to VMware virtual
machines requested from the My Virtual Assets portal. Examples of modifications that generate
change requests are lease extensions, requests for additional memory, and requests to terminate a
virtual machine.

Provision AWS resources

After the cloud_admin user configures the AWS offerings, a cloud user can request a VM from the service
catalog.
Because manual approvals are required, an EC2 approver can approve the request. After the request
is approved, the system creates a new catalog task. A cloud operator can complete the catalog task to
provision the virtual machine.
AWS CloudFormation provisioning tasks by group

Tasks for setting up CloudFormation, provisioning CloudFormation templates, and requesting
CloudFormation stacks from the service catalog depend on the user group to which you belong.
CloudFormation user groups
• CloudFormation Administrator: Members of this group own the Cloud Management environment and
are responsible for configuring the AWS resources used by cloud provisioning. Administrators can
create service catalog items from Amazon EC2 images and CloudFormation templates and approve
requests for CloudFormation stacks, and monitor the Cloud Management environment using the Cloud
Admin Portal.
• CloudFormation Operator: Members of this group fulfill provisioning requests from users. Operators
perform the day-to-day work of Cloud Management by completing tasks that appear in the Cloud
Operations Portal. Operators are assigned to specific virtualization providers and must be technically
adept with the products they support.
• CloudFormation Users: Members of this group can request CloudFormation stacks from the service
catalog and use the My Amazon Assets portal to manage any stacks that are assigned to them.
Approvals and provisioning for Amazon EC2

Use these procedures to make Amazon EC2 images available for provisioning from the service catalog.
Images are not available until all Amazon and account configuration is complete.
Two separate approvals are required before a VM is available for provisioning:
• Approval by the cloud administrator for the image to be available to users in the service catalog.
• Approval by an EC2 approver of a user request for an instance.
If the user request is approved, members of the provisioning group create the instance. When the virtual
machine is provisioned, the system creates a new asset in Asset Management. The new asset appears in
the My Assets portal of the requester.
1. Approve the available images
After you establish and configure the Amazon EC2 account, you retrieve the list of available images
and approve them for the service catalog offering. In this task, the administrator decides which images
are available for selection in the specific regions defined by Amazon. Only approved images are
available to fill requests from the service catalog.
2. Set up the Service Catalog Offering
The administrator must link the approved images to the operating systems offered to users in the
service catalog.
3. Approve and provision the request
4. Configure the lease period and duration

Approve a request for a virtual machine

As an EC2 approver, navigate to Service Desk > My Approvals and approve the virtual machine request.
Requests for virtual machines in the base system can be approved or rejected by members in either of the
following approval groups:
• EC2 Approvers
• Virtual Provisioning Cloud Administrators
Only one member of either approval group is required to approve a request.
Note: If the approver rejects the request, the process is finished and no instance is provisioned.
The system notifies the user that the request was rejected.
1. Approver: Pick up the task in Service Desk > My Approvals.

2. Open the request and click Approved or Rejected.
Provision a request for an Amazon virtual machine

EC2 Operators select the Amazon EC2 account, region, and image to fulfill approved requests from the
service catalog.
Role required: cloud_operator, cloud_admin, or admin

Approved requests appear in the Service Desk > My Groups Work queue for the members of the EC2
Operators group.
1. Open the task and select the Amazon Web Services account to use to provision the requested
instance.
2. In Region settings, select a region for the instance (an Amazon EC2 datacenter). Available regions
are those selected during the Amazon EC2 configuration.
The choice list of available images is filtered to show images in the region selected for the account
with the requested OS and size.


3. Enter a user-friendly name for the instance in the Instance name field.
The system uses the name to identify the instance in the My Virtual Assets portal and in the CMDB.
Amazon uses the name as the Name Tag in the EC2 instance list. If you request more than one
instance, the system adds a unique number to the name for each instance. For example, three
requested instances with the name TestLab become TestLab1, TestLab2, and TestLab3. If the
Instance name field is blank, the instance is identified by a machine-generated string created by
Amazon.
4. Select an Image to provision and click Close Task to launch the provisioning workflow that creates
the EC2 instance.
When the workflow finishes provisioning the instance, the requester receives an email containing the
instance ID, IP address, and public DNS for the instances created. If provisioning fails, the workflow
notifies the provisioning group by email.
Create a concept topic to introduce the background needed to perform this process or task.
Complete the EC2 provision task

As a cloud operator, navigate to Service Desk > My Groups Work and complete the catalog task to
provision the virtual machine.
Role required: ec2_operator, cloud_operator, cloud_admin, aws_admin, or admin

1. Open the catalog task record for the EC2 request.

2. Select the Amazon EC2 Account for provisioning this virtual machine.
3. In Region settings, select an Amazon EC2 datacenter for the instance.
4. If multiple Image choices are available, select one.

5. Click Close Task.
Provision Azure resources

The primary responsibility of a cloud operator is to fulfill requests from users to provision or modify cloud
resources. Some organizations configure resource catalog items so that a request requires no action by an
operator. The requests are fulfilled immediately without generating a change request.
Role required: cloud_operator
Most operator tasks start in the Cloud Operations Portal.
Provision VMware requests

Some service catalog requests for virtual servers that do not use task automation must be approved by a
Cloud Approver or Cloud Administrator, and then provisioned by a Cloud Operator.
Upon approval of the request, Orchestration automatically creates the virtual server and powers it up on
the network, using one of the IP addresses supplied. When Orchestration fulfills a virtual server request
and creates a VMware configuration item (CI), the system creates a new asset in Asset Management. The
new asset appears in the My Assets portal of the requester.
Workflow
In the base system, the approval and provisioning process for each virtual server request is controlled by
a workflow (Workflow > Workflow Editor) called Virtual Server. This workflow performs the following
tasks:
• Creates approval tasks for the approval group.
• Collects the provisioning information when the request is approved. (If the request is rejected, the
workflow ends.) The workflow determines if the request is for a Windows or Linux virtual machine.
• Creates a catalog task to select the proper virtual server template and supply it with the necessary
requirements, including the appropriate ESX resource pool.
• Sets the variables and provisions the virtual server. Using the template selected, Orchestration
clones the virtual server, attaches the IP address to the new virtual machine if guest customization is
configured.
• Powers up the virtual server.
• Notifies the requester that the virtual machine has been created successfully.
Approve or reject a VMware request

When a user requests a VM using the service catalog, the workflow creates an approval task in the Service
Desk approval queue of each appropriate group member.
Role required: itil role (in the VMware approvers group) or cloud_admin role (in the Virtual Provisioning
Cloud Administrators group), vmware_operator, admin
If your organization uses manual approvals, a VMware approver must approve the request. After the
catalog request is approved, the system creates a new catalog task. A cloud operator can complete the
catalog task to provision the virtual machine.
1. Navigate to Service Desk > My Approvals or to Service Catalog > Open Records > Tasks.
2. Open the approval request. If your organization has enabled templates to be sourced from target
vCenters, then, in the Provisioning Information section, you can select the Template from the list.
3. Change the state of the request to Approved or Rejected.

After any member of the approval group approves the request, the workflow creates the provisioning
task. The approval request is updated in the queues of other approval group members.
4. In the Description column, click the down-arrow for the VM. The feature summary appears.
Provision a VMware virtual server

The provisioning task is assigned to a member of the VMware Operators group.

Role required: cloud_operator, vmware_operator, itil role (in the VMware approvers group) or cloud_admin
role (in the Virtual Provisioning Cloud Administrators group)
1. Navigate to Service Desk > My Groups Work.
2. Open the provisioning task and then fill in the fields as described in the table. Some information is pre-
populated from the catalog request.
Options Description
Template Select an operating system template to be cloned for this virtual

machine.
Destination folder Each template belongs to a vCenter datacenter, which contains folders
of virtual machines. Select a folder from the datacenter that contains
the provisioned virtual machine. If no folder is selected, the resulting
cloned instance is placed in the folder containing the template that was
used to create the clone.
Clone name Provide the name of the virtual machine as it should appear in VMware
vCenter. This name must be unique on the ESX Server (or the cluster)
on which it is being provisioned.
Cluster Clusters appearing in the list are those from the datacenter in which
the selected destination folder resides. If the virtual machine is not
being attached to a cluster, choose None. In this case, make sure to
select a non-clustered Host.
ESX Host Select the ESX Server on which to deploy the virtual machine. If you
selected None in the Cluster field, only those hosts that are not part of
a cluster are available. If you did select a cluster for this virtual server,
then the available hosts all belong to the selected cluster.
Resource pool Select the ESX resource pool to use for this virtual machine. If a
cluster was chosen, the available resource pools belong to that cluster.
If a host was selected (and no cluster), the available resource pools
belong to the selected host.
Resource pools define the maximum amount of resources that
templates using that pool can consume. An ESX Server property
enables resource pools to expand when necessary if the ESX Server
has additional resources to spare. If you select the Resources pool,
the ESX Server creates a virtual machine for use under a normal load.
Datastore Select the datastore on which to provision the virtual server and
any data disks. To put the virtual server on the datastore where the
template is located, select None. The available datastores are for the
selected host.
Network Select the network that the virtual server will use. Available networks
are those from the datacenter in which the selected destination folder
resides.

Options Description
Guest If guest customizations are configured for this virtual server, select the
customizations appropriate value.
• VM host name: [Required] Name of the server hosting the virtual
machine being provisioned. Check the Notes in the request form
for the name designated by the requester.
• Windows/Linux configuration: [Required] Specifics for
Windows or Linux virtual machines configured in VMware Cloud
Management Instance > Customization Specifications.
Configuration information includes DNS for Linux and the product
key and domain credentials for Windows.
• Network configuration: [Required] Select the network and
the network configuration for the virtual server. The IP address
allocated to the virtual server is selected from a list of available
addresses configured in the network record.
If you choose not to apply guest customizations to the virtual server,

Orchestration provisions the server directly from the template, using
only the configuration available to that template.
Provisioning rules enable an administrator to select which vCenter resources (datacenter, network, and
folder) are used to provision virtual machines for a specific virtual machine category (such as Dev, QA, or
Prod) or for any category if the Category field in the rule is left empty.
Standard tags for VMware VM provisioning

While provisioning VMware VM, the cloud user has five standard tags to set that are stored locally.
The cloud user has five out-of-the-box standard tags to set while requesting a VM instance. These tags are
stored locally and are not pushed to vCenter. The following are the standard tags the user can input on the
VM instance order page:
• User Name (Automatically populated)
• Business Service
• Application
• Project
• Cost Center
After the VM is provisioned, the chosen tags are added.
Complete the provision task for VMware

You can provision a VM from a catalog task.
Role required: cloud_operator
1. Navigate to Service Desk > My Groups Work and select the open catalog task record for the virtual
machine request.


2. Complete all mandatory fields as appropriate for the virtual machine. For more information about this
form, see Provisioning Virtual Servers.
3. Select No from the Guest customization choice list.
View reserved VMware resources

Since Discovery happens at intervals, data on resource size is not always up-to-the-minute. You can view
resources that are currently being requested (Type, Reserved value, and Recently provisioned value)
on the VM Reservations page.
Role required: cloud_operator, vmware_operator, cloud_admin, vmware_operator, admin
Navigate to VMware Cloud > Administration > Reservations.
Table 504: VM Reservations page
Column Description
Resource Name of the requested resource.

Type Type of the requested resource property: CPUs, Memory, or Disk.
For example:
Resource: cluster , Type: Memory
Recently Value that was actually provisioned. This value is cleared after
provisioned value Discovery runs.
Reserved value Value that is being requested.
Monitor capacity usage of VMware clusters

The VM Capacities page displays the cumulative effective CPU, memory, and disk space of ESX hosts in
each cluster.
Role required: cloud_operator, vmware_operator, cloud_admin, vmware_operator, admin
You can view current allocation data on the VM Capacities page at VMware Cloud > Reports > Capacity
Usage.
The VMware: Select cluster assignment assigns the cluster to requested resources. The scripts that
contain the logic to auto-allocate clusters are:
• VMwareClusterMgr manages clusters. The findNextAvailableCluster function returns the
cluster that has the most CPUs among all clusters that meet the criteria based on the base system
cluster capacity checker script include, VMwareClusterCapChecker.
• VMwareClusterCapChecker determines which clusters are available and which cluster among the
available clusters can be overridden in the extension point with the VMWClusterCapCheckerExt key.
Configure VMware overallocation percentages

To use cluster resources more effectively, you can configure overallocation percentages greater than
100% for cluster CPUs and cluster memory provisioning if your organization finds that the actual usage
allocation figures from VMware are significantly overstated.
1. Navigate to VMware Cloud > Administration > Properties.

2. Configure the values for Overallocation percentage for VMware cluster CPUs and Overallocation
percentage for VMware cluster memory. The default values are 100%.
Cloud user actions

Cloud users request and manage VMs.
Note: Some changes to specifications and some state changes might require a change request.
Users with the cloud_user and cloud_admin roles can perform these actions only on virtual machines
assigned to them.
• Request new virtual machines from the service catalog for the virtualization products that your instance
supports (for example, VMware or Azure).
• Modify VM (Azure and VMware only): Request modifications to their virtual machines, such as
increased data disk size and memory or a state change such as start or stop.
• Update the end of the lease
• Pause VM
• Stop / Start VM
• Cancel VM
• Terminate VM
• Take a snapshot and schedule snapshots
• Restore from snapshot
• Delete a snapshot
Viewing and managing your cloud resources

Use the Cloud Resources page to view a summary of your virtualization requests and the status of all
virtual machines requested by all members of your team.
Cloud users can view the virtual machines that they ordered in the Cloud Resources page. Users with
the cloud_operator role can view the virtual servers they administer in the Cloud Operations portal. Open
the records for virtual resources directly from the portals to change instance specifications (CPU count,
memory, or disk size) or the state of the virtual machine. The system notifies users about the status of their
requested changes.
You can make these changes to your virtual servers:
• Modify specifications
• Update the lease
• Stop, Start, and Pause
• Cancel
• Terminate
• Take a snapshot, restore from a snapshot, and delete a snapshot
For all actions that are subject to change control, if change control is enabled, the action is added to
change request page. After the change request is approved, the user must return to the virtual asset page
to click link Proceed with Change under Related Lists.
Cloud Resource Catalog

Use the Cloud Resource Catalog to request virtual machines, Amazon stacks and key pairs, and Microsoft
Azure resource groups.

Requesting an Amazon virtual machine

Use the Cloud Resource Catalog to request an Amazon virtual machine to launch an instance.
1. Navigate to Self-Service > Cloud Resource Catalog and click Amazon Virtual Machines.
2. Click Amazon EC2 Instance - Advanced to request an Amazon virtual machine and fill in the fields,
as appropriate.
Field Description
Cost Center The cost center this request will be billed

against.
Project The project this instance will be billed
against.
Lease
Start The date and time you would like this VM to
be provisioned.

Field Description
End The date and time this VM may be retired

(your lease may be extended later).
Virtual Resource
Business purpose A detailed description of the business
purpose of this virtual machine to
facilitate any necessary approvals and/or
administrative decisions.
Used for Select an appropriate use category to
ensure your VM is provisioned properly for
your needs.
CMDB Attributes
Assignment Group The User Group that will own the
provisioned Configuration Item.
Application The application that will generate a
Used by::Usesrelationship between
the requested virtual machine and the
application.
Business Service The business service that will generate a
Used by::Uses relationship between the
requested virtual machine and the service.
Provisioning information
Account Select the Amazon EC2 account with
which you would like this instance to be
provisioned (determines what regions and
images will be available).
Region The selected region determines which
images will be available. Regions shown
here support the chosen size.
Offering When the Advanced check box is
unchecked, the default offering is set and
the size choices shown are filtered by the
image.
Advanced Check box to display image field.

Image Visible only when the Advanced check box
is checked.
Select the approved EC2 image to be
provisioned for this request. Images listed
are those that have an offering associated
with them. The size can be chosen with no
filtering bound by the image.

Field Description
Size Select the EC2 instance size that best suits

your needs.
Note: Not all sizes are available for

all images
Instance name The Name tag set on EC2 instance.

VPC Select the VPC to be assigned to this
instance being provisioned.
Subnet Select the Subnet to be assigned to this
VPC Security Group Security Group in selected VPC (up to 5
groups).
Requesting an Azure virtual machine

Use the Cloud Resource Catalog to request an Azure virtual machine to launch an instance.
Role required: cloud_user, cloud_operator, cloud_admin
1. Navigate to Self-Service > Cloud Resource Catalog and click Azure Virtual Machines.
2. Click Azure VM Instance - Advanced to request an Azure virtual machine and fill in the fields, as
appropriate.
Field Description
Resource Group
Use existing group Deploy new VM into an existing Resource
Group. If left unchecked, then a new
Resource Group is created.
Subscription Azure subscription for the Resource Group.
Group Name Name of the Resource Group.
Region Azure region where the Resource Group
resides.
Lease
Start Date and time that this VM is to be
provisioned.
End Date and time that this VM is to be retired
(this lease can be extended later).
Virtual Resource
Business purpose Detailed description of the business
purpose of this VM, to facilitate any
necessary approvals and/or administrative
decisions.
Used for Usage category, to ensure that the VM is
provisioned properly for your needs.
CMDB Attributes

Field Description
Assigned To Entity to which this VM is assigned.

Business Service Business service that generates a Used
by::Uses relationship between the
requested VM and the service.
Assignment Group The User Group that owns the provisioned
Configuration Item.
Application Application that generates a Used
requested VM and the application.
Cost Center Cost center to bill for this VM request.
Project Project to bill for this instance.
Location Region in Azure where the VM is to
be provisioned. The selected region
determines the available images. Regions
shown here support the chosen size.
only the available sizes are listed.
Advanced Select to display the list of approved

images. If checked, then the Offering
pulldown above lists only the sizes available
for the default image.
Image Visible only when Advanced is selected.
Select the approved Azure image to be
provisioned for this request. Only images
with associated offerings are listed. The
size can be chosen with no filtering bound
by the image.
VM Parameters
VM Name Name of the virtual machine.

Field Description
Admin Username Admin username for VM. The admin

username has the following requirements:
• For Windows
• The value must be from 1 to 15
characters long.
• The user names administrator,
admin, admin1, admin2, 1, a are
considered as invalid.
• The special characters \, /, " ",
[ ], :, |, +, =, ;, ,, ?, *, @, in the
user name are considered as invalid.
• For Linux
characters long.
[ ], :, |, +, =, ;, ,, ?, *, @, in the
Admin Password Admin password for VM. The admin

password has the following requirements:
• For Windows
characters long.
• Must have at least 3 of the following:
one lower case character, one upper
case character, one number, and one
special character.
• For Linux
characters long.
special character.
VM size Size of the VM.

Field Description
Custom Data Special instructions to pass to Azure for

provisioning purposes. Important: Data
entered here is automatically encoded
in Base-64 prior to sending, so do NOT
enter pre-encoded data or it will be double-
encoded. For more details on acceptable
data and required formatting, refer to
"Injecting custom data into an Azure virtual
machine" in Microsoft Azure documentation.
Storage
Storage Resource Group Azure Resource Group where the VM is to
be placed.
Storage Account Name Unique name for the Storage Account
Attach Additional Data Disks Select to add additional disks.
Number of Data Disks Visible only when Attach Additional Data
Disks is selected. Number of additional
disks for the VM, up to 32. The following
appear and are required when a number
greater than 1 is selected:
• Disk Size GB - Size in GB of every
additional data disk. Maximum is 1023.
• Disk Caching - Type of caching used by
every data disk.
Network
Virtual Network Resource Group Azure Resource Group where this virtual
network is located.
Virtual Network Name Unique name for this virtual network.
Subnet Name Unique name for this subnet.
Options
Need Public IP Select if the VM requires a publicly
accessible IP address.
Use Existing Network Interface Card If not selected, a new NIC is created using
the information entered.
Network Interface Card Visible only when Use Existing Network
Interface Card is selected. List of available
NICs. If Need Public IP is also selected,
then only NICs that have public IP
addresses are listed.
Public IP Address Type Visible only when Need Public IP is
selected and a new NIC is being created.
Private IP Address Type Visible only when Use Existing Network
Interface Card is selected.

Field Description
Private IP Address Visible only when Private IP Address Type

is set to Static.
Public IP Address Name Visible only when Need Public IP is
As used in Microsoft Azure. Auto-generated
if left blank.
Network Interface Card Name Visible only when Use Existing Network
Interface Card is not selected. Name for
the new NIC. Auto-generated if left blank.
Availability
Options
Need Availability Set
3. Click Order Now.

Either the Cloud Resources portal or the Order Status form opens, depending on how the Service
Catalog is configured. The portal shows the various reports associated with the logged-in user's virtual
assets and requests. Click the request item number or expand the Stage column to determine where
the request is in the provisioning process.
4. Upon successful creation of the instance, you receive an email containing the instance ID, IP address,
and the public DNS for the instances created.
If the provisioning request fails for any reason, an incident is automatically created and assigned to the
Cloud Administrators group (if the glide.vm.create_incident system property is enabled).
Requesting a VMware virtual machine

Use the Cloud Resource Catalog to request a VMware virtual machine to launch an instance.
1. Navigate to Self-Service > Cloud Resource Catalog and click VMware Virtual Machines.
2. Click VMware Instance to request a VMware virtual machine and fill in the fields, as appropriate.
Field Description
Lease
be provisioned.
Virtual Resource
your needs.
CMDB Attributes

Field Description

Used by::Uses relationship between
application.
Offering The offering that your administrator has
made available.
Notes Any notes you may have (such as desired
host name) for the IT provisioning team.
Use predefined size Select Yes to accept the default
specifications for the operating system
and size. Select No to define custom
specifications for this virtual machine.
Size Select the predefined VM size that best
suits your needs (some sizes may require
special approval).
Add additional disks Check box to add additional disks.
Number of disks Select the number of disks to add radio
button.
Disk size Specify disk size for all the additional disks.
View the My Team's Virtual Assets portal

Use the My Team's Virtual Assets portal to view VMs that you and your team members have ordered, and
to view current requests for virtual resources.
Role required: Cloud users (members of the Virtual Provisioning Cloud Users group)
Navigate to Self-Service > My Team's Virtual Assets.
Table 505: My Team's Virtual Assets portal
Team Virtual Assets All virtual machines assigned to the logged-

in user.
Team Virtual Resource Metrics Metrics on the team's VMs: total number of
active VMs, scheduled VMs, and VMs that
will expire soon.
VMs By State A chart of the team's VMs, grouped by state,
such as on, off, or paused.
VMs By Type A chart of the team's VMs, grouped by
provider type.

Cloud Resources dashboard

The Cloud Resources dashboard is designed as a one-stop shop for the cloud user to manage all cloud
resources. Cloud users (cloud_user role) can access a role-based graphical view of the cloud resources
assigned to the user or a group the user belongs to. Cloud users can perform life-cycle operations on the
list view.
Navigate to Cloud Management > Cloud Resources . The following tabs appear:

Location, Account and Provider are available,
Compute Detailed list view of the VMs assigned to the

user or one of the user's groups.
Storage Detailed list view of the Volumes assigned to the

user or one of the user's groups.
Stacks Detailed list view of the Stacks and Resource

groups assigned to the user or one of the user's
groups.
Amazon access If the Amazon Web Services plugin is installed,

this tab provides a way for the user to request
AWS console access. Amazon Access also lists
AWS Key-Pair requested by the cloud user.
Note:
If you are seeing a blank page:
You may see a completely blank page on the Cloud Resources portal as a result of a
recent upgrade and subsequent activation of the Cloud management feature. If this
has happened to you, please contact your System Administrator and request that the
glide.cms.enable.responsive_grid_layout system property be enabled for the system. Note that
enabling this property may affect dashboards in other products as well.
Cloud resources portals

The Self-Service and Cloud Management applications provide portals for viewing and managing the
cloud resources that cloud users order and the cloud resources that cloud admins and cloud operators
administer.
• Cloud admins and operators can use the Cloud Operations portal to view a role-based graphical view of
all cloud resources.
• Cloud users can use the Cloud Resources dashboard on page 1213 to access a role-based graphical
view of the cloud resources assigned to the user or a group the user belongs to.

Request and maintain VMs

Requested VMs are subject to normal approvals and some special provisioning tasks. For some providers,
you can create a service catalog request to start, stop, terminate, and extend the lease on a VM.
You can access and manage any of your resources from the My Virtual Assets portal. For example, you
can start or stop a VM, request the termination of a resource, or update the date that a lease should end.
Any VM created from a ServiceNow instance can be destroyed from that instance. This functionality
requires the Orchestration plugin for the provider.
Note: The topics in this section describe VMs, which are based on AWS, Azure, or VMware
images. AWS stacks and Azure Resource groups, in contrast, are collections of related cloud
resources.
Request a VM
You can request a VM from the Cloud Resource Catalog. The cloud admin has approved all of the
options in the catalog. The cloud operator will work to approve your request.
Requested VMs are subject to normal approvals and some special provisioning tasks. Users can make a
service catalog request to terminate a VM. Any VM created from a ServiceNow instance can be destroyed
from that instance.
1. Open the list of VM catalog items: Navigate to Self-Service > Cloud Resource Catalog and
then select your provider; AWS Virtual Machines or Azure Virtual Machines or VMware Virtual
Machines.
2. In the list, click the name of the desired VM template.
Specify settings for the VM.
Note: The number and kinds of settings depend on the template. Here are some common
variables:
Field Description
[Tag settings] Your cloud admin may have configured the system to request
values for tags that are applied to the resource. For example,
when you specify a value of Marketing for the Cost Center
tag, then the system can correctly charge the resource to the
Marketing department. Here are some typical tag names:
• Application
• Cost Center
• Project
• Service
• User Name

Field Description
Lease Start and End Select the start and end times for this virtual machine lease. The
lease start time is set automatically for the current date and time.
In the base system, the lease end time is set to 60 days after the
start time, and the maximum lease duration is limited to 90 days.
The system does not allow requesters to set a lease end time
beyond the configured limit. The lease duration is calculated from
the time the virtual machine is actually provisioned, which occurs
after the request is approved. If you request a virtual machine for
the current date (now), and there is a delay in approval, the end
date is reset according to the configured lease duration time.
Virtual Resource
Size Select the predefined size for this offering that has the desired
features (memory, storage, CPU speed).
Business purpose Enter a brief description of how this virtual server will be used.
Used for Select the purpose of this virtual machine. The categories
in this choice list are found in the Business Service
[cmdb_ci_service] table and also are used to define the
categories in the provisioning rules. The system does not
automatically end the lease for virtual machines marked as
Production. Instead, the system renews the lease on Production
virtual machines automatically for the default lease duration
and sends a notification to the requester each time the lease is
renewed.
CMDB Attributes
Assignment Group The user group that will own the provisioned configuration item.
Business Service Select the business service that depends on this virtual machine.
When Orchestration creates the virtual server, it also creates the
relationships to this business service in the CMDB.
A Used by::Uses relationship between the requested virtual
machine and the service is generated if a business service is
specified.
Cost Center The cost center that this request is billed against.
Application Select the principal application that depends on this virtual
machine, such as an exchange server or SQL Server database.
When Orchestration creates the virtual machine, it also creates
the relationships to this application in the CMDB.
Project The project the instance is billed against.
Size The instance size that best suits your needs. Not all sizes are
available for all images.
Instance name The Name tag set on the instance.
Admin name / Admin Admin user name and password for VM.
password
Computer name Name of computer.
Network Network.

Field Description
Requires public IP Requires public IP address.

address
Storage
Add additional disks Additional disks.
Offering (AWS Cloud only) Select the OS of the VM that you are
requesting.
3. Specify the Quantity of VMs to order and then click Order Now. The system submits your request. If
approval is required, there may be a delay while a cloud operator approves the change.
The view changes either to the My Virtual Assets portal or to the Order Status form, depending on how
the service catalog is configured. The portal shows the various gauges associated with the logged
in user's virtual assets and requests. To view the current request, click the request number in the
My Virtual Asset Requests list or expand the Stage column to determine where the request is in the
provisioning process.
You are notified by email of the results of your request. If the provisioning request fails for any
reason, an incident is automatically created and assigned to the Cloud Administrators group (if the
glide.vm.create_incident system property is enabled).
4. After the request is approved and the VM is provisioned, navigate to My Virtual Assets. Click the new
VM.
Request an Amazon VM
Users requesting an Amazon EC2 instance from the service catalog must have the cloud_user role.
1. Navigate to Self-Service > Cloud Resource Catalog and click Amazon Virtual Machines.
2. Click Amazon EC2 Instance - Advanced to request an Amazon virtual machine and fill in the fields,
as appropriate.
Table 507: Instance Request form
Field Description
Cost Center The cost center this request will be billed

against.
Project The project this instance will be billed
against.
Lease
be provisioned.
Virtual Resource

Field Description

your needs.
CMDB Attributes
Used by::Usesrelationship between
application.
Account Select the Amazon EC2 account with
which you would like this instance to be
provisioned (determines what regions and
images will be available).
Region The selected region determines which
images will be available. Regions shown
here support the chosen size.
the size choices shown are filtered by the
image.
Advanced Check box to display image field.

Image Visible only when the Advanced check box
is checked.
Select the approved EC2 image to be
provisioned for this request. Images listed
are those that have an offering associated
with them. The size can be chosen with no
filtering bound by the image.
Size Select the EC2 instance size that best suits

your needs.
Note: Not all sizes are available for

all images

Field Description
Instance name The Name tag set on EC2 instance. The

instance name is a special tag of the
instance and follows tag requirements:
• Maximum length is 255 characters.
• Do not use aws: as prefix. You can not
edit or delete instance name with this
prefix.
User Data Special instructions to pass to AWS for

encoded. Consult the AWS documentation
website for information on acceptable data
and required formatting.
VPC Select the VPC to be assigned to this
Subnet Select the Subnet to be assigned to this
VPC Security Group Security Group in selected VPC (up to 5
groups).
3. Click Order Now.

Request an Azure VM
Use the Cloud Resource Catalog to request an Azure virtual machine to launch an instance.
Role required: cloud_user, cloud_operator, cloud_admin
1. Navigate to Self-Service > Cloud Resource Catalog and click Azure Virtual Machines.
2. Click Azure VM Instance - Advanced to request an Azure virtual machine and fill in the fields, as
appropriate.
Field Description
Resource Group
Use existing group Deploy new VM into an existing Resource
Group. If left unchecked, then a new
Resource Group is created.
Subscription Azure subscription for the Resource Group.

Field Description
Group Name Name of the Resource Group.

Region Azure region where the Resource Group
resides.
Lease
Start Date and time that this VM is to be
provisioned.
End Date and time that this VM is to be retired
(this lease can be extended later).
Virtual Resource
Business purpose Detailed description of the business
purpose of this VM, to facilitate any
necessary approvals and/or administrative
decisions.
Used for Usage category, to ensure that the VM is
provisioned properly for your needs.
CMDB Attributes
Business Service Business service that generates a Used
requested VM and the service.
Assignment Group The User Group that owns the provisioned
Configuration Item.
Application Application that generates a Used
requested VM and the application.
Cost Center Cost center to bill for this VM request.
Project Project to bill for this instance.
Location Region in Azure where the VM is to
be provisioned. The selected region
determines the available images. Regions
shown here support the chosen size.
only the available sizes are listed.
Advanced Select to display the list of approved

images. If checked, then the Offering
pulldown above lists only the sizes available
for the default image.

Field Description
Image Visible only when Advanced is selected.

Select the approved Azure image to be
provisioned for this request. Only images
with associated offerings are listed. The
size can be chosen with no filtering bound
by the image.
VM Parameters
VM Name Name of the virtual machine.
Admin Username Admin username for VM. The admin
username has the following requirements:
• For Windows
characters long.
[ ], :, |, +, =, ;, ,, ?, *, @, in the
• For Linux
characters long.
[ ], :, |, +, =, ;, ,, ?, *, @, in the

Field Description
Admin Password Admin password for VM. The admin

password has the following requirements:
• For Windows
characters long.
special character.
• For Linux
characters long.
special character.
VM size Size of the VM.

Custom Data Special instructions to pass to Azure for
encoded. For more details on acceptable
data and required formatting, refer to
"Injecting custom data into an Azure virtual
machine" in Microsoft Azure documentation.
Storage
Storage Resource Group Azure Resource Group where the VM is to
be placed.
Storage Account Name Unique name for the Storage Account
Attach Additional Data Disks Select to add additional disks.
Number of Data Disks Visible only when Attach Additional Data
Disks is selected. Number of additional
disks for the VM, up to 32. The following
appear and are required when a number
greater than 1 is selected:
• Disk Size GB - Size in GB of every
additional data disk. Maximum is 1023.
• Disk Caching - Type of caching used by
every data disk.
Network
Virtual Network Resource Group Azure Resource Group where this virtual
network is located.

Field Description
Virtual Network Name Unique name for this virtual network.

Subnet Name Unique name for this subnet.
Options
Need Public IP Select if the VM requires a publicly
accessible IP address.
Use Existing Network Interface Card If not selected, a new NIC is created using
the information entered.
Network Interface Card Visible only when Use Existing Network
Interface Card is selected. List of available
NICs. If Need Public IP is also selected,
then only NICs that have public IP
addresses are listed.
Public IP Address Type Visible only when Need Public IP is
Private IP Address Type Visible only when Use Existing Network
Interface Card is selected.
Private IP Address Visible only when Private IP Address Type
is set to Static.
Public IP Address Name Visible only when Need Public IP is
As used in Microsoft Azure. Auto-generated
if left blank.
Network Interface Card Name Visible only when Use Existing Network
Interface Card is not selected. Name for
the new NIC. Auto-generated if left blank.
Availability
Options
Need Availability Set
3. Click Order Now.

Request and maintain VMware VMs

You can request an instance, receive notifications, and add or remove network adapters.
Open the Cloud Resource Catalog to request and maintain a VMware VM.

Notifications on status of requests and states of resources

The system notifies users of status changes to their cloud resources and acknowledges requests for cloud
resources.
Notifications can contain specifics of the action taken, the date, modifications made, and success/failure
information. Notifications include a link to the request or to the CI record for the virtual machine.
The system sends an email to a requester and asset owner in the following cases:
• Requested: A user requests a cloud resource. Subject: Request <number> has been opened on your
behalf.
• Approved: A user's request for a cloud resource is approved. Subject: Your request <number> has
been approved.

• Rejected: A user's request for a cloud resource was not approved. Subject: Your requested item
<number> for <VM type> has been rejected.
• Scheduled: The requested instance is scheduled for creation. Subject: <VM type> instance <name>
has been successfully scheduled.
• Provisioned: A user's cloud resource was successfully provisioned and is ready for use. Subject: <VM
type> instance <name> has been successfully provisioned.
• Modified: Applies to VMware only. A user's VM configuration (such as memory allocation or storage
capacity) was modified. Subject: The configuration of VMware instance <name> has been successfully
updated.
• Extended: The lease end date for a cloud resource was extended. Subject: The lease end of virtual
instance <name> has been successfully updated.
• About to expire: The lease on a user's cloud resource expires in n days. The default lead time in the
base system is one day. Subject: Virtual instance <name> will be terminated in <n> days.
• Terminated: The lease for a user's cloud resource has expired, and the resource was terminated.
Subject: VMware instance <name> has been successfully terminated.
Request a VMware instance

Users requesting a VMware instance from the service catalog must have the cloud_user role.
1. Navigate to Self-Service > Cloud Resource Catalog > VMware Virtual Machines.
2. Click VMware Instance to request a VMware virtual machine and fill in the fields, as appropriate.
The VMware Instance request form appears. By default the Quantity field does not appear on the
service catalog form for VMware instances. The system does not support ordering multiple VMware
instances in a single catalog request.
3. In the Catalog Item form for this virtual server, complete the following fields:
Field Description
Lease
be provisioned.
Virtual Resource
your needs.
CMDB Attributes
Used by::Uses relationship between
application.

Field Description

Offering The offering that your administrator has
made available.
Notes Any notes you may have (such as desired
host name) for the IT provisioning team.
Size Select the predefined VM size that best suits
your needs (some sizes may require special
approval).
Add additional disks Check box to add additional disks.
Number of disks Select the number of disks to add radio
button.
Disk size Specify disk size for all the additional disks.
4. Click Order Now.

Add a network adapter to a VMware VM

You can add a network adapter to a VM at any time.
Role required: cloud_user or cloud_admin
1. Navigate to My Virtual Assets and then click either My Virtual Assets or My VMware Assets.
2. In the list, click the VM name.
3. Verify that the VM is in the On, Off, or Paused state. If not, then click the Stop VM or Start VM or
Pause VM related link as needed. Proceed when the State of the VM is On, Off, or Paused.
4. Click the Add Network Adapter related link, specify the following settings, and then click OK.
Option Description
Adapter type Type of network adapter to add.

Network Network to connect the adapter to.

Option Description
Connect at power-on Select the check box to connect the network

adapter to the VM when the VM is powered on.
Clear the check box to leave the network adapter
in a not-connected state.
Note: If the VM is under change control (default setting and typically the case for production
systems), the system generates a change request when you submit the request. You receive
email when the cloud operator approves. After approval, return to the VM Instance form and
click the Proceed with Change related link.
After the network adapter is added, the system adds a network adapter record to a related list on the
VM record.
Remove a network adapter from a VMware VM

You can remove a network adapter from a VM at any time.
1. Navigate to My Virtual Assets and then click either My Virtual Assets or My VMware Assets.
2. In the list, click the VM name.
3. Verify that the VM is in the On, Off, or Paused state. If not, then click the Stop VM or Start VM or
Pause VM related link as needed. Proceed when the State of the VM is On, Off, or Paused.
4. Click the Remove Network Adapter related link, specify the name of the adapter, and then click OK.
Note: If the VM is under change control (default setting and typically the case for production
systems), the system generates a change request when you submit the request. You receive
email when the cloud operator approves. After approval, return to the VM Instance form and
When the network adapter is removed, the system removes the network adapter record from the
related list on the VM record.
VM operations
To make a change to an existing VM, select an action from a context menu or use the Related Links in the
VM record.
• Context menu: The list view displays all the virtual servers you or your teams requested through the
service catalog. Machines in all states appear on the list, including those that are terminated or have
been deleted. The state of the virtual machines is shown in the list, as are the Lease start and Lease
end times for each virtual machine. List editing is not enabled for lease times. To initiate a change from
the list of virtual machines, right-click an instance and select VM Management from the context menu.
Only the actions that are appropriate for the State of the virtual machine are available.

Figure 204: VM Portal View context menu
• Related Links: Open the virtual machine instance record and select an action from the Related Links.
The controls that appear depend on the State of the virtual machine.

Figure 205: Team Services form

Stop or start a VM
Cloud users can power-off and power-on their assigned VMs. Cloud admins and operators can perform the
actions on any VM.
Restrictions:
• Only a resource that was successfully provisioned can be started or stopped.
• The link that appears depends on the State of the virtual machine (On/Stop or Off/Start).
If the start or stop action is subject to change control, a pop-up window asks whether to proceed.
Compute tab.
3. lick Stop or Start related link.
Option Description
Stop Stops the VM and deallocates any associated

NIC. When the operation finishes, the VM is no
longer running and the account will not be billed
for its usage.
If the VM is under change control (as is typically
the case for production systems), the system
generates a change request. Click OK to stop the
VM.
Start Starts the VM. When the operation finishes, the

VM is running and billing starts.
If the VM is subject to change control (as is typically the case for production systems), the system
generates a change request. There may be a delay while an admin approves the change. You receive
email when the admin approves. After the admin approves, return to the VM Instance form and click
the Proceed with Change related link.
Virtual server termination

You can request the termination of a running VMware instance provisioned for you at any time during the
lease by using the My Virtual Assets portal in the service catalog.
You can request the termination of a running VMware instance provisioned for you at any time during the
lease from the Cloud Resources page. When the virtual machine reaches the end of its lease or grace
period, the system automatically terminates the instance without notice. Virtual machines marked with
a Used for value of Production do not automatically expire. You must manually terminate these virtual
machines.
Subscribe to notifications for a VM
You can subscribe to a VM to receive all notifications for the resource.
Compute tab.
3. lick Subscribe related link.
You are immediately subscribed to receive all notifications for the resource.

Update the end of the lease for a VM

When a VM reaches the end of its lease or its grace period, the system terminates the resource and
notifies the user. As a cloud user, you can request an extension or shortening of a lease for any of your
virtual resources.
Compute tab.
3. Click Update Lease End in the Related Links section.
4. Use the calendar to set a new date and time for the lease to expire. Click Update.
The system submits your request.
5. If approval is not required, the lease is immediately updated. If approval is required, there may be a
delay while an admin approves the change. You receive email when the admin approves. After the
admin approves, return to the VM Instance form and click the Proceed with Change related link.
State changes for VMs

The services portal for VMs enables an administrator to change machine states if the changes are
permitted by the VM providers.
The table lists possible states for VMs and the change controls that are available for each state.
Table 509: State Changes
State Controls
On • Modify VM
• Stop VM
• Pause VM (VMware)
• Terminate VM
Off • Modify VM
• Start VM
• Terminate VM
Paused • Modify VM
• Start VM
• Terminate VM
Scheduled • Modify VM
• Cancel VM
Starting No changes are permitted when a VM is in transition between states

Stopping No changes are permitted when a VM is in transition between states
Terminated No state changes are possible

State Controls
Error • Terminate
Canceled No state changes are possible

Pausing No changes are permitted when a VM is in transition between states
Terminating No changes are permitted when a VM is in transition between states
Take a snapshot (on-demand)

An Azure snapshot is a read-only copy of a specified virtual hard disk (VHD). In addition to taking a
snapshot on demand, you can schedule snapshots.
Note: The system auto-deletes the oldest snapshot when the Snapshot eviction policy limit is
exceeded. See Configure snapshots to execute on a schedule on page 1231.
Compute tab.
3. lick Take Snapshot related link.
Table 510: Take Snapshot
Field Description
Name Name that will be used as the label for the

snapshot.
Short description Single sentence or phrase that describes
the snapshot.
Virtual hard disk Select the VHD to take a snapshot of.
4. Click OK.
Note: If the VM is running, the VM is shut down at the start of the snapshot process and then
restarted when the process finishes.
If approval is not required, the system immediately takes the snapshot. If approval is required, there
may be a delay while an admin approves the change. You receive email when the admin approves.
After the admin approves, return to the VM Instance form and click the Proceed with Change related
link.
Configure snapshots to execute on a schedule

An Azure snapshot is a read-only copy of a specified virtual hard disk (VHD). You can schedule snapshots
to ensure that you regularly make a copy of a virtual resource so you can recover from errors.

If the VM is running at the start of the snapshot process, the VM is shut down and then restarted when the
process finishes.
Compute tab.
3. lick Schedule Snapshot related link.
Table 511: Take Snapshot form
Field Description
Name Name for the scheduled snapshot job that

you are configuring.
Active Select the check box to cause the
scheduled snapshot job to run on the
specified schedule.
Run Schedule to follow to run the scheduled
snapshot job.
Application Read-only. Application scope that the
eviction policy was created in.
Conditional Select the check box to specify the
conditions that must be met to take a
snapshot. When you check the box, the
system opens a standard condition builder.
Snapshot limit Maximum number of snapshots that are
saved for VMs that meet the specified
conditions. The system runs the eviction
policy script to delete a snapshot.
• When the Limit value is reached, the
scheduled job attempts to delete the
oldest snapshot before it creates a new
snapshot.
• The scheduled snapshot job will not
delete a snapshot that was created by an
on-demand request.
• On the first run of the scheduled job, if
the total number of snapshots for the
VM is equal to the global limit, then the
job deletes the oldest snapshot before it
creates a new snapshot.
Snapshot name Unique name that will be used as the label

for the snapshots. The system appends
timestamp text.
Snapshot short description Single sentence or phrase that describes
this snapshot.
VM instance Virtual machine that is associated with the
VHD to take a snapshot of.
Volume Virtual hard disk to take a snapshot of.

Field Description
Snapshot eviction policy Name of the script to run when deleting a

snapshot.
Send success notification Select the check box to send an email when
the snapshot is successfully created. See
Recipient's email.
Recipient's email Email address to send the success
notification to. See Send success
notification.
Skip next run Select the check box to skip the first
scheduled snapshot.
This is useful when you create a recurring
time that will occur too soon to be useful.
For example, if you create the schedule at
noon on a Monday and the snapshot recurs
each Monday at 5:00 PM, then check the
box to skip the first snapshot (5 hours after
you create the schedule). Instead, the first
snapshot will run next Monday at 5:00 PM.
If approval is not required, the system immediately takes the snapshot. If approval is required, there
may be a delay while an admin approves the change. You receive email when the admin approves.
After the admin approves, return to the VM Instance form and click the Proceed with Change related
link.
Restore a resource from a snapshot

A snapshot is a complete copy of VHD. To restore a VHD to an earlier state, you can write a snapshot over
the current state of the VHD.
Compute tab.
3. lick Restore From Snapshot related link.
4. If the resource Used for setting is Production, then the system creates a change request that must
overwrites the VHD with the snapshot. If approval is required, there may be a delay while an admin
approves the change. You receive email when the admin approves. After the admin approves, return
to the VM Instance form and click the Proceed with Change related link.
Delete a snapshot
You can delete a snapshot to free up disk space.
Role required: cloud_user, cloud_admin
Note: The system auto-deletes the oldest snapshot when the Snapshot eviction policy limit is
exceeded. See Configure snapshots to execute on a schedule on page 1231.
Compute tab.

2. In the Virtual Assets that I manage report, select a virtual resource.

3. Under Related Links, click Delete a Snapshot.
A dialog box lists the current snapshots and indicates whether change control applies.
4. Select the snapshot and click OK.
If change control is not enabled, the snapshot is immediately deleted. If change control is enabled, the
snapshot is deleted after approval.
Modify an existing cloud resource

You can update an existing resource to have a different size. The update changes the allocated disk
space, memory, and CPU.
Compute tab.
3. lick Modify VM related link.
4. If the resource Used for setting is Production, then the system creates a change request that must
be approved by a cloud operator or cloud admin. If approval is not required, the lease is immediately
updated. If approval is required, there may be a delay while an admin approves the change. You
receive email when the admin approves. After the admin approves, return to the VM Instance form and
Terminate a cloud resource

A cloud admin can configure the system to generate a change request whenever a user requests the early
termination of a resource. When an instance reaches the end of its lease (or its grace period), the system
auto-terminates the resource and notifies the user.
Role required: cloud_user who owns the VM, cloud operator, or cloud_admin
Caution: Termination deletes the resource and all associated data. You cannot restart a
terminated resource. Be sure to capture all needed data before terminating.
Compute tab.
3. lick Terminate VM related link.
If the resource Used for setting is Production, then the system creates a change request that must
terminates the VM. If approval is required, there may be a delay while an admin approves the change.
You receive email when the admin approves. After the admin approves, return to the VM Instance
form and click the Proceed with Change related link.
The State of the VM becomes Terminated and the VM will no longer be visible in the My Virtual
Assets portal.
Important: AWS: The system does not delete volumes for terminated resources. Use the
AWS console to delete volumes.
Extension point format:
// To run customer workflow, replace the following code

// with pushing a subflow to workflow.scratchpad.after_subflows
which

// needs to have properties for wfname and inputs
var subflow = {};

subflow.wfname = 'After Deprovision WF';
subflow.inputs = { 'u_sys_id': '' + current.sys_id };
workflow.scratchpad.after_subflows.push(subflow);
Any script or logic can be invoked. You can also populate any custom workflows to
execute before the termination or after the termination.
Add all workflows to the workflow.scratchpad.before_subflows or
workflow.scratchpad.after_subflows variables in the appropriate extension
points. A return value of successindicates if the extension point was successful or not.
The termination workflows run the custom deprovision workflows one at a time and if any
of them have errors, a task is created for the operator to manually resolve, and either
proceed with termination if Before Deprovision fails, or just exit the termination workflow
if After Deprovision fails.
View a cloud resource in the BSM map

The Discovery workflow discovers all virtual resources. You can view virtual resources in the CMDB
Business Service Management Map (BSM map) as a network of related resources.
Compute tab.
2. lick VM name.
The VM’s relationships to other CIs appears in the Related Items section. The view includes Business
Services and Applications referenced by tags on the VM or its parent resource group.
3.
Click the BSM icon.
The BSM map appears in a separate window.
Request and maintain a cloud application

Request and maintain AWS CloudFormation stacks and Azure resource groups.
• AWS CloudFormation
• To request an AWS stack, navigate to Self-Service > Cloud Resource Catalog.
• To manage an AWS stack, navigate to Amazon AWS Cloud > Managed Resources > Stacksand
• Azure resource groups

• To request an Azure resource group, navigate to Self-Service > Cloud Resource Catalog.
• To manage Azure resource groups, navigate to Microsoft Azure Cloud > Managed Resources >
Resource Group Instances
Request and maintain AWS CloudFormation stacks

Users with the cloud_user role can request an Amazon Web Services (AWS) CloudFormation
configuration, also called a stack, from the service catalog.
Role required:

• For their personal cloud resources, cloud_user users can manage some settings directly and must
change other settings by making a request to the cloud_operator.
• cloud_admin users have management access to all cloud resources
Requested stacks are subject to normal approvals and some special provisioning tasks.
1. Navigate to Self-Service > Cloud Resource Catalog.
2. The CloudFormation stack request form appears. Complete the following fields:
Table 512: Fields in CloudFormation Stack Request Form
Field Description
Assignment Group Select the user group that will own the
stack.
Business purpose Enter a brief description of how this stack
will be used.
Start and End Select the start and end times for this
stack lease. The lease start time is set
automatically for the current date and time.
In the base system, the lease end time
is set to 60 days after the start time, and
the maximum lease duration is limited
to 90 days. The system does not allow
requesters to set a lease end time beyond
the configured limit. The lease duration is
calculated from the time the stack is actually
provisioned, which occurs after the request
is approved. If you request a stack for now
(the current date), and there is a delay in
approval, the end date is reset according to
the configured lease duration time.
Business Service Name a business service that depends on
this stack.
Application [Optional] Name the principal application
that depends on this stack, such as
an exchange server or an SQL Server
database.
Account Select the AWS account that the stack
belongs to. If the account is already
selected, then this field will be read-only.
Used for Select the purpose of the stack (such as
Development or Training). the ServiceNow
instance does not automatically end the
lease for a stack marked as Production.
Instead, the instance renews the lease
on Production stacks automatically for
the default lease duration and sends a
notification to the requester each time the
lease is updated.
Stack Name Enter the name for the stack.

Field Description
Template Parameters Enter values for stack template parameter

variables.
Cost Center Enter the cost center that this request will be
billed against.
Project Enter the project that this request will be
billed against.
3. Click Order Now to order the CloudFormation stack.

Your view changes either to the My Virtual Assets portal or to the Order Status form, depending
on how the Service Catalog is configured. The portal shows the various gauges associated with
the logged-in user's virtual assets and requests. To view the current request, click the request item
number in the My Virtual Asset Requests list or expand the Stage column to determine where the
request is in the provisioning process.
4. Bookmark this page and return to it to track the status of this request.
Upon successful creation of the stack, you receive an email containing the ServiceNow instance ID, IP
address, and the public DNS for the ServiceNow instances created. If the provisioning request fails for
any reason, an incident is automatically created and assigned to the Cloud Administrators group (if the
View a CloudFormation stack

You can view a CloudFormation stack that belongs to an AWS account using the Stack Resources tab, or
as part of a dependency views map.
Role required:
To view a stack using the Stack Resources tab:

1. Navigate to Amazon AWS Cloud > Managed Resources > Stacks.
2. Click a stack.
3. Click the Stack Resources related list.
The AWS CloudFormation stack resources are listed.
Table 513: Discovered data
Field Description
Name Name of the resource.

Resource Generic resource record for this resource.
Resource Status Status of the resource.
Resource ID Resource ID of the resource.
Correlation ID Correlation ID of the resource.
A user with the Cloud Operator role can view the CloudFormation stack in the CMDB Business Service
Management Map (BSM) as a network of related resources.

Update a CloudFormation stack

You can update a stack by creating a change request once the stack has been successfully requested and
created.
Role required:
When you initiate and save a change request, the stack template body and parameters are copied over
and a new template is created containing the changes. Parameters that are no longer used in the updated
template are deleted and any new parameters are created. Any default values for the new parameters are
copied to the template parameter value table.
Users with the cloud_admin, cloud_user or cloudformation_operator roles can update stacks. Users with
the cloud_user can update only the stacks that they own.
1. Navigate to Amazon AWS Cloud > Managed Resources > Stacksand select a stack.
2. Click Create New Update Change Record.
If a draft change already exists for the stack, click Modify Update Change Draft to update the
change.
3. Modify the template body and template parameter values.
The Phase field indicates the state of the change request. Possible values are draft, requested, in-
progress, approved, rejected, published, and error.
4. Click Validate Stack Change to validate template body changes.
5. Click Validate Parameter Values to validate template parameters changes.
Any error messages appear at the top of the form.
6. Click Request Stack Change to submit the workflow.
7. Click OK.
If the stack change is under change control, you are redirected to a change request page that shows
the change request that was submitted.
If the stack change is not under change control, the update workflow is triggered.
8. After the change request is approved, log in to your instance again.
9. Navigate to your stack and click Proceed with Change to trigger the update workflow.
When the change workflow is completed, the system sends a "stack change success" email to the
user and updates the stack status, output, tags, parameters, template, and other information.
Note: After a change definition has been submitted, you cannot modify the stack until the change
is canceled or the change workflow has been completed. You must create a new change definition
to make an additional change.
Terminate a CloudFormation stack

By default, when an instance reaches the end of its lease (or its grace period), Cloud Management
terminates the stack and notifies the user. You can, instead, request the termination of a CloudFormation
stack that is running.
Role required:

A cloud administrator can configure the system to generate a change request whenever a user requests
the early termination of a stack.
1. Navigate to Amazon AWS Cloud > Managed Resources > Stacksand select a stack.
2. Select a CloudFormation stack to terminate. You can terminate a stack in any of the following states:
• Create Complete
• Rollback Complete
• Rollback Failed
Note: You cannot terminate a stack if there is an open change request (stopping, pausing,
and so on).
3. Under Related Links, click Terminate Stack.

If this action is subject to change control, a pop-up window advises you that change control is required
and asks whether to proceed. For stacks that are not subject to change control, the termination
workflow is triggered immediately.
When the stack has been terminated, the following information appears:
• Stack Status - Delete Complete
• Install Status - Retired
• State - Non-Operational
If stack termination failed, the following information appears:

• Stack Status - Delete Failed
• Install Status - Pending Repair
• State - Non-Operational
View a CloudFormation stack in a Dependency Views map

The Discovery workflow discovers the stack and lists the stack resources. When the Discovery workflow
finishes, you can view the CloudFormation stack in a Dependency Views map as a network of related
resources.
Role required:
The system creates skeleton records for the resources are added and CMDB CI relationships to verify the
correlation of the stack resources.
1. Navigate to Amazon AWS Cloud > Managed Resources > Stacks and select a stack.
2. Click the Dependency Views icon.
The Dependency Views map appears in a separate window.
Discovery workflows are supported for the following CloudFormation stack resources types:
• AWS::EC2::VPC - The VPC discovered information includes VPC ID, VPC name (name tag), region,
Classless Inter-Domain Routing (CIDR) block information, the Dynamic Host Configuration Protocol
(DHCP) ID, the instance tenancy attribute (dedicated/default), VPC state, and the is default attribute of
the VPC.
• AWS::EC2::Subnet - The discovered subnet information includes Subnet ID, VPC ID, Subnet name
(name tag), region, Classless Inter-Domain Routing (CIDR) block information, the available IP address

count, is default for region attribute, the map public IP on launch attribute, Subnet state, and the is
default attribute of the subnet.
• AWS::ElasticLoadBalancing::LoadBalancer - The discovered load balancer information includes name,

DNS name, Canonical Hosted Zone name, Canonical Hosted Zone name id, Load balancer created
time, Scheme, Security groups, Source security groups, VPC, Subnet, Instances, Listeners, Backend
server, policies, and availability zones for the load balancer.
• AWS::AutoScaling::AutoScalingGroup - The discovered auto scaling group information includes name,

resource name, created time, default cool-down, desired capacity, health check grace period, health
check type, launch configurations, load balancers, maximum size, minimum size, status, termination
policies, VPC zone identifiers, and availability zones.
Request and maintain Azure resource groups

As a cloud user, you can request and manage Azure resource groups from the My Virtual Assets portal.
For example, you can use the draft deployment feature to make updates, request the termination of a
resource group, or change the date that a lease should end.
Role required:
• Users with the cloud_user role have management access to their personal cloud resources
• Users with the cloud_admin role have management access to all cloud resources
The topics in this section describe resource groups -- collections of resources -- not individual VMs.
An Azure Resource Group is a collection of resources (Infrastructure, Networking, Managed Services, and
their access control policies) that you manage as a single unit. The collection can be a database server, a
database, a website and the subnets they reside in.
When you want to deploy, manage, test, and monitor them as a group, you define them within an Azure
Resource Manager (ARM) template(s) and manage them as a single resource group. ARM templates are
declarative JSON schemas that define your deployment or changes to your deployment within a resource
group. You can read more about resource groups on Microsoft's website: https://azure.microsoft.com/en-
us/documentation/articles
Request an Azure resource group
Resource groups are based on ARM templates that an admin configured and approved to be included in
the catalog.
1. Navigate to Self-Service > Cloud Resource Catalog and click Azure Resource Groups.
2. In the list, click the template for the resource group to request.
Specify settings for the resource group. The number and kinds of settings depend on the template.
Here are some common variables:
Table 514: Azure Template form
Field Description
Business purpose Enter a brief description of how this virtual

server will be used.

Field Description
Start and End Select the start and end times for this virtual
machine lease. The lease start time is
set automatically for the current date and
time. In the base system, the lease end
time is set to 60 days after the start time,
and the maximum lease duration is limited
to 90 days. The system does not allow
requesters to set a lease end time beyond
the configured limit. The lease duration is
calculated from the time the virtual machine
is actually provisioned, which occurs after
the request is approved. If you request a
virtual machine for now (the current date),
and there is a delay in approval, the end
date is reset according to the configured
lease duration time.
Business Service Select the business service that depends
on this virtual machine. When Orchestration
creates the virtual server, it also creates the
relationships to this business service in the
CMDB.
Application Select the principal application that
depends on this virtual machine, such as an
exchange server or SQL Server database.
When Orchestration creates the virtual
machine, it also creates the relationships to
this application in the CMDB.
Used for Select the purpose of this virtual
machine. The categories in this choice
list are found in the Business Service
[cmdb_ci_service] table and also
are used to define the categories in the
provisioning rules. The system does not
automatically end the lease for virtual
machines marked as Production. Instead,
the system renews the lease on Production
virtual machines automatically for the default
lease duration and sends a notification
to the requester each time the lease is
renewed.
Offering Select the offering—such as the operating
system, database server, or web server—for
the virtual machine you are requesting.
Size Select the predefined size for this offering
that has the desired features (memory,
storage, CPU speed).

Field Description
Notes Add any information that should be known

for provisioning, such as the virtual machine
network name.
3. Specify the Quantity of VMs to order and then click Order Now. The system submits your request. If
approval is required, there may be a delay while an admin approves the change.
The view changes either to the My Virtual Assets portal or to the Order Status form, depending on
how the service catalog is configured. The portal shows the various reports associated with the logged
in user's virtual assets and requests. To view the current request, click the request number in the
My Virtual Asset Requests list or expand the Stage column to determine where the request is in the
provisioning process.
4. After the request is approved and the VM is provisioned, navigate to My Virtual Assets. Click the new
VM.
5. On the VM Instance form, click the Proceed with Change related link.
You are notified by email of the results of your request. If the provisioning request fails for any
reason, an incident is automatically created and assigned to the Cloud Administrators group (if the
Update the end of the lease for an AWS stack or Azure resource group
When a resource group or stack reaches the end of its lease (or its grace period), the system terminates
the resources and notifies the user. As a cloud user, you can extend or shorten a lease for any of your
cloud resources.
1. Open the list of stacks or resource groups and then select one:
• Amazon AWS Cloud > Managed Resources > Stacks.
• Microsoft Azure Cloud > Managed Resources > Resource Group Instances.
2. Click the Update Lease End related link.

3. Use the calendar to set a new date and time for the lease to expire. Click Update.
The system submits your request.
4. If approval is not required, the lease is immediately updated. If approval is required, there may be a
delay while an admin approves the change. You receive email when the admin approves. After the
admin approves, return to the VM Instance form and click the Proceed with Change related link.
Update a deployed AWS stack or Azure resource group

To update a deployment of a stack or resource group, create a temporary draft copy of the template that
was used as the basis for the stack or resource group, modify the draft, and then apply the draft version of
the template to the stack or resource group.
2. Click the Create Draft Deployment related link. The State for the deployment changes to Draft.
Important: Any changes that you make on the form are applied to the draft and are not yet
applied to the deployed resource group.

3. Make the changes to settings. When you have validated the changes, return to the stack or resource
group form and perform one of the following actions:
Option Action
Submit the request to update the item with the Click the Implement Draft Deployment related
draft deployment that you configured on this link
form.
Save the draft deployment that you Click Update.
configured on this form for use at another
time.
Discard the draft deployment that you Click Delete.
configured on this form
The system processes your request for changes to the stack or resource group.
Terminate a stack or resource group

When you request early termination, the system may generate a change request. Cloud administrators
configure whether the system generates change requests for the terminate action.
Role required: cloud_user, cloud operator, or cloud_admin
Note: Terminating a stack or resource group results in the loss of all data and configuration that
is associated with the affected resources. Before terminating, be sure to back up any data that you
want to keep.
1. Open the list of stacks or resource groups:

• Microsoft Azure Cloud > Managed Resources > Resource Groups.
2. Select the stack or resource group to terminate. You can terminate a stack or resource group with
Resource Group status of Succeeded.
Note: You cannot terminate a stack or resource group that has an open change request
(Update in progress, Delete in progress, and so on).
3. Click the Terminate Stack or Terminate Resource Group related link.

If the action is subject to change control, a pop-up window advises you that change control is required
and asks whether to proceed. If the action is not subject to change control, the system immediately
triggers the termination workflow.
The following information appears when the stack or resource group has been terminated:
• Resource Group Status - Deleted
• Status - Retired
The following information appears when termination fails:

• Resource Group Status - Delete Failed
• Status - Pending Repair
Subscribe to notifications for a stack or resource group

You can subscribe to a stack or resource group to receive notifications for resources.
Role required: cloud_user, cloud operator, or cloud_admin


2. Click the Subscribe related link.

You are immediately subscribed to receive all notifications for the resource.
Assign resources to users from a multiple-items request

Multiple items in a single cart can be assigned to different users for cloud resource provisioning when the
two-step checkout process is not enabled. Affected users receive an email notification upon completion.
To assign resources to different users when creating a single request with multiple items, two-step
checkout cannot be enabled. Standard behavior when multiple items are ordered in a single cart is to allow
each requested item to be assigned to a different user, using the new variable assigned_to for each
item. If the assigned-to user is left blank, then the value in the opened-by user field is used.
Two-step checkout is not enabled by default. If the user chooses to enable two-step checkout, then all
items in the request are assigned to a single user and the new variable is ignored.
An email notification is sent to the assigned-to or opened-by user upon completion of the order, whether it
was successful or not. For security purposes, notifications for EC2 key pairs are sent only to the assigned-
to user. The following extension points support modification of email message and email recipients.
CMP provider extension points
• AWS Instance - AfterSchedule

• AWS Instance - SetErrorNotification
• AWS Instance - SetSuccessNotification
• AWS Stack - SetSuccessNotification
• AWS Stack - SetErrorNotification
• AWS Stack - AfterSchedule
VM extension points
• CloudFormationSetErrorNotification
• CloudFormationSetSuccessNotification
• CloudFormationAfterSchedule
• EC2SetErrorNotification
• EC2SetSuccessNotification
• EC2AfterSchedule
• AzureTemplateSetErrorNotification
• AzureTemplateSetSuccessNotification
• AzureTemplateAfterSchedule
• AzureVMAfterSchedule
Cloud Management reports

The ServiceNow Cloud Management application generates reports that you can customize in ways that
are not available in the default provider environment. You can filter the data that is displayed in the reports

and can associate custom tags with resources. Tags enable you to analyze the data using criteria that you
specify.
View Cost and Usage reports for all providers

The Cloud Management application displays a cost and usage overview report covering all providers. The
report can be grouped or filtered by provider, category, or tag.
Role required: cloud_operator or cloud_admin can set filters, run, and view reports
The default dashboard includes several reports including trend or aggregate data on cost and usage.
Report Description
Cost Report Shows totals and trends for the billed cost across
all categories.
Compute Usage Shows totals and trends of VM instance usage
(instance hours).
Network Usage Shows totals and trends of network usage, both
incoming and outgoing (GB transferred).
Storage Usage Shows totals and trends of storage capacity utilized
(GB hours).
Costs Shows Performance Analytics indicators and
breakdowns tracking cost.
This report is only available with the Performance
Analytics plugin.
Usage Monitor Shows Performance Analytics indicators and

breakdowns tracking usage.
Analytics plugin.
Quarter Scores Shows Performance Analytics quarterly totals

across categories.
Analytics plugin.
1. For all providers, navigate to Cloud Management > Reports > Cost & Usage Reports.
2. To refine the output, modify the data filters to specify how to select, group, and display the data.
• Filters include time range, cloud provider (Amazon, Azure, or all), account (subscription name
from Azure, or linked account ID from Amazon), region, application, business service, cost center,
project, and user name.
• Grouping includes category, provider, account, application, business service, cost center, project,
region, and user name.
Generate a Resource Optimization report

Resource Optimization reports list metrics that help you identify discovered resources that are
underutilized.
Role required:

• All cloud users can view resource optimization reports on resources assigned to themselves.
• Additionally, users with the cloud_admin or cloud_operator role can access reports on all resources,
across all cloud providers and for all users, bu going to the Cloud Management > Cloud Operations
Portal.
You can view resource optimization reports from the Cloud Management > Cloud Resources page.
1. Navigate to Cloud Management > Cloud Resources page.
The dashboard automatically updates with the data for all cloud providers, for all accounts, and in all
locations.
2. Use the pulldowns on the right side to drill down.
Cloud Provider List of available cloud providers
Account Accounts that the user is a member of,

which may also have assigned resources.
Location Cloud provider regions where the user may
have instantiated VMs.
The dashboard automatically updates with the requested data.
Schedule a Resource Optimization report

Resource optimization reports help you to better manage or utilize resources.
Running multiple scheduled jobs at one time can cause significant performance degradation. When
possible, schedule cloud discovery, billing data download, and resource optimization jobs to run a few
hours apart instead of overlapping.
To view scheduled jobs, navigate to System Definition > Scheduled Jobs.
1. To enable for your provider; Amazon AWS Cloud, Microsoft Azure Cloud or VMware Cloud,
navigate to Cloud Management > Administration > Properties and select Enable Resource
Optimization Report scheduled job.
Resource optimization reporting is enabled at the Cloud level, including all three providers.
2. Click the Report Schedule related link and then fill in the form.
Table 515: Report Schedule form
Field Description
Name Name of the scheduled report.

Active If selected, the scheduled report is active.
Run Frequency of the scheduled report.
Conditional If selected, conditions must be met before
the report is run.
Condition Appears if Conditional is selected. Specify
the conditions that must be met.
Run this script Script used to set conditions for the report to
run.

3. Click Update.
4. By default, the report scheduler, which runs every Monday, is disabled. To enable for your provider;
Amazon AWS Cloud, Microsoft Azure Cloud or VMware Cloud, navigate to Cloud Management >
Administration > Properties and select Enable Resource Optimization Report scheduled job.
By default, the scheduled job stops after 24 hours (86400 seconds). To change the setting, specify the
number of seconds in the The maximum time (in seconds) a resource optimization analysis is
allowed to run, before termination property.
Configure an Amazon Resource Optimization rule

The Cloud Management system tracks usage metrics to help you to identify discovered resources that are
underutilized. Configure values for the metrics in a resource optimization rule (for example, Volume IOPS,
CPU usage, and network I/O) that can flag a resource as underutilized.
Resource Optimization allows you to generate reports that help you to better manage or utilize resources.
The reports list underutilized resources. You can configure rules to schedule when to generate a report. To
use the resource optimization feature, Amazon resources must already be discovered and imported into
the instance. Use the Amazon Web Services account record form to perform Discovery.
Amazon Resource Optimization allows you to track Amazon resource usage through the Amazon
CloudWatch API.
The application supports optimization of the following resources:
• AWS VMs
• Elastic Block Store (EBS)
• Elastic Load Balancing (ELB)
Note: There is a potential charge to use this feature.
Note: You cannot create a new rule. You can, however, unselect the Active check box to stop
tracking metrics for a particular resource.
1. Navigate to Amazon AWS Cloud > Administration > Resource Optimization Rules and select a
rule.
2. Update the rule as needed and then click Update.
Table 516: Resource Optimization Rules form, common fields for all rules
Field Description
Name Name of the rule.

Over a period of days Number of consecutive days that are
combined to calculate the metric.
Note: CloudWatch metric data is

kept for two weeks. A rule that tries
to fetch data older than two weeks
will not return data. The maximum
recommended period for any rule is
14 days.
Active If selected, the rule is applied to the data.

Field Description
Workflow The workflow that runs the rule.
Table 517: Unique fields for the EBS rule
Field Description
Volume IOPS < Threshold value that is triggered once the

volume IOPS is below this number.
Include unattached volumes If selected, unattached volumes will be
included.
Table 518: Unique fields for the EC2 rule
Field Description
CPU Usage (%) < Threshold for percentage of CPU usage.

and Network IO (MB) < Threshold for size of the Network IO.
For number of days Number of days to use for the rule
Table 519: Unique fields for the ELB rule
Field Description
Number of attached healthy instances Threshold for the number of attached

healthy instances.
No instance attached If selected, a report will be generated for the
ELB - Unattached category.
Number of requests Threshold for the number of requests.
There are three default rules:

EBS: Volume IOPS < 1 over a period of 7 days.
EC2: CPU Usage (%) < 10 AND Network IO (MB) < 5 for 4 days over a period of 14 days.
ELB: Number of requests < 100 over a period of 7 days.
If the condition is met, that VM will be considered as an underutilized resource and will
show up in the Self-Service > Cloud Admin Portal Resource Optimization section.
If that VM is assigned to a user, it will also show up on the Resource Utilization report in
the Self-Service > MY Virtual Assets Resource Optimization section for that user.
Amazon Resource Optimization reports

Reports are generated for pre-defined optimization categories.
The Amazon CloudWatch API fetches the necessary metrics to check against the conditions that are
specified by Optimization rules. If the conditions are met, then the report for the category is generated.

Table 520: Resource Optimization reports
Optimization Category CloudWatch Metrics Resource Rule Fields Conditions
EC2 - Underutilized CPU Utilization, CPU Usage and CPU utilization < CPU
NetworkIn, NetworkOut Network IO Usage AND NetworkIn
+ NetworkOut <
NetworkIO
EC2 - Stranded StatusCheckFailed N/A StatusCheckFailed = 1
Instances
EBS - Underutilized VolumeReadOps, IOPS VolumeReadOps +
VolumeWriteOps VolumeWriteOps <
IOPS
EBS - Unattached N/A N/A cmdb's volume_status
field = unattached
ELB - Underutilized RequestCount Number of requests RequestCount <
Number of request
ELB - Unattached HealthyHostCount, No instance attached HealthyHostCount
UnHealthyHostCount AND
UnHealthyHostCount
< 1 AND No instance
attached is selected.
ELB - Attached HealthyHostCount Number of attached HealthyHostCount <
healthy instances Number of attached
healthy instances
Amazon CloudWatch API

The CloudWatch API returns CloudWatch metric data.
Request limits for the CloudWatch API are described in the Amazon CloudWatch area at: http://
docs.aws.amazon.com
Note: CloudWatch metric data is kept for two weeks. A rule that tries to fetch data older than two
weeks will not return data. The maximum recommended period for any rule is 14 days.
Configure an Azure Resource Optimization rule

The Cloud Management system tracks and reports on usage metrics to help you to identify discovered
resources that are underutilized. Configure values for the metrics in a resource optimization rule (for
example, CPU or memory usage) that can flag a resource as underutilized.
• Azure diagnostics must be enabled on each VM to get usage metrics for that VM.
• When enabling diagnostics from the console, you must select a storage account to store the raw metric
data.
• Only basic metrics are used. There is an additional cost in each storage account to save and transfer
this data.
Underutilized resources appear in the Resource Optimization report. The VM is considered underutilized
when either the CPU or memory is low. Data is collected from the following two VM metrics defined in
Azure diagnostics:

• Windows:
• \Processor(_Total)\% Processor Time
• \Memory\% Committed Bytes In Use
• Linux:
• \Processor\PercentProcessorTime
• \Memory\PercentUsedMemory
1. Navigate to Microsoft Azure Cloud > Administration > Resource Optimization Rules.
2. Click an existing rule or click New and then specify the conditions that a resource meets to appear in
the report as underutilized:
Field Description
Name Meaningful name for the rule.

[CPU usage (%) <] [OR Memory used (%) The two settings form a logical OR grouping:
<] When the usage for a resource falls below
either of the specified values during the time
period specified, then the resource appears
in the report as underutilized.
[For number of days] [AND Over a period The two settings form a logical AND
of days] grouping: When the CPU or memory usage
falls below either of the specified values
within the time period specified AND for the
specified number of days, then the resource
appears in the report as underutilized.
Workflow Workflow that runs the rule.

The default rule is:

CPU Usage (%) < 10 OR Memory Usage(%) < 10 for 4 days over a period of 10 days.
If the average daily CPU usage of an Azure VM is < 10% for 4 or more days within a 10-
day window, that VM will be considered as an underutilized resource and will show up in
the Self-Service > Cloud Admin Portal Resource Optimization section.
Configure a VMware Resource Optimization rule

The Cloud Management system tracks and reports on usage metrics to help you to identify discovered
resources that are underutilized. Configure values for the metrics in a resource optimization rule (for
example, CPU or memory usage) that can flag a resource as underutilized.
Underutilized resources appear in the Resource Optimization report. The VM is considered underutilized
when either the CPU or memory is low. Data is collected using the following two metrics defined for
VMware VMs:

• CPU usage percentage

• Memory usage percentage
1. Navigate to VMware Cloud > Administration > Resource Optimization Rules.

2. Click an existing rule or click New and then specify the conditions that a resource meets to appear in
the report as underutilized:
Field Description
Name Meaningful name for the rule.

[CPU usage (%) <] [OR Memory used (%) The two settings form a logical OR grouping:
<] When the usage for a resource falls below
either of the specified values during the time
period specified, then the resource appears
in the report as underutilized.
[For number of days] [AND Over a period The two settings form a logical AND
of days] grouping: When the CPU or memory usage
falls below either of the specified values
within the time period specified AND for the
specified number of days, then the resource
appears in the report as underutilized.
Workflow Workflow that runs the rule.
Note: If the VM is turned off the usage metrics are not returned for that VM.
The default rule is:

CPU Usage (%) < 10 OR Memory Usage(%) < 10 for 4 days over a period of 14 days.
If the average daily CPU usage of a VMware VM is < 10% for 4 or more days within a 14-
day window, that VM will be considered as an underutilized resource and will show up in
the Self-Service > Cloud Admin Portal Resource Optimization section.
View Azure Cost and Usage reports

The Cloud Management application displays billing data using standard, easily-manipulated ServiceNow
charts.
Role required: cloud_operator or cloud_admin can configure, run, and view reports
Users with the cloud_user role can view reports.
Note: The reports can display only the data that has been downloaded from the provider to the
ServiceNow database. Cloud admins can schedule periodic downloads. If billing data is missing,
cloud admins can run a download job on-demand to download the missing data.
1. Navigate to Cloud Management > Reports > Cost & Usage Reports.

The Billing Reports page displays the reports. To generate the reports, certain filters are applied to
the data that was downloaded from the provider. You can modify the filter settings to customize the
content and appearance of the reports.
2. To customize the reports, modify the data filters (standard ServiceNow filter controls). Click Filters
and then specify how to select, group, and display the data.
Advanced topics
You can customize your Cloud Management service.
Additional customizations to your Cloud Management service include custom providers and orchestration
activities.
Customizing your Cloud Management service

Virtualization extension points allow you to customize Cloud Management Provider operations, such as
ESXi hosts, datastores, datacenters, and IP selections.
The Cloud Management application provides integration solutions with AWS, Microsoft Azure, and
VMware. In addition to the provider-specific integrations, the solutions use a common set of features
and models, for example, the process of creating a service catalog item, change approval, provisioning,
reporting, and so on. You can use the generic framework to integrate another provider by implementing
extension points for provider-specific logic and using common functionalities.
You can customize the Virtual Machine Request, VM Creation, and VMware Provision workflows by
providing extension keys to the workflows that manage VM provisioning.
Add a record here to add a new Provider Add Extension Keys to refer to extensions points called by the
provisioning workflow Add a (custom) provisioning workflow (extension points will be called from here) Add
a (custom) catalog item handler script
Create a custom Cloud provider

You can customize Cloud Management Providers by defining keys for the extension points.
Provider information is stored in the Cloud Management Provider table [virtualization_provider].
To customize a provider, copy the default scripts, customize the copies, and select them in the appropriate
fields for the Cloud Management Provider form as described:
1. Navigate to Cloud Management > Cloud Management Providers.
2. Click the Cloud Management Provider and then fill in the form. Provide customized extension keys as
appropriate.
Table 521: Cloud Management Provider form
Field Description
Name Unique and descriptive name of the

virtualization provider.

Field Description
Error Notification Ext Key The extension key to generate a

notification email message and
subject. Provide values for the
workflow.scratchpad.notification.message
and
workflow.scartchpad.notification.subject.
The default for VMware is
VMWSetErrorNotification;
the default for Amazon EC2 is
EC2SetErrorNotification.
Success Notification Ext Key The extension key to generate
a notification email message
and subject. Provide values for
workflow.scratchpad.notification.message
and
workflow.scartchpad.notification.subject.
VMWSetSuccessNotification;
the default for Amazon EC2 is
EC2SetSuccessNotification.
Before Scheduled Job Ext Key The extension key to allow users do some
work before scheduled VM provisioning.
For example, the user can modify VM
parameters that are then passed to the
VM Creation workflow by the change
variable workflow.scratchpad.wf_variables.
VMWBeforeSchedule; the default for
Amazon EC2 is EC2BeforeSchedule.
After Scheduled Job Ext Key The extension key to run after a
scheduled job. The default for VMware
is VMWAfterSchedule; the default for
Amazon EC2 is EC2AfterSchedule.
Post Provision Ext Key The extension key to run after the VM is
provisioned. For example, you can set
up CMDB information in the script. The
provision result can be accessed by the
workflow.scratchpad.provisionResult
variable. The default for VMware is
VMWPostProvision; the default for
Amazon EC2 is EC2PostProvision.
Before Placement Ext Key The extension key to set up placement
workflow.

Field Description
Placement Ext Key The extension key to run when the catalog
item's task automation mode is set to Semi
automatic or Fully automatic. This
allows you to provide your own functions to
select provisioning details, such as the ESXi
host, datastore, network, and folder. The
default for VMware is VMWPlacement; the
default for Amazon EC2 is EC2Placement.
For details on how to edit this script, see
Editing the Placement Extension Key script
on page 1258
Before Deprovision Ext Key The extension key to take action before the
instance is terminated. There is no default
extension key provided, so no action will
be taken. Take any pre-cleanup action like
backup before instance is terminated here.
To use this feature, you must
create a new extension point in the
[vm_extension_point] table.
After Deprovision Ext Key The Extension key to take action after
instance is terminated. There is no default
extension key provided. Take any post-
cleanup action, like deleting snapshots, for
the instance being terminated here.
To use this feature, you must
create a new extension point in the
[vm_extension_point] table.
Catalog item handler The Cloud Management Provider handler

that defines how to order the item in the
service catalog. The default for VMware is
VMwareCatItemHandler; the default for
Amazon EC2 is EC2CatItemHandler.
Provision workflow The workflow that processes VM
provisioning. The default for VMware is
VMware VM Provision; the default
for Amazon EC2 is Amazon EC2 VM
Provision.
Resource Type Resource type of the provider.
CI Table CI type of the provider.
Description Description of the Cloud Management
Provider.
3. Edit the Approver Groups and Operator Groups, if necessary.

4. Click Submit.

Create a custom VM naming script

Cloud admins can use a custom script to automatically generate names for any virtual machine requested
by their users.
Whenever a VM is instantiated, it is initially given a name generated using a combination of the cloud
provider name, requestor information, and an identifying number. Cloud admins can customize this naming
scheme by creating and uploading a special VM naming script for each approved image.
1. Approve an image to be used for catalog offerings, per the directions for that cloud provider.
Cloud Provider Directions
AWS Approve images for AWS catalog items on page

1112
Azure Approve images for Azure catalog items on page
1132
VMware Create a catalog item for VMware on page 1151
2. Navigate to the list of catalog offerings.
Cloud Provider Navigate to
AWS Amazon AWS Cloud > Approved Images

Azure Microsoft Azure Cloud > Approved Images
VMware VMware Cloud > Available Images (Templates)
3. Click the gear icon to Update Personalized List.
4. From the Available list, select VM namer script, and move it to the Selected list.
5. Click OK.
The new column appears with the default entry VMnamer.
6. Click on the VMnamer entry to bring up the script editing page.
7. Modify the script as desired, and provide a new name and a short description for the script in the
appropriate fields.
8. Make sure that the Active checkbox is selected to enable use of this script, then click Update.
Once the script is update, the auto-generated names for any new VMs created from this image take on
the naming scheme outlined in the new script. Names for existing VMs remain unchanged.
Workflows that manage VM provisioning

You can use extension points to customize the workflows that manage VM provisioning.
Virtual Machine Request workflow
The Virtual Machine Request workflow defines the flow to request a VMware machine.

Table 522: Virtual Machine Request workflow
Extension Point Description
VMReserveSpace An extension point to reserve the space

for the requested VM. It should set the
workflow.scratchpad.reserveSpaceResult
variable, which is a JavaScript object with
following properties:
• error: (Boolean) Indicator for whether an error
has occurred.
• message: (String) Description of the reserved
space result.
VMWPlacement An extension point to change the workflow to

select placement for provisioning details. The
default is VMWPlacement for VMware and
EC2Placement for Amazon EC2.
before_schedule_ext_key An extension point to allow the user do some
work before scheduling VM provisioning. For
example, the user can modify VM parameters
that are passed to the VM Creation workflow by
changing workflow.scratchpad.wf_variables.
after_schedule_ext_key An extension point to do post work after a
scheduled job is created. It is fired for each job.
VM Creation workflow
The VM Creation workflow defines the flow to create a VMware instance, and picks up the provision
workflow from the virtualization_provider table and invokes it.

Table 523: VM Creation workflow
SetupPostProvisionWorkflow An extension point to configure the

subflow to run after a VM is provisioned. It
should push one JavaScript object to the
workflow.scratchpad.subflows array. The object
should have the following properties:
• name: (String) The name of the subflow to
run.
• inputs: (JavaScript object) The inputs to the
subflow.
The default extension point checks if there is

Puppet or Chef configuration template to be
attached. If yes, it runs the configure Puppet or
Chef workflow. The following parameters should
be set:
• u_req_item_id: The request item ID.
• u_request_user_id: The request user ID.
• u_virtualization_provider: The sys_id
reference to a record on the Virtualization
Provider table [virtualization_provider].
• u_vm_parameters: (String in JSON format)
The parameters passed to the workflow
configured in the provision_wf field of the
virtualization_provider table.
VMware Provision workflow
The VMware Provision workflow defines the flow to provision a VMware instance.
Table 524: VMware Provision workflow
VMWareNetworkSelectionSetup An extension point to set the workflow for

VMware network selection. The default is the
VMware Network Selection workflow, which uses
the VMWSelectIP extension point to select the
network.

VMWSelectIP An extension point to change the logic to select

the IP for the VM with different source. The
workflow.scratchpad.selections variable should
be filled with following properties:
• ip: (String) The IP address for the VM.
• pool_id: The sys_id for the network
configuration.
• netmask: (String) The net mask.
• dns: (String) The primary DNS server.
• dns2: (String) The secondary DNS server.
• gateway: (String) The gateway.
Editing the Placement Extension Key script

The placement_ext_key script runs when a catalog item task automation mode is set to semiautomatic or
fully automatic.
The script allows you to plug in your functions to select provisioning details such as ESXi host, datastore,
network, and folder. For VMware, the default script picks up the datastore that has the least space to host
the requested VM.
Table 525: Placement Extension Key script properties for VMware
clone_name (String) The VM name to be cloned.

datacenter (String) The datacenter ServiceNow sys_id in
vCenter.
network (String) The VMware network ServiceNow
sys_id.
host (String) The ESX ServiceNow sys_id.
datastore (String) The datastore sys_id.
folder (String) The folder sys_id.
cluster (String) The cluster sys_id.
resource_pool (String) The resource pool sys_id.
guest_customization (String) An indicator for whether customization is
required after provisioning.
ostype (String) The operating system type: Windows or
Linux.
hostname (String) The computer host name, excluding
domain.
win_config (String) The sys_id for the Windows custom
specification.

linux_config (String) The sys_id for the Linux custom

specification.
Table 526: Placement Extension Key script properties for AWS
image (String) The sys_id of the Amazon image.

account (String) The sys_id of the Amazon account.
region_settings (String) The sys_id of the region setting.
Virtualization Provider handlers

Virtualization Provider handlers define the process for ordering a resource in the service catalog. Each
Virtualization Provider uses a unique handler.
Handlers
Table 527: Handlers for Virtualization Providers
Virtualization Provider Handler
Amazon EC2 EC2CatItemHandler

Azure AzureCatItemHandler
VMware VMwareCatItemHandler

Example Virtualization Provider handler

Virtualization Provider Handler form
To view the details of the Virtualization Provider handlers, navigate to Cloud Management >
Virtualization Provider Handlers.
Table 528: Virtualization Provider Handler form
Field Description
Name Unique and descriptive name of the new

Virtualization Provider handler.
Active Check box that activates (selected) or
deactivates (cleared) the handler.
Client callable Check box that indicates whether the handler
can be called by a client.
Description Description of the Virtualization Provider handler.
Script The script that defines the catalog ordering
process.
Collect VM information using PostProvisionSource object

A PostProvisionSource object is created with information about a virtual machine that is collected
during provisioning. Users can use this normalized object to retrieve all required provider-specific
information about each VM instance.
Details provided and obtained during VM provisioning, such as IP address and operating system type, are
stored in a normalized object called PostProvisionSource on the workflow scratchpad. The following
is an example for retrieving the stored information from the normalized object.
var ipAddress =
workflow.scratchpad.PostProvisionSource.instances[0].ip_address;
var os = workflow.scratchpad.PostProvisionSource.instances[0].os;
A PostProvisionSource object is created after provisioning with the collected IP address and
the populated private IP address. It can also contain additional properties if so desired. A sample
PostProvisionSource object look like:
{
"instances" : [
{ "os": "Linux"
"ip_address": "02.03.06.05",
"primary_private_ip": "10.0.0.0"}
]
"extension" : {} // other custom properties may be added to this
extension object
}
The normalized object is then created based on the mapping table.
Property Value Active

instances scratchpad.provisionResult.return_instances true

Note that different information is collected for each cloud provider.

Sample PostProvisionSource object for an EC2 instance
The PostProvisionSource object for an Amazon EC2 instance contains both common and AWS-
specific properties.
Example of a PostProvisionSource object for EC2

The following PostProvisionSource object is created with VM information collected during provisioning
of an instance in EC2.
{
"instances" : [
{
"availabilityZone": "us-west",
"dns": "ec2-0160903.aws.com",
"image_id": "ai356tleqjk71",
"instance_id": "b13w345pmc",
"instance_name_tag": "ec2-7-1",
"instance_state": "7",
"instance_type": "d1-ety",
"ip_address": "09.03.17.08",
"os": "linux",
"private_dns": "ilr434j930j-3",
"primary_private_ip": "02.10.01.40",
"root_device_name": "null",
"root_device_type": "inst-wei",
"subnet_id": "savt-784b2fg",
"tags": {
"Name": "ec2na7nql",
"Tag Set": "MLQ49AG02",
"User Name": "System Administrator"
},
"volumes": [
],
"vpc_id": "vza3bf83df71dy"
}
]
extension object
}
Sample PostProvisionSource object for an Azure instance

The PostProvisionSource object for an Azure instance contains both common and Azure-specific
properties.
Example of a PostProvisionSource object for Azure

of an instance in Azure.
{
"instances" : [
{
"admin_username": "qzrwnfsj",
"computer_name": "qzrwnfsj470",
"container": "hcqi",
"disks": "[]",
"image_id": "23vejd903d9231071438fdfho3cnxt891",

"ip_address": "02.401.200.13",
"name": "qzrwnfsj470",
"os": "Linux",
"primary_private_ip": "03.0.0.40",
"region": "West US",
"state": "on",
"vm_size": "Basic A0"}
]
extension object
}
Sample PostProvisionSource object for a VMware instance

The PostProvisionSource object for an Azure instance contains both common and VMware-specific
properties.
Example of a PostProvisionSource object for VMware

of an instance in VMware.
{
"instances" : [
{
"config": "Yes",
"config_automation": "Yes",
"cpus": "1",
"datastore_morid": "dst32c7i3",
"disks": "[{\"provisionMode\":\"fr\",\"size\":\"25\"}]",
"hostname": "gjerr",
"instanceUuid": "lafjPN1nf4457jfbsD03FDN",
"ip_address": "01.02.04.03",
"memory": "123",
"morid": "v4559",
"name": "fbiwerier493",
"network_config": "dhcp",
"os": "Linux",
"serialNumber": "VMWare483 jiejf3 343 034fjAL23NA33043 30efj34878n,
"template": "b392djkf39j20cn3j03jazxsd",
"uuid": "3483vnhg4s3nfw3910j043h4",
"vcenter": "03.01.04.05"
}
]
extension object
}
Cloud orchestration activities

Orchestration activities are used automate tasks that are normally done manually.
You can use orchestration activities for AWS and VMware.
Orchestration activities for AWS

Amazon EC2 orchestration activities are for use in workflows.
AWS orchestration activities include:

• Change State
• Create Tag
• Describe Images
• Describe Instances
• Describe KeyPairs
• Describe Regions
• Run Instances
• Terminate Instances
EC2 activity result values

EC2 activities use a REST message to communicate with Amazon. All EC2 activities set their
activity.result value based on the response code returned by this REST message.
If the response code indicates an error, or if there is a REST fault, the activity result value is failure. If the
REST message does not return an error code or a REST fault, the activity result value is success.
Change State activity
The Change State activity sends commands to a VM to start, stop, or reboot the instance.
If the virtual machine is already in the specified state, the activity does not alter the instance.
Change State activity input variables
These variables determine the behavior of the activity.
Field Description
Account Select the name of the Amazon EC2 account

from which this instance was created.
Action • Start Instances
• Stop Instances
• Reboot Instances
• Use scratchpad variables
Instances Amazon VMs whose state you want to change.

Define multiple instances with a comma-
delimited list of instance IDs. If one instance in a
list of instances fails, the entire request fails. For
example, if you attempt to stop 5 instances, and
one instance is not an EBS volume, none of the
instances will stop.
Region Amazon EC2 region that is hosting
the instance. Access a scratchpad
pad variable for the region by adding
${workflow.scratchpad.region} to the
field.
Sensor script The script to execute after the request is
made and a response is received. You can
access the full XML response body from the
activity.output object. The script also
populates the instances variable.
Change state activity scratchpad entries

The activity writes this data to the workflow scratchpad.

instances An array of instance objects. Each object

contains:
• instance_id: the VM ID.
• instance_state: an EC2 status code:
• 0: Pending
• 16: Running
• 32: Shutting down
• 48: Terminated
• 64: Stopping
• 80: Stopped
• instance_xml: the raw XML returned by

Amazon.
Create Tag activity

The Create Tag activity adds private tags to a VM to simplify the administration of your EC2 environment.
This metadata consists of case-sensitive key/value pairs that you can use to create user-friendly names.
For example, you can define a tag with key = Name and value = Webserver. You can add up to ten unique
keys to each instance with an optional value for each key.
Create tag input variables
Field Description
Account Name of the Amazon EC2 account from which

this instance was created.
Region Amazon EC2 region that is hosting
the instance. Access a scratchpad
pad variable for the region by entering
${workflow.scratchpad.region} in the
field.
Instances List of Amazon VMs to tag. Define multiple
instances with a comma-delimited list of instance
IDs. If one instance in the list fails, the entire
request fails.
Tag Key Key for the VM tag, which allows up to 128
characters and can be any string. Do not use
the AWS: prefix in your tag names. This prefix
is reserved for Amazon Web Services use.
Remember that all tag keys are case sensitive.
Tag Value Value of VM tag, which allows up to 256
characters and can be any string value. Do not
use the AWS: prefix in your tag values. This
prefix is reserved for Amazon Web Services use.
Remember that all tag values are case sensitive.

Describe Images activity

Retrieves information about one or more Amazon machine images (AMI) visible to the specified account.
This activity also retrieves information about all public Amazon images, account-owned images, and
images from specified shared accounts.
Describe Images input variables
Field Description
Account Name of the account from which to retrieve

image information.
Region Endpoint of the Amazon-defined region from
which to retrieve the image information.
Image The retrieved image ID that starts with "ami-." If
this field is blank, information about all images
visible to the account is retrieved.
Sensor script The script to execute after the request is made
and a response is received. The activity stores
image information in an the images scratchpad
variable.
Describe Images scratchpad entries

images An array of image objects. Each object in the

array contains:
• image_id: the image's AMI ID.
• name: image name.
• image_state: image availability.
• architecture: the processor architecture of the
image, typically i386 or x86_64.
• platform: the operating system of the image,
Windows or Linux.
• ramdisk_id: the disk ID of the RAM.
• kernel_id: the image kernel ID.
• root_device_type: root device type, typically
EBS or instance store.
• virtualization: virtualization type, typically para
virtual or HVM (hardware virtual machine).
• image_xml: raw XML returned by the API call
for the image.
Describe Instances activity

Retrieves information about a single instance or all instances associated with the given EC2 account and
region.
Describe Instances input variables

Field Description

instance information.
which to retrieve the instance information.
Instance The ID of a single instance from which to retrieve
information.
Instances The comma separated IDs of the instances to
describe. If this variable is blank, ServiceNow
returns information about all instances on this
account.
and a response is received. The activity stores
instance information in the instances scratchpad
variable.
Describe Instances scratchpad entries

instances An array of instance objects. Each object in the

array contains:
• instance_id: ID of the running instance.
• private_dns: private DNS, accessible only
from within the EC2 region in which the
instance is running.
• dns: public DNS, accessible from any
computer on the Internet.
• ip_address: public IP address for the
instance.
• instance_state: state of the instance:
• 0: Pending
• 16: Running
• 48: Terminated
• 64: Stopping
• 80: Stopped

Amazon.
Describe KeyPairs Activity

The Describe KeyPairs activity retrieves information about the key pairs defined in the specified EC2
account.
These key pairs can later be used with the Run Instances activity to start instances.
Describe KeyPairs input variables

Field Description

instance information.
which to retrieve the instance information.
and a response is received. The information
about the key pairs is stored in the keyPairs
scratchpad variable.
Describe KeyPairs scratchpad entries

keyPairs An array of key pairs. Each object in the array

contains:
• name: name given to the key pair when it was
created in the account.
• fingerprint: public key fingerprint of the key
pair.
Describe Regions activity

The Describe Regions activity retrieves all the region endpoints defined by Amazon.
Describe Regions input variables
Field Description

region information.
and a response is received. The activity store
region information in the regions scratchpad
variable.
Describe Regions scratchpad entries

keyPairs An array of key pairs. Each object in the array

contains:
• name: name given to the key pair when it was
created in the account.
• fingerprint: public key fingerprint of the key
pair.

Run Instances activity

The Run Instances activity launches a specified number of instances of an image.
Run Instances input variables
Field Description
Account Name of the account in which the instances are

launched. This account is charged for the length
of time the instances are running.
User data [Optional] Metadata that defines bootstrap
behavior when launching EC2 virtual machines.
For information about using this parameter, see
the documentation regarding Instance Metadata
and User Data on the Amazon site.
Image AMI ID of the image used to launch the instance.
Minimum Count The minimum number of instances Amazon
must launch for this request to be successful. If
Amazon cannot launch this number of instances,
no instances are launched.
Maximum Count The maximum number of instances Amazon
should launch for this request, up to the
maximum number allowed for the specified
account.
Instance type The instance type. The valid values are:
• t1.micro
• m1.small
• m1.medium
• m1.large
• m1.xlarge
• c1.medium
• c1.xlarge
• m2.xlarge
• m2.2xlarge
• m2.4xlarge
• m3.xlarge
• m3.2xlarge
• hi1.4xlarge
• cc1.4xlarge
• cg1.4xlarge
• cc2.8xlarge

made and a response is received. The activity
stores instance information in the instances
Run Instances scratchpad entries



array contains:
• private_dns: private DNS, accessible only
from within the EC2 region where the
instance is running.
• dns: public DNS, accessible from any
computer on the Internet.
• ip_address: public IP address for the
instance.
• 0: Pending
• 16: Running
• 48: Terminated
• 64: Stopping
• 80: Stopped

Amazon.
Terminate Instances activity

The Terminate Instances activity terminates one or more instances in the specified region of the given EC2
account.
Terminate Instances input variables
Field Description
Account Name of the account in which the instance will

be terminated
Region Endpoint of the Amazon-defined region in which
the instance will be terminated.
Instance The ID of a single instance to terminate. This
variable is deprecated in the Calgary release,
and this ID must be put in the Instances variable.
Instances The comma separated IDs of the instances to
terminate. If this variable is blank, there are no
instances to terminate and the activity returns an
error.
made and a response is received. The activity
stores instance information in the instances
Terminate Instances scratchpad entries



array contains:
• private_dns: wmpty string, because a
terminated instance does not have a private
DNS.
• dns: empty string, because a terminated
instance does not have a public DNS.
• ip_address: empty string because a
terminated instance does not have an IP
address.
• 0: Pending
• 16: Running
• 48: Terminated
• 64: Stopping
• 80: Stopped

Amazon.
Orchestration activities for VMware

Your instance must have access to a MID Server configured to use VMware to run certain activities.
VMware orchestration activities are for use in workflows.
VMware orchestration activities include:
• Add Disk
• Change Network
• Change State
• Check VM Alive
• Clone
• Configure Linux
• Configure Windows
• Delete Snapshot
• Destroy
• Discover Customization Specifications
• Get VM Events
• Get VM Guest Info
• Reconfigure
• Revert to Snapshot
• Snapshot
Conversion function
Converts a UUID to the proper format automatically.

A function called turnCorrelationIdToUuid in the VMUtils script include converts a UUID to the
proper format automatically. Use this function to convert a UUID to the proper format within the workflow:
javascript:VMUtils.turnCorrelationIdToUuid(<uuid from another source>)
For example, you can enter javascript:VMUtils.turnCorrelationIdToUuid('42 10 c1 62 e3

1e 70 e6-4a 03 b4 6a bb e1 7b 4f') directly in the VM uuid activity input variable.
Another method is to use the function to create a scratchpad variable that is available to all the activities in
the workflow. For example, you might add a Run Script activity to the beginning of the workflow in which
you create the following variable:
workflow.scratchpad.uuid=VMUtils.turnCorrelationIdToUuid('42 10 c1 62 e3 1e
70 e6-4a 03 b4 6a bb e1 7b 4f')
You can then access this variable from any activity by entering ${workflow.scratchpad.uuid} in the
VM uuid activity input variable.
Determine VMware activity result values
VMware activities communicate with vCenter through a MID Server.
When a VMware activity sends a request, the MID Server sends a response to the ECC Queue. All
VMware activities set their activity.result value based on the payload of the response from the MID
Server. If this payload contains an error, the activity result value is failure. If the payload contains no error,
the activity result value is success. Some activities, such as Delete Snapshot, specify additional result
values.
Managed Object Browser
The Managed Object Browser (MOB) is a vCenter utility that allows users to view detailed information
about vCenter objects, such as images and virtual machines.
To find the UUID of a virtual machine using the MOB:
1. Navigate to https://<vCenter IP>/mob to log into the MOB.
2. Browse to content, rootFolder, and down the childEntity list into the appropriate datacenter, datastore,
and finally down to the actual virtual machine.
3. In the virtual machine, click config and find the uuid field.
Copy this value into the VM uuid activity input variable.
Managed object reference ID

A managed object reference (MOR) ID uniquely identifies a VMware virtual machine.
ServiceNow uses MOR ID values in several VMware activities to select specific virtual machines to act on.
VMware provides additional documentation on obtaining the MOR ID for a virtual machine.
Virtual machine UUID
If you are writing a workflow and not using an automated workflow from ServiceNow, you must provide a
properly formatted UUID.
The VMware universal unique identifier (UUID) required by VMware activities (VM uuid input variable)
must be in the following format: 4210c162-e31e-70e6-4a03-b46abbe17b4f. A UUID from another
source might be in the wrong format. For example the UUID from the VMX file (uuid.bios field) on the
virtual machine appears in this format, 42 10 c1 62 e3 1e 70 e6-4a 03 b4 6a bb e1 7b 4f,
and produces an error. If the UUID you have for a virtual machine is not in the correct format, use one of
these methods to obtain the correct value.
Add Disk activity
The Add Disk activity creates a new disk on a virtual machine.
This activity selects a datastore for the new hard disk automatically if you do not specify one.

Table 529: Input variables
Field Description
vCenter IP address of the vCenter server that manages

the virtual machine to operate.
Datastore MOR id The ID of the datastore on which to put this disk.
If this variable is blank, Orchestration searches
all the datastores associated with the virtual
machine to find one with sufficient space for the
disk being added.
VM uuid The VMware universal unique identifier assigned
to this virtual machine. The Virtual Machine
UUID topic provides instructions on properly
formatting the unique identifier for creating a
workflow.
Disk size (MB) The size of the new disk to create, in megabytes.
This activity provisions all the necessary space
for the new disk immediately (thick mode).
Change Network activity

The Change Network activity changes the network that a virtual machine is configured to use.
Field Description

workflow.
Network Name of the network. For example, Production
Network. A virtual machine can only access a
network in the same datacenter.
Change State activity

The Change State activity sends commands to vCenter to control the power state of a given VMware
virtual machine, such as powering on and powering off the VM.
If the VM is already in the state to which it is being changed, the workflow takes no action.

Field Description
vCenter IP address to the vCenter server that manages

Action Select the new state for the virtual machine:
• Power On: turns on a virtual machine that is
powered off or suspended and does nothing if
the virtual machine is already on.
• Power Off: turns off a virtual machine that is
powered on or suspended and does nothing
if the virtual machine is already off. This
variable returns an error if the virtual machine
is suspended.
• Suspend: suspends a virtual machine that is
powered on and does nothing if the virtual
machine is already suspended. This variable
returns an error if the virtual machine is off.
• Reset: resets a virtual machine that is
powered on. This variable returns an error if
the virtual machine is off or suspended.

workflow.
Check VM Alive activity

The Check VM Alive activity uses the VMware API to determine if a newly configured virtual machine is
alive.
The virtual machine is alive if its state is powered on and it uses the same IP address it was configured to
use.
Field Description

the virtual machine to check.
IP Address The IP address that the virtual machine with the
VM uuid parameter should have to be declared
alive.
workflow.

Clone activity
The Clone activity sends commands to vCenter to clone a given VMware virtual machine or virtual machine
template.
Several input variables require a MOR ID. ServiceNow stores MOR data in the Object ID field of
configuration item records.
Field Description

the virtual machine to clone and also will
manage the clone.
to the machine you are cloning. The Virtual
Machine UUID topic provides instructions on
properly formatting the unique identifier for
creating a workflow.
Clone name The name to assign to the newly cloned virtual
machine. The clone name has the following
requirements:
• Maximum length is 80 characters.
• The special characters %, /, and \ are
escaped in a clone name. A slash(/) is
escaped as %2F or %2f, a backslash(\) is
escaped as %5c or %5C, and a percent is
escaped as %25. The special character
% is not escaped when used to start an
escape sequence.
• Clone name is unique within a folder.
Folder MOR id The managed object reference ID for the folder

in which the cloned virtual machine resides.
This variable is optional. If this field is blank,
Orchestration places the cloned virtual machine
in the same folder as the source virtual machine.
Datastore MOR id The managed object reference ID for the
datastore the new virtual machine belongs to.
Orchestration places the cloned virtual machine
in the same datastore as the source virtual
machine.
Host MOR id The managed object reference ID for the
host the new virtual machine is assigned to.
Orchestration assigns the cloned virtual machine
to the same host as the source virtual machine.

Field Description
Resource pool MOR id The managed object reference ID for the

resource pool the new virtual machine is
assigned to. This variable is optional when
cloning a virtual machine. If this field is blank,
Orchestration assigns the cloned virtual machine
to the same resource pool as the source virtual
machine.
Resource Pool Owner Owner of the resource pool as seen by vCenter.
For example, the owner might be something like
labesx01.service-now.com or an IP address.
The owner should point to the ESX box on which
the original VM and clone are located (whatever
vCenter's representation of that ESX name is).
Configure Linux activity

The Configure Linux activity sends commands to vCenter to set the identity and network information on a
given VMware virtual Linux machine.
This activity also enables guest customization for the Linux machine. This activity fails if run against a
single virtual machine more than once.
Field Description

the Linux virtual machine being configured.
workflow.
Hostname The operating system name assigned to the
Linux virtual machine.
Domain The domain the Linux virtual machine is
assigned to.
IP address The IP address assigned to the Linux virtual
machine.
Netmask The netmask for the network the Linux virtual
machine's IP address belongs to.
Gateway The gateway address for the network the Linux
virtual machine's IP address belongs to.
DNS The DNS server for the network the Linux virtual

Configure Windows activity

The Configure Windows activity sends commands to vCenter to set the identity and network information on
a given VMware virtual Windows machine.
This activity also enables guest customization for the Windows machine. This activity fails if run against a
single virtual machine more than once.
Field Description

theWindows virtual machine being configured.
workflow.
Gateway The gateway address for the network the
Windows virtual machine's IP address belongs
to.
Administrator password The password assigned to the Administrator
user for this operating system.
Domain administrator password The password for the domain user with the
proper credentials to move a machine onto the
given domain.
Domain administrator A user who has the credentials to get this
Windows machine onto the domain.
DNS The DNS server for the network the Windows
virtual machine's IP address belongs to.
Hostname The computer name of the Windows virtual
machine.
IP Address The IP address assigned to the Windows virtual
machine.
Netmask The netmask for the network the Windows virtual
Organization The organization of the registered user for the
OS installed on this virtual machine. This value
appears in the Properties box of My Computer.
Time zone The time zone value. For example, the value for
the US/Pacific time zone is 4.
Domain The domain the Windows virtual machine is
assigned to.
Product key The Microsoft product key for the Windows
operating system installed on the virtual
machine.

Field Description
Registered user The registered user for the operating system

installed on the virtual machine. This user
appears in the Properties box of My Computer.
Run once A set of Windows commands that run on the
specified Windows machine when this activity
initializes.
License mode The type of license the Windows operating
system uses, either Per server or Per seat. See
the Microsoft site for information on licensing for
more information.
Concurrent connections When using a Per server license mode, the
Concurrent connections value specifies how
many users can access the Windows machine at
a time.
Delete Snapshot activity

The Delete Snapshot activity deletes a saved virtual machine snapshot from a vCenter server.
Table 536: Results table
Result Description
Success The snapshot was successfully deleted.

Failure An error occurred while attempting to delete the
snapshot. Additional details may be available in
the workflow log.
Not found The specified snapshot was not found on the
vCenter server.
Field Description
vCenter IP address of the vCenter server that stores the

snapshot to delete.
to the virtual machine storing the snapshot to
delete. The Virtual Machine UUID topic provides
instructions on properly formatting the unique
identifier for creating a workflow.
Snapshot MOR id The managed object reference ID of the
snapshot to delete.
Destroy activity
The Destroy activity sends a command to vCenter to destroy the named VMware virtual machine.

This activity deletes the virtual machine and removes it from the disk.
Field Description

the virtual machine to destroy.
workflow.
Discover Customization Specifications activity

The Discover Customization Specifications activity talks to vCenter to retrieve guest customization
specifications that can be used for VM provisioning.
If a spec_name is specified, the system only looks up that specification. If no spec_name is specified, all
customization specifications are discovered.
Field Description

the virtual machine to check.
Specification Name Name of the specification to discover. If this field
is blank, all specs are discovered.
Sensor script Script that processes the vCenter address and
specifications returned by the activity.
Get VM Events activity

The Get VM Events activity retrieves the most recent events for a virtual machine.
This activity stores the retrieved event information in the events sensor script variable as an array of
JavaScript objects. Each object in this array contains these fields:
Table 540: Object array fields
Field Description
Classname The class of the event generated by the vCenter.

Message The event text.
Time The timestamp when the event occurred.

Field Description

the virtual machine from which you want to
retrieve events.
workflow.
Max events The maximum number of events to retrieve from
the virtual machine. The activity returns at most
15 events if you do not specify a value.
Sensor script
Get VM Guest Info activity

The Get VM Guest Info activity retrieves the guest customization information for a virtual machine.
This activity stores the returned information in these sensor script variables:
Table 542: sensor script variables
Hostname The host name of the virtual machine.

State The power state of the virtual machine.
IP An array of strings that lists the IPv6 and IPv4
addresses of the virtual machine.
Field Description

the virtual machine from which you want to
retrieve guest customization information.
workflow.
Reconfigure activity
The Reconfigure activity updates the number of CPUs and the amount of memory assigned to a virtual
machine.

Field Description

workflow.
Number of CPUs The number of CPUs to allocate to the virtual
machine. If this field is blank, you must
reconfigure the memory for this virtual machine.
Memory (MB) The amount of memory, in megabytes, to
allocate to the virtual machine. If this field is
blank, you must reconfigure the number of CPUs
for this virtual machine. This value must be
divisible by 4. If the amount is not divisible by
4, the activity succeeds but the virtual machine
cannot start.
Revert to Snapshot activity

The Revert to Snapshot activity reverts a virtual machine to the state captured in a given snapshot.
Field Description

the virtual machine for which the snapshot was
created.
to the virtual machine from which the snapshot
was created. The Virtual Machine UUID topic
provides instructions on properly formatting the
unique identifier for creating a workflow.
Snapshot name Unique name of the snapshot.
Snapshot MOR id Reverts the virtual machine to the snapshot with
this ManagedObjectReference ID. If this variable
is present, the workflow ignores the Snapshot
name.
Snapshot activity
The Snapshot activity creates a snapshot of a virtual machine.
A snapshot stores the current state of a virtual machine, but is not a full backup.

Field Description

the virtual machine for which you want to create
a snapshot.
to the virtual machine from which the snapshot
is created. The Virtual Machine UUID topic
provides instructions on properly formatting the
unique identifier for creating a workflow.
Snapshot name Unique name of the snapshot.
Snapshot description Description that distinguishes this snapshot from
other snapshots of the same virtual machine.
Scratchpad variable The scratchpad variable to store the returned
snapshot ID. You can use this snapshot ID in
the Snapshot MOR id variable for the Revert to
Snapshot and Delete Snapshot activities.
Errors and Troubleshooting

Cloud troubleshooting includes provisioning rules and error handling.
Check troubleshooting and error messages to help determine the solution to common issues.
Troubleshooting provisioning rules

The provisioning rule selected for a particular request is expected to populate all required variables before
automatic provisioning can occur. If a required variable is not populated when all rule assignments are
completed, the workflow assigns a task to a cloud operator to complete the assignments.
A Provisioning Rules Log appears on the task that details the provisioning rule action. The log includes
information on testing rules, whether a rule was selected, which assignments were made, and what data
might have been missing.

Azure troubleshooting
Common issues while configuring Microsoft Azure Cloud.
I created a Service Principal but could not discover any subscriptions
• Make sure that you have used the correct Tenant/Client IDs and access key
• • Save the secret key when you create it on the Azure portal
• Make sure that the secret key is still valid

• Make sure that you have granted proper access to the service principal for the subscriptions you want
this SP to manage. Contributor role is recommended.
I just ran a Discovery on one of my subscriptions, but no resources or only part of

a resource was discovered
• Ensure that the Service Principal has proper permissions as described in the first section
• Check the Discovery log and ECC queue for errors (under Discovery status)
I ordered a new VM/Resource Group, but it is not on/ready
• The request might be going through the manual approval process.

• Most requests need additional mandatory information to be set before provisioning can occur. If the
provisioning rule does not set all necessary information, the system generates a catalog task for the
cloud operator to complete the request.

• Provisioning can fail on the Azure platform. In this case, the system generates a task that the cloud
operator must resolve.
• • Look for information in the task or go to the workflow context to look for clues. Sometimes Azure
provisioning succeeds but the task timed out waiting for the VM/resource group to come up. An
operator can make sure they are up on Azure portal and close the task to re-try Discovery.
I requested an action (like Start, Stop, or Modify) on a VM, but nothing happens
• Some VMs are under change control. If the request meets a change condition defined by the cloud
admin, then the request must be approved before the action can occur.
• After the change request is approved, you may need to reload the VM form to see the Proceed with
change action.
• It is possible that the request failed on the Azure platform. In such a case, the system generates a CI
task for the cloud operator to resolve the issue.
VMware error handling

Configuring virtual resources can produce errors, such as IP pools containing invalid addresses or
excessively large CPU count offerings. Errors also can occur from issues within the vCenter configuration
itself or from network issues.
When VMware vCenter detects a cloud management error, it sends the error description to the
ServiceNow instance, which pauses the provisioning workflow and creates a task to correct the error. The
provisioner to whom this task is assigned reads the error description in the task and opens the request item
to correct the configuration. When the provisioner closes the task, the workflow checks the condition that
produced the error and continues if the configuration is accepted.
Some problems cannot be resolved from within the instance. For problems in vCenter, consult the VMware
documentation.
Activities where errors can occur

Provisioning errors can occur in several workflow activities.
Table 547: Activities where errors can occur
Activity Possible Errors
Clone Duplicate name, datastore out of space.

Reconfigure Excessive CPU and memory values.
Change Network Network does not exist.
Add Disk Size problems: Not enough space.
Change State Virtual machine deleted by another user.
Select IP Address Out of space in the IP pool or problems configuring the IP pool.
Incorrect guest customization specifications.
Configure Windows Incorrect guest customization specifications.
Configure Linux Incorrect guest customization specifications.

Activity Possible Errors
VMware - Wait for VM to Start Incorrect guest customization specifications.

(Workflow)
Example error condition - Duplicate clone name

A name has been given that is already in use to a VMware clone.
1. vCenter detects the error and sends the contents of the error message to the ServiceNow instance.
2. The system stops the workflow and creates a catalog task in the Cloud Operations Portal.
This task shows that a requested instance named global-by-1 has generated an error.
3. Open the task and identify the error. The description shows that global-by-1 is a duplicate name.


4. Click the link in the Request item field to open the original request.


5. Enter a unique name for the virtual machine and click Update for the catalog task to appear. The
clone name for the virtual machine has the following requirements:
• Maximum length is 80 characters. The special characters %, /, and \ are escaped in a clone name.
A slash(/) is escaped as %2F or %2f, a backslash(\) is escaped as %5c or %5C, and a percent is
escaped as %25. The special character % is not escaped when used to start an escape sequence.
• Clone name is unique within a folder.
6. Click Close Task. The Cloud Operations Portal appears and the task shows a state of Closed.
7. The workflow resumes and checks the new clone name with vCenter.
8. vCenter approves the name, and provisioning continues.
Content packs for Cloud Management

Content packs contain preconfigured dashboards. These dashboards contain actionable data
visualizations that help you improve your business processes and practices.
Content packs
To enable the content pack for Cloud Management, an admin can navigate to Performance Analytics >
Guided Setup. Click Get Started then scroll to the section for Cloud Management. The guided setup takes
you through the entire setup and configuration process.

Istanbul ServiceNow Index
Index
A Amazon Resource Optimization reports 1248
Amazon resource optimization rule
active change window 952 configure 1247
active connection information Amazon virtual machine 1205
Solaris 371 Amazon VM
add a service to a group 635 request 1216
Add segment of service 652 Amazon VMs
administer 854 requesting 1214
aggregated connections 677 Amazon Web Services
aggregated edges 677 account details 1078
alert creating an AWS account 1078
impact 995, 998, 999 defining AWS policies 1083
monitoring 987, 990, 992, 993, 995, 998, 999, 1003 external credential storage 1079
report 1003 security tokens 1082
alert maintenance 977 Amazon Web Services (AWS) cloud
alert rules 849 discovering 380
Align versions of customized probes and sensors 266 Analyzing
Amazon service 666
approve the request 1193 Application Dependency Mapping (ADM)
catalog items 1117 application relationships 177
cloud administration 1111 CI relationships 178
cloud administrator tasks 1112 overview 173
complete the provision task 1196 requirements
configure 1079 Windows 2000 server 173
configuring tags 1174 application form
create catalog items 1114 personalize 514
create catalog items from EC2 images in Cloud application profile discover (APD)
Management 1113 APD files, create 509
prices 1119 APD folder, create 505
pricing catalog items 1119 application, classify 498
provision a virtual machine 1192 Discovery, run 501
Amazon AWS enable 495
configure 1055 environment file location, set 495
Amazon AWS Cloud environment file, create 496, 506
installed tables 1066 environmental details, view 510
installed user roles 1065 Linux 495, 495, 496, 497, 498, 501, 505, 506, 507, 508,
plugins 1063, 1065 510
properties 1072 proxy servers 495, 505, 508
Amazon CloudFormation 1122 SAP application on a server 509
Amazon CloudWatch API 1249 version file, create 497, 507
Amazon EBS 1121 Windows 495, 505, 508
Amazon EBS snapshots Windows 2003 server 505
discovering 1122 application profile discovery
viewing 1122 customization 511
Amazon EBS volumes application relationships
discovering 1121 Application Dependency Mapping (ADM) 177
viewing 1121 ARM parameters
Amazon EC2 variables 1139
approve images 1112 ARM templates 1138
asset management 1091 arrange services in groups 635
catalog items from EC2 images 1118, 1120 assets
Cloud Management tracking in Amazon EC2 1091
service catalog 1113 Assign resources
create catalog items from EC2 images 1118 multiple items request
image permissions 1084 two-step checkout 1244
installed with 1063 assignments
service catalog 1192 in the base system 1188
Amazon Elastic Block Store 1121 provisioning rules 1182

Set by Filter 1183 Azure resource groups

AWS managing 1235
billing reports 1089 requesting 1240
cloud administration 1111 Azure Resource Manager templates 1138
cloud administrator tasks 1112 Azure VM
configure 1055 instance provision 1207, 1218
configure lease 1179 template
create ReferenceType metadata 1131 parameter validation 1207, 1218
credentials 1079 terminate 1188, 1234
federated access 1082 Azure VMs
Orchestration activities 1263 requesting 1214
permissions 1085
view details of VPC subnets 1120
view details of VPCs 1120
B
virtual private clouds 1120 baseline, set 686
VPC security groups 1120 Behaviors
VPCs 1120 multiple domains 200
AWS account details 1078 Best Practice
AWS accounts add business services
discover 1087 by importing 616
AWS Cloud manually 616
regions 1080 by importing 617, 619
AWS CloudFormation create phase 616
template metadata 1131 en masse 617, 619
AWS demo data from load balancer 619
CloudFormation service catalog items 1075 import 619
CloudFormation stacks and CI resources 1076 import business services 616, 617, 619
CloudFormation stacks and tags 1075 load business services 616, 617, 619
CloudFormation templates 1074 manually 620
groups and users 1073 multiple 619
AWS reports 1244 phase 616, 616
AWS security token populate phase 616, 617
assign to user 1082 potential business service 620
AWS VMs billing data
requesting 1214 download 1177, 1249, 1250
Azure download on demand 1178
ARM templates 1138 download scheduler 1178
assigning tags 1176 billing reports
cloud administration 1111 AWS 1089
cloud administrator tasks 1132 cloud management 1251
Cloud Management manage 1090
service catalog 1133 Boundary 646
cloud_operator responsibilities 1198 bulk tagging 1176
configure 1055, 1093 business rules 831
configure lease 1179 Business rules installed with Event Management 831
configuring regions 1094 business service
configuring subscriptions 1095 boundaries 516
configuring tags 1174 create 628
create catalog items 1132, 1133, 1135, 1141 creating 628
create reference type metadata 1142 criticality 516
discovering resources 1095 define 628
Enterprise Agreement credentials 1096 defining 628, 630
instances 1093 entry points 630
resource group catalog items 1138 history 686, 692
resource groups 1240
schedule snapshot 1231, 1231
service principal 1094 C
troubleshooting 1282
catalog item
Azure ARM
create 1132, 1133, 1135, 1141
template metadata 1142
catalog items
Azure reports 1096, 1244
Azure resource groups 1138
change prices 1119

CloudFormation 1125, 1126, 1127, 1130, 1130 client scripts

pricing 1119 installed components
provisioning rules 1182 Service Mapping 534
variables 1140 Clone name
verify path to Validation 1275
in CloudFormation 1127 cloud
VMware 1151 Azure 1109
catalog items from EC2 Images cloud configurations 1117
categories in service catalog 1118 Cloud Management
Catalog Items from EC2 Images advanced topics 1252
add new sizes manually 1118 Amazon 1193
catalog offering Amazon Web Services 1108
link to VMware template 1155 change conditions, editing 1165
change history change control 1163
viewing 686, 692 change request conditions 1164
change record 686 change request, creating 1166
change request window 952 cloud resources
Change user operation 754 managing 1204
checkout redirect property CloudFormation 1192
CloudFormation 1131 error 1284
CI extension points 1252, 1259
adding to map 646 groups 1106
check dependencies 701 installation 1057
display 721 provisioning VMware requests 1198
in business services 701 virtual assets
marking as boundary 646 managing 1223, 1226
properties 721 VMware 1102, 1106, 1110
removing from map 646 VMware Networks 1145
Service Mapping Cloud Management automatic VM name generation 1255
name labels 675 Cloud Management extension points
properties 675 Cloud Management Providers, customizing 1252
supported by Service Mapping 523 workflows 1255
CI binding 849 Cloud Management overview 1054
CI class cloud operations
creating 732 roles 1059
Service Mapping 732 security 1059
CI relationships tasks 1191
Application Dependency Mapping (ADM) 178 user groups 1059
CI type Cloud Operations portal 1111, 1190
creating 732 cloud operator
Service Mapping 732 responsibilities 1190
CI types Cloud Provisioning
discovery schedule for 638 error
updating 638 example 1285
CIM validation
parameter 214 error 1285
CIM Discovery 464 Cloud Resource Catalog 1204
CimIQL cloud user tasks 1204
component tokens 218 cloud_admin group 1059
operation tokens 216 cloud_approver group 1059
results 222 cloud_operator group 1059
syntax 215 cloud_operator role
tutorial 220 responsibilities 1198
classification cloud_user group 1059
configuration item 91 CloudFormation
device 84 catalog items 1130
process 96, 393 catalog items, verify path to 1127
script 100 checkout redirect property 1131
classification script creating catalog items 1126, 1127, 1130
update 513 NoEcho parameter 1124
classifiers template parameters 1123
horizontal pattern probe 210 templates for stacks 1123

user groups 1192 credentials

CloudFormation groups and users applicative 542
examples 1073 AWS 1079
CloudFormation service catalog items checking IP service affinity 114
examples 1075 Service Mapping 540
CloudFormation stack VMware 1100
discover 1130 credentials, Service Mapping 543
managing 1235 customization specification
request 1235 VMware Linux VMs 1161
terminate 1238 VMware Windows VMs 1161
update 1238 customize
view Service Mapping 702
BSM 1190, 1235, 1239 Customized VM provision
CloudFormation stacks and CI resources post provision source object 1261
examples 1076 Customizing
CloudFormation stacks and tags mapping patterns 730
examples 1075
CloudFormation templates
examples 1074
D
CloudWatch API 1249 DAS example 440
clusters dashboard view 989
display 646 Data disk size
types 646 VMware 1156
cmdb_ci_endpoint 735 database catalog 369
collection endpoint for SNMP traps 898 datastores
community string 104 configuring 1161, 1203, 1203
compare business service versions 692 VMware 1162
component token 216 de-duplication 849
components define access to services 636, 827
Service Mapping 706 define user access to services 636, 827
Condition Token 219 defining a pattern
configuration item Discovery 4, 8, 10, 12, 14, 21, 23, 26, 26, 27, 28, 37,
check dependencies 701 41, 51, 51, 52, 52, 52, 53, 53, 54, 54, 55, 66, 66, 69,
creating 732 73, 76, 77, 78, 78, 81, 81, 82, 84, 104, 114, 114, 122,
display 721 124, 126, 127, 130, 135, 138, 139, 140, 140, 144, 147,
in business services 701 151, 152, 154, 156, 156, 157, 167, 168, 168, 169, 169,
properties 721 169, 173, 191, 200, 208, 210, 211, 213, 214, 223, 227,
configuration item (CI) 228, 234, 246, 248, 262, 264, 264, 269, 269, 272, 274,
classification of 91 278, 278, 280, 280, 281, 284, 285, 287, 288, 289, 290,
configure 295, 295, 295, 296, 299, 301, 306, 307, 313, 313, 315,
Azure 1093 317, 319, 324, 326, 326, 332, 346, 351, 351, 352, 352,
Microsoft Azure Cloud 1093 353, 359, 361, 361, 363, 364, 365, 369, 369, 370, 371,
Service Mapping 702 375, 375, 375, 378, 380, 393, 398, 399, 410, 411, 411,
configure access to maps 636, 827 412, 414, 417, 419, 420, 420, 423, 426, 426, 427, 427,
configure access to services 636, 827 427, 428, 428, 429, 429, 430, 430, 430, 430, 431, 432,
Configure Amazon EC2 for Cloud Management 432, 433, 433, 433, 434, 434, 435, 435, 436, 436, 436,
regions 1079 440, 443, 447, 447, 447, 449, 449, 452, 454, 456, 458,
configure event collection 888 470, 471, 473, 474, 479, 479, 483, 484, 485, 485, 486,
configure user access to services 636, 827 495, 514, 730, 730, 730, 737, 762, 774, 787
configuring credentials 542 Service Mapping 515, 516, 517, 517, 517, 517, 522,
connectivity 522, 522, 523, 532, 533, 535, 537, 538, 538, 538, 540,
to VMware instance 1102 540, 542, 543, 561, 609, 609, 609, 612, 612, 612, 612,
Connectivity section 787 614, 614, 614, 614, 614, 614, 614, 614, 616, 616, 616,
content pack 486, 847, 1289 616, 616, 616, 616, 616, 617, 617, 617, 617, 617, 619,
Control user access to business services 826 619, 619, 619, 619, 620, 620, 620, 620, 621, 621, 621,
cost and usage reports 624, 624, 624, 624, 624, 624, 625, 625, 625, 625, 625,
cloud management 1245 627, 627, 627, 627, 627, 628, 628, 638, 642, 642, 642,
CPU selections 642, 644, 644, 644, 646, 652, 652, 652, 666, 696, 696,
VMware 1156 702, 702, 702, 702, 702, 704, 704, 704, 704, 704, 706,
create maintenance rule 952 706, 706, 707, 707, 714, 716, 719, 721, 721, 721, 728,
create or close alerts 932 730, 730, 730, 730, 735, 737, 748, 751, 762, 787, 792,
792, 795

delete Cisco UCS 365

snapshots 1233 configuring CIs to display SAM data 370
Delimited text parsing strategy 773 datastore 306
demo data 1073 Dell Remote Assistant Card discovery 363
deployment General Software Packages 398
create draft 1242 HBAs on Solaris computers 452
device HPUX computers 280
classification 84 IP addresses 351
device classification IP networks 352
Windows hosts Linux computers 284, 287
Windows Remote Management (WinRM) 107 Linux configuration for attached storage 447
direct access storage example 440 Linux KVM 285
discovering Microsoft IIS Servers 399
vCenter 1103 mod_jk module 375
DiscoverNow 35 mod_proxy module 378
discovery Netware 288
AIX computers 279 network devices 326
create an empty pattern 738 Network Printers 352
modify a pattern 788 Network Routers and Switches 353
Discovery references for storage via host 449
activation of 12 relationships 359
Add an SNMPv3 user credential in Discovery 78 SAM table schema 369
Add the must_sudo parameter to the Puppet probe 419 services and daemons 361
adding simple probes to multiprobes 272 software 369
Amazon Web Services (AWS) cloud 380 Solaris computers 289
application profile discovery 495 Solaris zones 290
Application Profile Discovery (APD) 486 storage devices 471
behaviors 191 TCP connections 351
classification parameters 104 Tomcat servers 420
computers 278 Uninterruptible Power Supply 361
configuration vCenter 301
introduction 54 via host 447
configuration console virtual machines 295
devices to discover 26 WebSphere DataPower devices 364
disabling classifiers 27 Windows computers 315
software to discover 26 Windows configuration for attached storage 447
configuration for standalone storage 470 Database 410
Configure AWS Admin account 51 datastore
configure Azure service principal 53 data collected by Discovery 306
configure Azure subscription 53 datastores 313
Configure the credentials for the AWS account 52 discover
configuring identity sensors 124 Active Directory 429
configuring probe parameters 264 Adobe JRun 426
Create a Discovery schedule for a web service 52 Enterprise Message Service 429
Create a Discovery schedule for an Azure subscription Exchange Client Access Server 431
54 Exchange Hub Transport Servers 427
create pattern 730 Exchange Mailbox 430
creating a schedule 28 GlassFish Server 432
credentials for HBase instances 280
checking IP service affinity 114 HP Operations Manager 427
customization HP Service Managers 427
Cancel sensor transaction by duration 168 IBM WebSphere Message Broker 430
Turn off collection of port data for SNMP network IBM WebSphere Message Broker HTTP listener
devices 169 430
customization of 168 IBM Websphere WMQ 430
DAS example 440 Microsoft SharePoint 433
dashboard MongoDB instances 411
adding reports 167 Oracle Tuxedo 432
components of 157 PostgreSQL instances 411
data collected SAP ASCS 436
A10 load balancers 332 SAP Business Objects CMS Server 435
Apache web servers 375 SAP Central Services 433

SAP CI 433 Puppet

SAP Development Infrastructure 434 Add the must_sudo parameter to the Puppet probe
SAP Evaluated Receipt Settlement 434 419
SAP HANA database 435 Puppet software 417
SQL Server Analysis Services 428 range sets, importing 69
SUN JES 436 run 514
Sybase 426 SCCM
Tibco ActiveMatrix BusinessWorks 428 Asset Intelligence scheduled imports 82
discovery pattern 730 tracking software with 84
Discovery patterns 762 SCCM integration 81
documentation links for 4 schedule
domain separation 76 excluding IP addresses in 73
domain separation setup 77 schedule for Amazon Web Services 51
error messages schedule for Azure subscriptions 52
no sensor defined, identifying 484 sensors 211, 264, 269, 269, 274
probe not found, identifying 485 serial number types 126
sensor, fixing 485 Set SNMP version on the Discovery schedule 81
sensor, identifying 483 shell script 371
ESX servers 307 SNMP MIBs 234
extended capabilities of 169 SNMP probe 227
guided setup 14 SNMP probe parameters 228
horizontal discovery log 154 SNMPv3 support 78
horizontal discovery process flow 8 software discovery
hyper-v 319, 324 clustered Windows applications 393
identifiers source name 55, 208
converting custom legacy identifiers 130 status 138, 140, 144, 147
legacy 127 Status 139
identity probes storage 436
configuring 122 storage data collected
IP addresses used 66 SMI-S and CIM 458
JBoss servers 281 sudo 375
layer 2 timeline 140
introduction to 346 use patterns 210
legacy identifiers vCenter probe upgrades 296
creating 135 Veritas Volume Manager data 456
Linux servers VMware infrastructure 295
HBA data collected 449 VMware relationships without ESXi server 313
list of probes 214 VMware vCenter 295
load balancers 326 VMware vCenter discovery and process flow 299
log 152 WebLogic application server 420
log retention 156 WebSphere application server 423
logs 151 what Discovery can discover 10
multipath fibre channel storage 443 Windows servers
networks 41 clustered discovery 317
NGINX web server 412 HBA data collected 454
Operating system level virtualization (OSLV) discovery application mapping
Docker introduction 474 UNIX 370
Oracle databases 414 Discovery behaviors
pattern designer load balancing 194
creating relationships and references between CIs Discovery classification 4
774 Discovery identification 4
pattern log 154 discovery messages
patterns Service Mapping 657
domain separation 737 Discovery overview 4
permissions 248, 262 discovery patterns
ports and protocols 246 set precondition 750
powershell 173 variables 751
PowerShell 169 discovery probes
PowerShell probe 223 horizontal pattern probe 223
probes 211, 213, 248, 262, 264, 269, 269, 274 discovery schedule
Service Mapping 638

discovery steps alert maintenance status 977

define 741 closure 952
manage 741 flapping
Docker detection 951
introduction to 474 incidents 952, 982
domain separated environment 737 launching web application 983
domain separation properties 951
Discovery 76 rules 944, 963
modify patterns 737 Alert and CI remediation 984
pattern 737 alert binding 934
domain separation setup alert correlation
Discovery 77 rules 1006
download alert group 825
billing data 1177, 1249, 1250 alert history 998
draft deployment 1242 alert monitoring 987, 990
Alert Timeline 993
alerts
E automatic acknowledge 952
EA credentials automatic closure 952
Azure 1096 closes incident 952
EBS 1121 Alerts 976
EBS snapshots Alerts Console 990
discovering 1122 assign role 826, 888
viewing 1122 AWS Config integration 1091
EBS volumes best practice 878
discovering 1121 bind alerts to CIs 934
viewing 1121 Bind CIs 936
EC2 business service
image permissions 1084 impact calculation 963
EC2 instance business service group 826
request 1216 change request 1001
edit a pattern 788 CI Bind 943
elevated rights 543 CI bound to alerts 943
email 849 CI infrastructure 967
email notifications CI Type Mapping 941
creating 900 collaborate 977, 989
entry point collect events using web service APIs 893
class 735 configuration 820, 947
type 735 configuration settings 878
entry points 630 configuring event correlation rules 1009
environment file connector 863, 881
customize 512 connector instance 863
errors correlated alert groups 1004
Service Mapping 657, 661 create alert group 994
ESX resource pools create incident 971
configuring 311 create security incident 971
ESX servers create task 971
discovery of 307 creating an SLA 849
eval 743 creating an SLA configuration 847, 848
event integration 849 custom connector 868, 878
event management custom connector definition 867
event Dashboard 987
external event source dashboards 987, 990
connector definition 867 discovery 830
connector instance 863 domain separation 829
service groups 635 Domain Support – Domain Extension Installer plugin
Event Management 829
activate 818 email connector instance 899
additional configuration 820 event
advanced view 923 create manually 901
alert rules 917
active interval 951 event field mapping 904

event field mappings 909 Event Management installed tables 831

event groups 933 Event Management purge data 830
Event Management collect events using external event Event Management SNMP traps 898
sources 893 Event Management SolarWinds connector instance 890
event rule 911 Event Management view events 857
group 1004 Event Managementclosure
HPOM connector instance 881 alert 860, 944, 944, 949, 951, 951, 952, 963, 971, 971,
impact 957 977, 977, 978, 982, 982, 983, 983, 983, 989, 994, 1004
impact calculation 957, 963 Event Managementincidents
impact tree 1001 alert 860, 944, 944, 949, 951, 951, 952, 963, 971, 971,
Impact Tree 999 977, 977, 978, 982, 982, 983, 983, 983, 989, 994, 1004
In Maintenance 1001 script include 982
incident security 982
closes alert 952 event mapping rules 849
installation 818 event rule 932, 1018
JavaScript script 868 event rules 849
license usage 943 eviction policy 1181
manual service 820, 992 evt_mgmt.alert_black_list_fields 931
Manual Services EvtMgmtCustomIncidentPopulator 947, 948, 949, 982
impact calculation 963 EvtMgmtCustomIncidentPopulator.populateFieldsFromAlert
MID Server) 982
ITOA MetricExtension 1036 example: populate a CI with a text file 276
MID Web Server 1039 extend VM lease 1230, 1242
Overview dashboard 1003 extension points
plugin 818 Cloud Management 1259
POP3 connector instance 899
rule 923
rule configuration 911
F
rules federated access
bind 939, 939, 940, 943 AWS 1082
processing for alerts 918, 922 fibre channel storage 443
processing for events 918, 922 field dependencies for image sizes 1120
SCOM connector instance 884, 884, 892 File type parsing strategy 770
SCOM group 888 Filter table
secure connection 1043 Conditions 757
service map 995 Filter table operation 757
Simple view 918 filter token 217
SLA configuration Find matching URL operation 756
limiting the SLA configuration records returned 848
technical service 823
technical services G
impact calculation 963
Get process operation 759
topology 995
Get registry key
use JSON objects as data input and output 893
Pattern Designer 661, 743, 743, 743, 743, 754, 757,
view correlated alerts 1008
759, 762, 782, 784, 787, 795
VMware vRealize Hyperic connector instance 883
Get registry key operation 759
VMware vRealize Operations connector instance 891
Getting started
Event Management alert 931, 947, 952, 977
Cloud Management 1057
Event Management alert action rule 949
grace period
Event Management alert rule 948
VMware lease 1180
Event Management AWS CloudWatch 899
group membership
Event Management configuration 819
VMware 1144
Event Management create CI automatically 859
guest customization 1161
Event Management custom connector 873
guided setup
Event Management custom metric connector 870
Discovery 14
Event Management documentation links 813
guidelines 849, 878
Event Management event 854
Event Management event threshold 932
Event Management external event source 896 H
Event Management high availability 898
Event Management installed components 833, 842, 843, handleMetric 870
845 hardware
Cisco UCS 365

WebSphere DataPower devices 364 Linux VMs

history view 686, 692 VMware 1161
horizontal discovery 4 load balancers
host bus adapter (HBA) A10 332
data collected by Discovery for 449, 454 Apache Web Server 335
supported adapters 449, 454 Cisco CSS 345
Cisco GSS 345
Citrix Netscaler 337
I F5 BIG IP 339
identity token 217 fields 328
image permissions HAProxy 342
EC2 1084 NGINX 344
impact calculation 952 tables 326
incidents 948, 949 lsof command
Index Token 218 using 373
installed business rules 843
installed components 831, 831, 842 M
installed properties 833
installed roles 842 Manage alerts in the Alerts Console 994
installed script includes 842 manual service
instances monitoring 992
configuring Azure 1093 Manually create events 901
IP address Manually send events 901
VMware 1150 Map
IP addresses Service Mapping 666
creating a quick range 67 map view
excluding in Discovery schedules 73 Service Mapping 696
importing range sets 69 mapping
IT operations management service mapping 515
applications 4 Mapping boundary 646
ITOM 4 mapping patterns 730
maps
Service Mapping 666
J Match operation 761
JavaScript connector 873 memory selections
JavaScript script 870, 873 VMware 1157
JBoss servers Merge table operation 755
discovery of 281 merged connections 677
JSON key/value format 931 merged connectors 677
merged edges 677
merging edges
K Service Mapping 696
MetricCollector 870
Key Token 218
Microsoft
Keyword, command, and positional type parsing strategy
SQL server clusters
772
discovering 401
Microsoft Azure Cloud 1109
L mid
POST 1052
last_kpi_signature 870 MID server
latency issues 849 configuration 728
layer 2 Discovery MID Server
introduction to 346 configure default for Service Mapping 706
LDAP query operation 760 configure for VMware 1101
lease ESX server 1101
configure for VM 1179 extensions
lease grace period configuring the SNMP trap collector 188
VMware 1180 configuring vCenter event collector 184
lease virtual resource SNMP trap collector 188
update 1230, 1242 vCenter event processor 180
Library reference operation 776 selection sequence for Discovery 40
Limiting mapping area 646 Service Mapping 702

MID Server algorithm 706 Describe Images 1266, 1266, 1266

MID Server configuration 1034 Describe Instances 1266, 1266, 1267
MID Server selection 706 Describe KeyPairs 1267, 1267, 1268
minimum free disk space Describe Regions 1268, 1268, 1268
VMware 1163 result values 1264
Modifying Run Instances 1269, 1269, 1269
mapping patterns 730 Terminate Instances 1270, 1270, 1270
monitor events 857 Orchestration VMware activities
monitoring tools notification 854 Add Disk 1272
My Team's Virtual Assets portal 1212 Change Network 1273
Change State 1273
Check VM Alive 1274
N Clone Alive 1275
Netcool connector instance 888 Configure Linux Alive 1276
Netflow 714, 716 Configure Windows Alive 1277
network adapter Delete Snapshot 1278
adding to VMware VM 1225 Destroy 1278
removing from VMware VM 1226 determining result values in 1272
network Discovery Discover Customization Specifications 1279
convert IPs to range sets 49 Get VM Events 1279
introduction to 41 Get VM Guest Info 1280
schedule for 45 introduction to 1271
Network Discovery 41 Reconfigure 1280
Network Flow Logs 719 Revert to Snapshot 1281
network path Snapshot 1281
Service Mapping 695 organize services in groups 635
Network Performance Monitor (NPM) 890 OS
NoEcho parameter support for non-English 728
CloudFormation template 1124
non-elevated rights 561 P
non-privileged user 561
non-sudo commands 561 Parameter Token 219
non-super user 561 Parse command output operation 762
Parse file operation 764
Parse URL operation 766
O Parse variable operation 767
occurrence of something of interest 854 Parsing strategies 769
offering selections Patten Designer
VMware 1154 add column to table 782
open Dependency Views 701 pattern
operating system value 743
support for non-English 728 variable 743
Operating system level virtualization (OSLV) pattern definition
Docker example 795
introduction for 474 pattern designer
introduction to 473 creating relationships and references between CIs 774
operation token 216 horizontal discovery 209
operational metrics 1052 Pattern Designer
Operations Insight Create connection operation 754
description 813 Filter table 757
operator pattern example 795
cloud_operator role responsibilities 1198 shortcuts 743
Oracle transform table 782
discovery of 414 troubleshooting patterns 661
Orchestration UI 743
credentials for user interface 743
checking IP service affinity 114 working with 743
for VMware 1062 pattern modes 788
PowerShell probe 223 pattern version 790
Orchestration Amazon EC2 activities pattern versions 788
Change State 1264, 1264, 1264 performance 849
Create Tag 1265, 1265

permissions Query Delimiter Token 218

AWS 1085 quick discovery 35
placement extension key script 1258 quick IP range
plan business services 616, 616, 617, 619, 620 creating 67
planning 849
Planning
service 666
R
populate 931 range sets 49
Port Probes 241 raw metric information 870
Post provision source object RawMetric 870
Azure instance 1262 reclassifying
EC2 instance 1262 ServiceNow Discovery
VMware instance 1263 workstation 109
PowerShell probe workstation
creating 226 ServiceNow Discovery 109
price regions
VMware resources 1160 AWS Cloud 1080
prices configuring Azure 1094
change for catalog items 1119 Regular expression parsing strategy 772
pricing remediation 849
VMware 1160 report
privileged user 543 AWS billing 1178
probe Azure billing 1178
WMIRunner 240 Resource Optimization 1246
probes reports
horizontal pattern probe 210 Amazon Resource Optimization 1248
upgrades for vCenter 296 AWS 1244
procedures 936 Azure 1244
process Azure cost and billing 1096
classification 96, 100, 393 Resource Optimization 1245
process alarms as events 899 reserved VMware resources 1203
process handler resource group catalog items
create 101 Azure 1138
Properties resource groups
installed components Azure 1240
Service Mapping 529 requesting Azure 1240
Properties installed with Event Management 831 subscribe to 1243
Properties Token 218 terminate 1243
provision update 1242
request for Amazon VM 1193 Resource Optimization report
Provision schedule 1246
VMware request 1201 resource utilization
provisioning Discovery 12
VMware 1201 resources
VMware requests 1198, 1199 discovering Azure 1095
Provisioning reserved VMware 1203
errors 1284 restore resource
provisioning rule assignments from snapshot 1233
Set by Filter 1183 result 216
provisioning rules retrieveKpi 870
assignments 1182 roles
VMware 1187 cloud operations 1059
pull connector 870 selecting for VMware 1102
Puppet Roles
Add the must_sudo parameter to the Puppet probe 419 installed components
automation software discovery 417 Service Mapping 532
push external events from monitoring tools 896 Roles installed with Event Management 831
put file 779 rules
provisioning 1185
Q
query 216

S customizing maps
merging connector lines 696
SAN storage Discovery 443 data collection 517
scale environment 849 Debug mode 748
SCCM discovery flow 517
Asset Intelligence scheduled imports 82 discovery patterns 730
integration with Discovery 81 Discovery patterns 762
tracking software with 84 discovery rule 642
schedule discovery schedules 638
application 638 domain separation 628, 702
applicative CI 638 entry point 735
snapshot Azure 1231, 1231 entry point connectivity 624
scheduled jobs 831, 845 F5 644
Scheduled jobs installed with Event Management 831 finalizing patterns 792
scheduler Get started 537
billing data download 1178 Guided Deployment 621, 624, 625, 627
SCPRelay Probe 226 import business services 614
script import entry points 614
on classification 100 import from CSV 617
script includes 831 Installation 537
Script includes installed with Event Management 831 IP address connectivity 624
scripted integration 896 load balancer 644
security lsof 522
cloud operations 1059 Mapping
security groups Checking results 646
AWS VPCs 1123 Discovery messages 646
segment of business service 652 Errors 646
Service Analytics documentation links 813 Results 646
service health mapping flow 517
monitoring 987 mapping patterns 730
service level management maps 666
cloud management 1170 MID Server
Cloud Management 1172 IP range 706
cloud provisioning 1170 MID Server algorithm 704
service mapping MID Server choice 706
service groups 635 MID Server pool 706
Service Mapping MID Server selection 704
activating 538 MID Server selection criteria 704
activation 538 MID Server selection parameter 704
add business services manually 620 Netflow 522
application permissions 612 netstat 522
application rights 612 network devices permissions 612
behavior 644 network devices rights 612
Best Practice 614, 616, 616, 617, 619, 620 new algorithm 704
business rules 535 OID 609
business service 614, 628 Pattern Designer 795
business services 516 patterns
check connectivity 624 domain separation 737
commands 543, 561, 609 plan 614
configuration 702, 702, 721 planned business service 624, 625, 627
Connect to existing service 652 planned entry points 624
Create new service 652 Planner 614
Create new service from here 652 planning
create pattern 730 create business service 621, 625
creating a traffic based discovery rule 642 discover business service 625
creating a traffic-based discovery rule 642 fine-tune business service 627
credentials 540, 542 fix business service 627
Credentials 537 implement 627
CSV file 614 map business service 625
customization 721, 730, 792 planning business service 616, 616, 617, 619, 620
customize map view 696 planning phase 616, 616, 619
populate phase manually 620

potential business services 617, 619 Split business service 652

PowerShell commands 707 SQL servers 399
Prerequisites 537 SQL SMO object 399
process 517 SSH Command Probe 235, 235, 239, 240
rctrlx.exe 702 stack templates
rights 540 CloudFormation 1123
roles 532 stacks
script includes 533 subscribe to 1243
setup 721, 728 update 1242
SNMP 609 starting
subscription 538 VMs 1229
supported applications 523 state changes
traffic 642 cloud assets 1230
traffic connections 522 statement 215
traffic related rule 522 stopping
traffic-based discovery 714, 716, 719 VMs 1229
variables 751 storage
video data collected via host 447
planner 614 Linux configuration for hosts of 447
Service Mapping configuration 702 references via host 449
Service Mapping> Windows configuration for hosts of 447
installed components 526 storage path
Service Mappingconfiguration Service Mapping 695
MID Server 702, 702, 706, 707, 707 string 743
service principal subscribe
configuring Azure 1094 to stacks or resource groups 1243
ServiceNow Discovery to VMs 1229
reclassifying subscriptions
workstation 109 discovering Azure resources 1095
workstation sudo commands 543
reclassifying 109 super user 543
services and dashboard 849 system performance 849
ServiceWatch
activating 538
business services 516
T
mapping flow 517 tables 831
Set by Filter Tables installed with Event Management 831
assignment 1183 tags
Set variable operation 778 assign in bulk 1176
Shazzam probe assigning Azure 1176
configure 244 for cloud resources 1174
size definition missing 1177
VMware 1155 restrictions on 1176
snapshot virtual resources 1174, 1282
restore resource from 1233 task template 947, 948, 949
schedule Azure 1231, 1231 task template library 948
snapshots task templates 849
delete 1233 template parameters
eviction policy 1181 CloudFormation 1123
SNMP 609 templates
SNMP probe Azure ARM 1138
loading a MIB module 233 for CloudFormation stacks 1123
modules 234 vCenter 1151
parameters 228 terminate
SNMP query operation 781 Azure VM 1188, 1234
SNMP trap collector resource groups 1243
configuring 188 VMware virtual server 1229
SNMP-based queries 609 token 216
Software Asset Management Template traffic connections 522
configuring CIs to display SAM data 370 traffic discovery 522
table schema and Discovery 369 traffic mapping 522
SolarWinds Service & Application Monitor (SAM) 890 traffic rule 522

Transform table operation 782 VM configuration

troubleshooting VMware 1146
Microsoft Azure 1283 VM lease
Troubleshooting 479 update 1230, 1242
troubleshooting maps VMs
Service Mapping 657, 661 managing 1214
troubleshooting patterns requesting Azure 1214
Service Mapping 661 starting or stopping 1229
subscribe to 1229
VMware
U activate 1098
Unchange user operation 783 catalog item 1151
Union table operation 784 catalog offerings 1155
update cloud administration 1101, 1111, 1154, 1158, 1159
resource groups 1242 cloud administrator tasks 1144
stacks 1242 configure 1055
update VM lease 1230, 1242 configure for Cloud Management 1102
upgrade 849 configure lease 1179
use cURL to send events 896 configure MID Server 1101
use of custom scripts 947 configure offerings 1158
user access configuring tags 1174
event management 635, 636, 827, 863, 867 connectivity check 1102
service mapping 635, 636, 827 CPU selections 1156
user groups credentials 1100
cloud operations 1059 Data disk size 1156
CloudFormation 1192 datastores 1162
user records 1077 errors 1282
ESX resource pools
configuration 311
V group membership 1144
IP address 1150
variables
is Orchestration required 1062
catalog items 1139, 1140
lease grace period 1180
vCenter
Linux VMs 1161
configuring datastores 1161, 1203, 1203
memory selections 1157
discovery 1103
minimum free disk space 1163
probe upgrades 296
offering selections 1154
templates 1151
Orchestration activities 1263
vCenter event collector
price calculation 1160
configuring 184
pricing 1160
events listed 184
provisioning 1201
vCenter event processor 180
provisioning rules 1187
Veritas Volume Manager
relationships to without ESXi server 313
data discovered for 456
request instance 1224
version file
requirements 1100
customize 513
reserved resources 1203
Vertical file parsing strategy 771
role selection 1102
Virtual Assets portals 1213
size definition 1155
Virtual Private Cloud 719
terminate virtual server 1229
Virtual Private Cloud Flow Logs 719
troubleshooting 1282
virtual private clouds
virtual machines 312
AWS 1120, 1120
VM configuration 1146
Virtual Private Clouds
Windows VMs 1161
security group details 1120
VMware Cloud
view details 1120
checkout redirect property 1158
view subnet details 1120
create catalog items 1154
virtual resources
installed with 1098
tagging 1174, 1282
VMware requests
Virtualization Provider
provisioning 1198, 1199
Provider handlers 1259
VMware support
VM
Add Disk activity 1272
configure lease 1179
Change Network activity 1273
terminate Azure 1188, 1234

Change State activity 1273

Check VM Alive activity 1274
Clone activity 1275
Configure Linux activity 1276
Configure Windows activity 1277
conversion function 1271
Delete Snapshot activity 1278
Destroy activity 1278
Discover Customization Specifications activity 1279
Get VM Events activity 1279
Get VM Guest Info activity 1280
introduction to Orchestration activities 1271
managed object browser 1272
managed object reference ID 1272
Reconfigure activity 1280
Revert to Snapshot activity 1281
Snapshot activity 1281
virtual machine UUID 1272
VMware templates 1155
VMware vCenter
discovery of 295
VMware vCenter discovery and process flow
discovery of 299
VMware virtual machine 1211
VMware VM
adding network adapter 1225
managing 1222
removing network adapter 1226
standard tags 1201
VMware VMs
requesting 1214
VPC Flow Logs 719
VPCs
AWS 1120
security group details 1120
security groups 1123
view details 1120
view subnet details 1120
W
WebLogic
sudo 423
Windows
data
help the help desk 324
Windows operating system
fetch data 240
Windows VMs
VMware 1161
WMI method invocation
Pattern Designer 661, 743, 743, 743, 743, 754, 757,
759, 762, 782, 784, 787, 795
WMI method invocation operation 784
WMI query operation 785
workstation
reclassifying
ServiceNow Discovery 109
ServiceNow Discovery
reclassifying 109

Servicenow Istanbul It Operations Management PDF

Uploaded by

Copyright:

Available Formats

Servicenow Istanbul It Operations Management PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Servicenow Istanbul It Operations Management PDF

Uploaded by

Copyright:

Available Formats

06/12/2018

Istanbul ServiceNow IT Operations Management

© 2018 ServiceNow. All rights reserved. iii

Explore Set up Administer

Use Integrate and develop Troubleshoot and get help

Probes, sensors, and patterns

© 2018 ServiceNow. All rights reserved. 4

it is triggered. A base set of probes and sensors is

© 2018 ServiceNow. All rights reserved. 5

device, such as memory, network cards, drivers,

Horizontal discovery and top-down discovery

There are actually two types of discovery:

Horizontal discovery The Discovery application performs horizontal

Top-down discovery Top-down discovery, which is a technique used by

Discovery and MID Servers

© 2018 ServiceNow. All rights reserved. 6

In addition to the MID Server, you need:

Discovery and Help the help desk

© 2018 ServiceNow. All rights reserved. 7

Functionality Discovery Help the Help Desk

Unix systems (Solaris, AIX, HP-

Horizontal discovery process flow

© 2018 ServiceNow. All rights reserved. 8

3. The classification phase begins:

4. The identification phase begins:

5. Finally, the Exploration phase begins:

© 2018 ServiceNow. All rights reserved. 9

Devices and applications that Discovery can discover

• Network device classifications:

© 2018 ServiceNow. All rights reserved. 10

• Email and messaging services:

© 2018 ServiceNow. All rights reserved. 11

• Tibco ActiveMatrix BusinessWorks*

Target Instance Instance on which to activate the plugin.

Note: Plugins are activated in

Reason/Comments Any information that would be helpful for the

Discovery resource utilization

© 2018 ServiceNow. All rights reserved. 12

© 2018 ServiceNow. All rights reserved. 13

Guided Setup Use this method if you want to set up everything

Use guided setup for MID Server and Discovery

1. Navigate to Guided Setup > ITOM Guided Setup.

© 2018 ServiceNow. All rights reserved. 14

2. Click Get Started.

© 2018 ServiceNow. All rights reserved. 15

© 2018 ServiceNow. All rights reserved. 16

3. In the MID Server pane, click Get Started.

© 2018 ServiceNow. All rights reserved. 17

© 2018 ServiceNow. All rights reserved. 18

© 2018 ServiceNow. All rights reserved. 19

© 2018 ServiceNow. All rights reserved. 20

Set up Discovery manually

2. Enable the Discovery plugin.

• If Basic Authentication is enabled, a username and password must be provided.

© 2018 ServiceNow. All rights reserved. 21

Validate discovery results on page 37

Running discoveries in your network

MID Server configuration prerequisites

Discovery configuration prerequisites