SMF M010 GilmoreBook PDF

Service
Mapping
Fundamentals
participant guide
Service Mapping Fundamentals
© 2019 ServiceNow, Inc. All Rights Reserved
© COPYRIGHT 2019 SERVICENOW, INC. ALL RIGHTS RESERVED.
ServiceNow provides this document and the information therein “as is” and ServiceNow
assumes no responsibility for any inaccuracies. ServiceNow hereby disclaims all
warranties, whether written or oral, express or implied by law or otherwise, including
without limitation, any warranties of merchantability, accuracy, title, non-infringement
or fitness for any particular purpose.
In no event will ServiceNow be liable for lost profits (whether direct or indirect), for
incidental, consequential, punitive, special or exemplary damages (including damage to
business, reputation or goodwill), or indirect damages of any type however caused even
if ServiceNow has been advised of such damages in advance or if such damages were
foreseeable.
TRADEMARKS
ServiceNow and the ServiceNow logo are registered trademarks of ServiceNow, Inc. in
the United States and certain other jurisdictions. ServiceNow also uses numerous other
trademarks to identify its goods and services worldwide. All other marks used herein
are the trademarks of their respective owners and no ownership in such marks is
claimed by ServiceNow.

Table of Contents
Module 1: Service Mapping Overview ................................................... 7
Lab 1.1: Navigate Service Mapping ............................................. 17
Module 2: Horizontal Discovery ............................................................. 37

Lab 2.1: MID Server Installation and Configuration……………………48
Lab 2.2: Run Horizontal Discovery .............................................. 64
Lab 2.3: Work with Process Classifiers ........................................ 70
Module 3: Service Mapping ................................................................... 76

Lab 3.1: Customer Preparation ................................................... 91
Lab 3.2: Map an Individual Service ............................................. 100
Lab 3.3: Map Services Suggested by Service Mapping ................ 110
Lab 3.4: Bulk Mapping ................................................................. 118
Lab 3.5: Bulk Error Handling ........................................................ 139
Lab 3.6: Create Technical Service………………………………………………146
Module 4: Service Lifecycle…………………………………………………………………149

Lab 4.1: Review and Approve Map..………………………………………… 162
Module 5: Extending Patterns ............................................................... 173

Lab 5.1: Delimited Text Parsing Strategy .................................... 197
Lab 5.2: Regular Expression Parsing Strategy ............................. 210
Lab 5.3: Work with UNIX Commands (Optional) ……………………… 216
Lab 5.4: Track Configuration Files (Optional)..………………………….. 228
Module 6: Building Identification Sections ............................................ 234

Lab 6.1: Build Discovery Pattern from Generic Application ......... 262
Lab 6.2: More Identification Section Configuring ........................ 277
Module 7: Building Connection Sections ............................................... 288

Lab 7.1: Build Connection Section ............................................... 301
Lab 7.2: Build More Connection Sections .................................... 311

Module 8: Use Cases .............................................................................. 334
Use Case 1: ServiceWatch ............................................................ 342
Use Case 2: Moodle ..................................................................... 353
Use Case 3: Presta........................................................................ 367
Module 9: CMDB Reconciliation (Optional) ........................................... 370

Lab 9.1: Hardware Identification & Reclassification .................... 391
Lab 9.2: Application Identification Rules ..................................... 402
Module 10: Event Management (Optional) ........................................... 409

Lab 10.1: Event, Incidents, and Changes...................................... 425
Lab 10.2: Map Errors and Flow Designer……………………………………439

*Optional time permitting
Service Mapping Fundamentals 7

Service Mapping discovers all services in an organization and builds a comprehensive map of all
devices, applications, and configuration profiles used in these services.

A service is a set of interconnected applications and hosts which are configured to offer a service to
the organization. A meter, service panel, breakers, fuses, wires, junction boxes, outlets, and switches
could all be considered components of the Electrical service.
This underpinning Electrical service rolls up and supports the larger home service. It would make
sense if you wanted to map the home service, to actually map the most important underpinning
services first and then create dependencies to them from the home service.
Service Mapping has the capability to connect to an existing service from a service making it
possible to create relationships between services.

Service maps show infrastructure objects and semantic connections between them. Service
Mapping regenerates 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 service.
You can display service maps created by Service Mapping on the Event Management dashboard.
With Event Management, you can view alerts on critical CIs in order to take actions to remediate
issues on your organization's services.

IT Operations Management has become more critical and more difficult than ever before, with
virtualization and cloud technologies creating dynamic, fluid IT environments.
Service Mapping, ServiceNow’s service discovery and mapping solution, ensures that everything is
being done in a service centric context. When issues arise, Event Management can detect
abnormalities and pinpoint the impacted service by leveraging the CMDB.
IT can increase agility and lower costs by consolidating legacy tools into a modern, easy-to-use
service management solution in the cloud.

ServiceNow provides a wealth of products to support all levels within the Service Operations
Maturity path. This class focuses on the Service Mapping product which is part of phase 3. However,
it does touch upon Discovery and Event Management which is part of phase 1.

The problem is that there are usually no maps that show which IT components work together to
deliver a particular service. For example, a customer portal may depend on multiple applications,
middleware, virtualized and physical servers, network connections, and storage. When any of these
components or the connections between them fail, the service is impacted. Without a map that
shows the relationships, it is almost impossible to know why a service is down or performs poorly. If
there is a map, it is usually “tribal knowledge” in the minds of a few experts, and if it is documented,
it is almost always inaccurate.
Similarly, when a particular IT component fails or experiences performance issues, there is no easy
way to know which services, if any, are affected by the problem. Without this knowledge, it is
impossible to determine which are the most important problems to address first. For instance, an
infrastructure incident that has taken down an airline booking system that delivers millions of
dollars of revenue each hour is more important than fixing one that affects office supply orders, but
without a map, you cannot identify which is which.
The same applies to changes to IT infrastructure, where the growth of virtualization and cloud
causes regular changes. Unless IT components can be mapped to these services, changes are
unacceptably risky. To manually apply this information before you make a change is an incredibly
time-consuming process, which means your IT organization has to sacrifice agility or accept
heightened risk.

Estimated Time to Complete:
Lab 1.1: Navigate Service Mapping (15 minutes)

Lab
Navigate Service Mapping 01.01
615m
Lab Objectives
Cloud Dimensions just purchased Service Mapping and wants to become familiar with the
Service Mapping application and identify key modules and configuration areas.
In this lab, you will complete the following tasks:

• Navigate the Service Mapping and Discovery Applications
• View Discovery Patterns and Credentials
• View the MID Server module and Schedules
Access ServiceNow Training Instance
• Open any browser and enter the URL for the ServiceNow training instance provided by
your instructor or obtained from the reservation URL at the start of class.
• Log in using the username and password provided.
Service Mapping and Discovery Applications

1. Navigate to Service Mapping > Administration > Discovery Dashboard.
Note: After the initial discovery, the Discovery Dashboard will light up with valuable data
around discovered devices, applications, errors, schedules, and unused credentials.
2. Navigate to Service Mapping > Home.
Note: A message appears that Service Mapping is not ready for discovery. The Home page is
the starting point for all Service Mapping discoveries and allows a Service Mapping
administrator to access Service Mapping workflow tasks. This page also displays important
progress statistics. For example, view the number of services discovered with errors, waiting to
be approved, and completed.
3. From the bottom of the Home page, click the Additional Options link to view the
options available.

