OpsMgr++ : Management Packs

Windows Server 2008 Cluster MP is now available!

Boris Yanushpolsky — Fri, 13 Feb 2009 03:26:00 GMT

I have seen a number of questions on this in the past so I am happy to announce that we just released the Windows Server 2008 Failover Cluster MP. You can now download it on:

http://www.microsoft.com/downloads/details.aspx?FamilyId=AC7F42F5-33E9-453D-A923-171C8E1E8E55&displaylang=en&displaylang=en

Big thanks to those who helped validate the MP.

Configuring rules to run during business hours only

Boris Yanushpolsky — Fri, 19 Sep 2008 09:00:00 GMT

I have heard the question about creating rules that execute only during a certain set of hours many times in the last while. While its not straight forward, it is still possible. Attached to the this blog post is a MHTML file which I wrote that describes the steps of how this can be done and also gives you some clues as to how this can be done for a monitor. The MHTML file includes step by step instructions on how this can be done and also provides screen shots. The first time you do it, it will probably take 10-15 minutes. However the next time you do it, I think it will be pretty quick.

If you have questions about the steps written in the MHTML file, please leave me a comment. If you find this useful, please also leave me a comment and I can put together a sample for a monitor.

MPViewer 1.7 - Now works with latest E12 MP

Boris Yanushpolsky — Wed, 25 Jun 2008 04:06:00 GMT

Thanks Stefan for reporting that MPViewer export to HTML functionality didn’t work with the latest version of the E12 MP. This was caused by a bug in MPViewer. The new version is attached to this blog post. I also some more minor features such as frequency for performance monitors as well breaking out the monitors by type (unit, dependency, aggregate).

If you see any other issues looking at MPs, please drop me a a message.

Monitoring Windows 2008 Clusters

Boris Yanushpolsky — Wed, 04 Jun 2008 20:36:00 GMT

Are you interested in participating in a private beta program for the Windows 2008 Cluster management pack? If so, please send me an email (borisyan@microsoft.com). Please note that I am only able to provide access to the beta bits to 10 customers so this is on a first come first serve basis.

On Demand Detection

Boris Yanushpolsky — Wed, 04 Jun 2008 01:21:00 GMT

A really useful feature of Health Explorer in Operations Manager is the ability to force the agent recalculate health of a particular monitor. One the most common uses for this is when you want to confirm that the action that you took actually fixed the problem. If you have implemented your management pack correctly all you need to do is select the unit monitor in health explorer and click on the "Recalculate Health" button.

In order to make this button actually force your monitor to recalculate health state, you must do some extra work in your management pack, or else nothing will happen. This is especially important if you are either creating a new monitor type or creating a script based monitor. Basically when creating a new monitor type or creating a script based monitor, unless you do some extra work "Recalculate Health" will not do much for you and the users of your MP.

Before we dive into the details of what needs to be done, let's first review a standard two state script based monitor. This monitor uses a script to determine the health state of a service (in a shipping MP I would use a different monitor type, but this was but this was convenient for demonstration purposes).

<Category>Custom</Category>

</OperationalStates>

<ScriptName>GetServiceStatus2.vbs</ScriptName>

<Arguments>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$ dhcp</Arguments>

<![CDATA[

call Main()

Sub Main()

Dim oAPI

Dim oBag

Dim serviceName

Dim computerName

Dim statusColl

Dim serviceStatus

computerName = WScript.Arguments(0)

serviceName = WScript.Arguments(1)

Set wmi = GetObject("winmgmts:\\" & computerName & "\root\cimv2")

wql = "SELECT * FROM Win32_Service WHERE Name='" & serviceName & "'"

Set statusColl = wmi.ExecQuery(wql)

If statusColl.Count = 1 Then

Dim service

Set service = statusColl.ItemIndex(0)

serviceStatus = service.State

End If

Set oAPI = CreateObject("MOM.ScriptAPI")

Set oBag = oAPI.CreatePropertyBag()

oBag.AddValue "ServiceStatus", serviceStatus

oAPI.Return(oBag)

End Sub

]]>

</ScriptBody>

<XPathQuery Type="String">Property[@Name='ServiceStatus']</XPathQuery>

</ValueExpression>

<Operator>NotEqual</Operator>

<Value Type="String">Running</Value>

</ValueExpression>

</SimpleExpression>

</ErrorExpression>

<XPathQuery Type="String">Property[@Name='ServiceStatus']</XPathQuery>

</ValueExpression>

<Operator>Equal</Operator>

<Value Type="String">Running</Value>

