Course: Maintain the Health of the CMDB

Lesson: Manage Duplicate CIs

Video: De-Duplication Tasks Demo

Hello and welcome

We're going to be looking in this demo at deduplication tasks and how they are created and how the
system handles them. If there are duplicate CIs in the CMDB when duplicates are found in the CMDB
during an import or running an integration or discovering a CI through discovery and duplicates are in
the CMDB , then a deduplication task will be created.

First let's refresh our memory on identification rules and how they work so for our demo we're going to
actually create duplicates of a Windows Server and then run discovery against that same Windows
Server and see how the system handles it, but first let's understand the rules that come into play, we're
going to look at the hardware rule. There is one identification rule that identifies all hardware in
the CMDB, it's defined at the hardware level, notice that Windows Server falls under an extended class
of computer server and then there's an extended class called Windows Server. This is the class we will
be looking at, if we review the identification rule for Windows server, you'll see that the rule actually
comes into play are rules that are defined on the hardware table and the hardware table is the base
table for all hardware. These are the rules that are used in identification. They have priority 100, 200,
300, and 400. They look at serial number and serial number type first, then serial number, if a match is
found, it will basically give you an update immediately, but if no matches are found on serial number
and serial number type, it's going to then try the next rule in the priority order. It's going to look for the
serial number field on the hardware table and determine whether there's a match, if no matches found
it will look for name, and then eventually IP address and MAC address, if it finds no match is found, it
creates the record. If it finds a single match, then it's going to update the record, but if it finds multiple
matches that's where the deduplication's come into place and a deduplication task is actually created
and all other records that are not the oldest CI our update with the discovery source of duplicate.

So with that in mind let's first of all understand where all these fields are defined within our Windows
Server so I've navigated over to the windows module I'm going to open up a record and this is the serial
number that exists on the hardware table so this was actually defined in the hardware table because
Windows Server is extended from the hardware table. It inherits or has that field available, this is the
name field also part of the hardware table that is used as part of the reconciliation engine and the other
two are part of the related lists so here's the first rule that comes into play which is serial number and
also serial number type. So it's looking for a match on these and this in essence is a related list to the
serial number table and then there is also network adapters and this is where the IP address and MAC
address come into play so this is the 4th of those 4 identifier entries that are part of the hardware rule.

Now what I've done before we initiate discovery and create a duplicate CI is I've added this field, it's not
here by default but there's a field called discovery source which basically defines where did this record
come from and how did you get into the system and so if you're using horizontal discovery through
ServiceNow Discovery, the discovery source will be ServiceNow, if you're using Service Mapping, it will
show up as ServiceWatch, if your integrated with another application such as Alteris, would show up is
Altiris. If it is a duplicate record it will display as duplicate. In more recent releases of ServiceNow, the
field displaying duplicate is now in its own field and not part of the Discovery Source field.

When we talk about the oldest CI we're talking about the creation date of that CI, sys_created on, so the
system will update the oldest CI if duplicates are found.

Currently we have one record in the CMDB which has the name of IP one 198.51.46.199, I'm going to
right click on the header and just mimic that we have duplicates in here so I'm going to do an insert
instead so I created a second record, these records are identical the only thing that happens when you
duplicate a record is that there are no related list information so that first rule on serial number and
serial number type does not have data so there is actually no match on that so we're going to tweak our
rules so on hardware rule. So it ends up looking for this serial number first and that's where we're going
to end up finding duplicates.

I'm just going to force the deduplication task by having 2 records. So before we run discovery let's go
ahead and tweak our identification rules, we're going to do that from CI Class Manage, we can navigate
back to the hardware class and look at the identification rules, now again serial number serial number
type is first within the priority list, I'm just going to click on serial number, I'm going to modify this
priority to 50 so this rule is going to be looked at first. So when it finds that match that's when the
deduplication test should be created the oldest of those 2 CI should be updated and the duplicate
record should be flagged with a discovery source of duplicate.

Let's go ahead and run discovery so under discovery > discovery schedules, I'm going to go ahead and
run a quick discovery, I've already defined the target IP on the IP address that we have duplicates.
Discovery is going to basically go and discover that record. The return payload is going to be run through
the IRE, it will look at that hardware rule and it's going to evaluate serial number first, it's at that point
that is going to realize there's 2 records in the CMDB that have the same serial number so we're going to
go ahead and update the oldest CI of those 2 and we're going to flag the second CI the newest of those
two with the discovery source of duplicate.

After discovery is complete, I'm going to open up the discovery status record, what this will show me is
that the one device that was targeted was updated, so remember we had 2 records, 2 windows servers
in our CMDB, the one that had data in the related list was the oldest of the 2 and this is the record that
has the related list data so this is the oldest of the two CIs and this was the one that was updated.

Let's look a the duplicate, the discovery source that we added it now has a definition of duplicate.

Let's go ahead and look at the deduplication tasks as well and you can see that a task was created. If I
open it up, it provides some information about the duplicate and down below in list the 2 records that
were found that are duplicates, the one that was updated still has a discovery source ServiceNow and

2
the one that was flagged as duplicate the newest of the 2 shows the discovery source is duplicate. We
do have an option directly from here that allows you to remediate between those 2 CIs and this is a
basic wizard that allows you to choose which of the two CIs you want to keep, you can either merge the
data, delete one of the records or it will also provide guidance as to which one it believes is the master
CI.