Delete or deactivate Configuration items?

[mitzaka]

Hi SNC,

For those who are not yet drowning in Christmas celebrations:)

A question which has been commented in some posts here, but has no clear answer, so I decided to gather some opinions here.

We are in the state where we want to clean up our CMDB a little - it's very complex at the moment as it contains all kinds of CI classes, from business services, through networking stuff all the way to VMware vCenter things from Discovery. The idea is to start over simple and begin with just a list of need-to-have CI classes, and then build up on this and add more classes as we go.

We obviously have two options:

A. to delete all unnecessary CIs
B. to deactivate all unnecessary CIs

However, we need to be very careful because our CMDB has been used for quite a lot time and there are many incidents, tasks, and other records which are related to those CIs. I know the advantages and disadvantages will be something like:

• Keep the now-gone CMDB item in the database, but mark it as non-operational. This approach has the advantage of keeping intact any links you have from incidents, tickets, etc. to the now-gone CMDB item, thus keeping all your history and details available for investigations or reports. Because these items are still in your CMDB, it likely means that you'll want to filter out the non-operational items for certain kinds of reports, and views on-screen. For example, you might modify the Configuration -> Computers module to include such a filter (you can always remove it if you want to peruse the non-operational computers).
• Delete the now-gone CMDB item from the database. This approach has the advantage of simplicity — you delete the item, and it disappears immediately from all lists and reports. Simple! But the downside is that now any incidents, tasks, etc. that referenced this CMDB item lose their references, which destroys a little bit of your history.

Also I am afraid not to hit this problem:

For example, I ran this against VMware Virtual Machine Instance [cmdb_ci_vmware_instance] and it did delete everything in that table. However, this tables extends Virtual Machine Instance [cmdb_ci_vm_instance], which extends Virtual Machine Object [cmdb_ci_vm_object], which extends Configuration Item Base [cmdb_ci]. Every single one of those tables will have a record "orphaned" for each of the records you deleted in your extended table. This becomes a problem if you are doing a global search for all CIs against the Configuration Item Base table, let's say for a device named "WinPC1234", you can get back multiple records for one CI, but when you click on the "orphaned" records, it tries to open the record in the VMware Virtual Machine Instance table, and you get a nice "No Record Found" error.

So from your experience, could you share some thoughts on what would be a good safe and effective approach here.

Also, I do have three instances to play with - Dev, Test and Prod, so I am willing to try stuff.

Thanks in advance!

[poyntzj]

We mark ours as retired and add a retired date.   We do it on a weekly scan and mark anything not updated for 3 months as retired

As we are on Calgary we have to look at process MSSQL details too as even though these are scanned weekly via the discovery process the scan dates do not update.   Qe assume they are good and only "retire" them when the parent server is retired.   Don't really have any other way of processing that at the moment (after a ticket in HI, we were told it was a known problem).

don't forget to change any reference qualifiers so they do not look for retired CI's

[Slava Savitsky]

In my opinion, deactivating obsolete configuration items is better than deleting them. CMDB is the core of all processes. If you start deleting CIs, you can end up with a lot of orphan records here and there. And of course you lose some of your reporting capabilities over the old tasks.

[mitzaka]

Thanks for the answers, everyone. I also feel that disabling is the safer option, but this leads me to few questions - first, when I disable, I have to make sure that all the searches in the system will not include the disabled CIs, like Julian Poyntz said, right. And also, having tens of thousands of disabled CIs may affect my performance, right?

In the end, my goal is to build a clean CMDB which I can use for the future, so I know it's risky but perhaps if I want to start off clean, then maybe deleting is still worth considering. I have to admit though, that I am afraid of orphaned records... and what they could cause, like Slava mentioned.

If I delete and this brings to orphaned records, what will be my biggest concern? If it's historical data - I could live with that I guess. I am afraid that it might cause some more errors on the Discovery and BSM relationship side afterwards. Do you think so?

[Kalaiarasan Pus]

you could have a before query business rule and exclude all the disabled CI's from the query ... this way you don't have to make any changes on menus or filters etc ...

[mitzaka]

Ok, so in the end we made a decision to rebuild our CMDB, because it has a lot of cruft nowadays. In this context, as a first step, we are willing to delete all records of those classes which we define as unwanted now, and relationships between them in order to clean things up.

My idea of how this should go is:

1. cleanup the cmdb_rel_ci table and get rid of all the unwanted relationships.
Is there an OOTB way to do this? I saw an article for http://wiki.servicenow.com/index.php?title=CMDBUtil_API, which is supposed to do something similar. Has anyone used it? If this does not work, I guess I will have to go with some script. If anyone has done something similar, please share.

2. cleanup the CI records - I guess this will definitely need to be done by script, because the number is farily large. I am wondering should I do this with a background script? And I suppose I should try to tell the script to look for CI of a certain (unwanted) class and when found to delete.

Any thoughts on that guys?