Monthly Archives: November 2016

SCOM Events Dashboard

Dashboard visualization for Operations Manager does not include an Event Widget. But this does not mean that displaying events in a dashboard is off-limits.

My suggested usage example makes use of Powershell Grid Widget with Filter (https://gallery.technet.microsoft.com/Powershell-Grid-Widget-919dc3d6).

I would design the Events dashboard as a 2 cell grid layout: the above cell called Event Collection Rule and the one below just Events. Both cells will use the Powershell Grid Widget with Filter template.

And here are the scripts that I would use to configure them.

Event Collection Rule cell:

$rules = Get-SCOMRule | Where {$_.Category -eq "EventCollection"}
foreach ($rule in $rules)
{
    $dataObject = $ScriptContext.CreateInstance("xsd://rules")
    $dataObject["Id"]=$rule.Id.Guid.ToString()
    $dataObject["RuleName"]=$rule.Name
    $dataObject["RuleDisplayName"]=$rule.DisplayName
    $ScriptContext.ReturnCollection.Add($dataObject)
}

Events cell:

Param($globalSelectedItems)
foreach ($globalSelectedItem in $globalSelectedItems)
{
    $rule = Get-SCOMRule -Id $globalSelectedItem["Id"]
    $events = Get-SCOMEvent -rule $rule
    foreach ($event in $events) {
                $dataObject = $ScriptContext.CreateInstance("xsd://events")
                $dataObject["Id"]=[string]$event.Id.Guid
                $dataObject["TimeAdded"]=[string]$event.TimeAdded
                $dataObject["LoggingComputer"]=[string]$event.LoggingComputer
                $dataObject["Description"]=[string]$event.Description
                $ScriptContext.ReturnCollection.Add($dataObject)
     }
}

The end result is an easy searchable grid for rules that classify as EventCollection category, and the corresponding events collected by the selected rule. Note that even multiple rules selection will work.

Events can also be filtered, just make sure that you click on one of the columns of the grid first.

Advertisements

Script Generated Event Collection – the proper way to use

I want to share my experience on using the Microsoft.Windows.TimedScript.EventProvider data source module type (https://msdn.microsoft.com/en-us/library/jj130481.aspx).

I will suggest here a simplification of the sample provided in the online documentation, just to quickly illustrate the symptom.

Here is the code for a rule that should start collecting script generated events capturing in the Description the current date and time.

<Rule ID="TestingScriptGeneratedEventCollection" Enabled="true" Target="SC!Microsoft.SystemCenter.RootManagementServer" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>EventCollection</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.EventProvider">
            <IntervalSeconds>300</IntervalSeconds>
            <SyncTime />
            <ScriptName>TestingScriptGeneratedEventCollection.vbs</ScriptName>
            <Arguments />
            <ScriptBody>
              <![CDATA[ Dim oAPI, oBag Set oAPI = CreateObject("MOM.ScriptAPI") Set oBag = oAPI.CreatePropertyBag() Call oBag.AddValue("Description",CStr(Now())) Call oAPI.Return(oBag) ]]>
            </ScriptBody>
            <TimeoutSeconds>10</TimeoutSeconds>
            <EventOriginId>$MPElement$</EventOriginId>
            <PublisherId>$MPElement$</PublisherId>
            <PublisherName>TimedScript.EventProvider</PublisherName>
            <Channel></Channel>
            <LoggingComputer>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</LoggingComputer>
            <EventNumber>1001</EventNumber>
            <EventCategory>1</EventCategory>
            <EventLevel>2</EventLevel>
            <UserName />
            <Description>$Data/Property[@Name="Description"]$</Description>
            <Params></Params>
          </DataSource>
        </DataSources>
        <WriteActions>
          <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
          <!--<WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishEventData" />-->
        </WriteActions>
</Rule>

As you can see the Description property bag value goes directly into Description of the Event.

The result of this configuration is weird: either using an Event View in the OpsMgr console or by querying events using OM PowerShell you will notice that all the events have same description, despite the fact that Event Data is correct.

More precisely the Description will be the value for the last execution, updated for all events!

ev1

So here is the proper way to use this module:

<Rule ID="TestingScriptGeneratedEventCollection" Enabled="true" Target="SC!Microsoft.SystemCenter.RootManagementServer" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>EventCollection</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.EventProvider">
            <IntervalSeconds>300</IntervalSeconds>
            <SyncTime />
            <ScriptName>TestingScriptGeneratedEventCollection.vbs</ScriptName>
            <Arguments />
            <ScriptBody>
              <![CDATA[ Dim oAPI, oBag Set oAPI = CreateObject("MOM.ScriptAPI") Set oBag = oAPI.CreatePropertyBag() Call oBag.AddValue("Description",CStr(Now())) Call oAPI.Return(oBag) ]]>
            </ScriptBody>
            <TimeoutSeconds>10</TimeoutSeconds>
            <EventOriginId>$MPElement$</EventOriginId>
            <PublisherId>$MPElement$</PublisherId>
            <PublisherName>TimedScript.EventProvider</PublisherName>
            <Channel></Channel>
            <LoggingComputer>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</LoggingComputer>
            <EventNumber>1001</EventNumber>
            <EventCategory>1</EventCategory>
            <EventLevel>2</EventLevel>
            <UserName />
            <Description>%1</Description>
            <Params>
              <Param>$Data/Property[@Name="Description"]$</Param>
            </Params>
          </DataSource>
        </DataSources>
        <WriteActions>
          <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
          <WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishEventData" />
        </WriteActions>
</Rule>

Please note making use of Parameters and then inserting Param into Description.

With the changes above everything looks back to normal.

ev2

The State View vs State Widget

SCOM Widgets are in almost all situations equivalent to or superior to the corresponding Views. State Widget falls in the category that justifies the almost exception.

Here it is why I continue to use State Views:
– Superior group filtering (more details on this below)
– Contextual Maintenance Mode
– Ability to perform Copy & Paste data from the view
In favor of the State Widget I can only mark the fact that it is faster.

Whenever I need to show/report inventory of a specific class, my preferred method is to use a State View. Of course such task can be performed in OM PowerShell, but creating a State View it’s easy and graphical. The experience is similar to SQL Query Designer. And the best part of it is that allows you to apply an umbrella group filter (group members hosting or containing the class of interest).

Here is a use case example that will show why State View continues to be one of my favorites: show me all the instances of SQL Server 2008 Reporting Services installed on Windows Server 2012 R2 servers; and I’d like to know the following properties: Version, Service Pack Version and Install Path.

Here is what needs to be configured:

state1

Please note the highlighted: Show data related to: _ Show data contained in a specific group: _ (that is precisely what I am looking for).

And screen below for selecting only the class properties of interest.

state2

The results are Copy & Paste exportable (Ctrl+A, Ctrl+C, Ctrl+V).

state3

And I did not care to use in this example further, graphical filtering on properties matching some criteria, definitely useful.

The corresponding State Widget configuration looks somewhat similar:

state4

Please note the highlighted: Select a class to scope the members of the specified groups – far from what I need and questionably useful.

Indeed, with such configuration the widget does not provide any results. And no matter what else you would try to configure for the widget (I tried not only the UI, but also using Component Overrides in MP XML), you cannot get the results the State View is providing.
It might be because of the way Microsoft.SystemCenter.Visualization.GetManagedEntitiesDataSource is implemented, the fact that RecursionTypeNames is set to System.Library!System.Group (I am still researching this).

I will therefore conclude that, to my taste at least, the View implemented in the Microsoft.Mom.Ui.Components assembly is better than the State Widget.