Course: Maintain the Health of the CMDB

Lesson: CI Reclassification

Video: Reclassification Demo

Next let's take a look at reclassification. I have navigated over to the system properties list and also
performed a search under name that has class in it. You see 3 specific records that we want to look at.
The one that's glide.class.downgrade, .switched, and .upgrade are all enabled. These 3 global system
properties can determine how you handle reclassification within the system.

What I'm going to do is I'm going to take this record and copy the name field and then I'm going to
delete the specific record. I'm going to add it to the server table when I navigate over to the server table
click on new, you simply just paste in the name so you can see my new record is now under the server
class. I don't have any other attributes defined for it, but I do have the name.

Let's go revisit the CI identifiers we learned about this earlier on. We have a rule called hardware rule
and the hardware rule will determine whether there's a match in the CMDB or not, because we only
have one value defined for the server record which is name. Name is one of the criterion attribute that
we looked at so if it finds the same name of what's being discovered anywhere in the CMDB it will
consider that a match and because we have reclassification enabled, it will take that server record and
re classify it as a Windows Server record.

Let's test that by running ServiceNow discovery and find that same server and then seeing if the
reclassification takes place. So here's our discovery schedule that's going to go out and find our MID
server, let's run it and see how reclassification takes place, so as discovery is executing we can see the
rules that are being triggered in order to determine if there's a match for this specific CI. We can see
that there is no match in serial number because we didn't have any serial number for that record, we
did enter a server record with a name that matches this server that's being discovered. We found a
match on name. I click on the devices tab we can see that the class is Windows Server and it talks about
updating the CI. By selecting the CI we can see that we are now in the Windows Server table and our
record has been reclassified. If I go look at my reclassification task I have no reclassification task as the
reclassification took place automatically. If we look at our system log we will see specific details that
this win_server was actually upgraded. It uses the term update_with_upgrade, meaning that we took
that server record and we upgraded into a win_server record. The Windows Server table has more
attributes than the Server table thus going back to our definition earlier on that this specific record was
upgraded.

So I've navigated back to the system property list and performed one change. The property
glide.class.upgrade.enabled, I've now set to false which means that any kind of upgrade of a matching CI
cannot take place and as a result will get a reclassification task.
Let's perform the exact same demo that we did earlier on to see what happens. So I've already taken the
action of removing the Windows Server and I've added the name just as we did last time to the server
class so the Windows Server does not exist any longer, we're going to run discovery again and then to
see what happens with this server. After running Discovery look at the discovery status record you'll
notice that it actually completed after the identification phase. We started probes for the identification
phase and then we completed those, when we look at the discovery log there's some interesting
information here, we didn't find a match on serial number but we did find a match a name, but we did
also receive a warning message that says there is an identification error about reclassification. If we look
at our server record we won't see any updates associated with it so nothing actually occurred, none of
the exploration probes were executed the server record still appears as a server record because
reclassification was not allowed to take place and no additional attributes were added to the record.

If we navigate over to the reclassification task you'll see that a task was generated. When open it I can
determine what to do with this, I can follow it, I can open up a connect session with someone if
necessary, I can basically do a follow up and move this to work in progress or try to determine what is
going on and again how you want to handle this is fully in your control including visibility to the fact that
ServiceNow was trying to reclassify a device that you have in your CMDB.

Let's perform one last demo to understand what switched means. I've taken that same name for the
Windows Server that discovery understands is a Windows Server and I've removed it from the server
table, it's no longer also in the Windows Server table, it only exists here within the Linux server table or
Linux server class. We're going to run discovery again, it should find a match on name based on the CI
identifiers because we still have the switched system property set to true, it should take this Windows
Server or this Linux server and re classify it as a Windows Server.

Let's go ahead and test that as discovery runs we can see that there is a match that's found on the name
field so even though the Linux server is in a different table than what was discovered, we've now
discovered a Windows Server. The rule says if there's a match on name anywhere in the CMDB, move it
because reclassification in terms of a switch attribute is turned on. We can actually reclassify this device
to entirely different branch of the CMDB so this specific server which is a Windows Server looking for
classified now is a Windows Server. Let's click on CMDB record and you will notice that the Windows
Server appears.

To re emphasize we can see if we navigate over to the Linux server module that that Windows Server
where we had name defined as a Linux class is no longer there. The last area we can look to see that the
switch did also take place is the system log. From the system log you can see the identification did push
out some output that says the class name switched and there is an operation update_with_switch that
took place.

Again due to the reclassification of a switch type and because we have the system property enabled this
functionality was allowed. If we have turned that off within the system properties we would have ended
up with another reclassification task just like we did before

2
3