This is a good example group, since it contains several nested group each containing different types of objects.

There are three parameter you can change in this example:

GroupDisplayName = name of group you want to check

LevelCount = how far to look into a nested group scenario (this can also be used to find all hosted objects of group members)

StartLevel = at which level do you want to begin returning group/object membership (e.g.; do not return membership of root group, but start at second level)

This should be executed on your Operations Manager Data Warehouse, not the operational database.

DECLARE @GroupDisplayName as varchar(max) = 'All Operations Manager Objects Group',
        @LevelCount as int = 1,
        @StartLevel as int = 1,
        @ObjectListDate as datetime = getutcdate(),
        @ObjectList as xml

SET @ObjectList = '<Data><Objects><Object Use="Containment">' + 
    convert(varchar,(
        SELECT ManagedEntityRowId 
        FROM vManagedEntity 
        WHERE displayName = @GroupDisplayName)) + 
        '</Object></Objects></Data>'

CREATE TABLE #ObjectList (ManagedEntityRowId int)
INSERT INTO #ObjectList (ManagedEntityRowId)
EXEC [Microsoft_SystemCenter_DataWarehouse_Report_Library_ReportObjectListParse]
    @ObjectList = @ObjectList,
    @StartDate = @ObjectListDate,
    @EndDate = @ObjectListDate,
    @ContainmentLevelCount = @LevelCount,
    @ContainmentStartLevel = @StartLevel

SELECT ISNULL(vme.Path,vme.DisplayName) AS DisplayName, ManagedEntityDefaultName
FROM vManagedEntity as vme inner join
    #ObjectList on #ObjectList.ManagedEntityRowId = vme.ManagedEntityRowId

DROP TABLE #ObjectList

If you wanted to return a history of group membership, you could replace StartDate and EndDate parameters with your desired range.

Looking for a custom dashboard solution for Operations Manager? Give us a ring!

_

You could add this logic while creating a rule in the Operations console.

The reason you should not do this is because it’s going to require more compute time than is necessary. If the monitored event log typically has a steady stream of events written, a single event detection rule like this could create a significant processing bottleneck on the monitored computer.

This is because all filtering is happening at the data source level, which means every element in your expression filter is checked against every event that is written to the specified log on that computer. Searching for a string in the event description takes time, and this is why it’s a bad practice to implement event description processing in the data source module.

To implement event monitoring with minimal performance impact, I suggest including only these parameters in the data source criteria:

• Event Source
• Event Id
• Event Level
• Event Category
• Event Parameter [0-..]

Furthermore, I suggest including only these operators in the data source criteria:

• Equal
• NotEqual
• Greater
• GreaterEqual
• Less
• LessEqual

So, how is it possible to implement pattern matching while still providing minimal processing impact?

The answer is to process pattern matching criteria in a condition detection module.

Wow, what a concept! Let the data source filter the simple event criteria, then move to the next module to process more complex criteria. That’s the cool thing about using System.ExpressionFilter. The workflow will exit if the expression <> true.

To understand this logic a little better, here is the processing sequence…

Without Condition Detection:

1. DataSource\EventDetection\Provider – match event log and logging computer (if true, move next)

2. DataSource\EventDetection\Filter – process all criteria (if true, move next)

3. WriteAction\Alert – generate an alert

With Condition Detection:

1. DataSource\EventDetection\Provider – match event log and logging computer (if true, move next)

2. DataSource\BasicEventDetection\Filter – process simple criteria (if true, move next)

3. ConditionDetection\FilterDescription – process complex criteria (if true, move next)

4. WriteAction\Alert – generate an alert

Unfortunately, it is not possible to implement the condition detection module in the Operations console. You will need to author this using the R2 Authoring Console, Visual Studio Authoring Extension, or directly in XML. I am providing a rule fragment you can add to your project using VSAE.

Similarly, you could implement this logic in an event detection monitor.

The below fragment detects event 101, with source TEST and event level ERROR in the Application log. If simple criteria matches, move the next module to process complex criteria (match SomePattern in the event description). Generate an alert at the end.

