SCOM Alert Management Pack: Alert Ownership

This is the second of four articles discussing the features and capabilities of the SCOM Alert Management Pack. In this article, we’ll cover how to automatically set the value of the “Owner” field in Operations Manager alerts using the Alert Management Pack.

Introduction

By default, the “Owner” field for each OpsMgr alert is left blank. Using the Console, administrators can assign ownership to an individual or team. The field is free text: any value can be entered.

Alert Properties view showing an empy Owner field and Resolution State New.
Figure 1. By default, Operations Manager does not use the Owner field.

Alert Ownership

Why assign an “owner” to each alert? There many reasons why you might want to assign an alert Owner, chief among these is accountability. If you’ve been around OpsMgr long enough, you’re familiar with the “Alerts” view which lists out every open alert in the system. Who owns these alerts? What needs to be done with them?

The main "Active Alerts" view in Operations Manager showing many alerts from different management packs.  Ownership of the alerts is not clear.
Figure 2: Lots of alerts! But who owns them?

Most management packs have their own Alert Views which are specific to object classes defined within that pack. However, this can quickly become cumbersome to dig through dozens or hundreds of nested folders searching for the right Alert View.

Folder view in the SCOM Navigation pane showing many individual management packs.  Each of these folders may contain one or more Alert Views.
Figure 3: Each of these folders may have one or more Alert views

In addition, companies organize their IT teams differently and assign different areas of responsibility to each team. For example, at Company A, the Windows Team may also be responsible for Active Directory and DNS, but in Company B these technologies might be managed by different teams.

OpsMgr is deliberately engineered to allow for these different organizational complexities, but implementation is left up to individual customers.

The SCOM Alert Management Pack

With the SCOM Alert Management Pack, we assign alert ownership primarily based on the Management Pack that generated the alert. We use a customizable configuration file that allows OpsMgr admins to adjust alert assignment based on how their teams are organized. We allow you to define exceptions, so that you can make assignments more granular based on the properties of the alert. For example, we can differentiate ownership based on a substring of the full name for the monitoring object associated with the alert.

Now, with the Alert Owner field populated, we can create a custom view for the “Windows Team” that includes any alert where the Owner field equals “Windows Team”. This can include all the alerts from the basic Windows Management Packs, plus alerts from the Cluster Management Pack, the DNS Management Pack and others that you can choose. If you have created custom management packs with alerts that are specific to your Windows team, you can include those alerts as well. This allows you to put all the alerts for your Windows Team in one view and you don’t have to create a single group.

Getting Started

STOP!!!!!

  1. WARNING! If you have subscriptions that are tied to the “New” Alert Resolution State, you will want to pause before you enable the Assign SCOM Alerts rule. When we populate the Owner field in an alert, we update the Resolution State to “Assigned” (in our default configuration, this is Resolution State 5). If your notifications are tied to alerts being in “New” Resolution State, it *may* break your subscriptions. At a minimum, the Owner field of an alert will not yet be populated until the Alert is in the Assigned Resolution State.
  2. WARNING! If you have already implemented custom resolution states, be aware that by default, we use the following custom Resolution States:
    1. Resolution State 5 (Assigned)
    2. Resolution State 15 (Verified)
    3. Resolution State 18 (Alert Storm)

Installation

Download the Alert Management MP: https://github.com/hmscott4/AlertManagement .
Detailed installation instructions: Install Management Pack ยท hmscott4/AlertManagement Wiki (github.com)

A basic overview of the steps:

  1. Import the Management Pack
  2. Add custom resolution states
  3. Deploy the Configuration Files
    1. Edit Ownership Assignments to suit your environment
    2. Enable/Disable Ownership Assignments as needed
  4. Enable the “Assign SCOM Alerts” rule

Configuration Files

We generate two Configuration Files as part of the Management Pack. The default configuration files are meant to serve as a “starting point”. You may edit them as needed to suit your operational requirements.

IMPORTANT: The configuration files should be stored on a file share that is accessible to all the management servers in your Management Group.

IMPORTANT: When we generate the default assign.alert.config file, we iterate through all the management packs in your Management Group and make an educated guess as to the default owner. However:

  1. It’s likely that you will need to review alerts in the “Unassigned” assignment rule. These are likely to be custom management packs that we didn’t know what to do with.
  2. If you add new management packs to your Management Group, you will have to create the associations yourself.

