Notes on System Center Operations Manager : Modules

What is new: OpsMgr 2007 R2 - How to reset monitor state with recovery?

MSutara — Mon, 20 Apr 2009 20:28:00 GMT

Cameron had a nice example of using new R2 feature process monitoring in real life, but that raised a question about feature he wanted to use. Following is report of his issue and how we can help him to address his challenges using already existing feature of OpsMgr 2007.

Scenario: Monitoring a system with a process monitor. Define a recovery to reboot the system if it’s not running the process required. Run this recovery automatically on critical state.

Problem: In OpsMgr prior to R2 when a Recovery was created it had an option to “Reset monitor” which would put it to a healthy state. In R2, this now says “Recalculate State Monitor”. This is representing a challenge as described below:

Challenge: Recalculating the state may keep the monitor in a critical state until the system has been rebooted successfully and is in fact running the process. If the process does not start correctly after reboot, it gets stuck in the critical state and the recovery will not run again. With a Reset of this monitor to a Healthy state, this would work properly, but without that option available I am not seeing an effective way to make this work.

Workaround: Recovery is no different than other workflows loaded by OpsMgr and is rather similar to task. It consists of modules that are chained together and should provide some corrective action in order for monitor to fix its state. For that reason, first module could be the module which resets state of the monitor.

Following is module that could be used with recovery directly. It will reset the state of the monitor specified in configuration.

<xsd:element minOccurs="1" name="MonitorId" type="xsd:string" />

</Configuration>

</OverrideableParameters>

<ManagementGroupId>$Target/ManagementGroup/Id$</ManagementGroupId>

<ManagedEntityId>$Target/Id$</ManagedEntityId>

<MonitorId>$Config/MonitorId$</MonitorId>

</WriteAction>

</MemberModules>

</Composition>

</Composite>

</ModuleImplementation>

<OutputType>System!System.BaseData</OutputType>

<InputType>System!System.BaseData</InputType>

</WriteActionModuleType>

Next is another module which can be used as well. It resets the state of the monitor first and then executes command.

<SchemaType>System!System.CommandExecuterSchema</SchemaType>

</IncludeSchemaTypes>

<xsd:element minOccurs="1" name="ApplicationName" type="xsd:string" />

<xsd:element minOccurs="1" name="WorkingDirectory" type="xsd:string" />

<xsd:element minOccurs="1" name="CommandLine" type="xsd:string" />

<xsd:element minOccurs="1" name="TimeoutSeconds" type="xsd:integer" />

<xsd:element minOccurs="1" name="RequireOutput" type="xsd:boolean" />

<xsd:element minOccurs="1" name="MonitorId" type="xsd:string" />

</Configuration>

<ApplicationName>$Config/ApplicationName$</ApplicationName>

<WorkingDirectory>$Config/WorkingDirectory$</WorkingDirectory>

<CommandLine>$Config/CommandLine$</CommandLine>

<TimeoutSeconds>$Config/TimeoutSeconds$</TimeoutSeconds>

<RequireOutput>$Config/RequireOutput$</RequireOutput>

</WriteAction>

<MonitorId>$Config/MonitorId$</MonitorId>

</WriteAction>

</MemberModules>

</Node>

</Composition>

</Composite>

</ModuleImplementation>

<OutputType>System!System.BaseData</OutputType>

<InputType>System!System.BaseData</InputType>

</WriteActionModuleType>

Sealed MP with both modules is attached to this post.

Sample: Attached is also example providing use of modules with simple event based monitor. Monitor targets instance of “Root Management Server” and that is a reason why management pack also defines a view for state of this entity. When you choose to display “Health explorer”, you should be easily able to locate sample monitor.

