CONCEPT: The RockSolid Instance Hierarchy

The RockSolid Instance Hierarchy is used to apply policy settings that affect the installation level settings of SQL Server installations.  This policy has the following structure:

  1. Service Provider
  2. Instance Group
  3. Site
  4. Instance

In RockSolid policies are defined at various levels in the hierarchy, with an individual instance receiving the flow down policies from upper levels.  If there are individual settings that conflict in the policy structure, then the more specific (lower level) policy settings will override those settings defined higher in the policy structure.

Policy Approach

The following approach should be used to gain the most effective benefit from the RockSolid policy hierarchy.

  1. Most settings should be defined at the instance group level.  This is the key unit where all your monitoring, configuration and operational management settings should be defined for your selected groups of instances.  Defining settings at this level allows you to add any number of individual instances to the group without additional configuration, assuming the group level settings are valid for those instances.
  2. Only site specific exceptions should be defined at the site level.  If a site has a global exception to the group level policy defining this at the site level allows all instances from that site to receive the exception.  Setting at this level removes the need to configure the exception on each individual instance.
  3. Only instance specific exceptions should be defined at the instance level.  Using policies in this manner allows all global settings to be define within the instance group configuration, and only an individual instance settings that vary from those global settings to be defined at the instance level.  
  4. If you have universal settings that apply to all instance groups, these can be defined at the service provider level.  This may be suitable, for example, for setting global minimum monitoring and security & auditing settings.


In general, if your policy structure is defined in an effective way the bulk of your configuration will be performed at the instance group level.  Most instances within an group should not have exception policies defined.  If you are finding that many instances within a group have exceptions, this may be an indicator of a need for a separate group.

With this structure in place potentially dozens to hundreds, to thousands of SQL Server instances can be added to a group within minimal additional configuration, with all those instances inheriting the group level settings and having all relevant monitoring, configuration, analysis and management processes implemented based on your defined standards.

Have more questions? Submit a request


Please sign in to leave a comment.