4. From the top right of the Home page, click the Readiness Checklist icon to view a list
of tasks that need to be completed.
5. From the Readiness Checklist, click Done.
6. From the top right, click Map Status to bring up the Service Mapping Dashboard.
Note: The dashboard provides an up-to-date overview of the status of all service maps in an
organization, progress on error (tasks that are associated with mapping errors, counts of error
tasks, and other tasks associated with services.
Discovery Patterns
Discovery Patterns attempt to identify applications and their outbound connections
supporting the Business Service. Application CI data and their attributes captured from the
patterns are associated to the CI in the CMDB.
1. Navigate to Pattern Designer > Discovery Patterns.

2. From the List controls menu, click Create Favorite to save this menu as a favorite in
order to simply navigation to this module in future labs.
3. From the Create Favorite form, click Done.
Note: Favorites are easily accessible from the left navigator under the Favorites icon.
4. From the Discovery Patterns list, search for and open the Apache on Windows
record
Note: A new tab opens and displays the pattern. A pattern is responsible for identifying a
specific CI Type/class. This CI Type corresponds to a table extended from the Application
Configuration Item [cmdb_ci_appl] table in the CMDB.

The Pattern opens in a new tab and contains three sections:
• Identification Section: used to identify applications by performing a series of
identification steps by reading configuration details exposed by the CI.
• Extension Section: used to modify the discovery logic in identification sections without
changing the identification sections themselves.
• Connection Section: based on the results of the identification section, the connection
section steps are attempted to identify any outgoing connections from the identified
application.
Note: In future modules in this class, you work more in depth with modifying and building your
own Pattern, Identification, and Connection Sections.
5. Click and open the first record under the Identification Section.
Note: The Pattern Designer opens and displays all the steps that comprise the Identification
Section. You will work with Identification Sections more in detail later in the class.
6. Click the browser back button to return to the Apache On Windows pattern.
Discovery Credentials
Credentials must be defined before a device can be successfully discovered. Without proper
credentials, the discovery process cannot complete.
1. Close the Apache On Windows pattern browser tab, and navigate to Service Mapping
> Administration > Credentials.
Note: Discovery and Service Mapping use credentials that are stored in the same table and can
be shared between both applications. Credentials are used to access target devices in order to
query them for specific attributes.
2. Click New and view the different credential types.
Note: You will be creating several credentials later in class to discover the numerous CIs in the
training environment that support various Business Services.

MID Servers and Discovery Schedules
1. Navigate to Service Mapping > Administration > MID Servers.
MID Servers subscribe to messages published by an Asynchronous Message Bus (AMB) on the
ServiceNow instance, which notifies the MID Server that it has pending tasks in the ECC queue.
The tasks are in the form of a Probe or Pattern. MID Servers use the credentials defined in the
Credentials table to access devices to perform their work. In the next lab, you will set up a MID
Server.
2. Navigate to Discovery > Discovery Schedules.
Note: Discovery Schedules under the Discovery menu define how often infrastructure
configuration items such as servers, routers, and switches are discovered.
3. Select Quick Discovery.
Note: Quick Discovery is used to discover a single target IP address. This discovery method is
useful for testing discovery against a specific CI without having to build a schedule. It is
important to note that the underlying discovery process is the same between Quick Discovery
and a complete discovery schedule. The main difference is Quick Discovery is a faster method to
configure discovery of a single device while creating a discovery schedule can be useful for
rediscovery on a scheduled basis.
4. From the Quick Discovery dialog window, click Cancel.
5. Navigate to Service Mapping > Administration > Discovery Schedules.
Note: Discovery Schedules under the Service Mapping menu define when and how often Service
Mapping discovery, also known as top-down discovery, will execute on a scheduled basis.
Service Mapping schedules define how often an application or set of applications are discovered
that pertain to a service.
6. Select and open the All Applications Discovery Schedule.
Note: This baseline schedule defines the CI Type discovered by the schedule, the frequency of
the schedule, and the MID Server to use. The Discover field is read only and does not allow the
user to modify the type of discovery to perform. All other types of Discovery have to be
performed under the Discovery > Discovery Schedules menu.

REVIEW QUESTIONS:
Based on the navigation skills learned, answer the following questions. Refer to the end of
the lab to check your answers.
1. How many identification sections are configured for the Microsoft SharePoint
pattern?
2. In the IIS discovery pattern, what IIS versions are listed in the identification section?
3. What field is used to define the frequency in a discovery schedule?
4. How many different credential types exist in a baseline instance?

REVIEW ANSWERS:
1. One
2. IIS6 and IIS7
3. The Run field
4. 18

Even if IT operations work in technology silos, you might think it is reasonable that there are existing
service dependency mapping software solutions: tools that discover all of the IT components along
with their relationships, but this is not the case.
Most IT infrastructure discovery tools perform “horizontal discovery.” This means that they discover
individual technology domains, not end-to-end service flows. They discover all the servers,
databases, storage, and so on, but each domain is disconnected. They may discover direct
connections between individual IT components, as shown in the diagram, but they do not take a
vertical slice through the entire IT infrastructure to show how a service is delivered. Because of this,
they do not answer the fundamental questions: How do individual IT components issues and
changes affect specific services? And how do you isolate the root cause of service problems?
It can take weeks to sift through horizontal discovery data to find out how a single service is
delivered end-to-end. The process is not just a mechanical one; traditional discovery data is
insufficient to map service flows. IT staff have to sit down with multiple stakeholders, gather tribal
knowledge, and then construct the service map. This often requires multiple iterations to generate
an accurate map, and the process has to be repeated every time there is an infrastructure change. It
is not unusual for an enterprise to have 100 or 200 services that need to be mapped, thus the effort
required is overwhelming.

ServiceNow Discovery provides the following capabilities:
• Finds everything, whether it’s helpful or not

• Identifies all devices located in an IP address range and is very good in addressing all IT devices
from an inventory perspective for an Asset Management initiative.
Valid use-cases include inventory, software licensing, CMDB population, desired state validation by
providing actual state data, and CI relationship mapping to support incident, problem, and change.

Applications are mapped from an application to application and an application to host perspective
without any service awareness. ServiceNow Discovery provides this capability.

Service Mapping provides these capabilities:
• Only discovers components of the service and ignores everything else

• Allows IT Operations to become Service-Aware
• Provides a targeted discovery of the IT infrastructure directly related to the service. Top-Down
discovery discovers only the IT components that support the provisioning of the service

In this demo, you will see the end result of a top-down discovery with Service Mapping vs.
ServiceNow’s bottom-up discovery using Discovery. The main takeaway is that ServiceNow
Discovery, like all horizontal discovery tools, does not automatically discover a service and all of its
underlying infrastructure.

In order for Service Mapping to successfully discover a service, several key components are involved
including:
• MID Server: allows the Service Mapping application access to the target CIs within a company
network
• Discovery: responsible in discovering host CIs such as servers, routers, and switches that
comprise a service
• Discovery Patterns: identifies applications and connections related specifically to a service
• Identification and Reconciliation: acts a centralized and configurable method to determine inserts
and updates to the CMDB including the host and application CIs that comprise a service

ServiceNow is normally hosted in a ServiceNow datacenter, and it does not have the ability to access
a customer’s enterprise network directly. Many enterprises have multiple networks, often separated
by slow WAN links or security barriers, and Service Mapping needs access to all of them.
Service Mapping uses special server processes, called MID Servers installed on each enterprise
network that has computers and applications that will be discovered and mapped.
Each MID Server is a lightweight Java process that can run on a Linux, Unix, or Windows server. A
dedicated server is not required as the MID server's resource consumption is very low and is
controllable. The MID Server's job during Service Mapping is simply to execute work (probes) and
return the results back to the ServiceNow instance for processing (with sensors); it does not retain
any information. In effect, a MID Server is a remote extension of the ServiceNow instance on an
enterprise network.

The number of MID Servers required and where they should be placed depends on an organization's
needs. If devices and applications need to be mapped inside a private network, place the MID
servers inside the private network. If devices and applications that need to be mapped are located
in the DMZ, place the MID servers both in the DMZ and inside the private network.
MID Servers can have IP Ranges associated to them to prevent them from being assigned work for
targets that they cannot reach.
Note, for performance improvement, a MID Server can be added to both a load balancing cluster
and a fail-over cluster. MID Server clusters are available for Discovery, Service Mapping, Event
Management, Orchestration, and used with products integrating with ServiceNow.

The ServiceNow CMDB is populated by three methods:
• Horizontal discovery
• Top Down Service Mapping
• 3rd party sources such as home grown or other vendor discovery application
With ServiceNow’s automated identification and reconciliation framework, the attributes of

configuration items are accurately and carefully populated only by the “trusted sources” as
configured for each class or selected attributes.

1. Horizontal discovery finds everything within a targeted IP range, whether it’s helpful or not. Top-
Down Discovery only discovers components of the service and ignores everything else. Allows IT
Operations to become Service-Aware.
2. More easily discover, map, and monitor services. Make IT more Service-Aware.
3. ServiceNow instance, MID Server, Access to Targets, Port 443 access between MID Server and
ServiceNow instance.

Service Mapping uses MID Servers that are installed on each enterprise network that has hosts,
applications, and service that need to be discovered and mapped. Each MID Server is a lightweight
Java process that can run on a Linux, Unix, or Windows server. A dedicated server is not required as
the MID Server's resource consumption is very low and is controllable.
The MID Server's job during discovery is simply to execute work (probes) and return the results back
to the ServiceNow instance for processing (sensors); it does not retain any information. In effect, a
MID Server is a remote extension of the ServiceNow instance, on an enterprise network.

In addition to the above ServiceNow applications, the MID Server is used for other integrations
including:
§ Import Sets
§ Altiris
§ Microsoft SMS / SCCM
§ LANDesk Maintenance
§ Avocent LANDesk
§ HP OpenView Operations
§ Microsoft System Center Operations Manager (SCOM)
§ Borland StarTeam Integration
§ Microsoft MIIS
§ Service Assurance

The MID Server can be installed with other services. It is important to be aware that it is dependent
on server utilization and resource availability.
The size and complexity of your network may require the deployment of multiple MID Servers. The
default memory allocated to the MID Server is 1024MB. Generally, it is recommended to have a
separate MID Server, if using it for a different purpose, such as for a Web Services SOAP call, JDBC
query or Orchestration activity. If trying to gain performance enhancements from Discovery, it is
recommended to install a second MID Server on a completely separate system to obtain the
greatest benefits from configuring a MID Server load balanced cluster.
*If installed on a 64-bit Linux systems, the 32-bit GNU C library (glibc) must be installed. MID Servers
installed on Linux are limited to discovering only UNIX based systems, vCenter, SNMP, and CIM
devices with no Windows discovery.
**It is recommended to install MID Servers on Windows based operating systems to allow them to
discover both UNIX and Windows targets.
*** For more information on the system requirements, search for “MID Server System
Requirements” on the Docs site.
NOTE: The MID server is regularly installed and tested on Windows Server (2012, 2008 & 2016) and
Linux (Red Hat 6, Ubuntu 12, CentOS 6).

Each configuration activity provides the following resources to help you:
• Contextual embedded help
• Links to comprehensive documentation on the ServiceNow product documentation site

1. Create the MID Server user account and assign the mid_server role to it.
2. From the server, where the MID Server is to be installed, navigate using a web browser to a
ServiceNow instance, and from the MID Server application, download the appropriate zip file
containing the MID Server installation files.
3. Extract the zip file to a directory of choice.
4. Run the MID Server Installer.
5. Verify the service is up and running and configure the service account to use either a local or
domain admin.
6. Verify the MID Server registered successfully with the ServiceNow instance and has a status of
Up, and then from the MID Server record, click the Validate UI Action.
Local System is the default account used by Windows Services. It has a lot of capabilities, but only
on the system it runs on. To be able to access other systems on the network, the account used
should be a domain account or an account that is the same on other systems and can use “pass
through authentication.”
This version supports both 32 bit and 64 bit MID Servers. For the best performance, install the 64 bit
MID Server for your operating system and that ServiceNow will discontinue support for 32 bit MID
Servers in a future release.
Upgraded MID Servers might use different Java versions depending on their release level. MID
Servers upgraded from Kingston and earlier use the OpenJDK provided with the MID Server installer.
MID Servers upgraded from London continue to use the same JRE you configured for London. The
MID Server supports JRE 1.8.

Allow ALL applications: Allow all applications that use MID Servers to use this MID Server.
Allow ALL capabilities: Allow all capabilities to be used for all ITOM applications.
Note: Service Mapping and Service Analytics, which used capabilities in previous releases, rely on
the application for MID Server selection starting with the Istanbul release.
Allow ALL IP ranges: Make all IP ranges valid for this MID Server, meaning that it can target any IP
address.

Classroom Training Environment consists of the following:
Service Name Description

Americas Warehouse Management Portal Win2K8R2 (IIS)
EMEA Customer Support Win2K8R4 (Mongoose)
APJ Warehouse Management Portal Win2K8R3 (IIS)
Americas Stock Trader (Front End) Win2K8R2 (IIS)
Americas Stock Trader (Back End) Win2K8R2 (MSSQL Server)
EMA Dispatch Scanning Service Win2K8R5 (Apache, Tomcat, HSQLDB)
Americas Calendar Portal (Entry Pt) Ubuntu (HA Proxy LB)
Americas Calendar Portal (Cluster) Cluster-WinServer (Tomcat 1)

Estimated Times to Complete:
Lab 2.1: MID Server Installation and Configuration (15 minutes)

Lab
MID Server Installation and 2.01
Configuration 615m
Lab Objectives
Cloud Dimensions has decided to implement ServiceNow Service Mapping. As part of the
readiness phase, it is necessary to install and configure a MID Server in their environment.

• Create MID Server User
• Install and Configure MID Server
• Verify MID Server is Subscribed to AMB
• Validate MID Server
Requirements Summary
• Access to a ServiceNow instance

• Administrative access to a Windows Server on EC2 via RDP to install the MID Server

Before you begin, complete the chart below based on the information obtained from the
ServiceNow instance reservation page or notification for self-paced users. The below entries
will provide important connectivity and credential information with respect to your personal
ServiceNow instance and your personal Windows Server on Amazon EC2.
ServiceNow Instance URL
ServiceNow Instance Username/Password
Windows Server Public IP and Fully Qualified

Domain Name (FQDN) (used to RDP)
Windows Server Private IP (Starting with 198.51)
Windows Server Administrative

Username/Password
Note: If you cannot complete the chart above, please ask your instructor for assistance.
A. Create MID Server User

A MID Server user, with appropriate credentials, needs to be configured to allow the MID
Server to communicate with the ServiceNow instance.
1. Logged into your ServiceNow instance as the System Administrator, navigate to User
Administration > Users.
2. Click New.
3. In the User ID, First name, Last name, and Password fields, enter midserver.

4. Select the Additional actions menu and choose Save.
5. From the midserver user record, under the Roles related list, click Edit and add the
mid_server role by double clicking on it to the Roles List as shown.
6. Click Save.
7. Click Update.
Note: Numerous SOAP roles are added via inheritance. The MID Server user account will be
used later when configuring the MID Server on your Windows Server.
B. Install and Configure MID Server

The MID Server provides access for the ServiceNow instance to communicate with a
customer network.
1. Create a remote desktop connection to your Windows Server on Amazon EC2 using
the public IP or FQDN listed previously.
2. Log in to your Windows Server using the administrative credentials listed earlier.
3. From the remote Windows Server on EC2, navigate to C:\MID Server\agent.
Note: MID Server installation files have been previously downloaded and extracted to this
folder location..
4. Double-click the Installer.bat file.
5. Click Run.
Note: The ServiceNow MID Server Installer window may take a short while to display.

6. Complete the form with your instance URL and the midserver user credentials
created earlier.
7. After completing the form, click Test your connection and verify you receive a
message, Connection tested successfully.
8. Click Next and complete the MID Server name as shown:

• MID Server name: MID Server
Note: The wrapper name and display name are populated automatically.
9. Click Next to view the Configuration summary.
10. Click Next.
11. Click Start MID Server.
12. Click Exit.
C. Configure Service Account

1. From the Windows Server, navigate to Start > All Programs > Administration Tools >
Services.
2. Locate and double-click on the ServiceNow MID Server service to open the
properties window.
3. Under the Log On tab, select the This account radio button and configure the
account and password with the Windows user information you used to RDP to the
Windows server.
4. Click OK and then click OK again to the pop up message.
5. Right-click the ServiceNow MID Server service and select Restart.
Note: If you receive an error when restarting the MID Server, start the MID Server again and
the error should resolve.

D. Verify MID Server is Subscribed to AMB
The AMB Channel serves as a messaging service between the ServiceNow instance and the
MID Server. It notifies the MID Server when there are jobs to process.
1. Wait 30 seconds to give the MID Server time to restart, then from the Windows
Server, navigate to C:\MID Server\agent\logs.
2. Make a copy of agent0.log.0.
3. With WordPad, open the copy of agent0.log.0.
Note: When the MID Server is started, the MID Server process locks the log file from being
opened. You are making a copy of the log file in order to view its contents without the need to
stop the MID Server service. In addition, during training, it is recommended to open all Windows
files using WordPad versus Notepad, as some files may appear corrupted otherwise.
4. Search for last log message containing AMB, and verify it states, Subscribed to AMB.
Note: If you see the message, Subscribed to AMB, move to the next section of this lab.
Otherwise complete the remaining steps in this section of the lab.
5. From your ServiceNow instance, navigate to the MID Server user account you
created earlier.
6. Open the record and verify Web service access only is not checked.
7. If Web service access is checked, uncheck it, restart the MID Server service, and
repeat the first 4 steps of this section to verify that your MID Server is subscribed to
AMB.
8. To restart your Windows Server, navigate to Start > Administrative Tools > Services.
9. Right-click on the ServiceNow MID Server_MIDServer service and select Restart.
Note: If the MID Server is not subscribed to AMB, discovery will still work, however it will take
substantially longer.

E. Validate MID Server
The MID Server must be validated in ServiceNow to verify that it can pass information from
the customer network to the ServiceNow instance.
1. Toggle back to your ServiceNow instance.
2. Navigate to Service Mapping > Administration > MID Servers.
3. Open your MID Server record.
4. Under Related Links, click Validate.
5. From the Set Initial Selection Criteria dialog window, click Save.
6. After a few seconds, from the MID Server list, verify your MID Server displays with a
Status of Up and Validated is Yes.
Note: The validation process can take up to a minute to complete in some cases.
8. Click the Readiness Checklist icon.

9. Navigate to MID Server > Dashboard.
Note: The MID Server dashboard is a central place for MID Server users to monitor ongoing
operations. The dashboard consists of reports and gauges that display information from the
MID Server Status table.
Congratulations, you have completed the successful setup of a MID Server.
Lab Validation (Optional):
ServiceNow offers an Automated Test Framework that is used in this class to check if records
were correctly created during each lab. Run these tests if you would like to check completion
of each lab.
1. Navigate to Automated Test Framework > Administration > Properties.
2. Verify the first property to enable the test/test suite execution on your instance is
checked, if not, check the box and click Save.
3. Navigate to Automated Test Framework > Tests.
4. Open the 02.01-SMF-K010-MID Server Installation and Configuration record.
5. Click Run Test.
6. If the test fails, then click Go to Result.
7. Open the record with a Status of Failure.
8. Read the Description to see the why the failure happened. There should be mention
of at least one record that does not meet a query condition. Based on the condition,
you should be able to isolate where the problem occurred.
Note: If needed, there is also an option to deactivate a problematic step to verify the remaining
steps complete successfully.

9. Locate the step in the lab where the error occurred and resolve the problem.
10. Run the same test again.
Note: If the Run Test window displays a message of Succeeded 100%, you passed the test and
your lab work has been validated. Nice work.
Note: There may be situations where you successfully completed the lab and the test script fails
due to different naming conventions between what you entered and what was written in the
book. It is recommended to complete the labs using the same naming conventions to avoid this
situation.
As a reminder, this is an optional lab validation. If you are satisfied with your
work on a lab, you DO NOT have to work through the errors, if any occur, when
running this lab validation to be 100% successful.

After the Windows MID Server is installed and configured, it is possible to test and run your first
discovery. Two options are available, an administrator can do a Quick Discovery or create a
Discovery Schedule. The target IP can be configured as 127.0.0.1 which is a loopback address for the
localhost where the MID Server is installed. Either option uses the same Discovery process.
The MID Server itself is a good candidate to target for the initial discovery since connectivity and
credentials have already been validated during the MID Server installation and configuration. The
credentials that will be used for this initial discovery will be the local or domain user account
defined when setting up the MID Server originally.
Creating an initial basic schedule is simple; only a few fields need to be configured. Common fields
are Name, Discover, MID Server, and Discovery IP Ranges. After the Discovery Schedule is
configured, the UI Action titled Discover now will launch discovery leveraging the MID Server
defined and the target IP addresses listed.

After the schedule is configured and saved, a UI Action titled Discover now can be used to launch
discovery or the schedule can auto execute at a prescribed time each day, week, month etc. The
Discovery Status can be used to monitor the discovery process all the way to completion.

Port Scan Phase:
When Discovery is initiated, the Shazzam probe is launched to detect open ports on devices in the
network. The data returned is used by the Shazzam sensor to identify certain characteristics about
these devices based on the activity known to exist on these ports. For example, UNIX-based
operating systems communicate with the SSH protocol over port 22, and Windows communicates
with the WMI protocol over port 135 or higher. Discovery makes certain assumptions about the
host, applications, and processes running on these ports and launches the appropriate classify
probes to find out more.
Classification Phase:
Classify sensors process the data returned from the probes and compare it with configured criteria
for each class of host. What are you specifically? Windows 2008, Windows 2012?
Identification and Exploration Phases:
Patterns unify the identification and exploration phases of discovery. Discovery determines which
classifier to use based on the class of the CI and the criteria specified in all CI classifier records. The
classifier specifies the Horizontal Pattern probe, which in turn specifies which pattern to launch. The
Horizontal pattern probe also contains a sensor which does the actual work of updating the CMDB.
The operations in the pattern specify the actions that Discovery needs to take for both the
identification and exploration phases for both the host and then the discovered applications.
Discovery knows which identification rules to use based on the CI type in the pattern, and Discovery
makes inserts or updates to the CMDB based on these rules.

Host (Device) Detection and Top-level Application Mapping
Step 1 –Discovery is initiated.
Step 2a – if any of the first three phases of discovery fail, no host CI will be created.
Step 2b – If all the classification phase completes successfully, the host CI will be identified and
explored and eventually the host CI will be created or updated in the ServiceNow CMDB depending
on identification and reconciliation rules.
Step 3 – Identification and exploration of an application occurs after identification and exploration
of a device. Determination if an application CI is created or updated will depend on identification
and reconciliation rules.
NOTE: Under the ECC Queue tab of the Discovery Status, the phases and messages being passed
between the instance and the MID Server can be viewed. Clicking the Created date and time will
open another form where the XML payload can be viewed of either the output or input message.

The Dependency View map shows the application to application and host dependency mappings.
Some examples are:
§ PuTTY depends on SSHD (app to app dependency)
§ PuTTY runs on Windows Server (app to host dependency)
Based on the TCP connections discovered for different applications, Discovery will create the
application to application dependencies automatically.

Process Classification allows Discovery to create a particular application 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. As close to targets as possible.
2. The default polling interval is set to 40 seconds, but can be reconfigured. The MID Server
subscribes to messages published by the Asynchronous Message Bus (AMB) Client, which
notifies the MID Server that it has pending tasks in the ECC queue. The MID Server polls the ECC
queue on the interval defined in the mid.poll.time configuration parameter (default is 40
seconds), regardless of AMB message activity. This polling of the ECC queue at a regular interval
is done in case the AMB connection is dropped.
3. Port (Shazzam), Classification, Identification, and Exploration.
4. Using Process Classifiers. Within a process classifier, Discovery can use patterns, rather than
probes, to identify applications. Discovery triggers patterns from the Horizontal Discovery probe,
which can be specified on the process classifier record.

Lab 2.2: Run Horizontal Discovery (15 minutes)

Lab 2.3: Work with Process Classifiers (15 minutes)

Lab
Run Horizontal Discovery 02.02
615m
Lab Objectives
Cloud Dimensions has a MID Server installed and configured and wants to understand the
basic concepts around running horizontal discovery, viewing the discovery status, execution
times, and seeing discovered CIs within their CMDB, along with all the attributes collected.

• Run Discovery and View Status
• View Discovery Status Details
• View Discovery Timeline
• View Discovered CI in CMDB
Requirements Summary
• MID Server installed and configured in training environment

A. Perform a Quick Discovery
Quick discovery allows for a simplified method of discovering a CI without creating a
discovery schedule. A key point is that the discovery process is the same between running it
with quick discovery versus a discovery schedule. However, with quick discovery, no
schedule is required, therefore it provides a method to discover a single IP in the easiest way
possible.
1. Navigate to User Administration > Roles.
2. Search for the role, discovery_admin, and read the description of this role.
Note: From a security perspective, an individual can be granted this role if they need access to
the "Discovery" and "Discovery Definition" applications to configure, monitor, and run Discovery
operations without granting full ServiceNow admin capabilities.
3. Navigate to Discovery > Discovery Schedules.
Note: You may want to create a favorite to the Discovery Schedules module for easy access in
the future.
4. Click the Quick Discovery button.
5. Enter the following information:
Note: Replace PrivateIP with the Private IP Address of your Windows Server. It starts with
198.51… If you did not write down the IP Address earlier, you can RDP to your Windows server,
open a command prompt, and type in ipconfig to obtain it.
6. Click OK to start the discovery process of your Windows Server and to display the
Discovery Status list.
7. Open the Discovery Status record.
8. Under Related Links, click Refresh until the State displays Completed.
Note: Discovery should take approximately 1 minute to complete.

B. View Discovery Status Details
1. Click the various tabs (related lists) to view the details of the Discovery Status.
• Discovery Log: details discovery issues such as failed credentials, inaccessible ports,
firewall issues, services not running, and reconciliation rules used around the current
discovery
• Devices: details a list of devices that were discovered and created or updated
• ECC Queue: details the XML payload sent and retrieved between the ServiceNow
instance and the MID Server and could help identify potential issues for unexpected
results
2. Under the ECC Queue related list, sort the Created date in ascending order, and
view the various probe records to view the linear deployment of probes retrieved by
the MID Server (outputs) and XML Payloads returned from the MID Server (inputs).
C. View Discovery Timeline

1. Under the Related Links, click Show Discovery timeline.
2. Hover over the Shazzam bar to view details for the Shazzam probe.
Note: Communication times between the MID Server and the ECC Queue record are provided.

D. View Discovered CI in CMDB
1. Close the Discovery timeline tab and toggle back to the Discovery Status form and
click on the Devices tab.
2. Under the CMDB CI column, click the link to the discovered device.
Note: You are automatically navigated to the Configuration Item (CI) record in the CMDB.
3. Right-click the form header and select Configure > Form Layout.
4. Add the Discovery source to the Selected pane under the Assigned to field.
5. Click Save.
Note: The discovery source that created or updated the record is listed. In this example,
ServiceNow is listed as the discovery source.
6. Under Related Links, click Show Discovery events to view a summary of when the CI
was created.
7. Click the browser back button to return to the Windows Server form.

8. From the Windows Server form, select the Additional actions menu and choose
Show XML.
Note: This option, available to administrators, displays all data in XML format associated with
the record. The information can be useful if you want to look up a value of a field quickly even if
it is not displayed on the form.
9. Close the XML document.
10. Navigate to Discovery > Dashboard.

• How many new devices were discovered in the last 7 days?
• How many new applications were discovered in the last 7 days?
E. Create Credential
1. Navigate to Discovery > Credentials.
2. Click New.
3. Choose Windows Credentials.
4. Complete the form as shown:

• Name: Windows Credentials 1
• User name: .\administrator
• Password: [Enter password used to RDP to your Windows Server)
5. Click Submit.

CHALLENGE (Required):
• Ask a student for his or her private IP address which starts with 198.51..
• Using the Quick Discovery option, discover the Windows Server of one of the other
students in the class using the private IP address of their Windows Server. Do not use
their public IP.
• After discovery completes, locate the newly discovered server by navigating to
Configuration > Servers > Windows.
were created correctly and you met the desired outcome during the lab. Run these tests if
you would like to validate completion of the lab.
2. Execute the test that matches the lab you completed.
Note: If the Run Test windows displays a message of Succeeded 100%, you passed the test and
your lab work has been validated. Nice work!
There may be situations where you successfully completed the lab and the test script fails
book. It is recommended to complete the labs using the same naming conventions to avoid
these scenarios.

Lab
Work with Process Classifiers 02.03
615m
Lab Objectives
From the Dependency View map, Cloud Dimensions wants to visually display servers that are
running the IIS Server and Apache Web Server applications.

• View Dependency View Map, Process Classifiers, and Discovery Patterns
• Modify Baseline Process Classification
A. View Dependency View Map, Process Classifiers, and

Discovery Patterns
1. Navigate to Configuration > Servers > Windows.
2. Search and open the record that represents your Windows MID Server.
Note: You should have noted the name of your server in the previous exercise. The name should
start with ip.
3. Next to Related items, click the Show dependency views icon to display the
Dependency View map.

4. Notice Microsoft IIS Web Server displays as an application with a dependency
relationship to the host machine.
Note: ServiceNow Discovery identifies applications based on Process Classifiers, as you will see
later in this exercise. Notice a list of tracked files are also collected which can be configured in
the Discovery Pattern. You will learn how to configure tracked files in a later lab.
5. Close the Dependency View map and navigate to Discovery Definition > CI
Classification > Processes.
Note: A list of the baseline Process classifiers display that are used by ServiceNow Discovery to
identify applications on a host.
6. Search for and open the Microsoft IIS Server process classification record.
Note: Your MID Server has an IIS Web Server installed on it and meets the conditions of the
Process Classification. Therefore, a Runs on::Run relationship was built between the application
and the host. Additionally, the application was added to the Microsoft iis Web Server table as
configured in this record.
7. Under the Triggers probes related list, Pattern column, click and open the IIS
pattern.
Note: This is the pattern used to identify the IIS application. Discovery Patterns are shared
between Discovery and Service Mapping. Discovery Patterns will be covered in more depth later
in the class.

8. From the IIS pattern, click the Tracked Files tab.
Note: Additional files can be configured that can be collected during discovery.
9. From the Basic tab, under the Identification Section, click on Identification for
HTTP(S) entry point type(s) for IIS7 and above to open the pattern in Pattern
Designer.
Note: Pattern Designer is used to build the steps that are used by the pattern’s identification
section to identify a specific application. The steps in this identification section were used to
identify that IIS was running on your host Windows Server.
10. Click the Back to pattern button to return to the pattern.
Note: From the browser URL, you may need to remove the string of characters after .com to
return to the ServiceNow interface in order to proceed with the next step.
B. Navigate CMDB Tables

1. Navigate to Configuration > Application Servers > Web Servers.
Note: Two records exist for a Microsoft IIS Web Server. One that was found on your server and
the other that was found on the student server that you also discovered.
2. Navigate to Configuration > Applications.
Note: This is the base table for all applications stored in the ServiceNow CMDB. The two
Microsoft IIS Server application records should also display here. The class for the Microsoft IIS
Server is Microsoft iis Web Server, which is extended from the Application base table.

C. Modify Baseline Process classifier
Cloud Dimensions would like to discover and visualize the Apache Web Server on the
Dependency View map. An Apache process classifier exists, but the conditions need to be
modified in order to discover the Apache Web Server installed on your MID Server. It is
important to know that based on application deployment, process classifiers may need to be
reconfigured to properly identify an application due to various deployment methods.
1. Navigate to Discovery Definition > CI Classification > Processes.
Note: The baseline process classifications are listed.
2. Search for and open the Apache Server process classification record.
3. Modify the Conditions as shown to meet the specific implementation requirements

of Apache in the Cloud Dimensions environment.
IMPORTANT: Verify your configuration matches exactly what is shown.
Note: The last condition is an “AND” condition for Parameters | does not contain | runservice.
4. From the Test with field, click the lock icon and search for and select your Windows
Server where the name should start with ip.
5. After completing the modification, save the record and verify under the Test results
related list that one record displays representing Apache.
Note: It is good practice to test the process classifier to confirm the conditions set work as
expected.

Using Quick Discovery, discover your MID Server and validate on the Dependency View map
that an Apache Web Server to Windows Server dependency relationship now appears.
QUESTION REVIEW
1. From the Discovery Status record, under the ECC Queue tab, what is the name of the
probe being deployed to identify the Apache Web Server?
2. What is the file path and names of the tracked files collected from the Apache On
Windows pattern?
3. How many applications display on the Discovery Dashboard that were discovered in
the last 7 days?

QUESTION ANSWERS
1. Pattern Launcher: Apache On Windows Pattern
2.
3. Four (Apache Web Server, IIS Virtual Directory, Microsoft iis Web Server, Web Site)
these scenarios.


The Service Mapping Discovery Lifecycle Flow streamlines the overall service mapping process from
setup, to map, fix, review, and eventually final approval to deploy services to production. The overall
flow allows for easier adoption, faster times to usable service maps, and shorter time to value with
more efficient resolution of errors.

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 the Service Mapping application as described in Activate Service Mapping application.
2. Configure connections with MID Servers. MID Servers, which are located in the enterprise
private network, facilitate communication between servers on the network and
some ServiceNow applications, such as Discovery, Service Analytics, and Service Mapping.
3. Discover load balancers to gain visibility into suggested services to map
4. Configure known credentials required for Service Mapping to access hosts and applications.
5. Grant the following Service Mapping roles to relevant users:
• sm_admin for Service Mapping administrator
• sm_user for Service Mapping user
• sm_app_owner for any service owners

The plugin for Service Mapping is called Service Mapping (com.snc.service-mapping) and enables
top down service discovery. It has a dependency on the Event Management and Service Mapping
Core plugin.
The following plugins are activated automatically when you activate Service Mapping: IP-
based Discovery, Service Modeling, and REST IP Provider. The IP-based Discovery plugin contains
shared components of horizontal discovery used by Service Mapping. Service Mapping customer
also have the right to enable the Discovery plugin in order to have access to the full set of Discovery
menus and modules
To purchase a subscription, contact your ServiceNow account manager. The account manager will
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:
• Navigate to HI.
• Click Service Catalog.
• Click Request Plugin Activation, and fill out the form.

To discover and map CIs, Service Mapping accesses these CIs using commands, some of which
require credentials. The ServiceNow platform provides a centralized way of configuring credentials
for Discovery, Service Mapping, and other applications; so that you configure credentials for a
certain CI type only once. For example, if you configured credentials for Linux operating systems
for Discovery, you do not need to do it again for Service Mapping.
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 credential is referred to
in ServiceNow as applicative credentials.
Credentials, such as user names and passwords, or certificates, are required to gain access to a
computer or network device for ServiceNow Discovery. The platform stores these credentials in an
encrypted field on the credentials table that cannot\ be viewed.
It is good practice for ServiceNow professional services or partners not to enter customer
credentials, but rather have customers enter their own credentials.

The MID Server login credentials appear in the config.xml file in clear text by default, but you can
encrypt them. While the username and password are initially set in a config.xml configuration file on
the MID server, once the MID server retrieves the credentials, it can replace the clear-text password
with an encrypted password. For the encryption of the local MID server service account, the
password is encrypted using an AES128 encryption algorithm. The MID server also maintains an
encryption key that is generated each time it starts and remains in memory and not on the hard
disk. When credentials need to be sent from the instance to the MID server, the following process
takes place:
1. The instance retrieves the encrypted password and the unencrypted username from the
instance database table.
2. The instance decrypts the encrypted password, and then re-encrypts it using the MID server
encryption key.
3. The username and re-encrypted password are sent to the MID Server through the encrypted TLS
session was already established between the MID server and the instance.
4. The MID server receives the credentials and decrypts the password in memory before using the
credentials for remote operations. At no point is the credential password stored on the disk in an
unencrypted format.
Automation credentials are secured by encrypting them in the instance with the MID Server’s
trusted public key prior to transmission. When the MID Server is created, it generates a keypair,
consisting of a public and private key. After the MID Server is validated, it can use the private key to
decrypt automation credentials. You should occasionally rekey the MID Server to meet your
organizations security requirements.

Storage devices:
NetApp Filer Credentials
• SNMP v1/v2c read-only community string
• Read-only user via HTTP for config data
NetApp Filer Connectivity

• SNMP via open UDP port (configurable, default 161)
HTTP via open TCP port 80
EMC Credentials
• SYMCLI server user with access to symcfg, symdev, symmaskdb, symaccess
EMC Connectivity
• SSH via open TCP port (configurable, default 22)
Further credentials are required for certain applications and devices, including the following:
• Microsoft SharePoint, SSRS, SSIS, Exchange, NLB and CRM
• IBM WebSphere MQ and Data Power
• Cisco ACE, Citrix XenApp, Oracle RAC, Tibco EMS and F5 Load Balancer

CI discovery lifecycle scenario with credential-less credentials:
1. Customer adds new host to their network and Service Mapping knows nothing about the new
host credentials.
2. Credential-less discovery creates new host CI in the ServiceNow CMDB (Nmap cannot pick up
host serial number, but can identify OS family)
3. Service Mapping admin adds discovery credentials to ServiceNow for the new host.
4. Horizontal discovery runs successfully and uses credential-based classification.
5. Original host added to CMDB that contained limited data is updated and reconciled with richer
data discovered with credential-based discovery using the IP+MAC identification rule, preventing
duplicate CIs from being created.
For a detailed demo on Credential-less discovery refer to the ServiceNow Service Mapping Delta –
Kingston training:
https://servicenow.sabacloud.com/Saba/Web_spf/NA1PRD0015/common/searchresults/ServiceNo
w+Service+Mapping+Delta+-+Kingston/ALL

Service Mapping discovery begins with an entry point. This is usually a URL that users use to access
the service. Service Mapping requires credentials to access the host machines that run the
applications that comprise the service. It then uses Discovery Pattern information to build a service
map of all the components that contribute to that service.

Entry point is the first tier application on a host CI where the end user receives the service. Service
Mapping starts the mapping process from this point.
Entry points may vary depending on the nature of the service; a TCP port, a URL, a SQL port can all
serve as entry points to a service. Service Mapping comes with a list of preconfigured entry points
types and the attributes configured for the entry points depend on the type.
Entry points can be manually entered one by one, or imported from a CSV allowing for multiple
services to be discovered in parallel. Another option is to run discovery against the management IP
addresses of all load balancers in an enterprise and Service Mapping will automatically provide a list
of service candidates.

The Service Mapping Discovery Lifecycle flow provides methods to shorten the data gathering
around entry point candidates. Additionally with credentials are needed to map a service due to
more connections being found using traffic based discovery.
Service Mapping handles bulk mapping allowing hundreds of services to be mapped in parallel.
Guided error handling refines this mass of maps more quickly, bringing them to a “Review” state
quicker.
Legacy Approach starts the mapping process only after the customer:
1. Gathers data on entry points
2. Obtains credentials
3. Relies mainly on pattern based discovery as opposed to traffic based
4. Addresses errors and issues per map
Recommended Approach:
1. Enables automated discovery of candidate entry points by discovering load balancer and is not
blocked by manual data gathering of entry points
2. Relies on a traffic based discovery when no credentials are available by reducing traffic noise
using machine learning
3. Enables bulk, parallel mapping of many services at the same time
4. Enables cross service error handling to allow for resolving one error that will potentially fix many
common errors across multiple service maps
5. Steps are guided with prioritization, suggestions, tasks assignments, and better visibility of the
overall picture

3.1: Customer Preparation (5 minutes)

Lab
Customer Preparation 03.01
65m
Lab Objectives
Cloud Dimensions provided the Implementation team with the necessary information for the
Business Services they want discovered and modeled during the implementation.
As a member of the Implementation team, you will ensure you have the necessary
prerequisites to start the Service Mapping implementation including infrastructure for the MID
Servers to be installed, MID Server access to the targets, identification of the most critical
underpinning services, and valid credentials including available resources.
In this exercise, you will define the entry points that will be used for Service Mapping discovery
during the implementation and view potential service candidates.
Note: This exercise can be performed individually or as a group with the instructor.
A. Download and Review the Service Mapping Checklist

1. From your student ServiceNow instance, navigate to Self-Service > Knowledge >
Training Support Files, locate and download the file called Service Descriptions.
Note: If the KB does not display, please access the needed files from this link or access them
from another student instance. https://servicenow.box.com/v/m010-kb. Save this link for future
reference.
2. Open the file and view the various services that Cloud Dimensions intends to
discover, model, and monitor.
3. In the Entry Point column, complete the Entry Point information for the first four
services listed in the Excel file and rows 7 and 8.
Note: An Entry Point example consists of a web URL followed by the port used to access the
service (i.e. http://stocktrader.cd.com:8081). You can check your answers at the end of this lab.
4. After completing the prior task, from the Training Support Files KB, locate and
download Bulk Import 1 and Bulk Import 2 and view the various entry points
configured in these files.

B. Answer
Note: No further action is required in this lab, other than completing the Service Descriptions
file and viewing the Bulk Import files. These files will be referenced in later labs as you discover
the entry points defined in the Excel files. Please ask your instructor for assistance if you have
any questions or need assistance.

What is behind the various tiles?
• Map – Candidate entry point based on pre-defined criteria

• Fix – Service maps that contain errors
• Approve – Service maps flagged manually as ready-for-review/rejected or maps with CI count > 0
and Error count = 0
• Completed – Service maps flagged manually as approved
Services contain a new field called Process Status that contains the following states:
• Data Gathering
• Finished Questionnaire
• In Progress
• In Review
• Rejected
• Approved

Service Mapping discovery patterns help ensure that only relevant CIs are discovered for each
service. Typically, very little fine-tuning is necessary for 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 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
service and its operation. The 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 service. If unnecessary CIs are included in the map, they can
generate irrelevant alerts in Event Management. For example, when creating a service for a web
portal, Service Mapping may automatically discover a connection to external services, like PayPal,
that do not belong in the service.
Add mapping boundaries to remove the unnecessary CIs. Service Mapping can discover only the CIs
within these boundaries.

From the More Options icon at the top right, you can modify the Map Display from Application view
(default) to Host View. There are many other options to help customize the look and feel of the
service map.

You can view changes made to a service as a whole and to individual CIs belonging to a service.
The kind of change information gathered and displayed by ServiceNow depends on the Service
Mapping setup.
Role required: admin, sm_admin or sm_user
Every time you add a CI to or remove a CI from a service, a CI is upgraded or updated. Information
about the change is recorded in CMDB and Service Mapping retrieves it to create the change history
view. You may need to see the changes made to a service as part of the maintenance, planning, or
troubleshooting procedures.
There are several ways to view changes in Service Mapping:
• View change records for the entire service.
• View change records for a specific CI inside Service Mapping.
• You can see detailed history of a specific CI separate from its service as described in the Timeline
of CI changes.
• Compare the service before and after changes.

The discovery log displays all the patterns and steps performed with an indication of fail, pass or
executed.
Detailed log messages are displayed by:

• Entire log
• Pattern
• Identification / Connection sections
• Individual steps

Lab 3.2: Map Individual Service (20 minutes)

Lab 3.3: Map Services Suggested by Service Mapping (25 minutes)
Lab 3.4: Bulk Mapping (20 minutes)

Lab
Map an Individual Service 03.02
620m
Lab Objectives
Cloud Dimensions is eager to map their first service using Service Mapping. In this lab, you
configure an entry point to a service and view the results and discovery log information.

• Configure and map your first service
• View the results
• View the log
• View the map features
A. View the Online Payroll Service

Cloud Dimensions utilizes a service called, the Online Payroll Service. This service is
supported by an Apache Web Server and is installed on your MID Server instance over port
8080.
In the next section, you will define a single service to map and discover the Online Payroll
Service. However before discovering the service, you will view the service from the
perspective of a user of the service to provide visibility to the service you will discover using
Service Mapping.
1. Using the browser from your remote desktop connection of your Windows Server,
navigate to the following address:
http://[PrivateIP]:8080
Note: Replace PrivateIP with the Private IP address of your MID Server where the Apache Web
Server is installed.

2. From your laptop browser verify the service is also available over the public internet
by browsing to:
http://[PublicIP]:8080
Note: Replace PublicIP with the Public IP address of your MID Server.
B. Configure Service Mapping to Discover the Online

Payroll Portal
In this section, you will configure and discover a single service to map.
1. From your ServiceNow instance, navigate to Service Mapping > Home.
2. From the Additional Options link, choose Define A Single Service Map.

• Name: Online Payroll Service
• Owner: Andrew Jackson
4. From the right pane, select Web Application.
5. Configure the form as shown replacing Private IP with the Private IP address of your
Windows Server.
• URL: http://[Private IP]:8080
Note: Your Private IP address starts with 198.
6. Click Add.

7. From the left pane, under Add Entry Point, click HTTP(S) Endpoint to view the entry
point just added.
8. Click Add Entry Point.
Note: The list of entry points is displayed if another entry point needs to be added. At the
bottom of the list is an Other Application tile that provides additional entry point type options if
required.
9. From the top right of the Service Mapping Home form, click Save.
Note: You may need to click the X to close the green status bar if you do not see the Save
button.
10. From the top right of the Service Mapping Home form, click View Map.
Note: The service map displays with the Online Payroll Service being discovered. This process
may take one to two minutes to complete. There is a Run Discovery button that allows for the
manual rediscovery of the service if needed.
11. Verify that after short while your service map displays as shown:
Note: Service Mapping discovered the Online Payroll Service by using the simple configuration
of providing an entry point.

12. Select each of the three components displayed on the Service Map and view the
details about each in the Properties pane to the right.
o Entry Point
o Connection
o Application
Note: The Properties pane displays a list of different properties either configured or collected
during discovery.
13. Navigate to Service Mapping > Home and verify that there is one service to approve.
Note: There may be a delay before the service appears.
C. Verify Host Detection

Service Mapping uses Horizontal Discovery for Port Scanning, CI Classification,
Identification, and Exploration if the host CI does not exist in the CMDB. Since your MID
Server host CI was discovered in an earlier lab, the Discovery of the host was not
executed in the previous section. In this section, you will delete the host CI, rediscover
the service, and view the results.
1. Navigate to Discovery > Status.
Note: There is no recent discovery status record created when you discovered the Online Payroll
Service because the host CI already existed in the CMDB.
3. Search for and delete the Windows record that matches your MID Server record.

Note: Your MID Server is the host CI that has the Apache Web Server installed on it and
supports the Online Payroll Service.
4. After your MID Server record is deleted, navigate to Service Mapping > Services >
Application Services.
5. From the Online Payroll Service record, click View map.
Note: The map should no longer display anything.
6. Click Run discovery to rediscover the Online Payroll Service and then immediately,
navigate to Discovery > Status.
Note: A recent discovery status record should display with a State of Active because discovery
on the host has to be completed before the service can be mapped properly.
7. Navigate back to the Online Payroll Service map and after a few minutes, verify the
Application Service is mapped again.
Note: Discovery will take longer this time because the host has to be discovered first.
D. View the Service Mapping Discovery Log

The Service Mapping Discovery Log is useful in understanding and troubleshooting Service
Mapping discovery.
1. After Discovery completes, right-click the Apache icon and select Show discovery
log….

2. From the left pane, expand Apache On Windows.
Note: The discovery log shows the pattern that Service Mapping used to identify this
application. Additional details appear in the right pane when a specific pattern is selected. More
details on patterns and pattern writing will be covered later in the class.
P = Discovery Pattern
I = Identification Section
C = Connection Section
Green = success
Red = tried but not successful
3. From the left pane, select Discovery Log.
4. View the Process Detection details which are automatically picked up with Service
Mapping.
Note: The process details collected are used extensively by patterns to correctly identify
applications running on a specific host and port.
5. Close the Discovery log.

E. Explore the Map and Navigation Features
1. From the Additional actions menu, select Display in Host View to toggle the map to
display hosts vs. applications.
2. Expand the Server icon to display the Apache Web Server application.
Note: Host view when turned on adds the host to the service map. By default, it is turned off to
maintain a simplified view of the map and keep it less cluttered.
3. Turn off the Host View to display the original map view.
4. Click the Service Map Form icon to quickly navigate back to the Business Service
record.
Note: This option provides a simple method to navigate back to the Application Service
configuration record.
5. Click View map to return to the map.

F. View the Results
1. From the service map, select the Apache icon.
Note: a blue square should appear around the icon.
2. From the right pane, scroll and view the Properties window that displays the
Application and Server attributes collected.
3. At the bottom of the Properties pane, under the Server section, click the Detailed
properties link to quickly navigate to the server CI in the CMDB.
4. Open the Dependency View to display a map of the Windows Server.
Note: The map includes a relationship not only to the Apache Web Server that is part of the
service, but also with the IIS Web Server that was discovered by Horizontal Discovery in an
earlier lab. As a reminder, the service map only displays applications that support the service
being discovered versus the dependency view map displays all applications that were
discovered and dependent on a discovered host.

Note: If necessary, close the two new browser tabs that were opened before proceeding to the
next step.
5. Navigate to Service Mapping > Home and verify the dashboard appears with one
service to approve.
6. Open the Approve tile and notice that the service can be sent to the application
owner for final approval, however you will do nothing for now as the approval
process will be covered later in class.
Note: It may take several minutes for the Dashboard to display the new service to approve. The
approval process flow for a service will be covered at a later point class.
Congratulations, you have successfully mapped an individual service.

these scenarios.

Lab
Map Services Suggested by 03.03
Service Mapping 625m
Lab Objectives
Up to this point, Cloud Dimensions has mapped an individual service. Another approach is
available where Service Mapping can suggest services to map based on discovered load
balancers.
Service Mapping uses load balancers on a network to identify possible services (candidates).
As a Service Mapping administrator, you can map all or selected candidates in bulk, creating
multiple services in a single operation. This method of mapping can be useful for
organizations that do not have a lot of information about their services.
A. Configure Credentials and Discover Load Balancer

In this section, you will discover through horizontal discovery one of Cloud Dimensions load
balancers that they have on their network. After discovery completes, the discovered load
balancer will provide service candidates to map.
1. Navigate to Service Mapping > Administration > Credentials.
2. Click New.
3. Select SSH Private Key Credentials.

4. Complete the credential as shown:
• Name: Load Balancer .167
• User name: ubuntu (Note: username is case sensitive)
• SSH private key: Available from Self-Service > Knowledge > Training Support
Files
Note: It is good practice to paste the SSH private key into a generic text editor before pasting it
into the SSH private key field in order to remove any unwanted formatting. Include Begin and
End tags in SSH private key field.
Note: Credentials can be tested against the load balancer target host with IP Address
198.51.100.167.
5. After the credential tests successfully, click Submit.
6. Navigate to Service Mapping > Home and confirm, under the Map tile, there are no
candidates displayed.

8. Click Quick Discovery.
9. For Target IP enter 198.51.100.167.
10. Verify a valid MID Server is selected and click OK to start the discovery process.
11. Navigate to Discovery > Status and verify an entry appears with a State of Active.
Note: This indicates the load balancer is being discovered.
12. After the State displays Completed, navigate to Service Mapping > Home and verify
a new candidate displays under the Map tile.
IMPORTANT: Do not click the Map tile, this will start the mapping process, proceed to the next
step. If you click it by accident, navigate to the Application Services module and delete the
service just discovered to reset the Map tile count back to one.
13. Click Additional Options and select View Candidate List.
14. Open the record and modify the Name to Americas Calendar Portal.
15. Click Update.
16. Click the Back button to return to the Service Mapping Home page.

17. Click Map Your Services and then Continue to start Service Mapping discovery.
Note: A message should appear that the discovery is in progress.
18. Navigate to Service Mapping > Services > Application Services.
Note: The new Americas Calendar Portal service should appear.
19. Open the Americas Calendar Portal service map.
Note: After discovery completes, the map displays errors and is not complete due to credential
issues.
20. Click the Service Map Form icon.
21. From the left pane, click Additional Info.
22. From the Additional Info form, set Business criticality to 1 – most critical.
Note: Business criticality has no purpose when discovering a service, however the services that
are configured as more critical, when eventually approved and moved to an operational state,
will be placed in a tile on the Event Management dashboard that takes up more space
signifying its greater importance.
23. Click Update to save your changes.
24. Navigate to Service Mapping > Home and notice there is one service that needs
fixing.
Note: There may be a delay of several minutes before the service displays.

25. Click Fix Your Services.
Note: There are 3 errors that affect the same service.
26. Click the Network tile.
27. Click the Host detection failed tile and review the messages for targets .66, .215,
and .176.
Note: A Quick Tip appears informing you that after successfully resolving a single error, you can
apply the fix to try to resolve all errors

CHALLENGE 1 (Required):
Configure the following credentials and re-discover the Americas Calendar Portal
service.
Americas Calendar Windows Credential 1:
• User name: workgroup\administrator
• Password: SWAdvWork$1
Note: Credential can be tested against target 198.51.100.66 and/or 198.51.100.215
Americas Calendar Windows Credential 2:
• User name: workgroup\administrator
• Password: 1G00dDemo (one, capital G, zero, zero, lower d, upper D, lower emo)
Note: Credential can be tested against target 198.51.100.176.
Note: Your map may appear with different connections because the service was discovered
with Traffic based discovery. If you view the Service Mapping Home page, the service may still
appear under the Fix tile, however if you view the specific error messages, they will now display
resolved. Within a short while, the Home page will automatically refresh and the service will be
moved under the Approve tile.

Configure the map to not display CIs and connections discovered using Traffic based
discovery:
Congratulations, you discovered a service that was suggested by the discovery of one of the
Cloud Dimensions load balancers. In addition, you were able to resolve one error
surrounding credentials that resulted in multiple errors being resolved simultaneously. Your
service, in a short time, will now appear on the Service Mapping Home page under the
Approve tile.

these scenarios.

Lab
Bulk Mapping 03.04
620m
Lab Objectives
Cloud Dimensions, like many organizations, may have hundreds of services. Mapping each of
them individually can be time consuming. With Service Mapping, you can map a service
individually as performed in the prior lab or in bulk.
In this lab, you import and map more than one service at the same time. Cloud Dimensions
is well suited for this approach as they have performed cross-organizational mapping and
analysis and collected some information about planned services. Cloud Dimensions has
collected information in a specific order and saved it as a CSV file.
In this lab, you have Service Mapping extract the information from this file and automatically
create potential services referred to as service candidates.
A. View and Edit the Bulk Mapping CSV

In this section, you view and edit the CSV that contains entry points and service candidates
for services within Cloud Dimensions.
1. From Self-Service > Knowledge > Training Support Files, locate and download the
file called BulkImport1.
Note: If the KB does not display, please access the needed files from this link or access them
from another student instance. https://servicenow.box.com/v/m010-kb
2. Modify the Americas Warehouse Management Portal target entry point to include
the private IP Address of your MID Server.
Note: The Private IP Address of your MID Server starts with 198.51…
3. After modifying the file, save and close it.

B. Import CSV File and Map Services in Bulk
In this section, you import the CSV file and execute discovery.
2. From the Additional Options link, choose Import Service Map List.
3. Click Choose file and locate and select the BulkImport1 file you just modified.
4. Click Open.
5. Click Import.
Note: A list of two candidates displays. These records are stored in the Candidate Entry Point
[sa_cand_entry_point] table.

6. From the Additional Options link, choose View Candidate List.
Note: More details of the candidate list display. Note the Source is defined as CSV file.
7. Click the back button to return to the Service Mapping Home page.
8. Click Map Your Services to start the discovery process of the candidate services
imported.
9. Click Continue.
Note: Under Additional Options, a message regarding the Services discovery is in progress
appears. This process can take 5 to 10 minutes to complete. Continue to the next step while
discovery is executing.
10. While discovery is executing, navigate to Discovery > Status and verify a record with
a description of Bulk Service Mapping Discovery and one record with a description
of Discover CI appear.
Note: Horizontal discovery is being executed only on one of the two target hosts of the services
imported because your MID Server host is already in the CMDB and therefore discovery of the
MID Server host does not need to take place. The host CI for the other service is not in the
CMDB and horizontal discovery needs to execute prior to the application mapping process.
11. Navigate to Service Mapping > Services > Application Services and two new
candidate services should display with a Discovery status of In Progress.
12. From the Americas Stock Trader record, click View map.
Note: After a short while when discovery completes, the service is not successfully discovered
due to credential issues.

13. From the drop-down list to the right of Americas Stock Trader, choose Americas
Warehouse Management Portal.
Note: This method provides a simple way to navigate between services.
Note: After discovery completes, the Americas Warehouse Management Portal displays with no
errors and is ready for approval by the application owner.

14. Navigate to Service Mapping > Home and verify that one service requires fixing and
three services require approval.
Note: The Home page tiles take a little while to refresh, but eventually an additional service to
approve should appear under the Approve tile and a new CI should appear under the Fix tile
representing the .4 device not discovered as part of the Stock Trader service.
15. After the Fix tile displays a value of 1, click Fix Your Services.
Note: The Home page may take between 5 to 15 minutes to refresh. If it is taking too long,
please move on to the challenge to resolve the error that would appear.
16. Click the Network tile.
Note: The error is categorized as a Host detection failed error which is relating to unknown or
misconfigured credentials.
17. Click the Host detection failed tile.
18. Click OK to the Quick Tip.
19. View the message regarding the error associated to the 198.51.100.4 host.

Create the following additional credential in order to discover the SQL host supporting
the Americas Stock Trader.
Windows Credential:
• Name: Americas Stock Trader MSSQL Server
• User name: SQL01\administrator
• Password: 1G00dDemo
Note: Credential can be tested against target: 198.51.100.4
C. Rediscover Stock Trader Service

In this section, now that the correct credentials have been configured for the server CIs
supporting the Stock Trader service, you will rediscover the service.
2. Navigate to the Fix Your Services > Network > Host detection failed tile.
3. From the Quick Tip, check Don’t show again and click OK.
4. From the right pane, under ACTION ON ALL, click Retry Discovery and then
Continue.
5. Verify after a few minutes, the Error Status displays as Resolved for Host/IP
198.51.100.4.
Note: If the error does not refresh and display as resolved, move on to the next step and then
check back in a couple of minutes.

6. After the error is resolved, navigate to Service Mapping > Services > Application
Services.
7. Open the service map for the Americas Stock Trader and verify the map displays as
shown:
8. Navigate to Service Mapping > Home and all services should display as ready for
approval.
Note: The Home page may take from 5 to 15 minutes to update and reflect that the service is
ready for approval. Please move on to the next lab and check back later.
Congratulations you have successfully discovered two services using the bulk
mapping process. Only two services were used to reduce time during the
discovery process, however this process can be used to import hundreds of
services if required.

2. Execute the test that matches the lab you completed
these scenarios.

Entry Point (EP) – The technical details of an interface to a service (e.g. URL)
Entry Point Type (EPT) – Classification of entry points and connections according to interface type
(e.g. URL is an HTTP EPT)
Service
• A Configuration Item that describes a service by a set of entry points or a query on the
Service Mapping topology database
• Typically the top level for a service map
Configuration Item (CI) – An entity that Service Mapping discovers and its attributes. Ex:
Application, server, service
Connection – A relationship between the current application CI and possible CIs it talks to,
described in terms of "entry points" or application interfaces

Entry Point - Is a definition pointing to the CI where the end user receives the service. Typically, an
entry point refers to the first tier application on a host. Service Mapping starts the mapping process
from this point (e.g. https://www.clouddimensions.com:8081).
CI Type - A classification of a CI (e.g. Apache, MS-SQL, host, etc.). New CI Types are created from
the System Definition > Tables module.
Pattern - Description of how to identify a type of CI with sections that provide the steps to discover
the application CI and outgoing connections. Each Pattern has at one associated CI Type (Class).
• Identification Sections - the part of the pattern that contains instructions to identify the
application CI
• Extension Sections – allows an implementor to extend the baseline identification section
of a pattern without modifying the actual pattern itself which allows for easy upgrading
• Connection Sections - the part of the pattern that contains instructions to identify and
create outgoing connections
• Steps – are the basis for discovery by providing specific instructions used in the
identification and connectivity sections to identify application CIs and outgoing
connections
These items are covered in more detail throughout the course.

Host Detection and Top-level Application Mapping
Step 1 - Define an entry point. This is the protocol used to access the port for the top-level
application for the service.
Step 2 and 3 - If the host CI already exists due to a match in the CMDB, it will bypass the Discovery
process and go directly to the Service Mapping process and identify the application running on the
port defined by the entry point. Subsequently the application will be created or updated in the
CMDB and related to the host CI as determined by Identification and Hosting Rules.
The process to identify the host initially is performed by the IP address. The IP address is in the
CMDB, no discovery takes place. If there are duplicates, the most recent host, based on the last
discovery time is used. This process of looking up the host based on IP does not go through the
reconciliation engine.

Step 1 - Entry point is configured and top level application is mapped.
Step 2 - If a match is found in the Connection Section of the pattern for the application that is
connected to, the process will vary depending on if the target host is in the CMDB or not.
Step 3 - If the target host does not already exist in the CMDB, the discovery process will execute to
discover the host server. If discovery of the target host is not successful, the process will stop.
Step 4 - If discovery of the target host is successful, it is added to the CMDB and the Service
Mapping process continues to identify the application it is connected to.
Step 5 - After target host is discovered or if it already existed in the CMDB, the Service Mapping
process will continue to determine if there is a pattern match on the target application. If there is, it
is added to the CMDB with a connection relationship from the source host and application. Steps 2,
3, 4, and 5 will repeat for every application connected that is part of the service.
Step 6 - When all Connection Sections are tried for the target pattern, and no match is found, the
process stops.

From the Service Mapping Home page, the number in the Fix box indicates the number of affected
service maps.
Service Mapping classifies errors by their root cause, for example, missing credentials or task
timeout. For a fast and efficient process, fix errors belonging to the same category in bulk.

It is recommended to work through errors from top left to bottom right and aim to resolve all errors
in less than 2 weeks. Scheduling one-on-one meetings with domain, UNIX, and network admins will
greatly streamline the process.

Common troubleshooting suggestions are provided to help implementers and administrators solve
common errors.

Technical Services:
• are 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.
• are query based services on the CMDB defined by the user. A technical service reveals all the
CIs that match the defined filter and allows for visibility of similar CIs for an enhanced
understanding of the CMDB inventory.
• improve service delivery, increase IT efficiency, and enhance incident, problem, and change
management.

1. Entry point and credentials.
2. Root user or user with selective sudo access. SSH via open TCP port (default 22).
3. A protocol, host, and port to be used as the starting point to discover a service or to define the
outbound connection from one application to another.
4. Used to identify a type of CI with sections that provide the steps to discover entry points and
outgoing connections. Each CI Type has at least one associated Pattern.
• Identification Sections - the part of the pattern that contains instructions to identify an
application CI
• Connection Sections - the part of the pattern that contains instructions to identify and
create outgoing connections
5. Provides a potential list of service entry point candidates.

Lab 3.5: Bulk Error Handling (30 minutes)

Lab 3.6: Create Technical Service (5 minutes)

Lab
Bulk Error Handling 03.05
630m
Lab Objectives
Cloud Dimensions wants to address several errors affecting multiple service maps at the same
time to help streamline the service mapping process. The error handling forms available from
the Service Mapping Home page are designed to guide the user through an iterative approach
to handling groups of common errors at the same time. Some tiles have available instructions
or some have resolution actions to perform to remediate common issues.
Errors are categorized into six categories. The top-left tiles represent more fundamental errors
and as you address errors, moving towards the bottom-right, the errors reflect a more mature
environment, dealing with matters such as performance and map accuracy.
In this lab, you will aim to handle the first five categories, leaving map accuracy to the stage
where categories have a low number of errors and maps are almost ready.

• Import multiple service candidates
• Identify the errors which require handling
• Fix the issue
• Resolve one error
• Resolve all errors
• Address the next bulk of errors in priority
A. View Bulk Mapping Import File

In this section, you view the CSV that contains entry points and service candidates that will
be used to work through the Bulk Error Handling.
1. From Self-Service > Knowledge > Training Support Files, locate and download the
file called BulkImport2.
2. Open the file to view the various candidate services that will be imported and
mapped.

B. Force MID Server Error
In this section, you commit an update that will force an error associated to the MID Server
when executing discovery.
1. From your ServiceNow instance, navigate to System Update Sets > Retrieved
Update Sets.
2. Open the MIDError update set record.
3. Click Preview Update Set and then close the dialog window.
4. Click Commit Update Set then close the dialog window.
C. Import List of Candidate Services to Map

In this section, you import the CSV file.
2. From the Additional Options link, choose Import Service Map List.
3. Click Choose file, locate and select the CSV file just downloaded.
4. Click Open.
5. Click Import.
Note: A list of eight new candidates display. These records are stored in the Candidate Entry
Point [sa_cand_entry_point] table.
D. Map Services in Bulk

In this section, you map the services.
1. From the Service Mapping Home page, click Map Your Services and then Continue.
Note: The discovery can take several minutes. The form refreshes periodically. Wait until the
Map tile shows zero and the Fix tile displays eight before continuing to the next section.

E. Fix Errors in Bulk
In this section, you fix and resolve errors in bulk.
1. Click the Fix tile and navigate to Configuration > No MID servers for IP address.
Note: All services failed on the same fundamental error.
2. Verify a list of Automated Error Messages display.
Note: The bulk error form offers recommended actions on a selected error or on all errors. The
form guides you to first handle one of the errors. Dependent on the type of error, you may have
a specific link taking you to the relevant configuration form. In this case, it is the Edit Mid
Servers form. In addition, for some error types, there is a View instructions link for further
guidance.
3. Under ACTION ON ALL, click View Instructions.
4. Read the suggested instructions and click Close.
5. Under ACTION ON SELECTED, click Edit MID Servers.
6. Click and open the MID Server record.
7. From the MID Server form, under the IP Ranges related list, you are able to identify
the issue with the Type value misconfigured to Exclude versus Include the IP Range.

8. Double-click the Type column and set the Type to Include.
9. Click Update.
10. Close the form to return to the Automation Error Messages list.
11. Under ACTION ON SELECTED, click Retry Discovery.
Note: It is good practice to retry discovery only on one active error to determine if the fix works,
before retrying discovery on all active errors.
12. While discovery is executing, the Error Status changes to Pending discovery and
then In Discovery and finally to Resolved.
13. After the solution implemented resolved the initial error, under ACTION ON ALL,
click Retry Discovery to attempt to resolve all errors in bulk for all services.
Note: A message confirms you are aware that a bulk discovery will run.
14. Click Continue.
15. Monitor the Automation Error Messages until it refreshes and reflects an Error
Status of Resolved for all records.
IMPORTANT: Wait for all errors to be resolved before continuing.
Note: If you refresh the list manually, you will notice that some errors will display Resolved
while others will still be in a state of Pending discovery. This process can take several minutes to
complete. Please be patient and wait for all errors to resolve before continuing.

16. After all the errors are resolved, click the Back button two times or click the Errors
by Category breadcrumb to display the Errors by Category list of tiles.
Note: There are new Network errors. Solving the fundamental IP Ranges issue allowed
discovery to progress to the next stages and encounter the next set of errors. The categories are
organized from top left to bottom right and it is recommended to address the potential errors in
this order to progress most effectively through the discovery of multiple maps simultaneously.
17. Click the Network error tile.
Note: The Network tile is to the left of the Configuration tile signifying a more mature type of
error.
18. Click the Host detection failed tile.
19. Read through one of the messages and notice that a No valid credential found
message displays.
20. Make note of the Host/IP affected.
21. Navigate to Service Mapping > Administration > Credentials.
22. Create a new SSH Credential using the following information:

• Name: Bulk Targets
• User name: disco
• Password: disco
23. Click Test credential and verify the credential is validated against the target IP.
Note: The target IP can be found in the downloaded xls file.

24. After the credential tests successfully, click OK and then Submit.
25. Return to the list of Host detection failed automated error messages and Retry
Discovery on all services.
26. Wait for the re-discovery to complete and the error messages display as Resolved.
Note: This process may take several minutes to complete. Please be patient.
27. Navigate to the Service Mapping > Home page and verify the additional services
now appear as candidates to approve.
28. Only if any services display under the Fix > Map Accuracy > Map accuracy – Missing
inclusion connections tile, under ACTION ON ALL, click Retry Discovery to
rediscover the services another time.
Note: The Home page can take several minutes to reflect the additional services to approve. If
the refresh is taking too long, check back at a later time.
Congratulations, you have successfully resolved all errors affecting numerous

services, thus reducing the interaction with the organizations’ security and
network teams to a minimum.
You have not opened any service maps during the entire lab. From a process
perspective, it would now be time to inspect each of the service maps and
decide if it is complete and ready to be sent for review. You will perform the
review and approval process of a map in a future lab.

these scenarios.

Lab
Create Technical Service 03.06
65m
Lab Objectives
Cloud Dimensions is interested in managing and monitoring a group of similar configuration
items. As a first task, they would like to create a Technical Service representing all the IIS Web
Servers discovered by and stored in their CMDB that are critical to various services that it
offers.
A. 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.
In this section, you create a Technical Service, based on the requirements provided by Cloud
Dimensions, to logically group IIS Web Servers discovered by Service Mapping.
1. Logged in as System Administrator, from your ServiceNow instance, navigate to

Service Mapping > Services >Technical Services.
2. Click New.
3. Complete the Technical Service form as shown:

• Name: IIS Technical Service
• Business criticality: 2-somewhat critical
• Operational status: Operational
• Table: Microsoft iis Web Server
• Filter: Discovery source | is | ServiceWatch

4. Save the record.
5. Click View Result.
Note: A logical grouping of IIS Web Servers discovered by Service Mapping display.
Congratulations, you created a technical service that can be managed based

on a class of configuration items.



The Service Mapping Discovery Lifecycle Flow streamlines the overall service mapping process from
setup, to map, fix, review, and eventually final approval to deploy services to production. The overall
flow allows for easier adoption, faster times to usable service maps, shorter time to value with more
efficient resolution of errors.

In order for users to configure the discovery of services, the user must be assigned either the admin
or sm_admin role.
You can assign Service Mapping administrator and Service Mapping user roles directly to 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 can
be part of a broader administrator role like administrator.
Application or service owners that are subject matter experts that are responsible to review and
approve service maps should be given the sm_app_owner role.

Users who perform review and approval have the roles of a Service Mapping administrator
(sm_admin) and a service owner (sm_app_owner).
The Service Mapping administrator is responsible for mapping, fixing, and maintaining services. The
service owner is familiar with the infrastructure and applications making up the service. This user is
your service SME who provides information necessary for successful mapping of a service. Once a
service is mapped, this user reviews the results and either approves it or suggests changes.
The review and approval process is performed in the following stages:

1. After the initial mapping of services, the administrator fixes errors and sends individual services
for review. The system creates a service process task assigned to the service owner and sends an
email notification about it.
2. The service owner checks that the service maps are complete and all major components
comprising it are correctly represented. If necessary, the owner leaves comments, referred to as
reject messages, on service maps for the Service Mapping administrator to implement. The
service process task assigned to the owner closes. The system sends an email notification to the
administrator that the owner posted comments.
3. The administrator receives the email notification, views owner requests, and implements them.
4. The administrator resends the service maps for review. The system again creates a service
process task assigned to the service owner and sends an email notification about it.
5. If the revised service maps are satisfactory, the service owner approves them. If not, the owner
requests further fixes, which the administrator must address.

Once the owner approves a service several things occur:
• Its service State is changed to Approved (View from service record, under Basic Info)
• It appears under the Completed tile on Home page (View from Service Mapping > Home)
• It has its Operational status changed to Operational(View from service record, under Additional
Info)
• It appears on the Event Management Dashboard (View from Event Management > Dashboard)
• A Discovery Schedule can be created to rediscover the supporting applications of the service on
an ongoing basis (Can create schedules from Service Mapping > Administration > Discovery
Schedules)

Service health can be monitored with the assistance of enterprise monitoring tools such as Nagios
or SolarWinds

Discovery schedules, when configuring for Service Mapping, allow for rediscovery at a specific
application CI Type level such as Apache Web Server or at a parent level such as Application
[cmdb_ci_appl]. Additionally schedules can be configured against a specific CI.
Whenever an application CI gets rediscovered from a schedule that is executed, it returns the CI and
its outgoing connections resulting from the Connection Section of a pattern. If new outgoing
connections are discovered, then the target CIs for these new connections will be immediately
discovered. Otherwise, the target CIs for existing connections will be rediscovered based on their
own schedule. It is important to verify that at least one service, that the CI is part of, is in an has an
Operational state of Operational in order for it to be rediscovered.
Note that Discovery Schedules configured for Service Mapping only applies to application CIs
including the application CIs of load balancers. Hosts, including the device CIs of load balancers, are
rediscovered based on discovery schedules as configured under the Discovery menu.
Service Mapping uses a schedule for the most specific CI type. 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.
The All Applications baseline schedule can be used to discover all applications for all operational
services on a scheduled basis if more granular schedules are not needed.

1. After the bulk of errors have been resolved and errors in the individual services have been
resolved.
2. The follow occurs:

• Service State is changed to Approved
• Service appears under the Completed tile on Home page
• Service Operational status changes to Operational
• Service appears on the Event Management Dashboard
• A Discovery Schedule can be created to rediscover the supporting applications of the
service on an ongoing basis

Lab 4.1: Review and Approve Map (20 minutes)

Lab
Review and Approve Map 04.01
620m
Lab Objectives
This lab explains the various statuses a service map may have during its lifecycle.

• Get acquainted with the possible statuses
• Understand the related process stages
• Identify roles taking part in each stage
• Assign services with statuses
• Act according to roles
• Experience the service lifecycle
A. The Methodology
An Application Service is created in the system either manually or as a candidate. Once
created, it should always be under the responsibility of one person, either:
1. The Service Mapping administrator – a Technical owner
2. The SME (Subject Matter Expert) – a Business owner
The process status may change to any of the available statuses in any stage of its lifecycle.
For example, a service in the Approval stage may be rejected and require Data Gathering. A
process status should be changed by the action related to it. For example, the action Send
for Review will change the status to In Review
Possible Process Statuses:

• In Progress (initial status when created)
• In Review
• Rejected
• Approved
• Data Gathering
• Finished Questionnaire

B. Create Application Owner User
In this section, you create a user that acts as the application owner and approver.
1. Navigate to User Administration > Users.
2. Click New and create a user with the following information:

• User ID: bob.approver
• First name: Bob
• Last name: Approver
• Role: sm_app_owner
C. Get Acquainted with Service States

In this section, you identify the status in various forms.
2. Search for and open the Hello World service.
3. Notice the Process Status of the service displays In Progress.
Note: Do not confuse the Process Status with Operational status or Discovery status. You can
use the platform abilities to filter and generate reports based in this status for service progress.

D. Send Service for Review
In this section, you change the status of a review candidate from In Progress to Send for
Review.
1. From the Service Mapping > Home page, click the Approve tile and then the Send
for Review tile.
2. Search for and open the Hello World service to display the service map.
3. Click Send For Review.
4. For Assigned to field, choose Bob Approver.
5. In the Description field, enter Please review the Hello World Service.
6. Click Submit.
7. From the map, click the Service Map Form icon.
Note: The Process Status field viewed earlier is automatically changed to In Review.

E. Review and Reject Service
In this section, you will review a map and reject it. This action will change its status to
Rejected and the service will be sent back to the technical owner to remedy.
1. From the User menu, select Impersonate User, and impersonate Bob Approver.
2. Impersonating Bob Approver, navigate to Service Mapping > Services > My Tasks.
3. Open the task record.
Note: The task is of type Review Request.
4. Click the Service Mapp URL link to open the service map.
Note: As the application owner, you are not satisfied with the map and decide to reject it.

5. From the map, choose the Action -> Reject.
6. In the Message field, enter the following text:
• There should be an additional connection to a proprietary database, from the

Tomcat application.
7. Click Add, close the map, and from My Tasks, confirm the State of the task is
changed to Closed Complete.

F. Handle Rejected Maps
In this section, you will handle rejected maps and take appropriate actions which will change
their status accordingly.
1. Logged in as the System Administrator, navigate to the Service Mapping > Home
page.
2. Click the Approve tile and then click the Fix Rejected tile.
3. Notice the Hello World service is listed.
4. Click the service name to display the map along with the rejection details in the
Discovery Messages list.
Note: A Rejection error is categorized as Map accuracy. You may see this error and handle it via
the bulk error handling forms as well.

5. Click the Service Map Form icon to navigate to and open the Hello World application
service record.
6. Click Actions and select Request For Data.
Note: A Request for data form opens.
7. Set the Assign to field to Bob Approver.
8. In the Description field, enter something about the missing connection information
and click Submit.
9. Notice the Process Status changes to Data Gathering.

G. Handle Requests For Data
In this section, as Bob Approver, you handle the data request. The process status updates
accordingly.
1. Impersonating Bob Approver, navigate to Service Mapping > Services > My Tasks.
2. Open the new task record.
3. Click the Service Map URL link.
4. From the Hello World service form, under the Reject Messages tab, verify you are
able to view all related data and updates to the task States and Request types.
Note: Service Mapping provides a streamlined method to capture data and notes as part of the
service record, preventing valuable communication from being scattered in emails and files
stored on external systems.
5. Set State of the Data Request record to Work in Progress
6. From the Worknotes tab, enter the following information to communicate to the
technical owner.
• It seems that the entry point should be 8081 not 8080
7. Click Post.

8. From the Reject Messages tab, set the State of the Data Request record to Closed
Complete.
9. Click Actions and select Submit Questionnaire.
Note: This sets the Process Status back to In Progress.
H. Approve the Service Map

In this section, as the technical owner, you review and handle the notes. The process status
changes accordingly.
1. Logged in as the System Administrator, navigate to the Hello World service and
update its existing Entry Point port to 8081.
2. Click Update.
3. Click View Map.
Note: Discovery should automatically start due to the entry point update. After discovery
completes the map should display the missing database.

4. After discovery completes and the new database appears, from the map, click Send
For Review, to resend the map to the application owner for further review.
Note: Set the Assigned to Bob Approver and enter any text you like in the Description.
5. After submitting the Send For Review form, impersonate Bob Approver, and open
the task assigned.
6. Navigate to the Service Map URL link.
7. Click View Map.
8. Inspect the map to confirm the existence of the missing database.
9. Use the Actions button and select Approve Service Map to approve the map.
10. Logged in as the System Administrator, from the Service Mapping Home page,
confirm that the service displays under the Completed tile.
Note: The Service Mapping Home page may take several minutes to refresh and update
correctly. If anything appears under the Fix tile, you should notice that it is a Map Accuracy
error that has now been resolved. The error should be removed from the Fix tile after the next
refresh.
Congratulations, you have successfully navigated a service lifecycle and

participated in the various service states from In Progress all the way through to
Completed. The map is now promoted to production.



A CI Type (class) is a name of a table derived from the base application table [cmdb_ci_appl]. Within
ServiceNow, any table extended from a base CMDB table is known as an extended class. Within
Service Mapping, the term used for class is CI Type. In this example, the CI Type name is Microsoft
iis Web Server which is a table extended from within the CMDB table hierarchy. The actual table
name is [cmdb_ci_microsoft_iis_web_server] which is also known as the class.

A CI Type attribute is a field or column added to a table of a specific CI Type (e.g. Microsoft iis Web
Server). In this example Name, TCP port(s), Type, and Country Name are all CI Type attributes of the
Microsoft iis Web Server CI Type (class).
New CI Type attributes must be populated in order to display in the Properties pane. If a base field
needs to be added to the Properties pane, it can be added through the sa_map_properties view.

A pattern is divided into Identification and Connectivity sections. Within each section, there are a
set of steps that attempt to identify application CIs and any outgoing connections.
• Patterns identify applications and their attributes as well as their outgoing connections
• Several predefined discovery patterns exist for a large number of enterprise applications
• For in-house applications or where no patterns exists for a specific application, custom pattern
can be configured
All patterns run from the MID Server, e.g. WMI, SSH or any other command to get information.

Pattern structure is divided into three sections: Identification, Extension, and Connection
Identification sections usually have one pattern to them, but each subsection contains one or more
steps. If identification section fails, it goes onto the next identification section in the same pattern. If
all identification sections in a patter fail, the next pattern is tried.
If one identification section is successful within a pattern, then the steps within the extension
section are tried.
Connection sections contain subsections based on an Entry Point Type, and each subsection
contains one or more steps. If one identification section is successful, then all connection sections
within the same pattern are tried which may create between zero and x number of outgoing
connections.
• Does Discovery run through every pattern before it gives up? Yes
• Does a pattern need to be configured if, for example, an IIS Web Server is to be mapped
correctly? Yes
• What happens if no pattern exists for the target application? A generic application is created

Each pattern step performs an operation. Operations can be used to:
• Collect information from the registry, files, command lines

• Set variables used to identify applications, outgoing connections, and attributes

CI Attributes may be captured from various configuration files. To obtain a specific piece of
information to store in an attribute, you may need to parse a configuration file.
Various options are available to make it easy to parse various types of files. When other parsing
strategies such as delimited text do not work, regular expressions can be used to capture the
information needed.

If necessary, create a new CI Type attribute on the required class, then create a step or set of steps
in the appropriate Discovery Pattern Identification Section and populate a variable named exactly
the same as the CI Type attribute. The new CI Type attribute will display in the Properties pane, with
the collected value, automatically when discovered by Service Mapping.
For example, in order to populate a CI Type attribute called u_app_release_version, at least one
step needs to be created to collect the data and store it in a variable that matches the name of the
CI Type attribute.

Fill in the blank.
Note: It is important when declaring two positions for a delimited text parsing strategy, two
variables must also be declared.

• Matches any character
\ Escape next character
+ One or more repetitions
In ServiceNow’s Pattern Designer [a-z] or [A-Z] or [a-zA-Z] matches characters a to z or A to Z.

NOTE: The regex being used within the Pattern Designer is a Ruby flavor and the case insensitive flag
is hardcoded in the Pattern Designer. Refer to http://www.rubular.com
Other Regular Expression Resources:

• Text to Regular Expression Generator: http://txt2re.com/
• Regular Expression Tester: http://regexpal.com

\d Matches any decimal
\w Any alphanumeric character
\s Any whitespace character

In this example, the regular expression is extracting the value “21:21:45” from a file and inputting it
into a variable called “time”.

Service Mapping regular expressions are not case sensitive. [A-Z] normally refers to one capital
letter. To Service Mapping it is ANY letter.
The regular expressions are intended to get unique matches from the text. For example, if your
expression says ([a-z]+), to match the first word of a line and your file has multiple lines, you will get
a "list" variable and our comparisons may not yield the results you expect. Keep things simple.
Online Regex Parser: https://regex101.com/

In debug mode, you can browse to and open source files rather than having to RDP to a machine
and browsing the file system. Credentials configured in ServiceNow are used in order to successfully
connect in debug mode.

The Command Prompt is a useful feature available directly within Pattern Designer that can be used
to run commands on a remote host to gather information that may be used within a step. It utilizes
the credentials entered into the credentials table and debug mode must be enabled.

Connection Example: (SaCmdManager is case sensitive)
http://devinstance.service-now.com/SaCmdManager.do?ip=10.0.0.10
Command Examples:
type "C:\CloudDimensions\mongoose.cfg.txt”
dir "C:\CloudDimensions”
NOTE:
The Command Line Console can be restricted to specific groups or roles or be completely
deactivated by deactivating the SACmdProcessor record found from System Definition > Processors.

The horizontal discovery process can find configuration files that belong to certain applications and
add those configuration files to the CMDB. You can track the changes to these files by comparing
them to previous versions.
All configuration files are saved as a CI in the Tracked Configuration File

[cmdb_ci_config_file_tracked] table. If you enable the content to be saved, these CI records provide
the contents of the configuration files, including previous versions. From the configuration file CI
record, you can compare different versions.
Through a deletion strategy, you can specify what you want to do with tracked configuration file CI
records when discovery can no longer find them. You can keep the configuration file CI record,
automatically delete it, delete only the CI relationships to it, or mark it absent.

1. Creating a variable with the same Name as the relevant CI attribute will automatically populate
the attribute with the value contained in the variable. For example, in order to populate the CI
attribute called “location”, only a matching variable must be created in one of the steps with the
same name and case.
2. Use a Delimited text parsing strategy and set the delimiter to “City: “ and a comma and set the
position to a 1. Another option would be a using a Regular expression of City: ([a-z]+\s[a-z]+).

Lab 5.1: Delimited Text Parsing Strategy (30 minutes)

Lab 5.2: Regular Expression Parsing Strategy (15 minutes)
Lab 5.3: Work with Unix Commands (25 minutes)
Lab 5.4: Track Configuration Files (10 minutes)

Lab
5.1
Delimited Text Parsing Strategy 630m
Lab Objectives
In this lab, Cloud Dimensions is requesting that additional attributes be collected for the
Apache Web Server application, that supports the Online Payroll Service. Part of the Cloud
Dimensions application deployment and release strategy is to deploy a configuration file that
contains valuable information with respect to the application deployment, including location,
country, service supported, app release and version, app install date, and listening port.
A. View Apache Configuration File and Online Payroll

Service
An apache.cfg.txt file was deployed with the Apache installation on your Windows Server.
This file can be used to collect application attributes during discovery.
1. Log in to your personal remote Windows Server.
2. Once logged in, using Windows Explorer, navigate to: C:\Apache2\conf
3. Open the text file called apache.cfg and review its contents.
4. Still within your RDP session, open a browser and navigate to localhost:8080 to view
portal to the Online Payroll Service.
B. Review Data Collected from Apache Pattern

1. From your ServiceNow instance, logged in as the System Administrator, navigate to
the Online Payroll Service map and select the Apache icon.

2. From the right Properties pane, under Application, notice there are multiple
properties, App Release Version is not currently one of them.
C. Add New Field Attribute to the Apache Web Server

Class
In this section, you create a new field on the Apache Web Server table to store values for the
App Release Version.
1. Navigate to Configuration > CI Class Manager.
2. Click Hierarchy.
3. Under CI Classes, search and select Apache Web Server.

4. Under Class Info, click Attributes.
5. Click the Added tab.
6. At the bottom of the list, double-click Insert a new row and complete the row as
shown:
• Column label: App Release Version
• Column name: u_app_release_version
• Type: string
• Max length: 40
7. Click Save.

D. Modify an Existing Discovery Pattern
In this section, you add a new identification step that creates a variable and collects
information from the configuration file with a Delimited text Parsing Strategy.
First, you create a new variable and populate it using a Delimited text Parsing Strategy, then
you rerun discovery and verify the new data is collected.
In order to populate the new field with data collected from Service Mapping, it is necessary
to modify the appropriate pattern to collect the App Release Version from the configuration
file viewed earlier. Afterwards the value needs to be set into the variable that has the same
name as the field you created.
To modify the discovery logic in an identification section without changing the identification
section itself, an extension section to the pattern can be created to retain the integrity of the
baseline identification section. In this portion of the lab, you create an extension section with
a new step to collect the Application Release Version from the Apache.cfg file viewed earlier.
2. From the Discovery Patterns list, search and open the Apache On Windows Pattern.
Note: The Apache On Windows Pattern is associated with the CI Type/class ,Apache Web
Server, that you just added a new field to.
3. Under the Identification Section, click Identification for HTTP(S) entry point type(s)
to open the Pattern Designer.
Note: This is the Identification Section and the set of steps that were used to identify the
Apache Web Server that is part of the Online Payroll Service.
4. From the top left of the Pattern Designer, click the arrow next to Apache On
Windows pattern to navigate back to the Apache On Windows pattern.
5. From the Extension Section, click New.
6. In the Name field, enter Apache on Windows Extension and click Done.

7. From the Extension Section, click Apache on Windows Extension to open Pattern
Designer.
Note: The MID Server runs extension sections after identification sections and only if at least
one identification section completes successfully. If there is more than one extension section
associated with a pattern, an order value can be defined to determine the order that the MID
Server runs the extension sections.
8. From the left pane, double-click Untitled Step and rename the step to Collect App
Release Version.
9. Click OK to the pop-up window.
10. From the top of the Pattern Designer, click the Debug Mode button.
Note: Replace PrivateIP with the private IP Address of your Windows MID Server.
12. Click Connect.
Note: A green circle should appear on the Debug Mode button to indicate you are in Debug
Mode. Debug Mode is an interactive mode. In Debug Mode, the editor performs all actions that
you perform in the screen. It is recommended that you work in Debug Mode when creating or
editing identification, extension or connection sections. Ensure the step you just created is
selected before continuing.
13. After Debug Mode appears with a green dot indicating it is turned on, from the
Operation drop-down list, select Parse File.
14. From the Select File field, click Browse.
15. Browse to C:\Apache2\conf and double-click apache.cfg.txt.
Note: The file path should populate the Select File field.

16. Click Retrieve File Content.
Note: Service Mapping retrieves the contents of the file and sets the default parsing to
Delimited Text. The file path also can be typed if need be. Use forward slashes in configuring
the path.
17. In the Includes Lines field, enter AppReleaseVersion and hit enter to filter only for
the application release information in the output.
Note: The content retrieved within the text file is now filtered based on your criteria.
18. From the Variables section, click Add Variable.
19. Double-click _Name_ and name the variable u_app_release_version.
20. From the Delimiters field, click the pencil icon to configure the delimiter.
21. In the bottom field, enter a space and then click the plus sign to add a space as the
delimiter.

22. Click Done.
23. In the Positions field, enter 2 and then tab out of the field.
Note: 2.0 displays highlighted automatically representing the action of the step.
24. From the top of the form click Test and verify the variable u_app_release_version
has a value of 2.0.
25. Click Close.
Note: Your new step is now configured to search for a file called apache.cfg.txt in a specific
directory. If the file is found, it collects the AppReleaseVersion value and stores it in a variable
called u_app_release_version. If the CI Type attribute\field you created earlier matches the new
variable, it will populate the contents of the variable in the new field after discovery is rerun
automatically. It is important that the variable and the field name match exactly, both from a
spelling and case perspective.

26. From the top of the form, click the plus sign to add a comment.
27. In the Step Comments field, enter Collect and store App Release for deployed
Apache Server.
Note: It is always good practice to comment any new or modified steps.
28. Click Post to save the comment.
29. From the top of Pattern Designer form, click Save to save your configurations.
Note: Extension sections only need to be saved to take effect and do not need to be published.
30. Click the Back to pattern arrow.
31. From the Apache On Windows pattern form, click the Pattern tab and notice how
the original patterns NDL (Neebula Description Language) is not modified as there is
no App Release configured in the Pattern Text.
Note: The extension section is stored in a shared library and does not affect the baseline
pattern text or NDL.

• Run Discovery on the Online Payroll Service and after discovery completes, verify the
App Release Version is collected and displays in the Properties pane as shown.
• View the Discovery Log and verify the new step was executed successfully.
Note: If the App Release Version does not display, verify that the field name you created in the
CI Class Manager matches the variable you created and populated in the new step. It should be
noted that if you deviated from the steps in the lab and created the field using “Form Layout”,
the value may get unexpected results.

E. Navigate Easily to a Discovery Pattern
In this section, you learn a simple method to navigate to a Discovery Pattern with Debug
Mode configured.
1. From the Discovery Log window, select the Apache on Windows Extension.
2. From the top right of the Discovery Log window, click Debug to automatically
navigate to the Extension Section and have the Debug settings configured.
3. Verify that the Debug Extension Section configuration is automatically configured

for you, then click Connect.
Note: You have easily navigated back to the extension section in debug mode if further editing
is required. This method of accessing the pattern is usually a lot easier, since you do not need to
know the actual pattern or specific parameters needed for configuring debug mode.

Perform the following new configuration to collect the CityLocation information from the
Apache application apache.cfg.txt file supporting the Online Payroll Service:
• Create a new Apache Web Server field of type String called City Location
• Add a new step to the Extension Section you are working with that collects the
CityLocation information defined in the apache.cfg.txt file.
• Run discovery to display the City Location information in the Properties pane as shown.
Hint: Instead of creating a new step from scratch, attempt to copy and paste the step already
created, and modify it accordingly to meet the requirement.
CHALLENGE 3 (Optional):
Add a new step to the Extension Section you have been working with to collect the Listening
Port from C:/apache2/conf/httpd.conf file and populate the baseline field called TCP
ports(s).

CHALLENGE 3 ANSWER:
Good Practice: Instead of using the parse file operation for every step to retrieve the content of
the apache.cfg file, one query to the server for content of the file is all that is needed. The
results can then be stored in a variable, and then the variable can be used in subsequent steps
with a parse variable operation to retrieve the same data required without additional round
trips to the server.


Lab
Regular Expression Parsing 05.02
Strategy 615m
Lab Objectives
In this lab, you collect additional attributes that Cloud Dimensions is eager to obtain after
discovering the Apache Web Server supporting its Online Payroll Service. In this lab, a Regular
Expression parsing strategy is used to collect the information needed.
Regular Expressions are very powerful in filtering for the exact data needed when a Delimited
Text parsing strategy does not work.
A. View Configuration File Using Command Line Console

An Apache configuration file was deployed with the Apache installation. You can use this file
to learn how to collect application attributes during Service Mapping discovery with a
Regular Expression parsing strategy.
Service Mapping comes with a Command Line Console which provides an alternative to
having to RDP to a target file system to browse and research for information that may be
useful when configuring Discovery Patterns.
1. From your personal laptop, open a browser and in the URL field type in
[Instance]/SaCmdManager.do?ip=[PrivateIP]
Note: Replace Instance with your ServiceNow instance URL and PrivateIP with the private IP
address of your MID Server. SaCmdManager is case sensitive.
2. Once connected to the Command Line Console, from the prompt, type in ipconfig to
retrieve Ethernet adapter information about your MID Server.
Note: The Command Line Console uses the same credentials available from the credentials
table and sends its commands by way of the MID Server, so a slight delay will be experienced.

3. From the prompt enter type "C:\apache2\conf\apache.cfg.txt" to retrieve the
contents of the file.
Note: In the next section of the lab, you add an additional step to the Apache extension section
to collect the value for CountryLocation.
Note: The Windows type command is equivalent to the UNIX cat command and displays the
contents of a file. The Command Line Console provides an easy method to browse a target file
system without the need to RDP to the system and enter credentials. The credentials used
during this session must already be configured in the ServiceNow Credentials table or a 3rd party
credential store such as CyberArk if this integration is configured. Often when extending a
pattern or creating a new pattern, information about the target file system will be needed.
Using the Command Line Console simplifies this process.
Important: Console access can be deactivated if not needed. Simply navigate to System
Definition > Processors and deactivate the SaCmdProcessor record.
B. Add New Field Attribute for Apache Web Server

In the next section, you add a new step that creates a variable and collects information in the
configuration file with a Regular Expression Parsing Strategy. First you need to create a new
CI Type Attribute to store the Country Location data and then a new variable that uses a
Regular Expression Parsing Strategy.
2. Click Class Hierarchy, search and select Apache Web Server.

3. To right of the Apache Web Server class, click the Pin icon to pin the class.
4. From the left navigator, click Configuration > CI Class Manager.
5. Click the Hierarchy button again.
6. Click the Pinned Classes icon and notice Apache Web Server appears making future
navigation to this class easier.
7. Click Apache Web Server.
8. Under Class Info, click the Attributes tab and add the following new field under the
Added tab.
• Column label: Country Name
• Column name: u_country_name
• Type: String
• Length: 40
9. Click Save.

C. Modify Apache on Windows Extension Section
Now that you have created a new field for Country Name, in this section you will add an
additional step to the Extension Section to collect data for this field the next time Service
Mapping runs.
1. From the Apache on Windows pattern, open the Apache on Windows Extension in
Pattern Designer and configure Debug Mode if necessary.
Note: If Debug Mode is not enabled represented by a green dot, enable it as learned earlier.
2. From the left pane, right-click on the last step and choose New step below.
3. Rename the new step to Collect Country Name.
4. Complete the remainder of the form as shown:
• Operation: Parse File
• Select File: c:\apache2\conf\apache.cfg.txt
• Define Parsing: Regular Expression
• Variable: u_country_name
• Regular Expression: CountryLocation (.*)
5. Click the Test button to verify United States is returned to the u_country_name
variable and to verify the step is configured correctly.

6. If the correct test results are returned, click Save.
Run Discovery on the Online Payroll Service and verify the Country Name property is
populated with United States and displays in the Properties pane.
Using a Regular Expression parsing strategy and the data stored in the apache.cfg.txt file,
configure Service Mapping to display the Last Change Date in a string field after
rediscovering the Online Payroll Service as shown.
Hint: Use your training manual or visit https://regex101.com/ or http://www.rubular.com to

help determine the correct regular expression to use to meet the objective. For further help,
refer to the end of the lab for potential solutions.

CHALLENGE 2 ANSWER:
Acceptable Regular Expressions that all return the same results:
• DateTimeLastChange (\d{4}/\d{2}/\d{2})
• DateTimeLastChange (\d+/\d+/\d+)
• DateTimeLastChange (.{1,10})
• DateTimeLastChange (.*)-
• DateTimeLastChange (.+)-
• DateTimeLastChange ([\d\/]+)
Can you think of others? If yes, please test to verify your Regular expression works and share
with the class.
If time permits view the following video on Troubleshooting Service Mapping:

http://tinyurl.com/sm-troubleshooting

Lab
Work with UNIX Commands 05.03
(Optional) 625m
Lab Objectives
Services are generally comprised potentially of a hybrid environment of infrastructure
containing both Windows and UNIX type servers. In this lab, you add to your skills of searching
for, collecting, and parsing data from Windows configuration files and gain basic skills working
within a UNIX environment to search for and collect file data.
Most services will be supported by a mixed environment; therefore, it is important to know

how to work in both environments which includes executing basic UNIX commands.
Additionally, you work further with the Command Line Console and will be introduced to the
Command Prompt and the Parse command output operation within the Pattern Designer.
DISCLAIMER: There are many flavors of UNIX. Commands used in this lab are working
examples based on a Linux Ubuntu operating system where the UNIX credential defined for
the user has sudo privileges. It is recommended to type all commands versus using copy and
paste as this can cause variance in characters that may result in commands not working as
expected.
A. Command Line Console and UNIX Commands

The Command Line Console can be very useful in investigating file data that may be valuable
to Service Mapping. When investigating UNIX files, it is helpful to understand basic UNIX
commands. In this section, you use the Command Line Console to learn basic UNIX
commands to query files on a UNIX file system.
1. From your personal laptop, open a browser and in the URL field enter the following:
• [Instance]/SaCmdManager.do?ip=198.51.100.167
Note: Replace Instance with your ServiceNow instance URL. SaCmdManager is case sensitive.
198.51.100.167 is a load balancer on a UNIX system that is part of the Calendar Portal you
discovered earlier.

2. Once connected to the Command Line Console, to retrieve Ethernet adapter
information from the UNIX system you are connected to, enter the following:
• ifconfig
Note: The IP Address that is connected by the Command Line Console must be in the CMDB,
otherwise horizontal discovery is run against the target before you can connect to the target
and display the results of the command.
3. To display the user and group information, enter the following:
• id
Note: The user being used for this session is ubuntu which is part of the sudo group.
4. To display the directory you are currently in, enter the following:
• pwd
5. To list all files in the ubuntu directory, enter the following:
• ls /home/ubuntu or ls
Note: Since you are already in the ubuntu directory, you can just enter ls to display all files in
the current directory.

6. To locate if a file starting with lbapp exists in the smtraining directory, enter the
following:
• find ./smtraining –name “lbapp*”
• find /home/ubuntu/smtraining –name “lbapp*”
Note: As noted in the disclaimer, if no results are returned, verify you are typing the commands
in versus copy and pasting them as hyphens, quotes, and other characters will vary between the
book and command line interface.
Note: The period can be used to replace the path of the current directory and save significant
typing over time.
7. To display the contents of a file, enter the following:
• cat ./smtraining/lbappinfo
Note: Displaying the contents of a file is very useful to determine if valuable information is
available to use when creating or modifying patterns.
8. To search if the lbappinfo file contains the word location, enter the following:
• grep location ./smtraining/lbappinfo
Note: grep looks for a string within a file, which is very useful if the file you are looking at is
very large and contains a lot of text.

9. To search if the string appowner exists within the home/ubuntu directory or any of
its sub directories, enter the following:
• grep –r appowner ./
Note: This command can be valuable if you need to search for a string within a file and the
specific file location is unknown. The directory path should be as targeted as possible to avoid
any performance or memory issues on the operating system.
B. Service Mapping Process Detection

2. From the Service named Americas Calendar Portal, click the View map link to open
the Service map.
3. Right-click the HA Proxy icon and select Show discovery log…
Note: Service Mapping executes several UNIX commands during process detection to determine
which application is running on the port defined for the entry point.
4. Copy and paste the netstat command into the Command Line Console and hit enter.
Note: The results returned from this command differ if not executed as sudo.

5. Execute the same command again in the Command Line Console, but this time add
sudo to the beginning of the command and then hit enter.
Note: The results reveal that an application called haproxy is running on port 80 with a process
id. This is the first command executed for process detection on this host during Service Mapping
discovery. Commands will vary depending on operating system. From the Discovery log, if
interested, you can follow the remaining commands that are executed automatically during
process detection.
C. Explore the HA Proxy Configuration File

In the next section, you explore the haproxy.cfg file. The data collected automatically by
process detection performed by Service Mapping can provide valuable information in terms
of important directories and file paths.
2. From the service named Americas Calendar Portal, click the View map link to open
the Service map.
3. Select the HA Proxy icon and from the Properties pane, view the path to the
haproxy.cfg file.

CHALLENGE 1: (Required)
Using the UNIX command skills practiced in the previous section, search for the following
information contained in the haproxy.cfg file:
• What is the maxconn value?
• What are the IP Addresses of the 3 servers connected to as the backend portal?
CHALLENGE 2: (Optional)
• Find the version of HA Proxy
Hint: Use Google to search how to determine the version of HAProxy or refer to the end of the
lab for answers.
D. Work with the Run Command Assistant from the Pattern

Designer
Now that you have used the Command Line Console to explore and gather information on
specific files, you will learn how to use the Run Command Assistant available from the
Pattern Designer to perform similar commands.
4. From the Americas Calendar Portal service map, right-click the HA Proxy icon and
select Show discovery log.
5. Expand HA Proxy and select Identification for http.
6. Click Debug.
7. From the Debug Identification Section window, click the Connect button to open
the HA Proxy pattern in Debug Mode.

8. To the right of the Debug Mode button, click the Command Prompt button to open
the Command Prompt window.
Note: The Command Prompt provides an alternative to the Command Line Console to run
commands. The Command Prompt provides a powerful tool within the Pattern Designer to
research an application and find specific configuration data.
9. In the Command field, enter cat /etc/haproxy/haproxy.cfg and click Run Command
to return the contents of the haproxy.cfg file.
Note: Similar to the Command Line Console, the credentials being used by the Command
Prompt have to be preconfigured and all commands are executed by way of the MID Server.
10. In the Command field, enter grep maxconn /etc/haproxy/haproxy.cfg and click Run
Command to return any line in haproxy.cfg that contains the string maxconn.
11. In the Command field, enter haproxy –v and click Run Command to return the
version of HA Proxy.
12. Click Close to exit the Command Prompt window.
E. Working with Parse Command Output Operation

1. From the HA Proxy Identification Section, right-click the last step in the pattern and
select New step below.

2. Name the step test.
3. From the middle pane, choose Parse file.
4. In the Select File field enter the following:
• /home/ubuntu/smtraining/lbappinfo
5. Click Retrieve File Content.
Note: The results of the file display. It is possible to use a Delimited or Regular Expression
parsing strategy to obtain the necessary information needed and set it into a variable.
6. Change the Operation of the test step to Parse command output.
Note: Parse command output allows for the execution of any command line.
7. In the Set Command Details field, enter the following:
• cat /etc/haproxy/haproxy.cfg

8. Click the Run Command button to display the contents of the file.
Note: Like the Parse file operation, the Run Command operation also supports various parsing
strategies to obtain the desired information returned as output from a command and the ability
to set it in to a variable.
9. Update the Set Command Details field and enter the following:
• grep maxconn /etc/haproxy/haproxy.cfg
10. Click the Run Command button to display the results.
11. Update the Set Command Details field and enter the following:
• /usr/sbin/haproxy -v
12. Click the Run Command button to display the results.
Note: The same results are available as were earlier tested from the Command Line Console
and Command Prompt. The Command Line Console and/or Command Prompt within the
Pattern Designer provide valuable tools to assist in pattern writing to refine the operations, file
paths, and commands that may need to be written to return the desired results.
13. From the Temporary Variables pane, expand process to display the process
variables.
Note: Process variables provide dynamic paths to files and commands and can be used to
prevent hard coding of file paths.

14. From the test step, delete the contents in the Set Command Details field and enter
the following:
• $process.executableDir+"haproxy -v"
Note: It is possible to click and drag the temporary variable, executableDir to the Set Command
Details field to auto populate the field with the variable.
15. Click the Run Command button.
Note: The executable directory variable represents the path where haproxy –v is run to return
version information. This method provides a more dynamic and scalable method to obtain
version information as it can take path changes into effect.
16. From the upper left of the screen, click < HA Proxy to open the HA Proxy pattern
form.
Note: If on Chrome, select Leave to avoid saving any changes.

Using the skills learned in this lab and prior labs regarding extension sections, update the HA
Proxy discovery pattern to return the Maxconn value that is stored in the HA Proxy
haproxy.cfg file to display in the Properties pane from the service map when selecting the HA
Proxy icon.
CHALLENGE 1 and 2: Answers

CHALLENGE 3: Answer
• Create a new field in the HAProxy Load Balancer table called u_maxconn.
• Create a new extension section in the HA Proxy pattern to collect the maxconn value of
256
Note: There are multiple ways to collect the maxconn value. Any are acceptable. The only
thought you want to provide insight to is if the method you choose is scalable or not.
Adding the \s+ after maxconn and the ^ before maxconn allows the step to still capture the
value if for some reason the file was configured with one or more spaces between maxconn
and 256 and if maxconn appears in other strings such as in the second line of the results,
making this a more scalable solution.

Lab
Track Configuration Files 05.04
(Optional) 610m
Lab Objectives
The horizontal discovery process has the capability to collect configuration file data that
belongs to certain applications and add those configuration files to the CMDB. Additionally,
you have the ability to track the changes to these files by comparing them to previous
versions.
A. Configure Process Classifier

In this section, you verify there is a process classifier built and configured correctly to track
files.
2. Search and open the Apache Server process classification.
3. Under the Trigger probes related list, verify there is a HorizontalDiscoveryProbe

configured.
4. Open the HorizontalDiscoveryProbe for windows.
5. Verify the Active checkbox is set to true if it is not already configured.
6. Click Update.
Note: An active HorizontalDiscoveryProbe needs to be configured as part of a process classifier

in order for the Track Configuration File feature to function correctly. Files are actually tracked
during horizontal discovery by the use of patterns.

B. Configure Apache on Windows Pattern to Track
Configuration Files
In this section, you configure the Apache on Windows pattern to track a specific
configuration file.
1. Under the Trigger probes related list, click the link titled Apache On Windows to
open the pattern.
2. Click the Tracked Files tab.
Note: This tab only appears if a process classifier exists for the CI Type of the pattern you are
viewing and the process classifier has the HorizontalDiscoveryProbe configured as previously
mentioned.
3. From Tracked Files, click New.
4. Configure the form as shown:
• CI Type: Apache Web Server
• File Path: $install_directory + “/conf/apache.cfg.txt”
• Save Content: Checked
• Active: Checked

Note: Variables defined in the identification section can be leveraged in the File Path for
Tracked Files. (i.e. $install_directory = C:/Apache2)
5. Click Done and then Save.

CHALLENGE 1: (Required)
• Run a Quick Discovery against the Private IP address of your MID Server.
• After discovery completes, verify the tracked files are collected and display as part of the
Apache Web Server application record as shown:
• From the service map for the Online Payroll Service, verify when the Apache icon is
selected that the Tracked Configuration Files appear in the Properties pane as shown.

• RDP to your Windows Server and modify the c:\apache2\conf\apache.cfg.txt file as

shown.
• After modifying and saving the apache.cfg.txt file, run a Quick Discovery against the
Private IP address of your MID Server.

C. Compare Tracked Files
In this section you will compare the apache.cfg.txt file before and after the change you
recently made to it.
1. Navigate to Discovery > Tracked Configuration Files.
2. Search and open the record for c:\apache2\conf\apache.cfg.txt.
Note: The current content of the file displays.
3. Under Content Versions, check both records, and then click the Compare button.
Note: Changes between the two files are easily displayed along with their respective time
stamps. If the window does not display, verify your browser allows pop-ups to display.


1. Upon entry to the identification section, Service Mapping discovers:
• The host process serving the entry point
• The command line
• Populates all relevant variables
2. Pattern declares it knows how to discover the application if all steps are successful.
• Application CI is created or updated
• Steps populate the attributes
3. If identification fails, then try another pattern.

Host Detection and Identification Pattern Match
Step 1 – Define an entry point. This may be a URL or TCP port that is used to access the top-level
application for the service.
Step 2 – If a host does not currently exist, the discovery process will use the Port (Shazzam),
Classification, Identification, Exploration probes to identify the host machine that is running the top-
level application for the service. The host will be add to the CMDB. If the host CI already exists, it
will bypass the Discovery process and go directly to the Service Mapping process.
Step 3 – Once a host computer has been identified, Service Mapping will use the entry point to
access the top-level application of the service. It will utilize the steps in the Identification Sections of
various patterns to determine the correct application running and either create or update the
application in the CMDB.
Step 4 – If the application CI is successfully identified by an Identification Section within a pattern,

the application CI will be created or updated in the CMDB.

Patterns tried are listed in yellow. Successful pattern and identification section used is listed in
green. Failed identification sections tried are listed in red.

If an entry point is defined as http://www.cloud.com and the host machine running the top tier
application is Windows, then only Patterns where Operating systems is configured with Windows or
All, and the Identification Section is configured with an Entry point type of at least HTTP(s) will be
tried.

Successful steps under the Identification Section are listed in green.
A step may not be evaluated if a precondition exists on a step and is not met. In cases like this, the
step is not evaluated and the next step is tried.

In this demonstration, you will be shown where patterns are configured and how they relate to the
CI Type/Class Definition. Additionally, you will where and how patterns can be filtered by operating
system and run before or after another pattern. Lastly, you will see where an Identification Section
can be filtered based on Entry Point Type

Service Mapping patterns contain identification sections that are sequences of commands that are
used to discover applications and their outgoing connections. Service Mapping comes with a set of
baseline patterns that are used to discover and map many Enterprise applications and their
outgoing connections. In some cases, it may be necessary to customize a pattern such as defined in
the following cases:
• If your organization deploys proprietary applications, you must create new patterns for these
items to enable Service Mapping to discover them.
• If you deploy common enterprise applications in a non standard method, it may be necessary to
modify or extend the existing Service Mapping patterns to reflect the changes as they pertain to
your specific deployment of an application.
Each Service Mapping pattern is associated with only one CI Type\class. At the same time, Service
Mapping usually uses more than one pattern to discover the same CI Type, since the CI Type can use
different protocols, operating systems, entry points and so on. As an example, when looking at the
various baseline Discovery patterns, you will notice two specifically for Apache. One represents
Apache on Windows and the other is used to identify Apache on UNIX.

A series of steps exist for each Identification Section and Connection Section that are included in a
pattern. These steps are the basis for for identifying applications and building outgoing connections.
You define an operation for every step; the kind of operation dictates parameters and variables you
must configure for it.

The Get Registry Key and Match operation are two very popular and useful operations.
Important: If the precondition is not met on a step, the step is ignored and not evaluated, and the
next step is tried.

AppReleaseVersion 8.5.7
Using a delimited text parsing strategy with a space delimiter, you can retrieve the value of 8.5.7.
What delimiters and position can you use to retrieve just the 8?
Answer: a space and a period, with a position of 2

A backslash character (\) can be used as an escape character. It is good practice when retrieving a
file from a specific path, that the path is not hardcoded and a majority of the path is obtained
dynamically based on a variable being set by automatically by process detection or manually by
yourself.
For example, instead of retrieving a file using a hardcoded path such as ”c:\appsample\readme.txt”,
it would be recommended to obtain the former part of the path and setting it into a variable (i.e.
$install_directory_variable), then define the path to retrieve the file using the following syntax,
$install_directory_variable+"\readme.txt”. Using variables will allow the pattern to scale to various
installations where the readme file could reside on either the c:, d: or even e: drive.

A shared library consists of a sequence of discovery steps that were created for one pattern that can
be reused in another patterns. Modifying any step in the library will affect any other pattern
referencing this library, so changes to steps in a library should be done with caution.

When configuring a pattern step and setting a variable, you have the option to choose whether to
create a scalar variable, which would include just a single value, or a tabular variable which would
include generally one or more columns and rows.

Additional tips on creating Identification Sections:
• Create new Identification Sections when identifying applications that are not supported in
baseline patterns
• Avoid mixing support for applications deployed on different operating systems, preferably create
two separate Identification Sections or Discovery Patterns
• Configure Identification Sections as robust as possible by obtaining information in different ways

to support potential variety in methods used by customers in their application deployments
• Use a Match operation as the first step to immediately try to identify the application by process
or some other mean to avoid other steps from executing unnecessarily if no match is found
• Collect information such as installation location, version, name, configuration file path

Applications that are discovered by Service Mapping that do not have patterns that match will be
discovered and mapped as a Generic Application. These applications will display on the service Map
with a Generic Application icon and be stored in the Generic Application [cmdb_ci_appl_generic]
table which extends off of the Application [cmdb_ci_appl] table.

Once the Host detection process is successful, Service Mapping will attempt to identify the top-level
application running on a port defined by the Entry Point.
Patterns and their Identification Sections are run against the top-level application to determine if
there is a match. If a match is not found, a Generic Application will be assigned to that CI.
If a top-level application is identified successfully, Service Mapping will attempt to identify outbound
connections to other applications that are communicating with the top-level application by
attempting each of the Pattern Connection Sections.

All steps in an identification section of a pattern must complete successfully or not be evaluated (i.e.
precondition evaluates to false) in order for an application to be successfully identified by a specific
pattern and its identification section.

pattern and its identification section. In this example step 3 fails, and therefore there is no match
using this pattern.

pattern and its identification section. In this example step 2 fails, and therefore there is no match
using this pattern. Because step 2 fails, step 3 is not tried.

pattern and its identification section. In this example all steps succeed and therefore there is a
pattern match and the application is identified as a Mongoose Web Server.

Service Mapping identifies application configuration items (CIs) that it failed to properly discover as
generic applications. Service Mapping allows you to build patterns from scratch using Pattern
Designer. Another method from the service map is provided, Create pattern from generic
application, which provides a faster and simplified method of creating a pattern, process classifier,
and CI Type for a generic application.

In this demonstration, you will be shown the results of a successful pattern match and the results if
no pattern matches including how to create a pattern from the service map.

1. Host then the Process.
2. A pattern is successful when all steps are evaluated as true and/or steps are not evaluated due
to a precondition.
3. No pattern matches or exists, and the Generic Application pattern evaluates as true.

Lab 6.1: Build Discovery Pattern from Generic Application (30 minutes)
Lab 6.2: More Identification Section Configuring (40 minutes)

Lab
Build Discovery Pattern from 6.1
Generic Application 630m
Lab Objectives
Cloud Dimensions owns an EMEA Customer Support Portal that is supported by a Mongoose
Web Server. Service Mapping currently does not have a baseline CI Type or Discovery Pattern
to identify this application.
Cloud Dimensions wants the implementation team to create a new CI Type and Discovery
Pattern to discover and map their Customer Support Portal.
A. Start the Mongoose Web Server

A Mongoose Web Server on port 7095 is installed on your student Windows MID Server. The
Mongoose Web Server supports the Cloud Dimensions EMEA Customer Support Portal.
Before you discover the service, you need to verify the web server is up and running and
explore the files associated with the application.
1. Remote desktop to your Windows MID Server.
2. Browse to localhost:7095 to view the Customer Support Portal.
Note: If the page does not load, use Windows Explorer and navigate to C:\CloudDimensions
and double-click on mongoose-free-5.5 to start the Web Server.

3. Within Windows Explorer, from the C:\CloudDimensions directory, open the
mongoose.cfg (text) and mongoose (conf) files to view their contents and familiarize
yourself with the files, as you will collect data from these files during this lab.
Note: mongoose.cfg is a mocked file created for training purposes. mongoose is the actual .conf
file that is installed with the Mongoose Web Server.
B. Discover the Customer Support Portal

In this section, you will create an entry point and discover the Customer Support Portal.
Service Mapping does not have a predefined CI Type or Pattern for the Mongoose web
server application; however, it will still discover it as a generic application.
2. Launch a quick discovery against your MID Server in order for horizontal discovery to
rediscover your MID Server and collect the new Mongoose process running.
4. Under Additional Options, select Define A Single Service Map.
5. Complete the form using the following information:
• Name: EMEA Customer Support Portal
• Owner: Bob Approver
• Web Application Entry Point URL: http://PrivateIP:7095
Note: For the URL, replace PrivateIP with your Windows Server Private IP address provided by
the reservation page. It should begin with 198.51...

6. After adding the entry point, click Save.
7. From the Additional Info tab, complete the remaining configuration of the service
using the following information:
• Business criticality: 2 – somewhat critical
• Traffic based discovery: unchecked
Note: Some menus do not appear until the record is saved.
8. Click Update.
9. Click View Map.
10. After Discovery completes, verify a Generic Application CI Type appears.
Note: Discovery finds a Mongoose process running on the server for port 7095, however since
there is no Mongoose pattern, the application is identified as a Generic Application and is
assigned the generic application icon.
11. Right-click the Mongoose icon and select Show discovery log…

12. Notice the Generic Application patter is used.
13. Close the Discovery Log.
• View the Windows Server in the Dependency View map.
Note: The Generic Application displays.

C. Build Discovery Pattern, Process Classifier, and CI Type
from Generic Application
In this section, you create a new Discovery Pattern, Process Classifier, and CI Type (Class) to
correctly map the Mongoose Web Server. A CI Type is basically a class or an extended table
within the CMDB.
1. From the EMEA Customer Support Portal map, right-click the Generic Application
icon, and choose Create pattern from generic application.
Note: It is good practice to configure the conditions in a scalable manner to support various
installation configurations of the application.
3. Click Create.
Note: Do not leave the service map until discovery completes. Discovery should execute again
and map the application as a Mongoose Web Server. A new Process Classifier, CI Type (Class),
and Discovery Pattern is created during this process.

4. After discovery completes, verify the Mongoose map icon and properties update as
shown:
D. View new Class, Process Classifier, and Discovery

Pattern
In this section, you view the three new records that were created for Class, Process Classifier,
and Discovery Pattern.
1. Right-click the Mongoose Web Server map icon and select Show discovery log.
2. Verify the new mongoose pattern created is used to identify the web server and the
generic pattern is no longer used.
3. Close the Discovery log.

5. Click Hierarchy and search for and verify a new class called Mongoose Web Server is
created.
7. Search for and open the new ga_u_mongoose_web_server process classification

record.
Note: The condition created earlier for the process classifier is displayed.
8. Under the Trigger probes related list, under the Pattern column, click and open the
ga_u_mongoose_web_server pattern.
Note: This is the pattern that was automatically created for you.
E. Configure Mongoose Discovery Pattern and

Identification Section
In this section, you further configure the Mongoose pattern and identification section.
1. From the ga_u_mongoose_web_server pattern, change the Name to CD Mongoose

Web Server.
Note: It is good practice to prefix custom patterns with a common naming convention.
2. Under Identification Section, check the box, and click Edit to modify the
Identification Section.

3. Change the Name of the Identification Section to CD Mongoose Identification
Section.
4. Click Done.
5. Click Save.
6. Open the new CD Mongoose Identification Section record to open Pattern

Designer.
Note: Two steps have been automatically created.
7. Click the Debug Mode button and configure the URL with the correct path and port
to the Mongoose Web Server configured on your MID Server.
8. After the URL is configured, click Connect.

9. From the right pane, under Temporary Variables, expand computer_system,
entry_point, and process.
Note: In Debug Mode, some of the variables are populated, including several around
Mongoose. Each of these variables can be used as part of the pattern building process to assist
in correctly identifying an application.
10. From the left pane, rename the first step to Check Process Executable.
11. Under the Match operation, clear out any values that display.
12. Configure the form as shown.
• $process.executable | Equals | “mongoose-free-5.5.exe”
Note: It is good practice to reconfigure this step to perform a match on a specific process.
13. From the left pane, rename the second step to Set Name.

14. Under the Set Parameter Value operation, verify the step displays as shown:
Note: This step sets the name of the application to a hardcoded value of Mongoose Web
Server.
15. Click Save.
16. Click Publish.

Run discovery against the EMEA Customer Support Portal service and verify the
following:
• The Name displays as Mongoose Web Server as set in step two of the Identification
Section
• The CI Type displays as Mongoose Web Server as defined by the Mongoose Web
Server discovery pattern
• Discovery Log displays the updated identification steps you just configured.

F. Further Modify Identification Section
In this section, you modify the first step of the identification section to use a precondition.
1. Navigate back to the CD Mongoose Web Server pattern and open the identification
section.
2. Modify the first step as shown:
• Precondition: checked
• Following condition: $process.executablePath | Contains | Cloud
• If Condition is: True
• Following condition: $process.executable | Contains | mongoose
Note: In this step, you set a Precondition that must be met for the step to complete its
evaluation. By default, this checkbox is not selected and the step is unconditional; that is, the
step is always executed as defined. In some cases, it may be helpful to only evaluate a step
under certain conditions. The step evaluates that the executable contains mongoose only if the
executable path contains Cloud.

3. Click Test and verify you receive the following message.
Note: You need to be in Debug mode to run a test.
4. Place a number 1 after the word mongoose and click Test again and verify a failure
message is returned.
Note: The step fails because there is no executable called mongoose1.
5. Remove the 1 after mongoose.
6. Click Save and then Publish.

Run discovery against the EMEA Customer Support Portal and verify the following:
• Mongoose application is still identified as a Mongoose Web Server CI Type
• Discovery Log displays the Mongoose Web Server pattern is used and all steps execute
successfully

• Delete the mongoose-free-5.5.exe Generic Application that was created at the start of
the lab.

Lab
More Identification Section 6.2
Configuring 640m
Lab Objectives
In the previous lab, you successfully built an identification section to map a Mongoose Web
Server application in the Cloud Dimensions datacenter.
In this lab, you modify the identification section created in the previous lab to further
understand the features and flexibility that you have when building patterns.
Each scenario provides explanation for what you are supposed to accomplish with some
guidance in how to accomplish it. However, to deepen your pattern writing skills, this time you
are not given step-by-step instructions; instead, you need to leverage the skills you have
learned up to this point to accomplish the required outcomes.
The intention of this lab is to develop your independent pattern building skills and introduce
you to new operations and features available when building and configuring patterns.

A. Scenario 1
Cloud Dimensions wants to add a step to the CD Mongoose Identification Section to obtain
the listening port from the mongoose.conf file. Verify you are in Debug Mode prior to
starting.
Create New Step 1 – Parse File > Define Variable
Note: New step should be created above existing step 1

• Name: Parse File > Define Variable
• Operation: Parse file
• Select File: “C:/CloudDimensions/mongoose.conf”
• Include lines: listening
• Variable: mongoose_listening_port
• Delimiter: listening_port with a space at end
• Position: 1
• Terminate if not found: checked
Note: The Terminate if not found checkbox, when selected, terminates the step, and exits the
identification section if the step fails.

Modify Step 2 – Check Process Executable
Before a match is tried on process, Cloud Dimensions would like to confirm there is a match
on the entry point port with the port collected in the mongoose.conf file. Another
precondition needs to be added to the Check Process Executable step to meet this
requirement.
• Name: Check Process Executable
• Precondition: $entry_point.port | Equals | $mongoose_listening_port
Note: A plus sign may be added to the variable name when you add one into the form (e.g.
$mongoose_listening_port+). Simply tab out of the field and the plus sign will be removed
automatically.
• Save and Publish your changes and run discovery against the EMEA Customer Support
Portal service
• Verify the steps succeeded in the discovery log as shown:

B. Scenario 2
Cloud Dimensions is concerned that the path to the mongoose.conf file is hardcoded in the
Select File field in step 1. There may be a future change in process where the
CloudDimensions install directory for their Mongoose Web Servers are reconfigured to a
different file path.
In this scenario, as good practice, Cloud Dimensions would like to use a variable path to
represent the current directory Mongoose is installed in versus hardcoding the path. This will
save them from having to update the step if the file path changes in the future.
In the first step, you will reconfigure the file path to leverage the temporary variable called
process.currentDir. Next, you will concatenate to the end of the variable path, the
mongoose.conf name using a plus sign.
Modify Step 1 – Parse File > Define Variable
• Rename Step 1: Parse file using variable file path

• Select File: $process.currentDir+”mongoose.conf”
• Test Step 1 and verify Value of 7095 is still returned
• Save and Publish your updated pattern and then run discovery against the EMEA
Customer Support Portal service.

C. Scenario 3
Cloud Dimensions wants to build two identification sections to map the service differently if
it is supported by a licensed versus a free version of Mongoose.
In this scenario, you configure the identification section to determine if the version being
used is free in order to proceed with the correct identification section.
Reconfigure CD Mongoose Web Server Pattern
• Change the name CD Mongoose Identification Section to CD Mongoose Licensed

• Add a new Identification Section called CD Mongoose Free with an Entry Point Type of
All and a Process Strategy of Listening Port
• Verify the order of the Identification Sections display as shown

Add Steps to CD Mongoose Free Identification Section
In this section, you will open the CD Mongoose Free identification section and will add steps to
collect the version information, test if the application install version contains the word free,
and finally, test if the .exe contains the word mongoose.
Create Step 1
• Name: Collect Version

• Variable: $process.currentDir+”mongoose.cfg.txt”
• Parsing strategy: Delimited text
• Include lines: AppInstall
• Variables: app_install_version
• Delimiters: a space
• Positions: 2

Create Step 2
• Name: Test if free version

• Operation: Match
• $app_install_version | Contains | free
Create Step 3
• Name: Test if exe contains mongoose

• $process.executable | Contains | mongoose

Add Step to CD Mongoose Licensed Identification Section
In this section, you will open the CD Mongoose Licensed identification section and add a new
step to check if the version of Mongoose is free.
Create New Step 4:
• Name: Test if not free version

• $process.executable | Not Contains | free
• Save, Publish, and run discovery against the EMEA Customer Support Portal service
Note: The CD Mongoose Licensed section should fail and the CD Mongoose Free section should
complete successfully.

• Modify the pattern to obtain the Mongoose numerical version and have it display in the
Properties pane as shown after discovery is run against the EMEA Customer Support
Portal service.
Note: Version should be set into the baseline version attribute. Potential solution provided at
the end of this lab.

CHALLENGE 1 Answer
• Create a new step in the CD Mongoose Free Section to parse the mongoose.cfg.txt file
for the ApplicationInstallVersion and set it to a variable called version that maps to the
baseline field called version.
• It is possible to use either a Regular Expression or Delimited Text parsing strategy to
meet the requirement. An example of using both parsing strategies is provided below.
or



1. Executes subsections for each protocol or End Point Type (EPT).
2. If successful, creates one or more connections:
• Connections may have a category and type
• Category defines the relationship between the discovered connections

The host CI is created or updated based on the initial HorizontalDiscoveryProbe.
The web application is identified based on a match with one identification section.
The connection from the host to the web application and the web application to the database is
based on a match from a connection section.
Connection sections target other CI Types, that also need to be identified in a similar method as the
initial entry point application.

All required CI Type definition attributes on the Target CI Type must be populated to create a
successful connection.

Understanding which file contains the parameters that are configured to create a connection
between two applications will sometimes require research and investigation from the implementer.
Using the internet and sites like Google and YouTube can help tremendously during this
investigation process.
Additionally, the Command Prompt and Command Line Console can be used to help investigate
where connection parameters reside and provide insight into how to capture their details in
operation steps.

In this example, the entry point or outbound connection from Tomcat is HSQLDB. This connection
requires the target host, port, and instance.
Java.exe is a generic application. Either no CI Type definition exists for it, or no pattern matched.
Therefore in this example, a successful outbound connection was built, but the target application is
unknown and must be identified by a pattern as learned in a previous module.

Step 1 - Entry point is configured and top level application is mapped.
Step 2 - If a match is found in the Connection Section of the pattern for the application that is
connected to, the process will vary depending on if the target host is in the CMDB or not.
Step 3 - If the target host does not already exist in the CMDB, the discovery process will execute to
discover the host server. If discovery of the target host is not successful, the process will stop.
Step 4 - If discovery of the target host is successful, it is added to the CMDB and the Service
Mapping process continues to identify the application it is connected to.
Step 5 - After target host is discovered or if it already existed in the CMDB, the Service Mapping
process will continue to determine if there is a pattern match on the target application. If there is, it
is added to the CMDB with a connection relationship from the source host and application. Steps 2,
3, 4, and 5 will repeat for every application connected that is part of the service.
Step 6 - When all Connection Sections are tried for the target pattern, and no match is found, the
process stops.

In this demonstration, you see how to create a new Connection Section, configure the Create
connection step, define a Connection type, Entry point type, and Target CI type.

1. Create connection.
2. From a previous step or set of steps that parse the needed configuration file(s) that define the
connection parameters. The Command Line Console or Command Prompt can be useful in
finding the necessary configuration information.

Lab 7.1: Build Connection Section (25 minutes)

Lab 7.2: Build More Connection Sections (60 minutes)

Lab
7.1
Build Connection Section 625m
Lab Objectives
Cloud Dimensions has an internal service called the Dispatch Scanning Service that uses an
Apache Web Server and a Tomcat Application Server. The implementation team’s
responsibility is to discover the Apache Web Server on port 80 and then build a connection
section to discover the Apache Web Server to Tomcat connection with information collected
from Apache’s configuration file.
A. Navigate to the EMEA Dispatch Scanning Service

1. Remote desktop to your Windows MID Server.
2. Browse to http://198.51.100.11 to view the Dispatch Scanning Service.
Note: Dispatch Scanning Service will be the next Business Service you discover for Cloud
Dimensions.
Discover the EMEA Dispatch Scanning Service using the following information:
• Service Name: EMEA Dispatch Scanning Service
• Owner: Abel Tuter
• Entry Point Type: Web Application
• URL: http://198.51.100.11
• Business Criticality: 2 – somewhat critical
• Traffic based discovery: checked
Hint: Business Criticality and Traffic based discovery can be found from the Additional Info tab.

Note: Since this is the first time Service Mapping discovery is run against a host that was not
previously discovered, a full host discovery occurs, then process detection is executed, followed
by the execution of all patterns that allow for an entry point type of http and host operating
systems of Windows. The Service Mapping process can take a few minutes to complete.
B. Add a New Connection Section

This service also includes a connection to a Tomcat application server, but because no
connection section exists in the Apache pattern, no outbound connection was made. In this
section, you build an Apache to Tomcat connection section.
2. Search and open the Apache On Windows pattern record.
3. From the Connection Section, click New.
4. From the Connection Section dialog window, enter the name CD Apache to Tomcat
Connection.
Note: There is a baseline connection section for Apache to Tomcat, but based on Cloud
Dimensions implementation, they have decided to create a new connection section versus
modifying the baseline connection section. However, both methods are acceptable.
5. Click Done.

6. Save the pattern.
7. Click and open CD Apache to Tomcat Connection to open the connection section in
pattern designer.
8. Click Debug Mode and configure it appropriately.
Hint: Refer to the entry point defined at the start of the lab as a reference.
9. Click Connect.
Create New Connection Step 1
In this section, you create your first connection section step in the Apache on Windows
pattern to obtain information stored in the Apache httpd.conf file.
1. Change the name of step 1 to Get Tomcat proxy params.
2. Complete the form as shown by setting the following parameters:
Note: All strings are case sensitive
• File path: $process.currentDir+"conf\httpd.conf"
• Parsing Strategy: Delimited text
• Include Lines: Proxy
• Exclude Lines: Reverse|Via
• Variables: Table
o Variable Table Name: proxy_params_table
o Variable Column Names: key_column, path_column, url_column
• Delimiters: space
• Positions: 1,2,3

Note: A pipe can be used as an OR in the Include or Exclude Lines fields. This can be very useful
if you are trying to get more granular in terms of filtering data.
3. After completing the configuration of the step, click Test to verify the ProxyPass
string is parsed correctly as shown:
4. Click Close.

In this section, you create a second step to parse the URL value (or values if more than one
exists) into discrete variables automatically using the Parse URL operation and store them in
another table called proxy_url_table.
1. Create a second step as shown.
• Name: Parse Proxy URL
• Operation: Parse URL
• Source: $proxy_params_table[*].url_column
• Target: $proxy_url_table
Note: This step takes all URL discrete components and places them into specific columns of a
new table called proxy_url_table. Table names can be whatever you want to call them but
should have meaningful names.
2. Click Test to verify the URL is parsed as shown:
Note: This operation prevents the need for the pattern writer to parse the URL using a
delimited, regular expression or some other parsing strategy.

In this section, you create the last step that will create the connection between Apache and
Tomcat using the configuration information collected/parsed and stored in the various
columns within the proxy_url_table.
1. Create a third step as shown:
• Name: Create Tomcat Connection
• Operation: Create connection
• Select Connection Type: Application Flow
• Select Entry Point: HTTP(S) Endpoint
• Connection attributes:
o host | $proxy_url_table[*].host
o port | $proxy_url_table[*].port
o protocol | $proxy_url_table[*].protocol
o url | $proxy_url_table[*].url
3. Click Test to verify the variables are populated as shown:

Discover the EMEA Dispatch Scanning Service with the new connection section using the
following information:
• Save and Publish the pattern
• Rediscover the EMEA Dispatch Scanning Service
• Verify a new connection is created from Apache to Tomcat
• Verify the connection attributes are viewable in the Properties pane

C. Improve Performance
In the next section, you modify the CD Apache to Tomcat connection section to target the
Tomcat CI Type since you know this connection section is configured specifically to connect
Apache to Tomcat.
1. From the EMEA Dispatch Scanning Service map, right-click the Tomcat icon and
select Show discovery log…
2. Notice that several patterns are tried before a match with the Tomcat pattern.

Modify the CD Apache to Tomcat connection section as shown:
Note: Entering a Target CI Type limits the pattern being tried to only the specified CI Type. In
this example, only the Tomcat pattern will be tried when using this connection section.
• Save and Publish the pattern

• Rediscover the EMEA Dispatch Scanning Service
• After discovery completes, verify the Discovery Log for the Tomcat application only
displays that the Tomcat pattern is tried and is successful


Lab
More Connection Section 7.2
Building 660m
Lab Objectives
An Apache web server and a Tomcat application server comprise key applications for the Cloud
Dimensions EMEA Dispatch Scanning Service.
After the service is discovered, it is sent for review to the application owner, who brings to the
implementation team’s awareness that there is a connection from Tomcat to a HyperSQL
database that is missing from the map.
The implementation team must complete the map based on the missing information and send
the map back to the application owner for final approval.
In this scenario, it will be the responsibility of the implementation team to build a connection
section between the Tomcat war and HyperSQL, and build a functional identification section
and class for HyperSQL including an appropriate identification rule.
Note: This lab is designed to be less step by step to provide the student with more independent
learning, but should provide sufficient information to complete all sections.
A. Handle the Approval and Request for Data Process Flow

In this section, you send the EMEA Dispatch Scanning Service map to the application owner,
Abel Tutor, for review. Abel Tutor rejects the map and as the administrator you request
additional data, which Abel Tutor provides to you.
Hint: Refer to the lab, Review and Approve Map, if you are having difficulty navigating the
process flow to review and approve a map as required in the following tasks.
• Assign the appropriate role to the Application Owner, Abel Tuter, in order for him to be
able to review the map
• Starting from the Service Mapping Home page, navigate and send the EMEA Dispatch
Scanning Service for review to the Application Owner, Abel Tuter
• Impersonating Abel Tuter, review the map for the EMEA Dispatch Scanning Service, and
reject the map providing the following reason: “Tomcat should display a connection to a
database”

• As the System Administrator, from the EMEA Dispatch Scanning Service form, Request
additional data by asking to Abel Tuter the following: “Can you provide additional
information on the type of database Tomcat should be connecting to”
• Impersonating Abel Tuter, review the open task and from the Business Service form set
the Service Process Task that has a State of Open, to Work in Progress.
• From the Worknotes enter and post the following information: “Tomcat should display a
connection to a HyperSQL database” and finally select the action to Submit
Questionnaire.

B. Create a New Tomcat WAR to HSQLDB Connection
Section
Logged in as the System Administrator, after collecting the requirements from the
application owner, you work on the service map to bring it to completion and final approval.
The final map will require a new connection from the Tomcat war to a new CI Type called
HSQLDB.
• For the Tomcat war pattern, create a new Connection Section, called Tomcat WAR to
HSQLDB.

Create Step 1:
In the first step of the connection section, you use the Parse file operation to obtain JDBC
information from the parent conf XML file using an XML parsing strategy.
1. Open the Tomcat WAR to HSQLDB connection section into Pattern Designer.
2. Click the Debug Mode.
3. Configure Debug Mode as shown:
• Select Entry Point Type: HTTP(S) Endpoint
• URL: http://198.51.100.11:9080
• Directory: /examples
Note: The debug information represents the server and port that the Tomcat war application is
running on, which has critical information on how Tomcat is configured to communicate and
connect to HSQLDB.
4. Click Connect.
5. Complete step one as shown and then click Retrieve File Content.
• Rename step 1: Get JDBC Info
• Select File: $parent.conf_file
• Parsing strategy: XML file
Note: When creating a connection section, variables from the identification section can be
leveraged such as $parent.conf_file.

6. Within the retrieved content, towards the bottom, find the following string and
using your cursor, highlight it:
• jdbc:hsqldb:hsql://198.51.100.11:9001/xdb.
7. From the dialog box that appears, enter jdbc_info_column and hit enter.
Note: A temporary variable is automatically created and all similar XML tagged strings are
highlighted and stored in the table.
8. Under the Variables section, select Table.

9. Under the Variables section, configure it as shown:
10. Click Test to verify the result of the operation.
Note: You have created a table that contains all three JDBC connections.

Create Step 2:
In this step, you use the Filter table operation to filter only for the hsqldb connection in the
jdbc_info_table. This is the only connection of concern based on the entry point and service
being discovered.
1. Create step two as shown:
• Name: Filter Table for JDBC Info
• Operation: Filter Table
• Source table: $jdbc_info_table
• Target table: $new_jdbc_info_table
• $jdbc_info_table[].jdbc_info_column | Contains | “hsql”
2. Click Test and verify the new table displays filtered data with only the connection
information for HSQLDB.
Note: The Filter Table operation allows for the filtering of records that are pertinent to this
service.

Create Step 3:
In this step, you use the Parse Variable operation to segregate the HSQLDB URL string into
discreet components.
1. Create step three as shown:
• Name: Parse JDBC Connection Details
• Operation: Parse Variable
• Enter Variable: $new_jdbc_info_table[*].jdbc_info_column
• Define Parsing: Delimited Text
• Table Variable: jdbc_connection
• Variables: protocol, host, port, instance
• Delimiters: / and :
• Positions: 3,4,5,6
Note: In the hsql:// portion of the string, the first / acts as an escape character for the second /
and therefore are not included in the positional counting of the delimiters.

2. Click Test to verify the string is parsed correctly as shown:
Create Step 4:
In the last step, you use the information you collected, parsed, and stored in the
jdbc_connection table to define the connection information.
1. Create step four as shown:
• Name: Create Connection
• Operation: Create Connection
• Select Connection Type: Application Flow
• Select Entry Point: MS SQL Server Endpoint
• Enter Connection Attributes:
o host | $jdbc_connection[*].host
o Instance | $jdbc_connection[*].instance
o port | $jdbc_connection[*].port
Note: Currently no specific Entry point type exists for HSQLDB, so temporarily you utilize the MS
SQL Server Endpoint type since the attributes required to build a connection are the same.

2. Click Test and verify the connection information displays as shown.
3. Save and publish the pattern.
4. Rediscover the EMEA Dispatch Scanning Service.
5. Verify a new connection is created from the Tomcat WAR to a Generic Application
called java.exe as shown.
Note: The connection section is working, but there is no pattern and identification section
currently configured to identify HyperSQL, and therefore Tomcat shows a connection to a
Generic Application. Service Mapping knows it is connected to something, but cannot determine
the correct class (CI Type).

C. Create a New Entry Point for HyperSQL
In order for Service Mapping to identify the HyperSQL database you need to create a new
entry point, new CI type, new identification rule, new pattern and identification section. You
begin by creating a new Entry Point.
2. Click Hierarchy.
3. Under CI Classes, search for and select Endpoint.
4. Right-click Endpoint and Add Child Class.

5. Navigate the Create Class wizard to configure the new HSQLDB Entry Point using the
following information:
Provide Basic Info:
• Display Name: HSQLDB Entry Point
• Table name: u_cmdb_ci_hsqldb_entry_point
Note: A list of fields are inherited from the Endpoint table that was extended. Port and Host are
automatically inherited, but a new field for instance needs to be added.
Add Attributes:
• Column label: Instance
• Column name: u_instance
• Type: String
• Max length: 40

Set Identification Rule:
Hint: Under Identification Rule, click Add.
Hint: Under Identifier Entries, click Add and use attributes from the main table.

6. From the Create Class wizard, click Next.
7. From the Add Reconciliation Rules tab, click Next then Done to create the new
class.
D. Modify the Tomcat WAR to HSQLDB Connection Section

to use new Entry Point
1. Reopen the Pattern Designer for the Tomcat WAR to HSQLDB connection section.
2. From the Create Connection step, modify the Select Entry Point to use the new
HSQLDB Entry Point as shown:
Note: It may be necessary to reopen the Pattern Designer to refresh and view the new HSQLDB
Entry Point.

3. Save and Publish the pattern
4. Rediscover the EMEA Dispatch Scanning Service.
5. Verify a connection from the Tomcat war to the Generic Application is created using
the new Entry Point.
Note: MS SQL Server Endpoint is no longer being used.

E. Create New HyperSQL Class (CI Type)
In order to identify HyperSQL accurately and not as a generic application, it is still necessary
to create a new class (CI Type) and pattern. In a previous lab, you created a new pattern,
class, and process classifier from the generic application icon on the map. In this section, you
will use the CI Class Manager to create a new class that extends from the Database instance
class.
2. Click Hierarchy.
3. Under CI Classes, search for and select Database instance.
4. Right-click on Database instance, and select Add Child Class.
5. Configure the Provide Basic Info tab using the following information:
• Display Name: HyperSQL
• Table name: u_cmdb_ci_hypersql
• Icon: Database
6. Under the Add Attributes tab add a new field as shown:
7. From the Set Identification Rule tab, click Replace and verify Dependent is selected
and then click Save.
8. From the Set Identification Rule tab, under Identifier Entries, click Add.
9. From the New Identifier Entry window, select Use attributes from main table.

10. Configure the Identifier Entry as shown:
11. View and accept the defaults for the remaining tabs.
12. From the Add Suggested Relationships tab, click Done to create the new class and
identification rule.
Note: A new HyperSQL class extended from the Database instance class is created in addition to
a new HyperSQL identification rule.

F. Create New HyperSQL Discovery Pattern
2. Click New.
3. Configure the new pattern as shown:
4. From the Identification Section, click New.
5. Configure the Identification Section as shown.
6. Click Done.
7. Save the pattern.

G. Configure HyperSQL Identification Section
In this section, you create two steps. One to determine if hsqldb is contained in the
command line of the running process. The second step is to set the name of the application
from the HyperSQL readme file.
For the purpose of this exercise, you are going to keep the identification section steps to a
minimum, however it would be prudent to add additional steps to this section if the
following are required:
• further information to clearly identify HyperSQL

• information required for the Identification Rules
• information for any mandatory fields defined for the class/table
• additional information required from the application owner about the application
• potential information that may be used by each of the connection sections
1. Select and open the HyperSQL Identification Section to open Pattern Designer.
2. Click Debug Mode.
3. Complete the Debug Identification Section as shown:
4. Click Connect.

5. Complete step one as shown:
• Rename step 1: Match Command Line
• $process.commandLine | Contains | “hsqldb”
6. Complete step two as shown:
• Name: Set Name
• Select File: C:/hsqldb/readme.txt
• Define Parsing: Regular Expression
• Variable: name
• Regular Expression: .* (.+) v

Note: To better understand the regular expression used, navigate to regex101.com and enter
the Regular Expression and Test String and read the explanation. Note there are spaces before
and after the parentheses.
7. Test the step and verify name is populated as HyperSQL.
8. Save then Publish the pattern.
H. Update Create Connection Step and Rerun Discovery

1. Update the Tomcat WAR to HSQLDB connection section and modify the Target CI
type to HyperSQL.
2. Save then Publish the pattern.

3. Rediscover the EMEA Dispatch Scanning Service and verify the HyperSQL
application is identified using the HyperSQL class (CI Type) and not as a Generic
Application.
Note: If the HyperSQL pattern is not tried, a restart of the MID Server may be required.
I. Send Service for Final Review and Approval

The final step of the service lifecycle is to have the map approved by the application owner.
• Logged in as the System Administrator send the EMEA Dispatch Scanning Service for
review to the application owner, Abel Tuter
• Impersonating Abel Tutor, Approve Service Map
• Logged in as the System Administrator, from the Service Mapping Home page, verify the
service displays under the Completed tile as an Approved Service.
Congratulations, you have approved and completed the service map for the
EMEA Dispatch Scanning Service and met all the requirements as listed by the
application owner.



Estimated Time to Complete: 45 minutes



• Use Case 1: ServiceWatch (45 minutes)
• Use Case 2: Moodle (60 minutes)
• Use Case 3: Presta (45 minutes)

Lab
Use Case 1: ServiceWatch 8.01
645m
Lab Objectives
While Service Mapping is being implemented at Cloud Dimensions, the company plans to
continue to use their legacy ServiceWatch application that needs to be discovered and
modeled as a service using Service Mapping.
In the previous labs, you have been given step-by-step instructions to meet specific
requirements. In this lab, you will be given tasks with specific requirements that need to be
met.
Cloud Dimensions has set forth several requirements that are documented as tasks that you
will need to complete. In doing so, you will be validating your Service Mapping skills learned
during this training.
Hint: When discovery is running, it is recommended to move to the next task to understand the
requirements and even start the work required.
Note: For assistance if needed, potential solutions are provided at the end of this lab for your
reference.
Skills tested:
• Create new CI Type
• Configure Debug Mode
• Create new CI Type attribute
• Create and modify new Identification Section
• Assign new icon to CI Type

A. Discover and Model ServiceWatch Service
Cloud Dimensions wants to model and monitor their ServiceWatch service. They want the
implementation team to discover the Americas ServiceWatch Portal service that is
supported by the ServiceWatch application installed in their environment. The following
information is provided:
• Service Name: Americas ServiceWatch Portal
• Service contains one application running on host 198.51.100.241 on port 8080
• Application Owner: Andrew Jackson
• Traffic based discovery should be turned off
• Credentials are administrator/1G00dDemo for the server running the application
When first discovering the service, the implementation team notices the ServiceWatch
application displays as a generic application because no Discovery Pattern or CI Type exists in
the baseline Service Mapping application.
Results after running initial discovery:
Note: Discovery can take up to 10 minutes

B. Create New ServiceWatch Class and Discovery Pattern
The implementation team’s goal is to meet the following requirements:
• Create a ServiceWatch class that extends the Application table
• Set the ServiceWatch application class icon on the map to display as an Application
Server
• Create ServiceWatch identification section to Identify the ServiceWatch application
based on a match on neebula contained within the ServiceWatch commandLine
• Set name of application to Neebula ServiceWatch leveraging the wrapper.displayname
value found in the …ServiceWatch\server\conf\wrapper.conf file
The implementation team, is expected to define a dynamic path to the wrapper.conf file
using one of the process variables available.
Expected Results Post Configurations:

C. Populate Version
Cloud Dimensions would like to populate the Version attribute for the ServiceWatch
application with data obtained from the Windows registry where the ServiceWatch server is
installed.

• Set the ServiceWatch version based on the value found in the following registry path:
o HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Neebula ServiceWatch
The Implementation team’s goal is to modify the ServiceWatch Discovery Pattern, by adding
a new step using the Get registry key operation, to obtain the version value from the registry
path provided and display it in the Properties pane as shown.
Expected Results Post Configuration:
D. Get Final Approval from Application Owner

As a last step, final approval must be provided by the application owner.

• Configure application owner with appropriate role to review and approve the map
• Send the service for review to the application owner
• Impersonate application owner and approve map
• Verify approved map appears under the Completed tile on the Service Mapping Home
page

Potentials Solutions to Tasks:
Task A:

Task B:

• Delimiter: \bin\
• Position: 1

• File path: $server_path+"\conf\wrapper.conf"
• Regular expression: wrapper.displayname=(.*) Server

Task C:

Task D:


Lab
8.02
Use Case 2: Moodle Service 660m
Lab Objectives
Cloud Dimensions is in the process of installing and configuring a new learning portal to
provide its employees with easy access to all available internal classes.
In this lab, you install and configure the new learning portal, also known as the Moodle
Service.
After installing the new applications that comprise the service, you become inherently the
application subject matter expert and the application owner.
At the end of the lab, you are asked to discover the service using Service Mapping.
In this Use Case, you will:
• Create an IIS web site to host the Moodle application

• Install the Moodle and MySQL applications
• Create the MySQL database
• Configure Moodle to communicate with the MySQL database
• Configure Service Mapping to discover the Moodle service
Note: The steps to install and configure the IIS web site, Moodle, and MySQL are provided,
however you will be tasked with discovering the service.
Skills tested:
• Discover newly configured service where you are the Subject Matter Expert

A. Install MySQL
In this section, you install and configure MySQL Server on the Windows MID Server you were
provided. MySQL Server will be used as the database backend for the Moodle application
you will install and configure later in this lab.
1. From your Windows MID Server desktop, navigate to:

c:\CloudDimensions\MoodleMySQL\MySQL and double-click on mysql-installer-
community-5.7.16.0 to start the installation of MySQL.
2. Click Run.
3. After the License Agreement form displays, at the bottom select the I accept the
license terms checkbox and click Next.
4. From the Choosing a Setup Type form, select Server only and click Next.
5. From the Installation form, click Execute.
Note: The installation can take up to a couple of minutes.
6. After the installation is complete, click Next.
7. From the Product Configuration form, click Next.
8. From the Type and Networking form, modify the Config Type field to Server
Machine, accept the remaining defaults and click Next.
Note: The default port used is 3306.

9. From the Accounts and Roles form, enter the following:
• MySQL Root Password: #_M00dle_ (number sign, under score, capital M, zero,
zero, lower case dle, underscore)
• Repeat Password: #_M00dle_
10. After entering the password information, click Next.
11. From the Windows Service form, accept the defaults and click Next.
12. From the Plugins and Extensions form, click Next.
13. From the Apply Server Configuration form, click Execute.
14. After the configuration completes, click Finish.
15. From the Product Configuration form, click Next.
16. From the Installation Complete form, click Finish.
Note: You have completed the installation of MySQL Server.
B. Create Moodle Site on IIS

In this section, you create a web site using Microsoft Internet Information Services (IIS). The
new web site will host the application you install later in the lab.
1. From the Windows MID Server desktop, click Start > Administrative Tools > Internet
Information Services (IIS) Manager.
2. From the left pane, right-click on Sites and select Add Web Site.

3. Complete the Add Web Site window as shown:
• Site name: mymoodle
• Physical path: C:\inetpub\wwwroot\moodle
Note: The moodle application files were previously downloaded from the internet and copied to
the wwwroot directory
4. Port: 9090
5. Click OK.
Note: The mymoodle site is created using port 9090.
C. Install Moodle and Configure with MySQL Server

In this section you will install and configure the Moodle application and configure it to
communicate with the MySQL Server you previously installed.
1. From the left pane of the Internet Information Services (IIS) Manager window,
right-click on the newly created mymoodle site.

2. Select Manage Web Site > Browse to open the Moodle installation window.
Note: This page may take a short while to load.
3. From the Choose a language form, accept the default settings and click Next.
4. From the Confirm paths form, accept the default settings and click Next.
5. From the Choose database driver form, accept the default settings and click Next.
6. From the Database settings form, complete the configurations as shown:
• Database host: localhost
• Database name: moodledb
• Database user: root

• Database password: #_M00dle_ (number sign, under score, capital M, zero, zero,
lower case dle, underscore)
• Table prefix: mdl_
• Database port: 3306
Note: The information entered here is being written to a file called config.php. Discovery could
leverage the settings in this file to potentially identify the application and host connections.
7. After completing the Database settings, click Next.
8. From the Copyright notice form, click Continue.
9. From the Server checks form, verify from the bottom of the window, your server
meets all the minimum requirements and then click Continue.
Note: The transition to the next form may take a short time to complete while the tables are
being created.
10. From Installation form, verify the Moodle tables are created successfully and click
Continue.
11. From the Installation General section, complete the form as shown:
• Username: admin
• New password: MyM00dle_ (capital M, lower case y, capital M, zero, zero, lower
case dle, underscore)

• First name: Admin
• Surname: User
• Email address: [email of your choice]
• Select a country: [country of your choice]
• Timezone: [timezone of your choice]
12. After completing the profile information, click Update profile.

13. From the New settings form enter the following information:
• Full site name: Cloud Dimensions Moodle Service
• Short name for site: Moodle
14. Click Save changes.
Note: Moodle installation and configuration with MySQL is completed.

D. Verify the Installation
In this section, you verify the installation of the Moodle Service and view the configuration
information for Moodle and MySQL Server.
1. After completing the installation, you are navigated to localhost:9090/my/ to

display the Moodle web page.
2. From the Navigation pane, click Site home to display the Cloud Dimensions Moodle
Service home page.
3. Click Add a new course.
• Course full name: Service Mapping Fundamentals
• Course short name: SMF
• Course ID: SMF-M010
5. Click Save and return to create the course.
Note: A new course is added to the MySQL database that is a critical application that supports
the Moodle Service.

Using Service Mapping, discover the newly installed and configured Moodle service to return
results as shown utilizing the following information:
• Configure the Moodle service with a valid Entry Point
• From the IIS Virtual Directory discovery pattern, create a new connection section called
IIS Virtual Directory to MySQL
• In IIS Virtual Directory to MySQL connection section create a connection leveraging the
host and port defined in "C:/inetpub/wwwroot/moodle/config.php"
• Update the MySQL Server pattern by creating an extension section to collect the max
connections value from the my.ini file
Note: Take some time to attempt to discover this service without referring to the potential
solution at the end of this lab.

Potential Solutions:
Application Service Entry Point:

• http://PrivateIP:9090/mymoodle
IIS Virtual Directory to MySQL Connection Section Steps:
• Variable: host
• Regular Expression: .*dbhost.*'(.*)'

Collect Max Connection for MySQL Instance:


Lab
8.03
Use Case 3: Presta 645m
Lab Objectives
Scenario
Cloud Dimensions has a storefront supported by a service called Presta. Presta has a web
front end with a MySQL Server backend. The service is critical to Cloud Dimension’s monthly
revenue streams.
The implementation team is asked to discover and model the Presta service using Service
Mapping
You will achieve the following objectives:

• Configure credentials
• Configure Debug Mode
• Create Connection Section
• Create new CI Type attribute
• Modify Identification Section
• Parse XML file
• Filter table
• Set variable

A. Discover Presta Service
Discover the Presta service using the following information to achieve the expected results.
• Host Server for Apache: 198.51.100.165
• Apache Port: 80
• Host Server Credentials: administrator\1G00dDemo
• New Connection Section Required: Apache to MySQL
• MySQL Server Port: 3306
• Connection Information directory: C:\Bitnami\prestashop-1.6.1.4-0\conf
• Principal Developer located in file: ...prestashop-1.6.1.4-
0\apache2\conf\AppOwner
• Connection should display host, port, and instance information

Use Case 3 Solution Recording if needed:
• Navigate to Self-Service > Knowledge > Training Support Files > Use Case Solution


An up to date and accurate CMDB is crucial to streamlining a companies ITSM processes. Controlling
updates to the CMDB and identification of duplicate CIs is a must for any streamlined CMDB
process.
During this module, many of the common questions posted here will be answered and made clear
as to how Service Mapping interacts with the CMDB.

CMDB Identification and Reconciliation Framework helps maintain the integrity of the CMDB when
multiple data sources such as Discovery, import sets, and 3rd party applications are used to create
and update CI records in the CMDB.
The use of multiple sources increases the risk of introducing inconsistencies through duplicate
records. To maintain the integrity of the CMDB, it is important to correctly identify CIs and services
so that new records are created only for CIs that are truly new to the CMDB. Identification and
Reconciliation helps you prevent duplication of CI records, reconcile CI attributes, reclassify CIs, and
allow only authoritative data sources to update the CMDB.

The Identification/Reconciliation application is comprised of 6 key modules that will be covered in
this section.

The CMDB identifiers provide a single point of entry for inserting and updating CIs in the CMDB that
ensures data integrity. These identifiers simplify the way applications such as Discovery, Service
Mapping, and SCCM interact with the CMDB. By providing a common interface for updates, the
system reduces the probability of duplicate CIs from the different sources.
A baseline Kingston instance will contain these default Hardware and Application rules which are
used by Discovery, Service Mapping, and other 3rd party discovery tools to determine if a discovered
CI is inserted or updated in the CMDB. When discovery runs, it will iterate through each of the
hardware rule identifier entries until it finds one complete match with a CI in the CMDB, if no match
is found, a new hardware CI is created.

Example of Discovery iterating through the various Hardware Rules until a match is found using
Name.

In this demonstration you will see where Identification Rules are defined and how they are
configured.

Reconciliation Definition: If a CI Type or CI Type attribute does not have any reconciliation rules
defined, data sources are allowed to overwrite each other's updates.
Sample Background Script to test:

var payload = {items: [{className:'cmdb_ci_win_server',
values: {name:’serverxyz',
ram:'2048’,
disk_space:'1000'
}}]
};
var jsonUtil = new JSON();
var input = jsonUtil.encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCI('Altiris', input);
gs.print(output);

Datasource Precedence: if multiple data sources are authorized to update the same table or the
same table attributes in the CMDB based on the reconciliation definition, datasource precedence
assigns an order to each of these data sources to prevent a higher order (lower priority) data source
from overwriting a lower order (higher priority) data source.
Datasource Precedence and Reconciliation Definitions can be accessed under the Configuration
menu and are optional platform features and not specific to Discovery or Service Mapping.

If multiple data sources are authorized to update the same table or the same table attributes in the
CMDB, Datasource precedence rules allow for the assignment of a priority to each of these data
sources to prevent lower priority (higher order value) data sources from overwriting higher priority
(lower order value) data sources..
After an attribute is updated by an authorized data source, any subsequent updates are accepted
only from the same data source or from a data source with a higher priority (lower order value).
Updates from a data source with a lower priority are rejected. Without datasource precedence
rules, data sources can overwrite each other's modifications. Basically, last update wins.
In this example any update, to a Windows Server Disk Space, coming from ServiceNow Discovery
will take precedence over discovery data coming from Altiris or data coming from an import set.
1. Original Windows Server data is brought in by an Altiris– Record Inserted
2. Same Windows Server is imported by Import Set– Record Updated
3. Same Windows Server is discovered by ServiceNow – Record Updated
4. Same Windows Server is reimported – Record Not Updated

In this demonstration you will see where and how Reconciliation Definitions and Datasource
Precedence is defined and used.

De-duplication tasks provide details about duplicates, including a list of all duplicate CIs and the
internal payload used during the identification process. Review the details of each duplicate CI in the
task and the data that was used to determine that the CI is a duplicate.
When discovered hardware and applications come into ServiceNow, and duplicate records are
found, the discovery process continues and updates the oldest record (assuming there are less than
5 duplicate records), and a de-duplication task is created. Use de-duplication tasks to track the
duplicate CIs until they can be resolved.
There are a couple of System Properties to control this behavior:

glide.identification_engine.skip_duplicates
• Controls how identification processes a small set of duplicate CIs. When true, if the number of
duplicate CIs is less than the threshold specified by
glide.identification_engine.skip_duplicates.threshold, then the oldest of the duplicate CIs is
picked as a match and gets updated. The rest of the duplicate CIs are tagged as duplicates. When
false, matching a CI fails, and an error is logged.
glide.identification_engine.skip_duplicates.threshold
• Controls the maximum number of CIs that can be in a set of duplicate CIs to allow identification
to process the duplicate CIs according to the setting of
glide.identification_engine.skip_duplicates. If the number of duplicate CIs exceeds the threshold,
then identification processes the duplicate CIs as if glide.identification_engine.skip_duplicates is
set to false.

The configuration management database (CMDB) employs the following tables:
§ The core Configuration Item [cmdb_ci] table, which stores the basic attributes of all the CIs
§ The CI Relationship [cmdb_rel_ci] table, which defines all relationships between CIs
The Configuration Item table is extended to other tables, such as Hardware [cmdb_ci_hardware]
which in turn is extended to Computer [cmdb_ci_computer] and so on.
Each extended table is a class which is groups CIs that share the same attributes and are stored in
their own table. These classifications allow administrators to define the hierarchy of CIs within the
CMDB. It is recommended to keep CI classifications as simple as possible.
The base class that the [cmdb_ci] table extends off of is [cmdb]. This table was introduced a few
releases back, to support a different types of configuration items that ServiceNow customers may
want to populate and track in the CMDB that are not of type hardware or application. Some
customers build their own class structure under the [cmdb] table to populate and track different
types of items such as livestock, manufacturing parts, and microprocessor equipment.

Applications stored in the CMDB also extend off the core Configuration Item [cmdb_ci] table . In this
example, Tomcat extends off of an Application Server table that extends an Application table that in
turn extends off the Configuration Item table. Understanding these table relationships are very
important if you want to build UI Policies, Business Rules or Scheduled Jobs to support the
management of the CMDB.

Upgrade
The CI class is updated to a class that is higher in class hierarchy, and the newly assigned class is a
derived child of the current class and has additional attributes. For example, reclassifying a CI from
the cmdb_ci_computer class to the cmdb_ci_server class.
Downgrade
The CI class is updated to a class that is lower in class hierarchy, and the newly assigned class is a
parent of the current class and has less attributes than the current class. For example, reclassifying a
CI from the cmdb_ci_server class to the cmdb_ci_computer class.
The cmdb_ci_server class has attributes that the cmdb_ci_computer class does not have. During the
downgrade, these attributes and their respective values are not included in the new CI record that is
inserted into the cmdb_ci_computer class.
Switch
The newly assigned class is in a different branch in the class hierarchy and has a different set of
attributes than the current class. For example, reclassifying a CI from the cmdb_ci_linux_server class
to the cmdb_ci_win_server class.
Use the following System Property to enable logging of the Identification and Reconciliation engine:
• Name: glide.cmdb.logger.source.identification_engine
• Value: debugVerbose

1. Determines if a CI exists or not
2. Determines if a discovery source is allowed to update a CI or a CI’s attributes, it does not affect
who can create a CI
3. Yes
4. The oldest CI is updated, the newest CI has its discovery source updated to duplicate, and a de-
duplication task is created

Lab 9.1: Hardware Identification & Classification (30 minutes)

Lab 9.2: Application Identification Rules (15 minutes)

Lab
Hardware Identification and 9.1
Reclassification 630m
Lab Objectives
In this section, you learn how ServiceNow handles identification and reconciliation of
hardware CIs that are created or updated in the Hardware [cmdb_ci_hardware] table or any
of its extended tables. The identification rules (CI Identifiers) provide a single point of entry
for creating and updating CIs in the CMDB to assure data integrity.
These rules simplify the way applications such as Discovery, Service Mapping, SCCM, or any
other 3rd party application interacts with the CMDB.
By providing a common API for inserts and updates, the system reduces the probability of
duplicate CIs from different sources.
Additionally, during the CI identification process, a CI might need to be reclassified to a

different class. CI reclassification is automatically enabled in the system.
A. Hardware Reconciliation
In this section, you will learn how ServiceNow handles reconciliation of hardware CIs as they
are created or updated in the CMDB.
1. Navigate to Configuration > Identification/Reconciliation > CI Identifiers.
2. Search for and open the Identifier record named Hardware Rule.
Note: This rule is used to reconcile any CI that is inserted/updated in the Hardware
[cmdb_ci_hardware] table or any of its extended tables such as Windows Server
[cmdb_ci_win_server].

3. Under the Identifier Entries related list, open the records one by one that are shown
in the subsequent screen shot and view their details.
Note: There are Criterion attributes that must be met for the Identifier Entry to match.
Additionally, there is a priority that is defined which controls which order the Identifier Entries
are tried. For example, the Identifier Entry rule that uses name as the Criterion attribute is tried
third after attempting to match on one of the first two Identifier Entries.
5. Search for and open the record that represents your Windows MID Server.
6. From the main form, add two X’s to the end of the Serial number field value.
Note: Adding the additional characters to the Serial number will prevent the Hardware Rule to
reconcile on rule number 1 and 2, Serial number and Serial number type.
7. Under the Serial Numbers related list, add two X’s to the end of the Serial Number
of type system.
Note: Adding the additional characters to the Serial number prevents the Hardware Rule to
reconcile on rule number 1, Serial number and Serial number type.
8. Save the record.
10. Click Quick Discovery.

11. Set the Target IP to your Windows MID Server private IP address.
12. Select the MID Server you installed earlier.
13. Click OK to start Discovery.
14. Open the Discovery Status record that displays.
15. Under Related Links, click the Refresh UI Action until the State of the Discovery
Status record displays Completed.
16. After Discovery completes, select the Discovery Log tab and note that Rule 3
confirms a Match on the Name attribute.
Note: Rule 1 and 2 which relied on Serial number and Serial Number type, no match was found,
however the third rule found a match on name and the record is updated.
19. Verify the Serial number fields are updated and the X’s no longer display.

If any of the Hardware Rule Identifier Entries do not find a match, then a new Hardware CI is
created.
From the Configuration > Servers > Windows module, locate your Windows MID Server
record and modify the following fields by adding an x to the end of the existing values:
• From the Windows Server form modify the Name and Serial Number fields
• From the Serial Numbers related list, modify the Serial Number of type system
• From the Network Adapters related list, modify the MAC Address
• Using the Quick Discovery feature, run Discovery against your Windows MID Server and
verify a new Windows Server is created in the CMDB.
Note: A new Hardware CI is created because the Hardware Rule found no match on Name,
Serial Number, Serial Number Type, or MAC Address.

If the instance encounters duplicate CIs during the identification and reconciliation process,
the oldest CI is updated and the newest CI’s Discovery source field is updated with a value of
Duplicate. In addition, ServiceNow groups each set of duplicate CIs into a de-duplication task
for review.
Complete the following tasks:
• Before continuing delete your Windows Server record that contains the X in the name
• Open the record for your Windows MID Server and right-click the header and choose
Insert and Stay to create a duplicate CI
• Modify the OS Service Pack to Service Pack 1a
• Save the duplicate CI record just created
• From the Hardware Rule, find the Identifier Entry for serial number, and update the
priority to a value of 50.
Note: This forces discovery to check for a match on Serial Number first where currently two CI’s
exist with the same value.
• Using the Quick Discovery feature, rerun Discovery against your Windows MID Server
• After Discovery completes, navigate to Configuration > Identification/Reconciliation >
De-duplication Tasks and verify a new task is created regarding the duplicate records
found
Note: De-duplication tasks provide information on duplicate CIs and can be used to track
duplicate CIs until they can be resolved. An update still occurs on the oldest duplicate CI based
on created date/time.

B. Resolve Duplicates
In this section, you will learn how ServiceNow provides a wizard driven interface to resolve
duplicates CIs.
1. Open the de-duplication task record.
Note: Under the Duplicate Audit Results related list, the duplicate CI records display.
2. Notice the newest record of the duplicates has a Discovery source of Duplicate.
3. From the top right of the form, click the Remediate button.
4. From the Remediate window, click Next.
5. From the Select Master CI tab, click All to display both records.
Note: The wizard provides recommendations as to the suggested Master CI based on the
criteria under the Recommendations column.
6. Under the Recommended tab, select the record and click Remediate Manually.
7. From the Merge Attribute Values tab, click the 1 Other Value link to display the two
different values provided for this field.
8. From the OS Service Pack window, click Select to choose the Master CI record’s
value.
9. Click Next.

10. From the Merge Relationships and Related items tab, choose the defaults and click
Next.
Note: From the Determine Duplicate CI Actions tab, the administrator has the option to delete
the duplicate CI or set a specific attribute on the duplicate CI to a specified value such as Status
to Retired.
11. From the Determine Duplicate CI Actions tab, select Delete, since it is known this is
a test duplicate CI and is no longer needed to be tracked in the CMDB.
12. Click Next.
13. From the Review and Confirm tab, review the dashboard for the actions that will
take place.
14. Click Remediate and then Proceed to resolve the duplicate CI.
15. From the middle tile, click Check Progress to view the de-duplication task and verify
it displays a State of Closed Complete.
16. Navigate to Configuration > Servers > Windows and verify only one record exists
that represents your MID Server.

C. Reclassification
During the CI identification process, a CI may need to be reclassified to a different class. By
default, CIs are reclassified automatically. If automatic reclassification is disabled, then the CI
is not reclassified and the system generates a reclassification task for review.
A CI can be upgraded to a higher class (moved to an extended table), downgraded to a lower

class (moved to a table closer in the hierarchy to the base Configuration item [cmdb_ci table]
table), or switched to a different branch in the class hierarchy, for example from the Linux
Server [cmdb_ci_linux_server] table to the Windows Server [cmdb_ci_win_server] table.
In this section of the lab you will:

• Move your Windows Server to the Server table
• Run a script to mimic the rediscovery of your Windows Server
• View the reclassification of the Server to the Windows Server table
3. Right-click the header and choose Show XML.
4. Note the value for sys_class_name is Windows Server.
Note: The Windows Server is currently in the Windows Server [cmdb_ci_win_server] table/class
that is an extended table from Server [cmdb_ci_server] table.
5. Close the XML window.

6. Copy or write down the Name of your Windows Server.
7. After capturing the Name, delete the Windows Server.
8. Navigate to Configuration > Servers > All.
9. Click New.
10. In the Name field enter or paste the value you noted earlier.
11. Save the record to create the Windows Server in a new class.
12. Right-click the header of the new server record and select Show XML.
13. Note the new class of the server is cmdb_ci_server.
14. Close the XML window.
15. Navigate to System Definition > Scripts – Background.

16. Enter the following code and replace YOUR SERVER PRIVATE IP (e.g. ‘ip-198-51-166-
144’) with the Name value you copied earlier retaining the single quotes around the
name.
Note: If you prefer not to write the background script, you can copy and paste the script from
the Training Support Files KB on your student instance.
17. Click Run script and verify the log message UPDATE_WITH_UPGRADE displays.

Complete the following task:
• After the script runs successfully, verify the Windows Server is reclassified from the
Server [cmdb_ci_server] to a Windows Server [cmdb_ci_win_server] table
Note: You can reference the following system properties from sys_properties.list to configure
system-wide behavior for CI reclassification:
o glide.class.upgrade.enabled
o glide.class.downgrade.enabled
o glide.class.switch.enabled
Note: These properties are set to true by default, enabling automatic re-classification. To
disable automatic CI re-classification, set the respective properties to false.

Lab
9.2
Application Identification Rules 615m
Lab Objectives
In this section, you learn how ServiceNow handles identification of application CIs that are
created or updated in the Application [cmdb_ci_appl] table or any of its extended tables.
These identification rules simplify and unify the way applications such as Discovery, Service
Mapping, SCCM, or any other 3rd party applications are created or updated within the CMDB.
Required Resource(s): EMEA Customer Support Service is discovered
A. Rerun Discovery on EMEA Customer Support Portal

In the previous lab, you deleted your Windows Server which removed the applications from
the CMDB.
1. Navigate to EMEA Customer Support Portal map and rediscover the service.
2. After the service is rediscovered, select the Mongoose icon on the map, and from
the properties pane, under the Application section, click Detailed properties.

3. Add the Discovery source field to the form under Description.
4. Modify the form as shown:
• Version: 5.4
• Discovery source: Altiris
5. Click Update.
Note: You are simulating that another discovery application updated the record with a different
version.
6. Navigate to EMEA Customer Support Portal map and rediscover the service.
7. After discovery completes, verify the Version and Discovery source fields are
updated to their original values.
B. Application Identification Rules (CI Identifiers)

In this section, you will learn how ServiceNow handles reconciliation of Application CIs as
they are created or updated in the CMDB.
2. Search for and open the Identifier named Application Rule.
Note: This rule is used as a catchall identification rule for any CI that is inserted/updated in the
Application [cmdb_ci_appl] table or any of its extended tables such as Microsoft Web Server
[cmdb_ci_microsoft_iis_web_server] table. In addition, this rule is used if no specific
identification rule is created for a new application class/CI Type.

3. Under the Identifier Entries related list, select to open the identifier entry record
that has an Order value of 100.
Note: The Application Rule is used to reconcile applications based on a match for Running
process command, Running process key parameters, and Class. The Allow null attribute is
checked which allows one of the incoming attributes to be blank and still allows for a potential
match with the other Criterion attributes.
5. Search and open the Mongoose Web Server application record.
Note: The Version collected from the Mongoose Pattern used by Service Mapping is 5.5.
6. Add the following fields below Discovery source as shown:
Note: Running process command and Running process key parameters are used by the
Application Rule to determine uniqueness for applications if no other more specific class
Identification Rule is available.


• Modify the Mongoose Web Server record as shown:
• Save the modifications and rediscover the EMEA Customer Support Portal service
• After the service is discovered navigate to Configuration > Applications and verify two
Mongoose Web Server applications exist
Note: The Application Rule did not find a match based on the Identifier Entries and therefore
created a new Mongoose Application.
Note: Before continuing, delete the Mongoose record that contains version 5.4.

C. Create New Application Identification Rule (CI
Identifier)
In this section, you create a more specific identification rule for the Mongoose application.
2. Search and open the Mongoose Web Server record.
3. Modify the Running process command and Running process key parameter fields as
shown:
4. Click Update.
Note: The Application Rule will now fail if used, as it would not find a match on these fields, if
discovery is executed again against the EMEA Customer Service Portal.
6. Click New.
• Name: CD Mongoose Identifier
• Applies to: Mongoose Web Server
• Independent: unchecked

8. Save the record.
9. From the Identifier Entries related list, click New.
Note: You have created a specific more granular Mongoose identification rule that will be tried
prior to the Application Rule. This rule will try to match on Name, Class, and Version. If it finds
no match, it will fall back on the parent rule which is the Application Rule looked at previously.
11. Click Submit.

Recall there is one discovered Mongoose Web Server application that has its Running
process command and parameters field modified which created duplicates in the previous
example.
• Rediscover the EMEA Customer Support Portal
• Verify the discovered Mongoose Web Server application reconciles with the current one
in the CMDB based on the new CD Mongoose identification rule by verifying that the
Running process command and parameters fields are updated with the correct values
and the x’s are removed
• Navigate to Configuration > Applications and confirm there is only one Mongoose Web
Server record in the Applications table and no duplicate was created


ServiceNow provides a wealth of ITOM products available in suites to support any level of need in a
customer’s ITOM landscape.
ITOM Standard (Discovery + Event Management)

• Gain the ability to understand infrastructure and its health
ITOM Professional (ITOM Standard + Operational Intelligence and Orchestration)

• Eliminate Service Outages
ITOM Enterprise (ITOM Professional + Cloud Management and Service Mapping)

• Service Lifecycle Management

The ITOM suite provides a complete 360° Solution for mapping, maintaining, and restoring key
services.
ServiceNow Discovery technology discovers the CI components that make up an IT infrastructure;

servers, network devices, printers, applications, and more.
Service Mapping moves the CMDB into the next strategic level by proving a targeted mapping of the
IT components that support the operational state of a service. The CMDB is transformed from an
inventory to a service aware dependency map.
Event Management collaborates with existing monitoring systems to provide a real-time state of the
IT infrastructure. The application processes infrastructure events and through a combination of
event mapping and alert rules, events are processed and are converted and consolidated into
significant Alerts for investigation and remediation.
ServiceNow Orchestration provides the final piece of the jigsaw. Through the use of workflow, MID
Server, and network processing technologies, Orchestration can provide automated investigation
and remediation on IT systems.

SolarWinds Server & Application Monitor (SAM) is used here as an example of a monitoring tool
that integrates directly with ServiceNow’s Event Management application. SolarWinds can monitor
all the infrastructure in a customer datacenter using WMI, SNMP, CIM, JMX & VMware® API
protocols. In addition, SAM is an agentless and scalable monitoring product that can be deployed
effortlessly across an entire environment.
Services discovered and modeled by Service Mapping can be monitored by 3rd party monitoring
tools to gage overall service health.

Key Tables
Events table: receives events from monitoring systems in approx. real-time. Events carry details of
the Source, Severity CI/Node, Message key and Description of the issue.
Alerts table: Events are processed and are either ignored, transformed and/or promoted to
significant Alerts. Alerts are triggers for action and apportioned to devices and processes in the IT
infrastructure
Rules
Event Rules: Are configured to filter/transform and provide processing logic to either ignore or
promote the Event to an Alert.
Event Field Mapping: This provide functionality to map source data into the appropriate attributes
and data values in ServiceNow.
Alert Rules: Alert rules provide configuration option for the Alert to trigger related records (e.g.
Incident, Knowledge, Problem). Alert rules can also provide option for remediation via
Orchestration procedures.
Connectors
Connector definitions – these are configurations for specific vendors. The connector definition
specifies the MID Server script include that pulls events from the external event source. Baseline,
there are several connector definitions available in the platform: SolarWinds, Microsoft, IBM
Netcool and HP Operations Manager, vRealize, Hyperic. SCOM.
Connector Instances – these are specific configuration to connect to a specific system monitor.

The Event Monitor could be any monitoring tool such as Netcool, Microsoft System Center
Operations Manager (SCOM), SolarWinds, Splunk, or HP Operations Manager. Events can be created
in ServiceNow either through a REST integration or through a MID Server if a native Event connector
definition is available.

Events are generated in ServiceNow and become visible from ServiceNow’s Event Management
application and correlated to Alerts.
An alert can be linked to an incident. This link can be created automatically by an alert rule using a
task template, or can manually be created with the Create Incident button.
Event Management is a separate licensed product or can be purchased as part of one of the
bundles. The Event Management plugin must be enabled which allows IT operation administrators
to combine multiple event sources from monitoring tools such as Icinga, Nagios, or SolarWinds into
a single management console.

The Event Management Dashboard allows you to see your environment at whatever level of detail
you need. For example, you may want to view all your services from a high level, business unit, or
technology type view. The comparative size of the tiles can be configured with reference to
different metrics (business criticality, status, severity, or cost)
The Event Management Overview can be configured to display key reports on the state of services,
alert analysis by service and/or configuration item.

The Event Management service Map provides visibility to the specific Cis that comprise a service
and display the association of the events and the associated CIs that are affecting the overall health
of the service.

The Event Management service Map provides visibility to the specific Cis that comprise a service
and display the association of the events and the associated CIs that are affecting the overall health
of the service.

In this demonstration, you will see the Event Management application, and the automation of
generating an alert and incident from an Event including the change history.

1. Event Management tracks individual events from one or more external systems from a centralized
system and interface
2. Rules
3. Service and Dependency View Maps

Estimated Time to Complete:
Lab 10.1: Events, Incidents, and Changes (30 minutes)

Lab 10.2: Map Errors and Flow Designer (10 minutes)

Lab
Events, Incidents, and Changes 10.1
(Optional) 630m
Lab Objectives
Cloud Dimensions has applications that are clustered to provide high availability on their
critical service called Americas Calendar service. Cloud Dimensions wants to understand how
adding an Event Management license to their ServiceNow Service Mapping implementation
would compliment the functionality they have already invested in.
In addition, they want to further understand the value Service Mapping brings to their overall
incident process and how to view changes to their services.
In this lab, you generate events against one of the CIs that make up this service, work an
incident for the service, and view changes to the service.
A. Add Business Service to Event Management Dashboard

A natural next step for the Americas Calendar Portal that was discovered in an earlier lab and
determined to be accurate, would be to monitor the service for any issues. A separate
licensed ServiceNow application known as Event Management can be used to streamline this
process. Cloud Dimensions is still investigating the benefits of Event Management and would
like to understand how Service Mapping and Event Management complement each other.
1. Navigate to Event Management > Dashboard.
Note: The dashboard only displays approved services. Note that the Event Management license
must be purchased, and the Event Management plugin must be enabled to view the Event
Management application, the dashboard and the other Event Management modules.
3. From the Approve tile, locate the Americas Calendar Portal and go through the
approval process for the service, as learned in an earlier module.
Note: Once a service is approved, the Operational status is changed to Operational and the
service is added to the Event Management Dashboard.

4. After the service is approved, logged in as the System Administrator, navigate to
Event Management > Dashboard.
Note: The Americas Calendar Portal appears on the Dashboard.
5. Double-click on Americas Calendar Portal.
Note: The service map from the perspective of Event Management loads. This map is similar to
that of Service Mapping, but the surrounding buttons and related lists differ.
B. Generate an Event
In this section, you generate an event against the HA Proxy server that is a critical CI of the
Americas Calendar Portal.
1. Navigate to Event Management > Simulation > Event Generator.
Note: This is a non-baseline application that is available as an update set. The Event Generator
allows you to quickly simulate an event into ServiceNow.
• Source: EventSimulator
• Node: ip-198-51-100-167
• Type: EventGen
• Message key: EG001
• Severity: Critical

• State: Ready
• Classification: IT
• Description: Memory exceeded threshold on server ip-198-51-100-167
• Additional information: { "Status":"Up"}
3. Click Generate Event.
Note: If a pop-up window is presented from the browser, click Leave as changes do not need to
be saved.

4. You are automatically navigated to Event Management > All Events.
Note: An event should appear shortly with the Source of EventSimulator. It may be necessary to
refresh the list.
5. From the Events list, search and open the event record, with a source of
EventSimulator, to view the details.
Note: Notice the reference to an alert, which is automatically opened.
6. From the Alert field, click the reference icon to open the Alert record.
Note: The Alert details appear which includes the Configuration item affected.
7. Navigate to Event Management > Overview to view multiple charts around alerts
opened and configuration items and services affected.
Note: The Event Management Overview dashboard automatically refreshes every 15 seconds.
Note: The Americas Calendar Portal appears in red indicating there is a critical alert affecting
the service.
9. From the Dashboard, double-click the Americas Calendar Portal to view the map.
Note: A red line appears below the HA Proxy indicating something is wrong with this CI.
10. From the Alert related list, the alert affecting the service displays.

11. From the upper right, under the Additional actions menu, turn on the Map Indicator
for Incident.
Note: Currently no incident was opened associated to the alert.
12. From the service map, note the Alert displays below the map, when the HA Proxy CI
is selected, but no indicator for an incident displays as no incident was automatically
generated based on the alert.
Note: Visibility around the root cause of the criticality is seen based on the red associated with
the HA Proxy.

C. Work with Event Management
In this section, you create a Task Template and Alert Action Rule that will automatically open
an incident when an event is generated against the HA Proxy.
1. Navigate to Event Management > Rules > Alert Management.
2. Click New.
3. From the Alert Info tab, complete the following:
• Name: Memory Usage Exceeded
4. From the Alert Filter tab, complete the form as shown:
• Source | contains | Event
• Description | contains | Memory Exceeded

5. From the Action tab, complete the form as shown:
• Subflow: Create Incident
NOTE: A new incident for alerts generated for high memory usage is created.
6. After completing the form, click Submit.
D. Open and Investigate Incident

In this section, you regenerate the event to automatically open an incident against the HA
Proxy. After the incident is opened you try to determine an accurate impact and urgency,
then resolve the incident and close the alert.
1. Navigate to Event Management > All Events.
2. Locate the EventSimulator event, and modify the State to Ready in order for the
event to be reprocessed by the Event and Alert Rules.
Note: In a test environment, this is a simple method to reprocess an event versus having to
regenerate it again. If for some reason the event does not get reprocessed, it will be necessary
to regenerate the event as you did earlier. If the incident is not being created, delete the alert
record. You must first change the State to Closed, then delete it and lastly regenerate the event.
3. After the event is Processed, click the Alert number to open the Alert form.
Note: The Alert should now have a reference to a task (incident) record that was automatically
opened. If no incident is referenced, verify your Alert Action Rule is set up as described. If the
Alert Action Rule is correct, try closing the existing alert and reprocess the event or delete the
event and regenerate it by executing the .bat file from your remote Windows server.

4. From the Alert Task field, click the reference icon to open the Incident.
Note: The task/incident record created contains all the details configured earlier in the Task
Template.
5. From the Configuration item field, click the Reference icon to open the referenced
record.
Note: The Linux Server record opens and it can be determined that the server only has 3,952 Mb
of RAM.
6. Click the Back button to return to the Incident form.
7. From the Configuration item field, click the Open in Dependency Views icon to
open the Dependency View map.
Note: The Linux Server displays additional icons on the map to provide visibility associated with
the new incident record.
8. From the upper right, select Map Settings and under Max Levels, change the value
to 1 and then click Apply to view the effect.

9. Modify the Max Levels back to 3 and then click Apply.
10. While on the Settings menu, expand Map Indicators.
11. Turn off all Map Indicators except for Alerts and Incident.
12. From the upper-right, click Details to display tabs that show active Alerts and
Incidents associated with the CI.
13. Click the Related Services tab to provide visibility to the technician that the CI is a
critical server that supports the company’s Americas Calendar Portal.
14. From the Related Service related list, select the Americas Calendar Portal to
highlight all the CI’s that comprise this service.
Note: Visibility to service and the CIs supporting the service are available from the Dependency
View map.

15. Close the Dependency View map tab and toggle back to the Incident form.
16. Change the Impact and Urgency fields to 1 – High as it is clear that this is a server
that supports a critical service and must be prioritized higher than originally
determined.
17. From the Assigned to field, choose Beth Anglin.
18. In the Work notes field, enter This is a critical server that supports the Americas
Calendar Portal, please upgrade RAM to 8GBs and click Post.
19. Save the record.
20. From the bottom of the Incident form, notice the Priority 3 SLA is automatically
cancelled and a new Priority 1 SLA is started, and the elapsed time is carried over
from the initial SLA.
E. Create a Change
It has been determined that the Linux Server needs to have more RAM installed. Typically, a
change record would be created. To save time, you assume the change went through the
proper approval process and RAM was updated to 8GB. From a services visibility perspective,
Service Mapping provides a Time Line of all changes to a service and all of it supporting CIs.
1. Navigate to Configuration > Servers > Linux.
2. Search for and open the Linux Server record named ip-198-51-100-167.
Note: This is the HA Proxy server record.
3. Change the RAM field value to 8,000.
4. Click Update.
5. Navigate to Service Mapping > Services > Application Services and open the service
map for the Americas Calendar Portal and select the HA Proxy icon.
6. Notice from the Changes tab, all changes affecting this CI display including the
recent change to the server CI.
7. From the map, click anywhere in the white space to deselect HA Proxy.

8. Under the Changes tab, click the change record associated to the host with the IP
Address of 198.51.100.167 and notice how the CI affected is highlighted.
9. From the Timeline of CI Changes, notice the markers which indicate some sort of
change has taken place.
10. Hover over the last marker that should reflect the most recent change.
11. Write down the indicated time of the change.
12. Click the Expand timeline icon.
Note: A Compare view appears.

13. In the Compare point 1 field, enter a date/time that is a few minutes prior to the
change time, and in the Compare point 2 field, enter a date/time that is a few
minutes after the change time.
14. Click Compare.
Note: If a pop-up blocker prevents access to the new tab, allow pop-ups from this web site.
15. Select the HA Proxy icon, and from the Properties pane, view the change that took
place between the two compare points, which should reflect the update on RAM on
the server CI.
16. After viewing the Comparison information, close the Comparison view tab.
17. Navigate to Configuration > Servers > Linux.
18. From the Linux Servers list, open the ip-198-51-100-167 record.
19. From the Linux Server Additional action menu, explore each of the History options
to view the changes to the CI including the recent change to memory.
Note: A list of changes and comparison data is available both from the service map and the
CMDB.

F. Resolve Incident and Close Alert
Event Management is configured to close associated alerts when an incident is resolved. In
this section, you will resolve the incident that was previously opened since the RAM has
been successfully increased on the HA Proxy server, and verify the Alert is simultaneously
closed.
1. Navigate to Event Management > Properties.
2. Review the default property settings for actions when an alert is closed or an
incident is resolved.
3. Navigate to Incident > Open.
4. Search for and open the Incident record opened earlier.
5. From the Incident State field, set the value to Resolved.
6. From the Resolution Information tab, set the Resolution code to Solved
(Permanently).
7. In the Resolution Notes, enter RAM increased on server to 8GB.
8. Click Update.
9. Navigate to Event Management > All Alerts.

Note: The alert now displays closed.
10. Navigate to Event Management > Overview.
Note: There are no Active Alerts or services being affected.
Note: The Americas Calendar Portal now displays in green representing no alerts.

Lab
Map Errors and Flow Designer 10.2
(Optional) 610m
Lab Objectives
You will achieve the following objectives:
• Create a flow that creates an incident when a map fails to complete and generates an
error message
• Test the flow by forcing an error and viewing the incident record created
Scenario
Cloud Dimensions is happy with their Service Mapping and Event Management
implementation and can easily view the service health of their services from a single
dashboard. However, Cloud Dimensions is also interested in implementing an incident process
when map errors occur.
In this lab, you implement this requirement utilizing the Flow Designer to automatically
generate an incident record based on map errors.
A. Work with Flow Designer

In this section, you build a flow to automatically create an incident when a mapping error is
generated.
1. From the left navigation pane, enter and navigate to automation_error_msg.list.
Note: The Automation Error Messages list displays all Service Mapping and Discovery errors.
The Source application column defines which application generated the error.

2. Open any record where the Source application is Service Mapping.
3. Right-click the header and choose Show XML.
4. Notice the value for sys_class_name is sa_discovery_message which defines the

table this record is stored.
5. Close the XML file window.
6. Navigate to Flow Designer > Designer.
7. Click New > New Flow.
8. From the Flow Properties form, in the Name field, enter SM Mapping Error.
9. Click Submit.
10. Select Click to add a Trigger.
11. Complete the trigger as shown:
12. After completing the trigger configuration, click Done.
13. Select Click to add an Action, Flow Logic, or Subflow then Action.
14. Select ServiceNow Core > Create Record.

15. Complete the new action as shown:
• Action: Create Record
• Table Name: Incident [incident]
• Fields:
o Impact | 2 – Medium
o Category | Software
o Short description | Trigger > Service Discovery Messages Record > Message
16. Click Done.
Note: You have successfully configured a flow to trigger when an error message is created in
the Service Discovery Message table with a Source application of Service Mapping. The resulting
action is to open an incident with an Impact of Medium, Category of Software, and the Short
description dynamically contains the error message text.
17. Click Save.
18. Click Activate.
B. Force Map Error

In this section, you force a mapping error to test the new flow and automated incident
generation process for map errors.
1. Navigate to Service Mapping > Services > Application Services and open the
Americas Stock Trader map
2. Click Run Discovery.
3. Wait a few seconds and then click, Stop Discovery.

4. After discovery completes, note the error message that displays under the Discovery
Messages tab.
5. Navigate to Incident > Open.
6. Search for and open the most recently opened incident which should have been
opened as a result of the mapping error created as a result of the new flow
configured.
7. Note the preconfigured values for Impact and Software including the dynamic text
in the Short Description field.
Congratulations on completing the lab!

www.servicenow.com/services/training-and-certification.html
4810 Eastgate Mall, San Diego, CA 92121, USA • (858) 720-0477 • (858) 720-0479 • www.servicenow.com
©2018 ServiceNow, Inc. All rights reserved.

ServiceNow believes information in this publication is accurate as of its publication date. This publication could include technical inaccuracies or typographical errors. The information is subject to change without
notice. Changes are periodically added to the information herein; these changes will be incorporated in new additions of the publication. ServiceNow may make improvements and/or changes in the product(s)
and/or the program(s) described in this publication at any time. Reproduction of this publication without prior written permission is forbidden. Then information in this publication is provided “as is”. ServiceNow
makes no representations or warranties of any kind, with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.
ServiceNow is a trademark of ServiceNow, Inc. All other brands, products, service names, trademarks or registered trademarks are used to identify the products or services of their respective owners.

SMF M010 GilmoreBook 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

SMF M010 GilmoreBook PDF

Uploaded by

Copyright:

Available Formats

Service

Service Mapping Fundamentals

Module 2: Horizontal Discovery ............................................................. 37

Module 3: Service Mapping ................................................................... 76

Module 4: Service Lifecycle…………………………………………………………………149

Module 5: Extending Patterns ............................................................... 173

Module 6: Building Identification Sections ............................................ 234

Module 7: Building Connection Sections ............................................... 288

Service Mapping Fundamentals

Module 9: CMDB Reconciliation (Optional) ........................................... 370

Module 10: Event Management (Optional) ........................................... 409

Service Mapping Fundamentals

Service Mapping Fundamentals 7

Service Mapping Fundamentals 9

Service Mapping Fundamentals 10

Service Mapping Fundamentals 11

Service Mapping Fundamentals 13

Service Mapping Fundamentals 14

Service Mapping Fundamentals 15

Lab 1.1: Navigate Service Mapping (15 minutes)

Service Mapping Fundamentals 16

In this lab, you will complete the following tasks:

Access ServiceNow Training Instance

Service Mapping and Discovery Applications

2. Navigate to Service Mapping > Home.

Service Mapping Fundamentals 17

5. From the Readiness Checklist, click Done.

1. Navigate to Pattern Designer > Discovery Patterns.

Service Mapping Fundamentals 18

3. From the Create Favorite form, click Done.

Service Mapping Fundamentals 19

2. Click New and view the different credential types.

Service Mapping Fundamentals 20

2. Navigate to Discovery > Discovery Schedules.

3. Select Quick Discovery.

4. From the Quick Discovery dialog window, click Cancel.

5. Navigate to Service Mapping > Administration > Discovery Schedules.

6. Select and open the All Applications Discovery Schedule.

Service Mapping Fundamentals 21

3. What field is used to define the frequency in a discovery schedule?

4. How many different credential types exist in a baseline instance?

Service Mapping Fundamentals 22

2. IIS6 and IIS7

3. The Run field

Service Mapping Fundamentals 23

Service Mapping Fundamentals 25

• Finds everything, whether it’s helpful or not

Service Mapping Fundamentals 26

Service Mapping Fundamentals 27

• Only discovers components of the service and ignores everything else

Service Mapping Fundamentals 28

Service Mapping Fundamentals 29

Service Mapping Fundamentals 31

Service Mapping Fundamentals 32

Service Mapping Fundamentals 33

With ServiceNow’s automated identification and reconciliation framework, the attributes of

Service Mapping Fundamentals 34

Service Mapping Fundamentals 35

Service Mapping Fundamentals 38

Service Mapping Fundamentals 39

Service Mapping Fundamentals 40

Service Mapping Fundamentals 41

Service Mapping Fundamentals 42