This rule fragment needs to be updated with your criteria and alert details. If you build it, alerts will come – and your manager will thank you.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Monitoring>
    <Rules>
      <Rule ID="MyMp.Rule.EventDescriptionMatches" ConfirmDelivery="true" DiscardLevel="100" Enabled="true" Priority="Normal" Remotable="false" Target="Windows!Microsoft.Windows.Computer">
        <Category>Alert</Category>
        <DataSources>
          <DataSource ID="BasicEventDetection" TypeID="Windows!Microsoft.Windows.EventProvider">
            <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
            <LogName>Application</LogName>
            <Expression>
              <And>
                <Expression>
                  <SimpleExpression>
                    <ValueExpression>
                      <XPathQuery>EventSourceName</XPathQuery>
                    </ValueExpression>
                    <Operator>Equal</Operator>
                    <ValueExpression>
                      <Value>TEST</Value>
                    </ValueExpression>
                  </SimpleExpression>
                </Expression>
                <Expression>
                  <SimpleExpression>
                    <ValueExpression>
                      <XPathQuery>EventDisplayNumber</XPathQuery>
                    </ValueExpression>
                    <Operator>Equal</Operator>
                    <ValueExpression>
                      <Value>101</Value>
                    </ValueExpression>
                  </SimpleExpression>
                </Expression>
                <Expression>
                  <SimpleExpression>
                    <ValueExpression>
                      <XPathQuery>EventLevel</XPathQuery>
                    </ValueExpression>
                    <Operator>Equal</Operator>
                    <ValueExpression>
                      <Value>1</Value>
                    </ValueExpression>
                  </SimpleExpression>
                </Expression>
              </And>
            </Expression>
          </DataSource>
        </DataSources>
        <ConditionDetection ID="FilterDescription" TypeID="System!System.ExpressionFilter">
          <Expression>
            <RegExExpression>
              <ValueExpression>
                <XPathQuery>EventDescription</XPathQuery>
              </ValueExpression>
              <Operator>MatchesRegularExpression</Operator>
              <Pattern>SomePattern</Pattern>
            </RegExExpression>
          </Expression>
        </ConditionDetection>
        <WriteActions>
          <WriteAction ID="Alert" TypeID="Health!System.Health.GenerateAlert">
            <Priority>1</Priority>
            <Severity>2</Severity>
            <AlertMessageId>$MPElement[Name="MyMp.Rule.EventDescriptionMatches.AlertMessage"]$</AlertMessageId>
            <AlertParameters />
            <Suppression />
          </WriteAction>
        </WriteActions>
      </Rule>
    </Rules>
  </Monitoring>
  <Presentation>
    <StringResources>
      <StringResource ID="MyMp.Rule.EventDescriptionMatches.AlertMessage"/>
    </StringResources>
  </Presentation>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="MyMp.Rule.EventDescriptionMatches">
          <Name>Event Description Match Alert Rule</Name>
        </DisplayString>
        <DisplayString ElementID="MyMp.Rule.EventDescriptionMatches.AlertMessage">
          <Name>Event Description Match</Name>
          <Description>Event description match pattern specified in rule configuration.</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

Do you need help developing a management pack? Give us a ring!

__

How to create a computer group using VSAE

Original post: How to create a computer group in the R2 Authoring Console

The main thing to focus on here is $MPElement[Name="YourMp.Class.YourClass"]$. This is referencing the class in which you want to include it’s hosting Windows Computer object.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="YourMp.Class.YourComputerGroup" Abstract="false" Accessibility="Public" Base="SC!Microsoft.SystemCenter.ComputerGroup" Hosted="false" Singleton="true" />
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>
  <Monitoring>
    <Discoveries>
      <Discovery ID="YourMp.Discovery.YourComputerGroup" ConfirmDelivery="false" Enabled="true" Priority="Normal" Remotable="true" Target="YourMp.Class.YourComputerGroup">
        <Category>Discovery</Category>
        <DiscoveryTypes />
        <DataSource ID="DS1" TypeID="SC!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$MPElement[Name="YourMp.Class.YourComputerGroup"]$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule>
              <MonitoringClass>$MPElement[Name="Windows!Microsoft.Windows.Computer"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="SC!Microsoft.SystemCenter.ComputerGroupContainsComputer"]$</RelationshipClass>
              <Expression>
                <Contains>
                  <MonitoringClass>$MPElement[Name="YourMp.Class.YourClass"]$</MonitoringClass>
                </Contains>
              </Expression>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>
    </Discoveries>
  </Monitoring>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="YourMp.Class.YourComputerGroup">
          <Name>Your Computer Group</Name>
          <Description>This group contains instances of Windows Computer objects that host YourClass.</Description>
        </DisplayString>
        <DisplayString ElementID="YourMp.Discovery.YourComputerGroup">
          <Name>Your Group Discovery</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

