CI classes that can be excluded but will not hurt Service Mapping

joostdirkson
Kilo Contributor

Can anyone advise me on typical CI classes we may not need to disciver, without hurting the Service Mapping? Like File system, Disk, Disk partition?

1 ACCEPTED SOLUTION

robertgeen
Tera Guru

Hello Joost,


So my suggestion is to start with what the organization needs. This should answer most of the question. Excluding something from discovery shouldn't affect service mapping too much as long as it's not something that is needed for identification purposes. File systems and things like that are a good example of possible things you don't need but it's going to be hard to tell what Service Mapping really uses (for example Layer 2 information you may think adds too much garbage but Service Mapping uses it to figure out the network path so there are things to think about for that).



Either way I would start with a blueprinting exercise and then turn things off and test from there.


View solution in original post

3 REPLIES 3

benly
ServiceNow Employee
ServiceNow Employee

Hi Joost,



To assist you with your question, I'd just like to know why you need to exclude some CI classes and if there is a goal in particular you'd like to reach? Some background information would help us answer your query.



Cheers,


Ben


Hi Ben, tne CMDB manager doesn't want to fill his CMDB with classes that he doesn't want to manage. basically that's it. He doesn't want a BIG CMDB.


robertgeen
Tera Guru

Hello Joost,


So my suggestion is to start with what the organization needs. This should answer most of the question. Excluding something from discovery shouldn't affect service mapping too much as long as it's not something that is needed for identification purposes. File systems and things like that are a good example of possible things you don't need but it's going to be hard to tell what Service Mapping really uses (for example Layer 2 information you may think adds too much garbage but Service Mapping uses it to figure out the network path so there are things to think about for that).



Either way I would start with a blueprinting exercise and then turn things off and test from there.