Advanced vs. Basic Schedules...

[SlightlyLoony]

If you've been poking around in the Discovery application, you may have noticed an intriguing little box on the schedule form: the "Discovery Type". It gives you three choices: Basic, Advanced, and Networks. What do those things mean?

In this post, I'll discuss two of those choices (Basic and Advanced). I'll leave the third choice for another post.

(note: the photo at right is not me)

The Basic discovery type is all that's needed for most situations. The schedule form for a basic discovery is what I've described in previous posts: you can set up when the discovery should run, the IP ranges to discover, and the MID server that should handle the job. This is easy to understand, and if it will handle your needs, it's what you should use.

But there are occasions when the basic discovery just won't do the job, or perhaps not in the most convenient way.

For example, suppose your enterprise's IP addresses are organized by geography and equipment category (see this post). Then let's imagine that you want to discover each geographic area every Saturday, at 5 PM local time — but you also want to discover all printers (in all geographies) at 5 PM Houston time on the 5th of each month, so Accounting can reconcile your usage against the printing vendor's invoice. You could do this with basic Discovery schedules, but you'd end up entering all the printer IP address ranges twice — once for the geographic schedules, and once for the printer usage reconcilation schedule. That's not what you'd really like to do!

Advanced discovery gives you a feature that solves this problem: Range Sets. You define range sets (at Discovery Definition → Range Sets) exactly the same way that you define the IP ranges in a basic discovery. The difference is that here you're giving each of these ranges a name, and you can use the range you've defined in any advanced discovery.

Here's another challenge for a basic discovery: suppose you are discovering some IP ranges that include a mix of equipment types: some Windows, some Unix/Linux, some network gear, and some printers. You must use a MID server running on Windows to explore Windows machines, but you'd rather use a MID server running on Unix for the other equipment. Then, just to make life more interesting, your network gear has Access Control Lists (ACLs) that restrict SNMP access to a select few servers — so to explore them, you need a MID server running on one of those worthy servers, but you really want to use that MID server only when strictly necessary.

How on earth could you do all that?

Discovery Behaviors can do all this and more. In the example at right, you can see that I've defined a behavior named "Flexible Wood" that uses two MID servers for different purposes. This behavior uses

sanops01

as the "Pinger" MID server (for pinging and port scans). Then initially it will use

sandb01

to run Windows (WMI-based) probes, and

sanops01

to run all the other kinds of probes. Should any of those probes fail (say, because an ACL prevented the MID server from communicating with the target system), then the alternative behavior will be invoked. In this case I've only defined an alternative SNMP MID server — which (if I had such a thing) could be the MID server located on the especially worthy host.

So...if you find yourself having trouble making the basic discovery schedules do what you need, check out the features in advanced discoveries. Between range sets and discovery behaviors, they add a whole lot of flexibility…