How to create an instance group using VSAE

Original post: How to create an instance group in the R2 Authoring Console

The main thing to focus on here is $MPElement[Name="YourMp.Class.YourFirstClass"]$. This is referencing the discovered instances in which you want to include in your group. You can add multiple classes if you need the group to contain different types of instances.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="YourMp.Class.YourInstanceGroup" Abstract="false" Accessibility="Public" Base="MSIL!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="true" />
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>
  <Monitoring>
    <Discoveries>
      <Discovery ID="YourMp.Discovery.YourInstanceGroup" ConfirmDelivery="false" Enabled="true" Priority="Normal" Remotable="true" Target="YourMp.Class.YourInstanceGroup">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryClass TypeID="YourMp.Class.YourFirstClass" />
          <DiscoveryClass TypeID="YourMp.Class.YourSecondClass" />
        </DiscoveryTypes>
        <DataSource ID="DS1" TypeID="SC!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$MPElement[Name="YourMp.Class.YourInstanceGroup"]$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule>
              <MonitoringClass>$MPElement[Name="YourMp.Class.YourFirstClass"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="MSIL!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass>
            </MembershipRule>
            <MembershipRule>
              <MonitoringClass>$MPElement[Name="YourMp.Class.YourSecondClass"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="MSIL!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>
    </Discoveries>
  </Monitoring>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="YourMp.Class.YourInstanceGroup">
          <Name>Your Instances Group</Name>
          <Description>This group contains all discovered instances referenced in the MonitoringClass(es).</Description>
        </DisplayString>
        <DisplayString ElementID="YourMp.Discovery.YourInstanceGroup">
          <Name>Your Instance Group Discovery</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

How to create a group of Windows Computer instances that host some class and matches a property of that class.

Original post: How to create a group of Windows Computers based on a discovered property of virtually any class

The main thing to focus on here is $MPElement[Name="YourMp.Class.SomeClass"]$. This is referencing the Windows Computer hosted instances in which you want to include in your group. Also notice SomeProperty and SomePattern – this is the property you will be comparing in your regular expression.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="YourMp.Class.YourComputerGroup" Abstract="false" Accessibility="Public" Base="SC!Microsoft.SystemCenter.ComputerGroup" Hosted="false" Singleton="true" />
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>
  <Monitoring>
    <Discoveries>
      <Discovery ID="YourMp.Discovery.YourComputerGroup" ConfirmDelivery="false" Enabled="true" Priority="Normal" Remotable="true" Target="YourMp.Class.YourComputerGroup">
        <Category>Discovery</Category>
        <DiscoveryTypes />
        <DataSource ID="DS1" TypeID="SC!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$MPElement[Name="YourMp.Class.YourComputerGroup"]$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule>
              <MonitoringClass>$MPElement[Name="Windows!Microsoft.Windows.Computer"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="SC!Microsoft.SystemCenter.ComputerGroupContainsComputer"]$</RelationshipClass>
              <Expression>
                <Contains>
                  <MonitoringClass>$MPElement[Name="SomeMp.Class.SomeClass"]$</MonitoringClass>
                  <Expression>
                    <RegExExpression>
                      <ValueExpression>
                        <Property>$MPElement[Name="SomeMp.Class.SomeClass"]/SomeProperty$</Property>
                      </ValueExpression>
                      <Operator>MatchesRegularExpression</Operator>
                      <Pattern>SomePattern</Pattern>
                    </RegExExpression>
                  </Expression>
                </Contains>
              </Expression>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>
    </Discoveries>
  </Monitoring>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="YourMp.Class.YourComputerGroup">
          <Name>Your Computer Group</Name>
          <Description>This group contains Windows Computer instances that host some class and matches some property of that class.</Description>
        </DisplayString>
        <DisplayString ElementID="YourMp.Discovery.YourComputerGroup">
          <Name>Your Group Discovery</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

Check out this other post about adding Health Service objects to a group.

Need help developing a management pack? Drop us a line

.

_

If you want unit monitors targeting the application component class to rollup health to its hosting class (local application), you can add a dependency monitor

I prefer to add dependency monitors to the fragment that contains the class in which I want to rollup. So, this fragment is a repeat of the application component class fragment posted earlier, which the exception of including the dependency monitor (highlighted).

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="SCOMskills.Demo.ApplicationComponent.Class" Abstract="false" Accessibility="Public" Base="Windows!Microsoft.Windows.ApplicationComponent" Hosted="true" Singleton="false">
          <Property ID="CsvField1" Key="false" Type="string"/>
          <Property ID="CsvField2" Key="false" Type="string"/>
        </ClassType>
      </ClassTypes>
      <RelationshipTypes>
        <RelationshipType ID="LocalApplicationHostsApplicationComponent" Base="System!System.Hosting" Accessibility="Public">
          <Source ID="LocalApplication" Type="SCOMskills.Demo.LocalApplication.Class"/>
          <Target ID="ApplicationComponent" Type="SCOMskills.Demo.ApplicationComponent.Class"/>
        </RelationshipType>
      </RelationshipTypes>
    </EntityTypes>
  </TypeDefinitions>
  <Monitoring>
    <Monitors>
      <DependencyMonitor ID="ApplicationComponentAvailabilityRollup" Accessibility="Internal" Enabled="true" MemberMonitor="Health!System.Health.AvailabilityState" ParentMonitorID="Health!System.Health.AvailabilityState" RelationshipType="LocalApplicationHostsApplicationComponent" Priority="Normal" Remotable="false" Target="SCOMskills.Demo.LocalApplication.Class">
        <Category>AvailabilityHealth</Category>
        <Algorithm>WorstOf</Algorithm>
      </DependencyMonitor>
    </Monitors>
  </Monitoring>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="SCOMskills.Demo.ApplicationComponent.Class">
          <Name>SCOMskills Application Component Class</Name>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.ApplicationComponent.Class" SubElementID="CsvField1">
          <Name>CSV Field 1</Name>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.ApplicationComponent.Class" SubElementID="CsvField2">
          <Name>CSV Field 2</Name>
        </DisplayString>
        <DisplayString ElementID="LocalApplicationHostsApplicationComponent">
          <Name>Local Application class hosts Application Component class</Name>
        </DisplayString>
        <DisplayString ElementID="ApplicationComponentAvailabilityRollup">
          <Name>Application Component Health</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

_

Module Type used in this post: Microsoft.Windows.2SingleEventLog2StateMonitorType

Scenario

Change state to critical and raise a critical alert when event Id 101, from  source TEST, and event level is Error is detected in the Application log. Resolve alert when same event is detected with event level Information.

A note about event level:

1 = Warning

2 = Error

4 = Information

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Monitoring>
    <Monitors>
      <UnitMonitor ID="SCOMskills.Demo.Event101.2State" Accessibility="Public" ConfirmDelivery="false" Enabled="true" ParentMonitorID="Health!System.Health.AvailabilityState" Priority="Normal" Remotable="false" Target="SCOMskills.Demo.ApplicationComponent.Class" TypeID="Windows!Microsoft.Windows.2SingleEventLog2StateMonitorType">
        <Category>AvailabilityHealth</Category>
        <AlertSettings AlertMessage="SCOMskills.Demo.Event101.2State.AlertMessage">
          <AlertOnState>Error</AlertOnState>
          <AutoResolve>true</AutoResolve>
          <AlertPriority>Normal</AlertPriority>
          <AlertSeverity>Error</AlertSeverity>
          <AlertParameters>
            <AlertParameter1>$Data/Context/EventDescription$</AlertParameter1>
          </AlertParameters>
        </AlertSettings>
        <OperationalStates>
          <OperationalState ID="Unhealthy" HealthState="Error" MonitorTypeStateID="FirstEventRaised"/>
          <OperationalState ID="Healthy" HealthState="Success" MonitorTypeStateID="SecondEventRaised"/>
        </OperationalStates>
        <Configuration>
          <FirstComputerName>$Target/Host/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</FirstComputerName>
          <FirstLogName>Application</FirstLogName>
          <FirstExpression>
            <And>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery>EventSourceName</XPathQuery>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>TEST</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery>EventDisplayNumber</XPathQuery>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>101</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery>EventLevel</XPathQuery>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>1</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
            </And>
          </FirstExpression>
          <SecondComputerName>$Target/Host/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</SecondComputerName>
          <SecondLogName>Application</SecondLogName>
          <SecondExpression>
            <And>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery>EventSourceName</XPathQuery>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>TEST</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery>EventDisplayNumber</XPathQuery>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>101</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery>EventLevel</XPathQuery>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>4</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
            </And>
          </SecondExpression>
        </Configuration>
      </UnitMonitor>
    </Monitors>
  </Monitoring>
  <Presentation>
    <StringResources>
      <StringResource ID="SCOMskills.Demo.Event101.2State.AlertMessage"/>
    </StringResources>
  </Presentation>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="SCOMskills.Demo.Event101.2State">
          <Name>Event 101 Monitor</Name>
          <Description>Detect event Id 101. Raise alert if error, resolve alert if informational.</Description>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.Event101.2State.AlertMessage">
          <Name>Detected Event Id 101</Name>
          <Description>{0}</Description>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.Event101.2State" SubElementID="Healthy">
          <Name>Healthy</Name>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.Event101.2State" SubElementID="Unhealthy">
          <Name>Unhealthy</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

_

Example of override parameters by implementing the built-in module type in your discovery

Zooming in on the script arguments, you can see this:

$MPElement$ $Target/Id$ $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$ c:\ScomSkillsDemo.csv

This isn’t very friendly to an operator that is setting a discovery override, and presents greater opportunity for override mistakes. The only parameter an operator might need to change is the CSV File Location.

So, how can this be improved from an operator perspective? One option is to create a new module type. If you have multiple parameters you want separated in the Operations console, this is probably the best option, as the built-in provider only allows for a single string of arguments.

This example is purely to offer a better experience for the operator creating overrides – there is really no difference in how instances will be discovered under the hood. The result will be new override parameters available in the Operations console.

Example of override parameters by implementing a custom discovery provider

What does this do?

This performs the same discovery as the previous fragment, but creates custom override parameters in the Operations console.

Fragment 1: Custom discovery module type

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <TypeDefinitions>
    <ModuleTypes>
      <DataSourceModuleType ID="SCOMskills.Demo.TimedScript.DiscoveryProvider.Custom" Accessibility="Public">
        <Configuration>
          <xsd:element minOccurs="1" name="Interval" type="xsd:integer" />
          <xsd:element minOccurs="1" name="CsvFileLocation" type="xsd:string" />
          <xsd:element minOccurs="1" name="PrincipalName" type="xsd:string" />
          <xsd:element minOccurs="1" name="Timeout" type="xsd:integer" />
        </Configuration>
        <OverrideableParameters>
          <OverrideableParameter ID="Interval" ParameterType="int" Selector="$Config/Interval$"/>
          <OverrideableParameter ID="CsvFileLocation" ParameterType="string" Selector="$Config/CsvFileLocation$"/>
          <OverrideableParameter ID="Timeout" ParameterType="int" Selector="$Config/Timeout$"/>
        </OverrideableParameters>
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <DataSource ID="Scheduler" TypeID="System!System.Scheduler">
                <Scheduler>
                  <SimpleReccuringSchedule>
                    <Interval>$Config/Interval$</Interval>
                  </SimpleReccuringSchedule>
                  <ExcludeDates />
                </Scheduler>
              </DataSource>
              <ProbeAction ID="Script" TypeID="Windows!Microsoft.Windows.ScriptDiscoveryProbe">
                <ScriptName>SCOMskills.Demo.Discovery.vbs</ScriptName>
                <Arguments>$MPElement$ $Target/Id$ $Config/PrincipalName$ $Config/CsvFileLocation$</Arguments>
                <ScriptBody>
                  <![CDATA[
Option Explicit

Dim oArgs
Set oArgs = WScript.Arguments
if oArgs.Count < 4 Then
   Wscript.Quit -1
End If

Dim SourceID, ManagedEntityId, TargetComputer, SourceFile

SourceId = oArgs(0)
ManagedEntityId = oArgs(1)
TargetComputer = oArgs(2)
SourceFile = oArgs(3)

Dim oAPI, oDiscoveryData, oInst
Set oAPI = CreateObject("MOM.ScriptAPI")
set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

Dim oFso, oFile, aField
Set oFso = CreateObject("Scripting.FileSystemObject")

If (oFso.FileExists(SourceFile)) Then
Set oFile = oFso.OpenTextFile(SourceFile)
aField = split(oFile.ReadLine,",")

set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='SCOMskills.Demo.ApplicationComponent.Class']$")
call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)
call oInst.AddProperty("$MPElement[Name='SCOMskills.Demo.ApplicationComponent.Class']/CsvField1$", aField(0))
call oInst.AddProperty("$MPElement[Name='SCOMskills.Demo.ApplicationComponent.Class']/CsvField2$", aField(1))
call oInst.AddProperty("$MPElement[Name='System!System.Entity']/DisplayName$", TargetComputer)
call oDiscoveryData.AddInstance(oInst)

Else

Wscript.Quit -1

End If

Call oAPI.Return(oDiscoveryData) 
                ]]>
                </ScriptBody>
                <TimeoutSeconds>$Config/Timeout$</TimeoutSeconds>
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="Script">
                <Node ID="Scheduler" />
              </Node>
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.Discovery.Data</OutputType>
      </DataSourceModuleType>
    </ModuleTypes>
  </TypeDefinitions>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="SCOMskills.Demo.TimedScript.DiscoveryProvider.Custom">
          <Name>SCOMskills Custom Timed Script Discovery</Name>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.TimedScript.DiscoveryProvider.Custom" SubElementID="CsvFileLocation">
          <Name>CSV File Location</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