</ValueExpression>

</SimpleExpression>

</SuccessExpression>

</Configuration>

</UnitMonitor>

This monitor looks totally fine and will work properly by running the script and interpreting the results of the script every 180 seconds. The problem is that if you try to recalculate the health state of this monitor using health explorer, nothing will happen. This is because the underlying monitor type which in essence acts as the foundation for this monitor does not implement an "On Demand Detection". The "On Demand Detection" section of the monitor type provides additional information to OpsMgr in order to allow it to recalculate the health state at any point in time rather than waiting for the 180 seconds interval. Now lets look at the steps that need to be taken in order to implement a monitor which will react to a request to recalculate its health state:

1 - Implement a probe which is just responsible for retrieving the particular piece of instrumentation

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

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

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

</Configuration>

<ScriptName>GetServiceStatus.vbs</ScriptName>

<Arguments>$Config/ComputerPrincipalName$ $Config/ServiceName$</Arguments>

<![CDATA[

call Main()

Sub Main()

Dim oAPI

Dim oBag

Dim serviceName

Dim computerName

Dim statusColl

Dim serviceStatus

computerName = WScript.Arguments(0)

serviceName = WScript.Arguments(1)

Set wmi = GetObject("winmgmts:\\" & computerName & "\root\cimv2")

wql = "SELECT * FROM Win32_Service WHERE Name='" & serviceName & "'"

Set statusColl = wmi.ExecQuery(wql)

If statusColl.Count = 1 Then

Dim service

Set service = statusColl.ItemIndex(0)

serviceStatus = service.State

End If

Set oAPI = CreateObject("MOM.ScriptAPI")

Set oBag = oAPI.CreatePropertyBag()

oBag.AddValue "ServiceStatus", serviceStatus

oAPI.Return(oBag)

End Sub

]]>

</ScriptBody>

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

</ProbeAction>

</MemberModules>

</Node>

</Composition>

</Composite>

</ModuleImplementation>

<OutputType>System!System.PropertyBagData</OutputType>

</ProbeActionModuleType>

2 - Implement a composite data source module which would combine the probe with a scheduler. Its not a must, but I would recommend you do this to simplify the implementation of the monitor type in step 3:

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

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

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

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

</Configuration>

</OverrideableParameters>

<Interval Unit="Seconds">$Config/IntervalSeconds$</Interval>

</SimpleReccuringSchedule>

</Scheduler>

</DataSource>

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

<ComputerPrincipalName>$Config/ComputerPrincipalName$</ComputerPrincipalName>

<ServiceName>$Config/ServiceName$</ServiceName>

</ProbeAction>

</MemberModules>

</Node>

</Composition>

</Composite>

</ModuleImplementation>

<OutputType>System!System.PropertyBagData</OutputType>

</DataSourceModuleType>

3 - Monitor type which contains a section called "OnDemandDetection". The section is highlighted below:

</MonitorTypeStates>

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

<xsd:element name="TimeoutSeconds" type="xsd:int" />

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

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

</Configuration>

</OverrideableParameters>

<IntervalSeconds>$Config/IntervalSeconds$</IntervalSeconds>

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

<ComputerPrincipalName>$Config/ComputerPrincipalName$</ComputerPrincipalName>

<ServiceName>$Config/ServiceName$</ServiceName>

</DataSource>

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

<ComputerPrincipalName>$Config/ComputerPrincipalName$</ComputerPrincipalName>

<ServiceName>$Config/ServiceName$</ServiceName>

</ProbeAction>

<XPathQuery Type="String">Property[@Name='ServiceStatus']</XPathQuery>

</ValueExpression>

<Operator>NotEqual</Operator>

<Value Type="String">Running</Value>

</ValueExpression>

</SimpleExpression>

</Expression>

</ConditionDetection>

<XPathQuery Type="String">Property[@Name='ServiceStatus']</XPathQuery>

</ValueExpression>

<Operator>Equal</Operator>

<Value Type="String">Running</Value>

</ValueExpression>

</SimpleExpression>

</Expression>

</ConditionDetection>

</MemberModules>

</Node>

</RegularDetection>

</Node>

</RegularDetection>

</RegularDetections>

<OnDemandDetection MonitorTypeStateID="Running">

<Node ID="RunningCondition">

<Node ID="Probe" />

</Node>

</OnDemandDetection>

<OnDemandDetection MonitorTypeStateID="NotRunning">

<Node ID="NotRunningCondition">

<Node ID="Probe" />

</Node>