Let’s have a closer look at the “assign.alert.config” file. The XML is broken down into two primary regions: “exceptions” and “assignments“. Think of assignments as being the “default” behavior. Exceptions are just that: exceptions to the defaults.

<exceptions>
     <exception ID="1" Name="Server Offline" Owner="EFG Windows Team" enabled="true">
        <Alert Name="Health Service Heartbeat Failure" > 
           <AlertProperty>MonitoringObjectDisplayName</AlertProperty>
           <AlertPropertyMatches>efg.lcl</AlertPropertyMatches>
        </Alert>
     </exception> 
     <exception ID="2" Name="Server Offline" Owner="Windows Team" enabled="true">
        <Alert Name="Health Service Heartbeat Failure" /> 
     </exception> 
     <exception ID="3" Name="Windows Server EFG" Owner="EFG Windows Team" enabled="true">
        <ManagementPack Name="Microsoft.Windows.Server.2016.Monitoring" /> 
           <AlertProperty>MonitoringObjectFullName</AlertProperty>
           <AlertPropertyMatches>efg.lcl</AlertPropertyMatches>
     </exception> 
 </exceptions>
 <assignments>
     <assignment ID="1" Name="Windows" Owner="Windows Team" enabled="true">
       <ManagementPack Name="Microsoft.Windows.Server.2016.Monitoring" />
       <ManagementPack Name="Microsoft.Windows.Server.2012.Monitoring" />
       <ManagementPack Name="Microsoft.Windows.Server.2012.R2.Monitoring" />
     </assignment>
     <assignment ID="2" Name="Monitoring" Owner="Monitoring Team" enabled="true">
       <ManagementPack Name="Microsoft.SystemCenter.2007" />
     </assignment>
 </assignments>

First things first:

  1. Exceptions that have an AlertProperty filter always get processed first
  2. Exceptions that do not have an AlertProperty filter get processed next.
  3. Assignments are always processed after exceptions
  4. Each rule (exception or assignment) may be enabled or disabled by changing the “enabled” attribute

Ownership Assignment Process

When the “Assign SCOM Alerts” rule runs, we do the following:

We evaluate each open alert where the Owner field is blank or “Unassigned”. We then match it to an exception or an assignment in the configuration file. We then update the alert Owner and set the resolution state to “Assigned”. Once a match is found, we’re done with that alert.

If we are unable to find a match, then the Owner will be updated to “Unassigned“. We always check for open “Unassigned” alerts during the “Assign SCOM Alerts” phase. So, if you update the configuration file, we’ll update the ownership assignment for matching “Unassigned” alerts.

Interpretation

Using the example above, alerts are evaluated using the following rules (in order):

  1. Exception ID 1 assigns any alert with the Name “Health Service Heartbeat Failure” AND where the MonitoringObjectDisplayName matches “efg.lcl” to the “EFG Windows Team”.
  2. Exception ID 2 assigns any other alert with the Name “Health Service Heartbeat Failure” to the “Windows Team” (meaning “Health Service Heartbeat Failure” alerts where the MonitoringObjectDisplayName does not match “efg.lcl”.
  3. Exception ID 3 assigns any alert from the Windows Server 2016 Management Pack AND where the MonitoringObjectFullName matches “efg.lcl” to the “EFG Windows Team”.
  4. Assignment ID 1 assigns any alert generated by the Windows Server Management Packs (and which do NOT match “efg.lcl”) to the “Windows Team”.
  5. Assignment ID 2 assigns any alert generated by the Microsoft.SystemCenter.2007 to the “Monitoring Team”

Enable Ownership Assignment

By default, the “Assign SCOM Alerts” rule is disabled. To enable the rule, use an override:

Figure 4: Create an Override to Enable the “Assign SCOM Alerts Rule”

There are two overrides that are required:

  1. Configuration File: this is the fully qualified UNC path to the assign.alert.config file. Remember to put it on a file share accessible to all Management Servers.
  2. Enabled: set to true

Optionally, you can also set the following Overrides:

  1. Assigned Resolution State: String value; if you don’t want to impact your current subscriptions, you could set a value of “New”
  2. Unassigned Resolution State: String value; if you want to use an alternate Resolution State for alerts that can’t be matched in the configuration file, enter it here. Note: you must create this Resolution State yourself.
  3. Debug Logging: If you are having issues (or you just want to see what’s going on underneath the covers), enable Debug Logging. Log entries will appear in the Operations Manager Event log. Search for Event Id 9931.

Results

In my lab environment, I have three separate domains “administered” by two independent teams:

  1. Exception 1 ensures that “Health Service Heartbeat” alerts get assigned to the “EFG Windows Team
  2. Exception 2 ensures that remaining “Health Service Heartbeat” alerts get assigned to the main “Windows Team“. These are alerts generated in the Microsoft.SystemCenter.2007 Management Pack, which we otherwise would target to the “Monitoring Team“).
  3. Exception 3 ensures that alerts generated by Windows Servers in the efg.lcl domain get assigned to the “EFG Windows Team“.
  4. Assignment 1 assigns other Windows alerts to the main “Windows Team
  5. Assignment 2 assigns alerts associated with the Operations Manager Infrastructure to the “Monitoring Team”.

