Can I customize which probes are triggered for different schedules?

[kurtdean]

I am discovering across multiple sites with different requirements.

While one set of sites is OK with one set of probes, other sites require that only a minimal set of probes take place.

For example, the Linux Classification will trigger 15 probes (including multiprobes). If I  would like to only trigger 5 specific probes when discovering on a particular subnet, is it possible to do this?

I have created a custom behavior, but that only seems to modify which protocols to discover.  

[Aditya Telideva · Accepted solution]

Yes, you can !

Did you include the probe in the proper classifier? I'm assuming you want to use it in on a Unix/Linux server. You need to go to the 'Unix' module under CI classifications.   There should be two related lists at the bottom - 'classification criteria' and 'triggers probes.' Hit the edit button on the 'triggers probes' related list and you should see the name of the probe you want to launch. Make sure you set it to the proper phase, most likely exploration, once the probe is triggered by the necessary device classifier. Once it has been added there, the probe should be launched with the rest of the OOB probes once the Unix classification criteria has been met during the Unix classifier probe. If you need or want to create a separate classification for a specific platform, follow the directions in the Wiki article below.

http://wiki.servicenow.com/index.php?title=Discovery_Classification_Parameters

[kurtdean]

Thank you!

Since I will need to run different probes for Linux on different networks, I'm assuming I will use the IP address parameter to determine which.

[kurtdean]

Hi, I think I've followed the recommendation but still having trouble. Here's what I've done:

• Created a new Classifier with an order of 10 and a criteria of IP address equals the address of the host I am doing a test discovery on.
• Added only the 5 probes that I need to run (phase Exploration)
• Run a Discover now on this one host

Looking at the discovery log, all of the typical Linux probes have run. It seems even though the IP address matches the criteria, this classifier is not returning true.

I then tried disabling the standard Linux classifier and re-running the discovery. In this case, it's unable to classify the host. I've verified the address is correct. The parameter name is "IP address" as specified in the documentation.

Again the requirement is for certain subnets, only those 5 probes are allowed to run on the hosts. I still need to be able to run a full discovery on all other subnets.

[Dave Ainsworth]

Hi Kurt,

I think the problem is that in the port probe, it defines which classification to trigger. It might be possible to define more than one IP service for port 22 and then multiple port probes to trigger each classification. Then you would have the behaviour that only has the IP service linked to the port probe that triggers the classification you want with the fewer probes. I have never tried this and really don't know if it would work. I think it would be more likely it wouldn't work.

However, I was testing something with condition scripts on classify probes recently and was able to pass a parameter to a function within a script include and get the function to return true or false to control whether the probe is triggered or not.

In the condition script, one variable available is 'source' which is the IP address that is being discovered.

If I create a simple script include as follows:

var classifyCheck= Class.create();

classifyCheck.prototype = {

      initialize: function() {

      },

      canScan: function(ip) {

              if (ip == '1.2.3.4')

                      // Don't want to trigger probe on this IP

                      return 'false';

              else

                      return 'true';

      },

      type: 'classifyCheck'

};

Then for example, in the ARP classify probe, I can add the following:

        new classifyCheck().canScan(source) == 'true'

In the case above, if the IP address is '1.2.3.4', it will return 'false' and the probe will not run. For every other IP address, it will run.

Screenshot so you can see where this is added:

Note that I have never tried this in a production environment. The extra calls to the functions will add some overhead and slow discovery down as it needs to check every probe for every device being discovered and the more complex the checking of the IP addresses, the more overhead there will be.

Regards,

Dave