</OnDemandDetection>

</OnDemandDetections>

</MonitorImplementation>

</UnitMonitorType>

4 - Monitor which uses the monitor type created in step 3.

<Category>AvailabilityHealth</Category>

<AlertOnState>Error</AlertOnState>

<AlertPriority>Normal</AlertPriority>

<AlertSeverity>MatchMonitorHealth</AlertSeverity>

<AlertParameter2>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</AlertParameter2>

</AlertParameters>

</AlertSettings>

</OperationalStates>

<ComputerPrincipalName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</ComputerPrincipalName>

</Configuration>

</UnitMonitor>

Now the agent will have all the required information to be able to recalculate the health state of the monitor at any given time. The one thing that you should keep in mind is that OnDemandDetection is not possible for every scenario such as event based monitors as the monitor state is driven purely by an occurrence of a particular event and until that event is logged, there is nothing much you can do.

The one area that I would urge you to strongly consider implementing OnDemandDetection is specifically for script based monitors as this is just a matter of refactoring the monitor implementation.

Hope this post provided some additional information on how to build a management pack. If you have questions about OnDemandDetection, please leave me a comment on the blog and I will try to respond to it.

Attached to this post is a sample MP that contains both monitors.

MPViewer 1.5 - Performance rules and monitors

Boris Yanushpolsky — Tue, 03 Jun 2008 22:17:00 GMT

I finally had a bit of time to work on improving MPViewer so here is a new a version. The main improvement in this version is additional visibility into performance rules and monitors. Now there are two new columns which show you the performance object name and counter name.

For the next version I am hoping to do the same thing for event rules and monitors though its a bit more complicated to do.

What do YOU think about the Cluster Management Pack?

Boris Yanushpolsky — Sat, 19 Apr 2008 03:44:00 GMT

Several weeks ago we released an update to Windows 2003 Cluster MP to address several customer initiated issues. I am very interested to hear what you think about the cluster MP and what has been your experience in deploying and using it, or things that you wish the MP had. If you are reading this post and have the Cluster MP deployed, I would really appreciate if you could send me a message or post a comment on the blog.

Cluster MP Upgrade

Boris Yanushpolsky — Fri, 04 Apr 2008 21:21:00 GMT

Looks like there is some confusion as to the what exactly needs to be done in order to upgrade to the latest version of the cluster MP. Here is a flow chart that should clear things up:

Windows 2003 Cluster Management Pack update is now available on MP Catalog

Boris Yanushpolsky — Wed, 02 Apr 2008 19:04:00 GMT

We have just posted an updated version of the Windows 2003 Cluster Management Pack. This update resolves several customer initiated issues. This update also includes some changes in order to prepare for the Windows 2008 Cluster MP.

Here is a link to the download: http://www.microsoft.com/downloads/details.aspx?FamilyId=AC7F42F5-33E9-453D-A923-171C8E1E8E55&displaylang=en&displaylang=en

Due to the nature of the changes you will need to first uninstall the previous version of the cluster management pack. The steps are documented in the MP Guide which is part of the download package. The MP guide also has a complete list of changes.

MP authoring samples - NT service based discovery

Boris Yanushpolsky — Tue, 01 Apr 2008 04:00:00 GMT

One of the things that I have been wanting to cover in this blog is advanced MP authoring. Lately I have been spending a fair bit of time doing MP related work so I am going to start blogging on this subject. My main focus will be to provide samples as well as share some thoughts that come to my mind when doing MP related work.

One of the problems that I see pretty frequently is people only want to target a particular set of computers when creating a new rule or monitor. A lot of times these computers perform a common function. Perhpas the most correct way to do this is define a new type and the discover instances of this type. This can be done using the Authoring Console or using raw XML. In this blog post I will show how you can do this by checking if a particular service is installed and not disabled on a computer as in many cases this is a easy way to identify a server as performing a particular function.

One the goals of providing the XML is so that you can easily tweak this to your needs and use it.

If you find this sort of samples usefull, please let me know and I will post more. If you have questions about the MP below please post comments and I will try to address them.

<ID>NTServiceBasedDiscoverySample.MP</ID>

</Identity>

<Name>NTServiceBasedDiscoverySample.MP</Name>

<ID>Microsoft.SystemCenter.Library</ID>

</Reference>

<ID>System.Library</ID>

</Reference>

<ID>Microsoft.Windows.Library</ID>

</Reference>

<ID>System.Health.Library</ID>

</Reference>

</References>

</Manifest>

</ClassTypes>

</RelationshipTypes>

