Overrides in SCOM 2007

Article
12/05/2006

In SCOM 2007 we have implemented a powerful, but somewhat complicated override architecture.

Basic overrides for rules, monitors and other workflows fall into two categories: configuration and property overrides. Configuration overrides allow you to override particular configuration elements that are unique to a workflow, while property overrides allow you to override the properties (such as the Enabled property) that are common among all workflows or a particular type (i.e. rules, monitors, etc).

Configuration overrides actually begin with the the management pack author declaring what portions of configuration are overrideable. For instance, if I declare the following DataSourceModuleType in a management pack:

<xsd:element name="Name" type="xsd:string"></xsd:element>

</Configuration>

</OverrideableParameters>

<Assembly>MyAssembly</Assembly>

<Type>MyType</Type>

</Managed>

</ModuleImplementation>

<OutputType>MyDataType</OutputType>

</DataSourceModuleType>

the configuration element Name is declared as being overrideable via the OverrideableParameters element. This means that any workflow that uses this data source type, will be able to leverage this as an overrideable parameter. If a portion of configuration is not marked as overrideable, it can't be overridden. Also, we only support simple types of overrideable parameters, so if you have something complex that needs to be overridden, it needs to be declared as a string and your module would need to do the parsing on its own.

Nothing special needs to be declared for property based overrides. All workflows support overriding the "Enabled" property (an implicit property indicating whether the workflow is enabled or not) and monitors have additional property overrides defined that allow all the various alert related parameters to be overridden.

When actually defining an override, there are several things that need/can be specified. First off, you need to specify which workflow you want the override to apply to. You also have to specify which configuration element, by referencing the OverrideableParameter ID, or which property you want to override as well as the new value you want. Lastly, you need to define where this override applies. We provide two ways to specify this: Context and ContextInstance. The Context attribute specifies which class you want the override to apply to while the ContextInstance (which is the Guid Id of a monitoring object you want to target) specifies a particular instance. I will go over exactly how these are resolved in a bit, when I talk about the algorithm we use for applying overrides. The other thing you can specify for these overrides is whether or not they are "Enforced". Enforced overrides always take precedence over non-Enforced and can only exists in non-sealed management packs to better allow administrators to manage their overrides.

Orthogonal to the aforementioned overrides, we also have the concept of category overrides. Category overrides apply to workflows whose Enabled property as defined as onAdvancedMonitoring, onStandardMonitoring or onEssentialMonitoring. These overrides follow the same targeting concepts as the others with the addition of which Category of workflow to apply to (EventCollection, StateCollection, etc), but act in broad strokes by enabling and disabling many workflows with a single override. If I have a rule that is defined as onAdvancedMonitoring, it will only run if there is an override indicating that onAdvancedMonitoring is enabled. If I have a rule that is marked as onEssentialMonitoring, it will run with an override applied of onAdvancedMonitoring, onStandardMonitoring or onEssentialMonitoring. Essentially, each level is a superset of the level before it, and is enabled as such. SCOM will ship out of the box with overrides enabling onStandardMonitoring while SCE will ship with onEssentialMonitoring.

Now, how do all these overrides actually get applied? To take the most complicated case, we'll work with an instance. We want to know what overrides apply to a particular instance of IIS for a particular rule targeted toward IIS. The first thing the algorithm does, conceptually, is gather all the types and instances that are in this instances hierarchy. So, this instance would include the IIS class and any classes that it derives from all the way to System.Entity and the computer instance that hosts this IIS instance and the computer class of this computer as well as all it's base classes. Next, the algorithm collects any overrides that may apply to this particular rule and overlays them on the hierarchy. So, if you have an enabled override disabling this rule with a context of System.Entity, it will exist in this objects hierarchy. With this conceptual hierarchy in mind, the algorithm starts at the top and traverses down applying the following criteria, in priority order:

1. Non-Category enabled overrides always win over category overrides
2. An enforced override always wins over a non-enforced override
3. Instance targeted overrides always win over class targeted overrides
4. Overrides in non-sealed management packs always win over sealed overrides
5. A child in the hierarchy of overrides always wins over a direct parent override of the same type (instance vs class)
6. Class overrides from contained instances always win over class overrides of the instance.
7. Instance overrides with the higher relative depth win over those with a lower depth. Depth is calculated from the root node(s) of the containment hierarchy of which the instance in question is a part
8. Randomly chosen

There are methods in the SDK that will give you resultant set. One MonitoringObject and MonitoringClass there are several overloads for GetResultantOverrides. The UI also exposes resultant overrides via the overrides UI for workflows and eventually there will be a summary view of overrides available as well.

Overrides in SCOM 2007

Additional resources