Disable CI Class

[big-m0dem]

What is the best way to disable a specific CI class from being discovered outside of the Configuration Console, like network adapters, config files, next hop routing rules, etc...?

We would like to stop certain classes from being discovered, and then delete them from the cmdb. We don't want them to show up on any upstream or downstream relationships.

[cynlink1]

Hi @Dave Hertel,

When you stated 'think very carefully about deleting a class in the CMDB' in your response, did you mean deleting all of the data stored in a particular CI class table OR deleting the actual CI class from the Hierarchy in the CI Class Manager or both?

Since implementing Discovery, everything has been turned ON in the Configuration Console. While Discovery has been running for quite some time, we weren't actively managing the data. Now that we are focused on improving the health of the CMDB, we are overwhelmed with the vast amount of data. Similar to the original author of this point, I've been considering turning off Discovery for some CI types. Your recommendations for stopping the Discovery of specific CI classes are very helpful and make sense. However, I was curious to know if you have ever encountered any edge case scenarios where deleting the data was an appropriate course of action? If yes, would you mind sharing some examples?

Thanks,

Cyn

[DaveHertel]

Hello -- to answer your 1st question, when I stated 'think very carefully about deleting..." I meant deleting the CLASS.   If the CI class is an out-of-the-box class I wouldn't delete a CI class... that will likely come back to haunt someone/you, someday.  Maybe not, but I wouldn't remove a default OOB class.   Deleting CI's within a class is also generally not recommended, but yes there are times when deleting the CI's makes sense.   One common situation I see is that there is very old junky data that a customer has looked at, reviewed the content, maybe it was created years ago... or imported poorly, etc.. and as part of a 1-time cleanup effort, then intentionally delete "junk" i.e. useless CI's.

Yes, Discovery collects a lot of stuff and probably more than you might care about.  To filter the noise, consider simple stuff like removing/editing the left nav menu so you don't have to see so much noise. Of course it's still there in the CMDB, but since Disco put it there to begin with, I don't recommend getting rid of it just because it's a lot of questionable-value CIs. 

If the data was imported/loaded manually, that's different -- because a human can look at its content and make some value-trade-off decisions and perhaps purge it.   But for Ci's created via Discovery, it doesn't make much sense to delete most of it unless you are A) 100% sure it's truly useless junk, and B) Discovery won't re-populate it after you delete it.  

Sometimes a customer will decommission a data center or a physical site and the older hardware isn't needed in the CMDB and the biz-process analysts (for ITSM) don't care about the old CI's from a decomm'd DC.  So that's another situation where a 1-time purge of 'junk' may be warranted.

My 2.5 cents.  Hope that helps some??

[cynlink1]

Hi Dave,

Your feedback is very helpful. Thanks so much for the super quick response!

Take care,

Cyn

[Michael Searle]

Hi Dave,

I realize this is an old thread but I'm hoping you're still watching it.

In my case, I want to delete a handful of CI classes because I don't like how I created them. After creating a few I realized I wanted to name the tables differently. Is there a way to delete the handful of classes I created?

And, yes, I'm an inexperienced ServiceNow admin stumbling my way along and learning as I go.

Thank you.

Michael

[Wendy Peterson]

Did you every turn these off. I am getting a similar request from my manager. He wants to clear the file system table and disable those from getting created. I thought about archiving them but then that had me questioning how are they being used. TIA