</EntityTypes>

<!--

This data source is composed of three module:

Scheduler - This will kick off the discovery which uses this datasource every N seconds

Probe - This will check if the specified service exists and is not disabled

Mapper - This will cause discovery data to be created

-->

<xsd:element name="IntervalSeconds" type="xsd:unsignedInt" />

</Configuration>

</OverrideableParameters>

<Interval Unit="Seconds">$Config/IntervalSeconds$</Interval>

</SimpleReccuringSchedule>

</Scheduler>

</DataSource>

<ComputerName>$Target/Property[Type='Windows!Microsoft.Windows.Computer']/NetworkName$</ComputerName>

<!--

This is where we specify which service to look for.

In this case its the Alerter service.

-->

<ServiceName>Alerter</ServiceName>

</ProbeAction>

<ClassId>$MPElement[Name="Sample.ServerRole"]$</ClassId>

<Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>

<Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>

</Setting>

<Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>

<Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>

</Setting>

</Settings>

</InstanceSettings>

</ConditionDetection>

</MemberModules>

</Node>

</Composition>

</Composite>

</ModuleImplementation>

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

</DataSourceModuleType>

<!--This composite probe module consists of two modules:

1 - Probe module which queries the service control manager for info about the specified service

2 - Condition detection module which checks whether the startup type of the service is not set to "Disabled"

See http://blogs.msdn.com/sampatton/archive/2008/03/10/win32serviceinformation-modules.aspx for more info

-->

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

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

</Configuration>

<ComputerName>$Config/ComputerName$</ComputerName>

<ServiceName>$Config/ServiceName$</ServiceName>

</ProbeAction>

<!--

This is where we specify that we only care if the service startup mode is not disabled

-->

<XPathQuery Type="Integer">Property[@Name='StartMode']</XPathQuery>

</ValueExpression>

<Operator>NotEqual</Operator>

</ValueExpression>

</SimpleExpression>

</Expression>

</ConditionDetection>

</MemberModules>

</Node>

</Composition>

</Composite>

</ModuleImplementation>

<OutputType>System!System.PropertyBagData</OutputType>

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

</ProbeActionModuleType>

</ModuleTypes>

</TypeDefinitions>

<Category>Discovery</Category>

</DiscoveryClass>

</DiscoveryTypes>

</DataSource>

</Discovery>

</Discoveries>

</Monitoring>

<Views>

<Category>Operations</Category>

<InMaintenanceMode>false</InMaintenanceMode>

</Criteria>

<Name>State</Name>

<Id>Sample.ServerRole</Id>

</ColumnInfo>

<Name>Maintenance Mode</Name>

<Id>InMaintenanceMode</Id>

</ColumnInfo>

</ColumnInfo>

</ColumnInfo>

<Name>Display Name</Name>

<Id>DisplayName</Id>

</ColumnInfo>

</Presentation>

</View>

</Views>

</Folders>

</FolderItems>

</Presentation>

<Name>NT Service Based Discovery Sample MP</Name>

</DisplayString>

<Name>Sample Server Role</Name>

</DisplayString>

<Name>Sample NT Service based discovery</Name>

</DisplayString>

<Name>Sample MP</Name>

</DisplayString>

<Name>Sample objects state (will be unmonitored as there are no monitors in the MP)</Name>

</DisplayString>

</DisplayStrings>

</LanguagePack>

</LanguagePacks>

</ManagementPack>

The Cluster MP is ready!

Boris Yanushpolsky — Wed, 05 Mar 2008 02:08:00 GMT

The long awaited cluster management pack for Windows 2003 is finally ready. The MP package contains the management pack files as well as a QFE.

http://www.microsoft.com/downloads/details.aspx?FamilyID=ac7f42f5-33e9-453d-a923-171c8e1e8e55&DisplayLang=en

If you did not upgrade to the final bits of SP1, you will need to install the QFE and the import the Microsoft.Windows.Library management pack. After that's done, you will need to import the following MP files:

Microsoft.Windows.Cluster.Management.Monitoring

Microsoft.Windows.Cluster.Management.Library

Microsoft.Windows.2003.Cluster.Management.Monitoring

Microsoft.Windows.2003.Cluster.Management.Library

If you do have SP1 installed, all you need to do is import the following MP files:

Microsoft.Windows.Cluster.Management.Monitoring

Microsoft.Windows.Cluster.Management.Library

Microsoft.Windows.2003.Cluster.Management.Monitoring

Microsoft.Windows.2003.Cluster.Management.Library

