SERVICENOW DISCOVERY
ServiceNow Discovery is an agent-less solution that will scan your network on regular basis for any kind
of connected device. It works in a 4-steps process:
1.
Shazzam: scan the network and discover connected devices
2.
Classification: try to define what kind of device has responded following pre-defined pattern
(i.e.: if the device responds to WMI queries, it must be a windows machine…etc.) and gather information
about the device.
3.
Identification: reconcile the device and gathered information with an existing CI in the CMDB.
4.
Explore: get more information about the device such as running processes if applicable or some
deeper information on the device itself.
ServiceNow being a SaaS solution, in order to be able to discover devices/equipments, the solution
relies on what is called a MID server, which is a small Java program running on a server within
customer’s network and capable of executing various kind of jobs.
PLAN Discovery
It is not the solution that will make the organization discover magically devices they own. It’s a solution
to support users in the configuration management process but not replacing them. Before anything,
study the network topology of the organization. The primary reason for this is to plan how many of
those MID servers will be needed. These should be deployed strategically within the organization’s
network to ensure that the scanning will be complete.
PRIORITIZE
Define what’s most important and key. On a network, there could be lots of different kind of devices.
Not all of them are relevant in a CMDB and more specifically, not all of them relevant within a network
range/subnet. When Discovery has to scan a certain IP range within a datacenter, what are the most
relevant devices Discovery has to see? Probably servers, routers, switches…etc. In order to put in
practice this priorization, key functionalities with Discovery are behaviours, credentials and
functionalities. On a per phase and MID server basis, it can be controlled what accesses are granted and
what protocols should be used in order to make sure we keep control on the scope of the scan. In
addition to that, the configuration console is easy to use to control what main discovery functionalities
are enabled or disabled.
START SMALL AND SIMPLE AND EXPAND LATER
This is repeated many times when implementing ServiceNow. One of the main reason for this is that it is
easy to do something with ServiceNow in comparison with other tools where careful design an planning
need to be done. It is too easy to go too fast and put into production something not fit for use or
purpose. With ServiceNow Discovery, because data it creates has great visibility (the CMDB is used
across a whole bunch of processes, primarily incident, problem and change management), it is hard to
do a U-turn if six months down the road, we realize we did not do it right. It is then best to start small
and simple. Take the time to validate the result. And finally, continue with multiple phases to expand its
usage based on priorities.
DON’T UNDERESTIMATE THE DESIGN PHASE
In a CMDB project, designing is key. For Discovery it is the same. For each phases of the project, no
aspects of the implementation should be neglected. Implementing the solution can be difficult and
challenging in some organization’s environment. Implementing Discovery requires talking to many
different SMEs within the organization who all have different requirements which can be constraints for
the project. It is also good to manage well in advance expectations. Security aspects of the solution
should be discuss at early stage to make sure everyone is aligned.
CMDB
CONFIGURATION MANAGEMENT AS PER ITIL COPY
As per ITIL books, configuration management (or Service Asset and Configuration Management - SACM)
is a process that:
• Supports the business and customer’s control objectives and requirements.
• Supports efficient and effective Service Management processes by providing accurate configuration
information to enable people to make decisions at the right time, e.g. to authorize change and
releases, resolve incidents and problems faster.
• Minimises the number of quality and compliance issues caused by improper configuration of services
and assets.
In Configuration Item, there is the word “Configuration” which needs to be emphasized. In a
CMDB/CMS, we really focus on configuration information about a given element of the IT inventory:
• That an element is a server and not a network device
• That a server has 64 GB or RAM
• That a storage device is consumed by the ESX cluster XYZ …etc.
Remember that the CMDB needs to be maintained for many classes that will stand between a
service and a datacenter. It’s better to have a simple CMDB with up-to-date and trustful data
than a complex CMDB not maintained and therefore with data users cannot trust.
Fig: CI attribute decision flow
ESTABLISHING A CONFIGURATION MODEL
The goal of a configuration model is to document and track the configuration and evolution of
your CMDB. It’s a relatively simple diagram that illustrate clearly how classes relate to each other.
It should help users to understand how the CMDB is structured and how they should use it.
Fig : Example of a configuration model
CONFIGURATION MODEL
The configuration model has been sub-divided into the following areas to dig into:
1. Datacenters
2. Networks
3. Storages
4. Computing
5. Applications
6. End-user devices
7. Services
As illustrated by the above diagram, each area has a dedicated color which should help to understand
how they relate with each other. The objective here is to present how the vast out-ofthe- box CMDB of
ServiceNow can be efficiently used in your implementation.
INTEGRATION WITH CMDBS
When integrating ServiceNow CMDB in an organization that has multiple CMDBs will be dealing with the
overlap of two sources and the reconciliation of data. The following diagram represents a potential
situation:
When multiple data sources overlap, it is important to define SSOT and put in place
reconciliation rules
In this use case, we can see that multiple sources overlap. The network source with Discovery, SCCM
With Discovery…etc. The concept is that for each classes, a SSOT should be defined (Single Source Of
Truth). Some classes will be manually maintained and therefore their SSOT is manual inputs. Some
others will get most of configuration information from a MDR and therefore, if agreed and decided so, it
becomes the SSOT. When we have an overlap, there must be a source that takes precedence over the
other(s). A matrix like the following one should be defined and documented:
Example:
• Class “Computer” (cmdb_ci_server)
• Sources are SCCM and Discovery
Source
SCCM
Discovery
Order
100
200
Action
Create/Update
Create/Update
Attributes
All
All
In the above example we consider SCCM being the SSOT as it has the smallest order. We also consider
it can create and update records, but we don’t specifically list attributes it has ownership on. Discovery
has the exact same setup but a highest order because it is not considered, for this class to be the SSOT
or the most accurate source.
The second challenge will be about reconciliation. Now that there are 2 sources and that the SSOT is
defined. How does each source recognize if a CI has to be inserted of if the CI exists already and has to
be updated? For hardware CI, usually the serial number is used as it is known to be unique worldwide.
Nevertheless, depending on the source, other attributes may need to be used such as the MAC address,
an IP address or the hostname. Each of these attributes may be formatted slightly differently from a
source to another (especially the MAC address) and it needs to be addressed somehow.
ServiceNow has introduced a new CI Reconciliation/Identification engine (to not confuse with the old
Discovery CI identification engine) that applies the above theoretical concepts and will greatly help
dealing with multiple CMDB sources. The procedure is the following:
1. Document data source precedences for each classes in scope
2. Document reconciliation definitions (which source can update what attributes)
3. Review and eventually adapt CI identifiers
CI identifiers are a set of rules, evaluated in a certain order, that tells the system how to identify a CI.
Hardware devices will usually be identified trying the correlation ID first, if not found it will try the serial
number and then other attributes like the hostname or IP and MAC address.
CMDB MAINTANCE PROCESS
Once the CMDB is in place, it should not be static. The content of the CMDB needs to be maintained or
updated and for some areas, as much as on a daily basis. For that we need processes.
Modification/maintenance of the CMDB may occur in various contexts but the three main processes
that will “take care” of your data in the CMDB are:
•
•
•
Change management
Configuration management
Asset management
Change management can be a proactive or reactive process. In the latter, a change request will occur
following an issue (incident/ problem). A change request can affect one or more configuration item(s)
and subsequently impact one or more service offering(s). The change request needs to be approve by all
people it concerns (thus the reason for having good data in your CMDB because that will be the source
to define these people) and once it is completed, the CMDB needs to reflect what the change request
was all about.
Configuration management is the process that is “called” when a change request is completed and
the CMDB needs to be updated. That’s for the reactive part of the process. The other part of the process
is mostly proactive where periodic review of the CMDB are performed. The objective is to ensure data
matches the reality. If it does not match the reality, it has to be referred to change management (either
something was implemented/ installed without change request or the CMDBwas not updated properly
following a change request).
CMDB maintenance Process
CMDB audit and verification process
ROLES AND RESPONSIBILITIES
Three processes were introduced, bellow is basically how they Interact with each other:
SERVICENOW SERVICE MAPPING
As for Discovery, Service Mapping is an agent-less solution that shares and uses the same technologies.
Initially. With the Geneva release of ServiceNow, it is fully integrated within the platform. As stated in
the previous chapter, Discovery has an horizontal or bottom-up type of discovery approach. Service
Mapping is top-down.
Fig : Horizontal discovery vs. top-down approach
You basically give Service Mapping an entry point: URL or IP address of an application. The solution will
do the rest. It will scan the host if necessary and then explore it and try to understand what kind of
application it is. This is done using a set of pre-configured pattern (out-of-the-box, but new ones can be
created). If a pattern match, it will create the CI in ServiceNow and act accordingly. In Service Mapping
there are two distinct phases:
1.
Identification of the application
2.
Connectivity discovery
Let’s take a practical example: the application is a Java EE program running on a JBoss web server and
using an Oracle database:
1.
The application is identified according to the pattern and explored (a CI is created in ServiceNow
with the corresponding attributes).
2.
Service Mapping will look at possible connectivity and try to find a match. It will discover a
matching connection with an Oracle database and a JBoss web server.
3.
Service Mapping now has two entry points to explore against patterns and try to identify the
Oracle database and the JBoss web server.
4.
And the process goes on recursively until no connections are found anymore.
How does that fit into our CMDB?
What Service Mapping is doing very well is creating a map of an application with technical
dependencies. Technical dependencies, to be accurate, also means going down to a very granular view.
This might not fit into a configuration model, where for instance, we focus on the application as a whole
(the application, the application server and all potential small elements…etc.). The level of details
Service Mapping is bringing to ServiceNow is just too high if it had to be maintained manually. But there
is no magic behind Service Mapping. The tool does not have the judgement of a human being and
capable of simplifying a hierarchy of elements. It just does what we tell it to do. We could modify its
behaviour by heavily customizing all the out-of-the-box patterns but we would be loosing on its added
value and, above everything, that would not be a good practice.
The answer is that the audience or the usage of the information Service Mapping is bringing to
ServiceNow is slightly different than the rest of the CMDB. The big plus of Service Mapping is its usage in
conjunction with an event management integration. The dependency map is displayed with a timeline
and because it is refreshed on regular basis, allows the user to go back in time to check the state of the
application or see what has changed. Events are displayed in this timeline.
KSFs listed for Discovery are also valid in the context of Service Mapping:
1.
Plan plan plan: technologies are the same, MID servers need to be at the right place as well.
2.
Prioritize and start small: focus first on the most important/critical applications (3 or 5 to start with
I would say).
Even though not trivial to setup, it is feasible to have mulitple abstraction levels in the CMDB
3.
Don’t underestimate design: to make sure a pattern works, you need to understand how the
application works and where Service Mapping should look for information on connectivity and so on.
This can be complexe.