Fragment 2: Implementing the custom discovery module

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Monitoring>
    <Discoveries>
      <Discovery ID="SCOMskills.Demo.TimedScript.Custom.Discovery" ConfirmDelivery="false" Enabled="true" Priority="Normal" Remotable="true" Target="SCOMskills.Demo.LocalApplication.Class">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryClass TypeID="SCOMskills.Demo.ApplicationComponent.Class">
            <Property TypeID="SCOMskills.Demo.ApplicationComponent.Class" PropertyID="CsvField1"/>
            <Property TypeID="SCOMskills.Demo.ApplicationComponent.Class" PropertyID="CsvField2"/>
            <Property TypeID="System!System.Entity" PropertyID="DisplayName"/>
          </DiscoveryClass>
        </DiscoveryTypes>
        <DataSource ID="DS" TypeID="SCOMskills.Demo.TimedScript.DiscoveryProvider.Custom">
          <Interval>60</Interval>
          <CsvFileLocation>c:\ScomSkillsDemo.csv</CsvFileLocation>
          <PrincipalName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</PrincipalName>
          <Timeout>60</Timeout>
        </DataSource>
      </Discovery>
    </Discoveries>
  </Monitoring>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="SCOMskills.Demo.TimedScript.Custom.Discovery">
          <Name>SCOMskills Timed Script Custom Discovery</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