Dont forget to enable proxying on the agents which manage cluster nodes.

We are very interested to hear your feedback about the MP, so please post it as comments on the blog.

Why cant I configure an event view to show events collected only by my rule?

Boris Yanushpolsky — Thu, 28 Feb 2008 23:10:00 GMT

While writing a management pack today, I came across an interesting issue. When you create an event view, you can specify in the criteria of the event view that it should only show events collected by a specific rule. When you do this, a dialog comes up that lists all the rules that you can filter by. Looks like this dialog only show rules where the rule category is EventCollection. If you create a rule and dont specify its category as EventCollection, it does not show up and you cant make the UI filter by this rule.

If you are creating the rule in the Operations Console, be sure to configure the category of the rule as “EventCollection”. By default its set to “Custom”.

From an XML perspective, here is how it looks:

<Category>EventCollection</Category>

So if you want your rule to show up in the list of rules that the user can filter by, be sure to mark it as an EventCollection rule.

One more thing, if you are writing a management pack and want to define a view in the MP that only shows events generated by a particular rule, here is what you need to put in the view criteria:

<Category>Operations</Category>

<Rule>$MPElement[Name='SampleEventCollectionRule']$</Rule>

</RuleList>

</Criteria> the rest of the view xml follows…

This will cause the view to show only events collected by the specified rule.

However if you don’t mark the rule as an “EventCollection” rule then, in the view properties, the GUID of the rule will be shown rather than the rule name.

Creating a new task with overridable parameters

Boris Yanushpolsky — Tue, 11 Dec 2007 21:22:00 GMT

Couple of days ago I saw a question on one of the newsgroups regarding creating a task where the operator can specify one or more parameters that are used by the task when launching the task. Unfortunately it’s not possible to create such as task today in the OpsMgr console, however you can do this using the SP1 RC authoring console or just in XML. The key part is defining a new WriteAction and specifying which parameter can be overriden (see the highlighted section below). Here is a sample MP that shows how you can do this in XML:

<ID>SampleMP.UserConfigurableTaskParameters</ID>

</Identity>

<Name>Sample MP - User Configurable Tasks Parameters</Name>

<ID>System.Library</ID>

</Reference>

<ID>System.Health.Library</ID>

</Reference>

<ID>System.Performance.Library</ID>

</Reference>

<ID>Microsoft.Windows.Library</ID>

</Reference>

<ID>Microsoft.SystemCenter.Library</ID>

</Reference>

</References>

</Manifest>

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

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

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

<xsd:element name="TimeoutSeconds" type="xsd:int"/>

</Configuration>

<OverrideableParameters>

<OverrideableParameter ID="Parameter1" Selector="$Config/Parameter1$" ParameterType="string" />

<OverrideableParameter ID="Parameter2" Selector="$Config/Parameter2$" ParameterType="string" />

<OverrideableParameter ID="Parameter3" Selector="$Config/Parameter3$" ParameterType="string" />

<OverrideableParameter ID="TimeoutSeconds" Selector="$Config/TimeoutSeconds$" ParameterType="int" />

</OverrideableParameters>

<ScriptName>SampleScript.js</ScriptName>

<Arguments>"$Config/Parameter1$" "$Config/Parameter2$" "$Config/Parameter3$"</Arguments>

var scriptArgs = WScript.Arguments;

WScript.Echo("Parameter 1 " + scriptArgs(0));

WScript.Echo("Parameter 2 " + scriptArgs(1));

WScript.Echo("Parameter 3 " + scriptArgs(2));

</ScriptBody>

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

</WriteAction>

</MemberModules>

</Composition>

</Composite>

</ModuleImplementation>

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

</WriteActionModuleType>

</ModuleTypes>

</TypeDefinitions>

<Tasks>

<Category>Maintenance</Category>

<Parameter1>Parameter1Value</Parameter1>

<Parameter2>Parameter2Value</Parameter2>

<Parameter3>Parameter3Value</Parameter3>

</WriteAction>

</Task>

</Tasks>

</Monitoring>

</ManagementPack>

Targeting poster

Boris Yanushpolsky — Tue, 27 Nov 2007 22:06:00 GMT

Below is a link to a targeting poster that we have created to help select the proper targets when creating rules and monitors. The poster illustrates some of the most common scenarios and provides best practices on how to properly target rules and monitors. Feedback is always welcome of course.

http://download.microsoft.com/download/f/a/7/fa73e146-ab8a-4002-9311-bfe69a570d28/BestPractices_Rule_Monitor_REV_110607.pdf