Overrides in SCOM 2007

Artigo
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.

Comments

Anonymous
December 11, 2006
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:

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.
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.

Anonymous
February 20, 2007
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? Paul
Anonymous
February 20, 2007
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.
Anonymous
February 26, 2007
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?
Anonymous
February 26, 2007
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.
Anonymous
June 05, 2007
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: ManagementPackRuleConfigurationOverride ManagementPackMonitorConfigurationOverride ManagementPackDiagnosticConfigurationOverride ManagementPackRecoveryConfigurationOverride ManagementPackDiscoveryConfigurationOverride Any suggestions as to how this can be done?
Anonymous
June 05, 2007
The comment has been removed
Anonymous
June 05, 2007
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?
Anonymous
June 05, 2007
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.
Anonymous
June 14, 2007
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:

MonitoringDiagnostic
MonitoringDiscovery
MonitoringRecovery
MonitoringRule
MonitoringTask I need to be able to obtain the overrideable parameters for instances of:
ManagementPackDiagnostic
ManagementPackDiscovery
ManagementPackRecovery
ManagementPackRule
ManagementPackTask (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.

Anonymous
June 15, 2007
Here's the path you need to follow:

Start with the management pack element of interest.
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.
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.
When you have the module type, there is a collection of ManagementPackOverrideableParameters on it called OverrideableParameterCollection. Hope this helps.

Anonymous
July 26, 2007
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.
Anonymous
July 26, 2007
You can't. Overrides with a non-null context-id are not meant to be removed from the management group context.
Anonymous
February 12, 2008
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) ?
Anonymous
February 12, 2008
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.
Anonymous
February 12, 2008
You can either not discover it in the first place, or you need to disable each rule/monitor individually for that instance. There is no way to disable monitoring of an instance entirely in this release.
Anonymous
February 13, 2008
I would like provide a bit more detailed description of what we trying to accomplish. The instances in question are going to be created in our application, using the connector SDK. When we are creating the objects, we wouldn't know which objects the user would like to exclude from monitoring. Yes, we can let the user define an exclusion list in our application's config file. Ideally we want the user to be able to configure all monitoring related settings in OpsMgr. I would be interested in your thoughts on (a) Is this an unusual scenario in OpsMgr world (b) Am I heading down the wrong road with this design? I get the feeling may be I accomplish the end goal if I took a different approach. Much appreciate your time.
Anonymous
November 09, 2008
I am still trying to get my hands around overrides. Perhaps it is because I do not completely understand the hierarchy within SCOM. To be clear. You reference Category overrides; but, I just don't see how to implement a category override within SCOM. For example. How would you override the EventCollection category ? Then, please point me in the direction of a document explaining hierarchy within SCOM. Thank You
Anonymous
November 10, 2008
The category is what the override applies to, so if you create a category override, essentially the "target" of that override is workflows of that category. I don't know of any specific documents outlining the hierarchy concepts of described here, but the topic is fundamental to understanding Operations Manager, including but not limited to understanding overrides. I'd recommend you read all the Operators Manager documentation found here: http://www.microsoft.com/systemcenter/operationsmanager/en/us/default.aspx
Anonymous
April 13, 2011
The comment has been removed
Anonymous
April 14, 2011
Is P a single server or are you trying to handle the P drive of all servers? If P is a single specific server, and if that server is discovered in all your environments, the Guid will actually be the same. If the problem you have is the latter, you should create a new class for P drives, discover then explicitly and target your override to that.
Anonymous
June 06, 2011
The comment has been removed
Anonymous
June 07, 2011
The comment has been removed

Compartilhar via

Overrides in SCOM 2007

Comments

Recursos adicionais