One of the recoveries present in attached MP runs automatically with WARNING state. Highlighted is MPElement replacement representing monitor you want to reset. (It should be same as value of the attribute Monitor! Also, please observe that using just a reset module causes its output to be displayed in “Context” tab as well as two state changes will appear to have “same” time of change in Health Explorer.

<Category>Maintenance</Category>

<MonitorId>$MPElement[Name="Microsoft.SystemCenter.Community.Monitors.RecoverySample.EventBasedMonitor"]$</MonitorId>

</WriteAction>

</Recovery>

DISCLAIMER:

Please evaluate in your test environment first! As expected, this solution is provided AS-IS, with no warranties and confers no rights. Use is subject to the terms specified at Microsoft.

HOWTO: Registry Attribute Definition explained

MSutara — Thu, 28 Feb 2008 23:45:00 GMT

Maybe you already needed to use probe module to retrieve data from registry, check the existence of registry key or similar task involving registry when for example discovering your custom managed entity space. In that case you definitely met

<xsd:element name="RegistryAttributeDefinition" minOccurs="1" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="AttributeName" type="xsd:ID" />

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

<xsd:element name="PathType" type="xsd:integer" />

<xsd:element name="AttributeType" type="xsd:integer" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

It appears there is no explanation of PathType and AttributeType tags and their mapping to number available anywhere yet, so I will try to help there, as well as post an example of registry use to check key existence and how it should be done for OpsMgr 2007 …

PathType

· 0 – Key. Path is full path to the key.

· 1 – Value of specified registry key. Path includes name of the value.

· 2 – Default value of specified registry key. Path is full path to the key.

AttributeType

· 0 – Boolean: used when checking existence of the key or value.

· 1 – String: converting result value to string if possible.

· 2 – Integer: converting result value to number if possible.

· 3 – Float: converting result value to float.

Example to recognize Vista

Following is XML fragment when retrieving the value CurrentVersion under hive HKLM\Software\Microsoft\Windows NT\CurrentVersion helps to recognize Windows SKU. Similarly I could test existence of the value under some key (or key itself), in which case I need to provide full path to the value and change PathType to 1 (or ) in the case when checking the existence of key).

<AttributeName>WindowsCurrentVersion</AttributeName>

<Path>SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion</Path>

</RegistryAttributeDefinition>

</RegistryAttributeDefinitions>

Result registry data type can be used with subsequent module thru $Data/…$ replacement, or direct XPath query when used with expression filter. To recognize Vista, compare with its version number (6.0)

<XPathQuery>Values/WindowsCurrentVersion</XPathQuery>

</ValueExpression>

<Operator>Equal</Operator>

</ValueExpression>

</SimpleExpression>

</Expression>

Example to test existence

Following is XML fragment when testing the existence of the key CustomApplication under hive HKLM\Software.

<AttributeName>CustomAppExists</AttributeName>

<Path>SOFTWARE\CustomApplication</Path>

</RegistryAttributeDefinition>

</RegistryAttributeDefinitions>

To test use following expression

<XPathQuery>Values/CustomAppExists</XPathQuery>

</ValueExpression>

<Operator>Equal</Operator>

</ValueExpression>

</SimpleExpression>

</Expression>

OpsMgr2007 SP1 RC rolling ugrade and cluster aware application monitoring.

MSutara — Mon, 12 Nov 2007 23:25:00 GMT

Rolling upgrade of OpsMgr2007 is performed the way that server bits are upgraded, new management packs are requested and delivered and those are later pushed down to agents. Operations Manager 2007 SP1 Release Candidate contains an issue when monitoring of cluster aware application (like SQL, Exchange …) is present within topology.

This issue is manifesting itself by unloading several rules responsible for discovering instance of Virtual Server as well as monitoring failover of cluster resource group matching that particular instance of Virtual Server. It is caused by changes to configuration of native modules defined inside of Microsoft.Windows.Cluster.Library management pack.

Rules will be unloaded until new binaries are approved, delivered and replace binaries shipped with Microsoft operations Manager 2007 RTM. Impact of this unload is that during the rolling upgrade of OpsMgr2007 SP1 RC, newly created cluster aware applications are not discovered, already present cluster aware applications are not “actively” monitored if they had failed over to another cluster node or when cluster service stopped, paused or crashed.

Rules are re-loaded and are able to process new configuration once binaries present with OpsMgr2007 SP1 RC are replaced and loaded by runtime on agent (health service) running on cluster node.

Sample of event notifying about discovery rule unload:

Event Type:   Error
Event Source:          HealthService
Event Category:       Health Service
Event ID:       4511
Date:            11/09/2007
Time:            9:26:27 AM
User:            N/A
Computer:     testBox

Description:
Initialization of a module of type "ClusterDiscoveryDS" (CLSID "{97B1EF21-757C-4004-86BB-57939E2C98D8}") failed with error code “Element not found” causing the rule "Microsoft.Windows.Cluster.Classes.Discovery" running for instance "Cluster Service" with id:"{0753905A-5ACE-5C70-1B0A-7980743053FA}" in management group “marius”