_

Fixing this wasn’t officially a part of the disk monitoring project I was tasked with, but just knowing the fact it didn’t utilize cookdown was enough to compel me to rewrite the entire workflow. After I fixed the cookdown problem and finished other additions to the disk space monitor, I was going to post a management pack here with an updated logical disk free space monitor…until I stumbled across a blog entry Kevin Holman posted over a year ago.

I’m not sure if Kevin realized at the time that his addendum MP fixed the cookdown problem, but it does. Head over to his blog to download the addendum MP, especially if your company uses a lot of instance level disk space overrides.

For those that need a refresher on cookdown, this is a programming technique that (if implemented properly) will execute only one instance of a script data source even if there are multiple monitoring instances that consume the output. The key to cookdown is passing no (or only necessary) configuration elements into the script execution, and processing instance and state filtering after script execution by using expression filters.

If the script expects configuration input, and the monitor configuration is changed by an override, the script will need to run once for each instance override. In the case of the logical disk free space monitor, this leaves a huge door of opportunity to run multiple copies of the data source script, and this will lead to resource consumption on the monitored computer.

The built-in logical disk free space data source module (cookdown broken with overrides)

<DataSourceModuleType ID="Microsoft.Windows.Server.2008.FreeSpace.Moduletype" Accessibility="Internal" Batching="false">
  <Configuration>
    <xsd:element minOccurs="1" name="ComputerName" type="xsd:string" />
    <xsd:element minOccurs="1" name="DiskLabel" type="xsd:string" />
    <xsd:element minOccurs="1" name="IntervalSeconds" type="xsd:integer" />
    <xsd:element minOccurs="1" name="SystemDriveWarningMBytesThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="SystemDriveWarningPercentThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="SystemDriveErrorMBytesThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="SystemDriveErrorPercentThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="NonSystemDriveWarningMBytesThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="NonSystemDriveWarningPercentThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="NonSystemDriveErrorMBytesThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="NonSystemDriveErrorPercentThreshold" type="xsd:double" />
  </Configuration>
  <OverrideableParameters>
    <OverrideableParameter ID="Interval" Selector="$Config/IntervalSeconds$" ParameterType="int" />
    <OverrideableParameter ID="SystemDriveWarningMBytesThreshold" Selector="$Config/SystemDriveWarningMBytesThreshold$" ParameterType="double" />
    <OverrideableParameter ID="SystemDriveWarningPercentThreshold" Selector="$Config/SystemDriveWarningPercentThreshold$" ParameterType="double" />
    <OverrideableParameter ID="SystemDriveErrorMBytesThreshold" Selector="$Config/SystemDriveErrorMBytesThreshold$" ParameterType="double" />
    <OverrideableParameter ID="SystemDriveErrorPercentThreshold" Selector="$Config/SystemDriveErrorPercentThreshold$" ParameterType="double" />
    <OverrideableParameter ID="NonSystemDriveWarningMBytesThreshold" Selector="$Config/NonSystemDriveWarningMBytesThreshold$" ParameterType="double" />
    <OverrideableParameter ID="NonSystemDriveWarningPercentThreshold" Selector="$Config/NonSystemDriveWarningPercentThreshold$" ParameterType="double" />
    <OverrideableParameter ID="NonSystemDriveErrorMBytesThreshold" Selector="$Config/NonSystemDriveErrorMBytesThreshold$" ParameterType="double" />
    <OverrideableParameter ID="NonSystemDriveErrorPercentThreshold" Selector="$Config/NonSystemDriveErrorPercentThreshold$" ParameterType="double" />
  </OverrideableParameters>

