ServiceNow Discovery: MID Servers and Schedules
Introduction
If Discovery Schedules are the navigation system in your Car, the MID Servers are its engine.
To successfully go from point A to point B, i.e. Run Discovery, we need both Discovery Schedules and MID Servers to not only be correctly configured, but more importantly, correctly configured to work with each other.
Something so fundamental took me several implementations to standardize.
Using MID Server Clusters is the one configuration for Discovery Schedules that we recommend for all Customers, independent of the actual number of MID Servers they have.
This balance between Discovery Schedules and MID Servers is key to a very fundamental configuration that provides benefits that aren’t obvious on the surface.
MID Servers and Schedules
There are several ways that you can configure the relationship between a Discovery Schedule and a MID Server. You can Auto-Select a MID Server, Specify a single MID Server, use Behaviors or use Clusters.
While it is intriguing to try a different set of these combinations to discover ‘Configuration Items’, the only option that we recommend selecting is MID Server Clusters.
With this approach, we have seen the following benefits:
No errors during migration, since the Schedules are referencing a MID Server Cluster Record, vs a MID Server Record. And by definition, each MID Server has a different sys_id in different environments.
Easy to scale your horsepower by simply adding MID Servers to the Cluster, without making any changes to Discovery Schedules.
Forces you not to use Behaviors, Functionalities and Capabilities, which complicates your MID Server deployment.
The obvious exception to this rule is when your Schedule is not configured to discover ‘Configuration Items’. In this context, ‘MID Server’ is the only option we have on the Form. But those types of discoveries are few and far in between.
Conclusion
While sealing the relationship between MID Servers and Schedules via MID Server Clusters may seem restrictive at first, it results in laying the foundation for a deployment that is not only easy to maintain but allows you to scale as you grow your ServiceNow Discovery footprint without the need to revisit the MID Server Design or the MID Server Architecture.
I am curious to learn more about any specific use cases, including scenarios with one MID Server, where Clusters isn’t the best option. Feel free to provide your inputs and insights in the comments below.
