- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-10-2014 03:26 AM
I'm new with Discovery and we are currently we made up and running the Discovery to Development.
My problem is we don't want all Classes to be discovered and like to filter out which classes needs only to be discovered.
Can you help me how ? Let's say below are the items I would like to eliminate classes like:
a. Disk
b. File System
c. Memory Module
d. Print Queue
e. UPS Output
f. Exit Interface Routing Route etc.,
TIA!
Solved! Go to Solution.
- Labels:
-
Discovery
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-10-2014 06:54 AM
There are two ways you can do this if you are looking to filter that information:
1) Go into the device classification for the type of CI you are scanning (server, printer ,router, et al) and remove those probes. Most of those probes should be a 1:1 match for the related lists, but some related lists are populated by a multiprobe. You will have to "scan and check" to make sure. This will prevent that information from being populated at all.
2) Alternatively you can simply remove those related lists from the forms themselves and modifying modules and reports where necessary. It's a bit more work initially but allows you to keep all CI information full and up-to-date.
I don't typically recommend removing probes because it can have affects on managing your CMDB outside of eliminating certain types of CIs (ie not utilizing the "running processes" probe prevents discovery from creating and updating CI relationships).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-10-2014 06:54 AM
There are two ways you can do this if you are looking to filter that information:
1) Go into the device classification for the type of CI you are scanning (server, printer ,router, et al) and remove those probes. Most of those probes should be a 1:1 match for the related lists, but some related lists are populated by a multiprobe. You will have to "scan and check" to make sure. This will prevent that information from being populated at all.
2) Alternatively you can simply remove those related lists from the forms themselves and modifying modules and reports where necessary. It's a bit more work initially but allows you to keep all CI information full and up-to-date.
I don't typically recommend removing probes because it can have affects on managing your CMDB outside of eliminating certain types of CIs (ie not utilizing the "running processes" probe prevents discovery from creating and updating CI relationships).

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-02-2014 07:52 AM
This is great info, because I am attempting to do the same. The main reason/concern is from a licensing point of view; we only have enough licenses to cover our servers, but we're getting printers, routers, etc.
One more question/clarification though: Do I need to remove the probes or simply deactivate the CI classification?
Thanks!
Mel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-02-2014 10:52 AM
You can remove the probes from the classification and/or deactivate the classifications themselves. However you still run the risk of creating CIs you don't want to. In your particular case, it sounds like you want all connections being made via SSH (Linux/Unix) and WMI (Windows) but not SNMP. If that is the case, I would just create a discovery behavior that excludes SNMP functionality.
Take a look at this: http://wiki.servicenow.com/index.php?title=Discovery_Behaviors
There is an out-of-box functionality definition that would include everything but SNMP. Assign that definition to the Discovery schedules where you are getting back printers and routers but only want to scan servers (might be all of them). If you are looking to avoid more types of targets (ie storage arrays), you can define your own functionality definition to apply to the Discovery behavior.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-02-2014 11:03 AM
Wonderful!!!!!! This is exactly what I needed. Thank you very much!