The proper way to implement a script data source to utilize cookdown (configuration and state filtering should happen at the monitor type, not the data source module)

<DataSourceModuleType ID="Microsoft.Windows.Server.2008.Monitoring.Addendum.FreeSpace.ModuleType" Accessibility="Internal" Batching="false">
  <Configuration>
    <xsd:element minOccurs="1" name="IntervalSeconds" type="xsd:int" />
    <xsd:element minOccurs="1" name="TargetComputerName" type="xsd:string" />
  </Configuration>

I wonder if Microsoft will plan to fix this in the future. Good thing these modules are flagged internal, so it shouldn’t be much to ask and an update wouldn’t break upgrade compatibility for customers.

This post applies to Windows MP versions 6.0.6958 – 6.0.6989.0.

_

The examples below can be reproduced with OpsMgr 2012 SP1 by opening Health Explorer for the Windows Computer object.

Example 1

Two unhealthy instances; one critical and the other warning.

Health Explorer default behavior

Instance in warning state isn’t listed with the filter applied.

Remove the unhealthy filter

Instance in warning state is listed when filter is removed (as expected).

Example 2

Two unhealthy instances; both critical.

Health Explorer default behavior

Both critical instances are listed.

.

Remove the unhealthy filter

Both critical instances are listed (as expected).

Example 2

Two unhealthy instances; both warning.

Health Explorer default behavior

Both warning instances are listed. Also notice that HEALTHY instances of the SAME TYPE are also listed.

Remove the unhealthy filter

Both warning instances are listed, as well as everything else (as expected).

The main takeaway with this post is to beware of the default behavior in Health Explorer – it might only show you half the truth. I’m not sure if I’d go as far as lodging a bug or calling into Microsoft support services for this, but I certainly didn’t’ expect this behavior with the filtering option.

I hope the community receives this book well, and that this edition lives up to its reputation! Thanks to Kerrie Meyler, Cameron Fuller, and John Joyner for doing such a great job in supporting the contributors and to keep things moving along.

Error      80           Namespace prefix 'maml' is not defined

It’s a very easy fix. Simply add the highlighted below to the management pack fragment and build away.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:maml="http://schemas.microsoft.com/maml/2004/10">