ServiceNow Discovery: Schedule Design

Introduction

Discovery Schedules control when ServiceNow Discovery is triggered and which parts of the network get discovered at what time.

Due to the infinite permutations and combinations of infrastructure landscapes, designing Discovery Schedules was arduous, inconsistent and as a result, suboptimal.

In some cases, we didn’t know where to start or how to segment the schedules. In other cases, the exceptions superseded the rules and any changes to the schedules implied a complete redesign resulting in multiple meetings rehashing previous assumptions.

In short, it wasn’t the best experience for anyone involved and because the design was a new idea every time, the only way we knew it would work for sure is after it was implemented.

But then, there were implementations where this process was smooth and simple. I started looking at these implementations to find similarities with the approach we took to designing the Discovery Schedules. What I have captured below is now a consistent approach we take with every Discovery Schedule design.

As a result, the effort is painless and the maintenance is moot. And the result is beautiful!

Schedule Design

The first step in designing Discovery Schedules is collecting [IP Subnets]. There is not been a single implementation where we get all the IP Subnets the first time around. But with the steps below, we are able to iteratively ingest what we got and seamlessly integrate new inputs into the existing design, by following the steps below:

1. Collect IP Subnets including their description and their Location

2. Grouping the Schedules:

   1. Group the IP Subnets by Location. THIS is the granularity of your Discovery Schedules. The added advantage we are able to, out-of-the-box, populate the value of the ‘Location’ attribute on the Discovery Schedule Form into the ‘Location’ attribute of the CI, discovered via this Schedule!

   2. If Location is not available, Group the IP Subnets by Class B.

3. Avoid this:

   1. Avoid grouping Schedules by Protocol or in any other random order.

   2. Avoid having the same subnets be a part of multiple schedules.

4. Split long running schedules, so none of them run for more than 4 hours. The lower the number here, the better!

5. Finally, Daisy Chain the schedules (i.e. have them run one-after-another) for predictability, supported by the following configurations:

   1. Align the first schedule in the Daisy Chain to trigger at the beginning of the approved run time.

   2. At many customers this is towards the end of the maintenance window or a follow-the-moon approach to minimize activity during business hours..

   3. Set ‘Max run time’ to 5 hours and select the ‘Run if Cancelled’ check-box, so that an unforeseen error doesn’t disrupt the Daisy Chain.

   4. Configure ‘Run Once’ in non-Prod and specify a periodic time to trigger the Schedule in Prod. This one-time post-migration step prevents Discovery from running in both Prod and non-Prod at the same time.

   5. You can always use the ‘Discover Now’ UI Action to run the Schedule without triggering the Daisy Chain.

Conclusion

With the steps captured above, any subsequent IP Subnets received easily go into the correct Discovery Schedule driven by Location or Class B. This approach extends well beyond the project allowing for simple addition and removal of Subnets without impacting the Discovery Schedule Design.

With this as the foundation, learn more about how MID Servers and Schedules work together.

Do you approach your Schedule design differently? I am curious to learn more about scenarios where the approach wouldn’t work. Look forward to the comments below.