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:
<DataSourceModuleType ID="MyDSModuleType" Accessibility="Public">
<xsd:element name="Name" type="xsd:string"></xsd:element>
<OverrideableParameter ID="Name" Selector="$Config/Name$" ParameterType="string"/>
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:
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.
I received a couple good questions via email that I wanted to post here for others benefit:
In general I think I follow this. The guiding princial seems to be the more specific the targeting the greater chance of winning. However can you expand on algorithm rule:
4. A child in the hierarchy of overrides always wins over a direct
parent override of the same type (instance vs class)
By 'hierarchy of overrides' do you mean the conceptual precedence after overrides are applied to targets in the hierarchy. i.e. my understanding is that overrides do not inherit from each other - it is the target tree that is hierarchical. Also when you say 'direct parent' am I right in assuming it means a parent at any level back or are you implying 'immediate parent'
ie only one level back?
Answer: Yes, by hierarchy I mean the conceptual hierarchy of overrides as superimposed over the classes and instances in an instances virtual hierarchy. This hierarchy includes its direct classes, followed by any instances that contain it, and their classes.
For the second question, what I mean a parent at any level, but up the same hierarchy. i.e. my instances class is NOT a "child" of an instances that contains my instance class, if that makes sense. So if I am a SQL Server, the SQL Server class is not a child of the Computer class, even though the computer class is still in my hierarchy by virtue of the computer than contains me.
6. Class overrides from contained instances always win over class
overrides of the instance.
I'm not sure I understand what 'Class overrides from contained instances'
means. Can it be an override applied at the class level because one of its contained instances is targetted? That seems to be going backwards. And 'class overrides of the instance' means an override applied to an instance because it actually targetted the class? Can you give an example of rule 6?
Answer: Another good question. Let's take a simple example. Given a database, db1, of class Database in a distributed application, 401Ka, of class 401K, if I have an override targeted to the classes Database and 401K, the 401K one is considered more important, everything else (the other 5 points) being equal.
The reason is that this particular db is further specialized by the fact that it is a 401K db, i.e. 401K DB is more specialized that DB by itself.
You state in your article:
"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."
How is it possible to determine what property overrides exist for a ManagementPackElement that don't have to be explicity defined?
For example, if I use the SDK to query the Microsoft.Windows.Server.2003.LogicalDisk.FreeSpace monitor and ask for all overrideable parameters it returns 9 different ones.
However if I use the OM 2007 console it returns a total of 15 possible overrides, which include "Enabled", "Generates Alert", "Auto-Resolve Alert", etc in addition to the 9 overrideable parameters that I can obtain a list of via the SDK.
So how can I use the SDK to determine those 6 additional property overrides (including "Enabled") that exist in addition to the overrides that I can obtain via the SDK?
Or do I just have to make assumptions about what property overrides can be overridden based on the results that I see in the OM 2007 console?
The additional property based overrides are defined in enums and are fixed. For monitors the enum is Microsoft.EnterpriseManagement.Configuration.ManagementPackMonitorProperty and for all other workflows the enum is Microsoft.EnterpriseManagement.Configuration.ManagementPackWorkflowProperty.
Thanks Jakub for clarifying this.
However I am still a bit confused over how Property overrides work.
For example, if you view the overrideable "Enabled" property in the OM 2007 Console it defines "Enabled" as being a Boolean value with only true or false settings.
However if you examine the Enabled property of ManagementPackMonitor it is defined as being a ManagementPackMonitoringLevel enumeration, which can take three different values in addition to true or false.
So why am I limited when attempting to override this property to only true/false using the OM 2007 console?
And why is this reported as a Boolean value in the OM 2007 console when the property itself is defined as a ManagementPackMonitoringLevel enumeration value?
Good question. The enabled property is overloaded to be used with both simple enabling and disabling of workflows and for broad category based overrides. If you look at the post again, the paragraph starting with "Orthogonal to the aforementioned overrides, we also have the concept of category overrides" describes category overrides and talks about these three values. These values can only be set at authoring time and cannot be used for subsequent overrides.
How do I use the SDK to define an override for a ProbeActionModuleType configuration overrideable parameter in a MonitoringTask?
An example of this is the "TimeoutSeconds" parameter defined for the Task "Microsoft.Server.AD.2003.GeneralResponseCheck.Task" in the AD 2003 Monitoring MP.
I can do this for a Probe Action configuration overrideable parameter in a Diagnostic, but not for a MonitoringTask.
None of the following configuration overrides defined in the SDK seem to support taking an instance of a Task to allow me to create an appropriate override, the way that I can for a Diagnostics probe action parameter, by creating an instance of a ManagementPackDiagnosticConfigurationOverride.
None of the following seem appropriate:
Any suggestions as to how this can be done?
Overrides for tasks work a little bit differently. They are not persisted and are only available per task execution. The Overrides collection for tasks is available on the MonitoringTaskConfiguration class.
Thanks for the quick response Jakub - although I'm not totally sure I understand.
I think what you're telling me is that its not possible to create an override in a MP that refers to an overrideable parameter in a Task.
Is that correct?
Correct. Task overrides are not "global". They only apply to a single run of the task. Essentially, you can't change the task configuration for a sealed task across the board, but rather for a single run of the task only.
You talk in this article about how overrideable parameters are defined in the XML that defines a MP.
Is there a method of obtaining the overrideable parameters for management pack elements for management packs that are not installed?
You have SDK methods GetOverrideableParameters for instances of:
I need to be able to obtain the overrideable parameters for instances of:
(ie. for MP elements before the MP is installed) and I can't find a method in the SDK that appears to allow me to do so.
How would you recommend that I go about getting the overrideable parameters for MP elements for a MP before it is installed in a management group?
Thanks in advance for any advice or suggestions you can provide.
Here's the path you need to follow:
1. Start with the management pack element of interest.
2. Look at all the modules that make the element. For instance, with a rule, you have a data source collection of modules a single condition detection module and a collection or write action modules.
3. Next, for each module look at the TypeID which is a reference to the module type. GetElement off the TypeID should get you the actual module type object.
4. When you have the module type, there is a collection of ManagementPackOverrideableParameters on it called OverrideableParameterCollection.
Hope this helps.
Okay - here's another problem I have with overrides - regarding how to interpret the ContextInstance field.
If I save a management pack to a file on the disk and the MP contains overrides with non null ContextInstance values - how can I make sense of the ContextInstance values?
As you've described previously the ContextInstance contains a GUID for a monitoring object in the management group - but once MPs been saved to a disk file and now needs to be interpreted independently of the management group from which it came, how can I interpret the ContextInstance GUID?
It would be nice if at the very least, I could relate the GUID back to the discovery rule that was used to create the monitoring object in the management group that was overridden - but I can't figure out how to do this (or anything else useful to interpret the GUID).
Any idea as to how I can interpret the ContextInstance GUID in the case where I don't have access to the management group itself?
I have access to the file saved for the MP defining the override and to file copies of all the MPs which are referenced by it. Hopefully this would give me enough information to provide a useful intepretation of this field.
You can't. Overrides with a non-null context-id are not meant to be removed from the management group context.
Is there a way to define an override that can help enable/disable all the monitors and/or rules on a particular object (ie instance of a custom class) ?
In continuation to my previous post, I know this can be accomplished by using maintenance windows, but we want to provide an option for the customer to exclude a particular object from being monitored indefinitely.