What does this look like in OpsMgr? I have shut off four servers in my lab: 3 from my primary (“ABCD”) domain, and 1 from my secondary (“EFG”) domain.

When the alerts first show up, they look just as the always do:

Lab results: Four alerts with Resolution State "New" and no "Owner" assigned.
Figure 3: New Alerts. Note that we haven’t assigned an Owner yet

After a couple of minutes, the Management Pack gets the new alerts, updates the Owner field and sets the Resolution State to “Assigned“:

Lab results: Four alerts with Resolution State "Assigned" and the Owner field updated according to the configuration file rules.
Figure 4: Alerts with Owner Assigned and Resolution State Updated

Note: By default, the Owner field is not displayed in the main “Alerts” view. You can add it to the display by right-clicking the title bar and selecting “Personalize View…“. Then, click on the check-box next to the “Owner” field. While you’re at it, consider checking the fields “Last Modified” and “Repeat Count“.

By double-clicking on the alert, we can see the Owner field and the Resolution State:

Detailed Alert Properties view showing the Owner field populated with the value "Windows Team" and the Resolution State set to "Assigned".
Figure 5: Alert Owner Updated and Resolution State set to “Assigned”

Internally, if you look at the History tab in the Alert, you’ll see what was done. We add a comment that indicates:

  1. The value to which the Owner field was updated;
  2. the specific entry from the configuration file which was used in the assignment process

The History tab looks like:

Alert History tab (in the Alert Properties) showing assignment of the alert and the configuration rule used in the assignment process.
Figure 6: Alert History

Now, if I’m a member of the EFG Windows Team, I can create a custom Alert view and display all the alerts that have been assigned to the “EFG Windows Team”. It doesn’t matter which Management Pack generated the alert, I can filter just those alerts that have been Assigned to the EFG Windows Team.

Creating a custom Alert View in "My Workspace" showing open alerts where the "Owner" field is equal to "EFG Windows Team"
Figure 7: Create a Custom View for Open Alerts Assigned to “EFG Windows Team”

After saving this new view, I can open it and see all the Open alerts that have been assigned to the EFG Windows Team. Note that I snuck in a couple of additional alerts. These were generated by the Windows Server 2016 Management Pack and were assigned to the EFG Windows Team because the Monitoring Object Full Name matches the text “efg.lcl”. This action was performed by Exception ID 3.

Results of the Custom Alert view showing the "Health Service Heartbeat Failure" alert generated as part of the test, plus two other alerts assigned to the EFG Windows Team.
Figure 8: The new Custom View Showing Alerts for the EFG Windows Team

Benefits

Now, instead of having to search all over the OpsMgr console to find the alerts that apply to my team, I can find all of my alerts in one place. I don’t have to create a lot of complex Dynamic Groups to ensure that my support teams only see the alerts that they “own”.

We can also leverage the alert Owner field when generating incidents for a Service Desk application. We can map the Owner field to a specific queue within the Service Desk application. This helps ensure that alerts get routed to the correct team immediately.

Finally, with PowerShell, we can generate reports with the number of open alerts by Owner. This can help drive greater accountability into our monitoring solution.

Here’s a quick one-liner in PowerShell to show the count of open alerts by Owner:

Get-SCOMAlert -Criteria "ResolutionState < 255" | Group-Object Owner

And the results:

Figure 9: Summarizing Open Alerts by Owner

Acknowledgements

There are a lot of people who have helped make this management pack a reality. It would be impossible to thank all of them, but I would like to specifically acknowledge:

  • Dan Reist
  • Shane Hutchens
  • Tyson Paul

2 Replies to “SCOM Alert Management Pack: Alert Ownership”

  1. Can this be modified to use Windows Computer_Extended to assign the Owner or even from a dynamic group that is created off of this Windows Computer_extended attribute?

    1. Hi Joe,

      The short answer is absolutely. The long answer (as in many cases with SCOM) is that it’s not as easy as we’d like it to be.

      We’ll specifically focus on the Alert Escalation configuration file (as opposed to Ownership assignment).

      In the alert escalation configuration file we have the element “PostPipelineFilter”. There’s a LOT you can do with this.

      In the following example, we’ll take an alert and update it to ResolutionState 5 and update CustomField1 to the value of the ‘Environment’ property from the Windows Computer Extended class:


      # in this snippet/example assume the pipeline variable ( $_ ) is already populated with the alert object.
      $alert = $_
      $fqdn = $null
      $managementGroup = Get-SCOMManagementGroup

      if ( -not [System.String]::IsNullOrEmpty($alert.PrincipalName) )
      {
      $fqdn = $alert.PrincipalName
      }
      else
      {
      $fqdn = Get-SCOMClassInstance -Id $alert.MonitoringObjectId |
      Foreach-Object -Process { $_.GetMonitoringRelationshipObjectsWhereTarget() } |
      Where-Object -FilterScript { $_.SourceMonitoringObject.Fullname -match 'Microsoft\.SystemCenter\.HealthService' } |
      Select-Object -ExpandProperty SourceMonitoringObject -Unique
      }

      if ( [System.String]::IsNullOrEmpty($fqdn) )
      {
      # This appears to be a special case for the Database Mirroring management pack
      $object = Get-SCOMClassInstance -Id $alert.MonitoringObjectId
      $machineNameProperty = $object | Get-Member -Name *MachineName | Select-Object -ExpandProperty Name
      if ( -not [System.String]::IsNullOrEmpty($machineNameProperty) )
      {
      $fqdn = $object.$machineNameProperty.Value
      }
      }

      if ( [System.String]::IsNullOrEmpty($fqdn) )
      {
      # Get the root management server as a catch-all
      $fqdn = Get-SCOMClass -Name Microsoft.SystemCenter.RootManagementServer | Get-SCOMClassInstance | Select-Object -ExpandProperty DisplayName
      }

      # This is faster than using Get-SCOMClass and Get-SCOMClassInstance
      $criteria = [Microsoft.EnterpriseManagement.Monitoring.MonitoringObjectGenericCriteria]::new("FullName = 'Microsoft.Windows.Computer:$fqdn'")
      $windowsClassInstance = $managementGroup.GetMonitoringObjects($criteria)
      $environment = $windowsClassInstance.Values | Where-Object -FilterScript { $_.Type.DisplayName -eq 'Environment' } | Select-Object -ExpandProperty Value

      # Set the environment to CustomField1
      if ( $alert.CustomField1 -ne $environment )
      {
      $alert | Set-SCOMAlert -CustomField1 $environment -Comment "Alert updated by the alert automation: Set CustomField1"
      }

      In your case, you might choose to set the Owner property based on the ‘Environment’, or you could change the ResolutionState of the alert. It’s very flexible.

      Always test your code before making changes to the configuration file.

      HTH,

      Hugh

      Some additional notes:
      1. It’s hard for me to post xml in comments, so I’ll post a version of the entire section below (without xml tags)
      2. If you don’t have ‘Environment’ in your Windows Extended Class, you would substitute for whatever property you are using.

      Elements in the rule:
      rule: (name=”Set Alert CustomField1 to Environment” enabled=”true”)
      Category: “”
      Description: “Set Alert CustomField1 to Environment”
      Criteria: “ResolutionState=5”
      NewResolutionState: 5
      PostPipelineFilter: (see code above)
      Comment: “Alert updated by the alert automation: Set CustomField1”

Leave a Reply

Your email address will not be published. Required fields are marked *