Work with alerts in System Center Operations Manager using your connector

The article is intended for people familiar with the System Center Operations Manager product.

Terminology:
SCOM - instead of the full name;
Alert is the same as alert. There is simply no good analogue in Russian.

Introduction

In SCOM, unlike many other monitoring systems, an alert is an independent object. Depending on the settings, the test may already be green, but the alert will remain active. Alerts are used and processed:

• operator (man)
• standard connectors (for example, Command Channel)
• external connectors (for example, a connector for synchronization with the Service Desk system)

The presence of the Command Channel already provides ample opportunities for working with alerts, but this approach is, firstly, not very beautiful, and secondly, not the best in performance. Therefore, let's create our own external connector, which sends letters to the alarms that have occurred. Yes, there is a standard for this, however, in the course of the narration it will become clear that the functionality of our connector is practically unlimited. For the impatient: the whole script lies here .
')
To create a connector, we use Powershell. Because:

• it is simpler than C #
• such a script is easier to maintain / modify

SCOM SDK libraries will also be used. Usually they are located in C: \ Program Files \ Microsoft System Center 2012 R2 \ Operations Manager \ Server \ SDK Binaries on any SCOM server.

Connector installation

First of all, you need to create an external connector, for this we also use the script . I will not analyze it in detail, since we will use the same objects in the main script. Main part in it:

$connectorGuid = New-Object Guid("{6A1F8C0E-B8F1-4147-8C9B-5A2F98F10007}"); if ($action -eq "InstallConnector") { #   SCOM $mg = New-Object Microsoft.EnterpriseManagement.ManagementGroup($ManagementServer); $icfm = $mg.ConnectorFramework; $info = New-Object Microsoft.EnterpriseManagement.ConnectorFramework.ConnectorInfo; $info.Description = "..."; $info.DisplayName = $ConnectorName; $info.Name = $ConnectorName; $connector = $icfm.Setup($info, $connectorGuid); $connector.Initialize(); } 

GUID choose arbitrary, the main thing is to use the same connector in the main script. By the way, using the link script, you can delete the connector.

Important. After creation, the connector will be available in the graphical console SCOM. There you can set up a subscription to alerts - the procedure is almost the same as for standard connectors. If you do not do this, no alerts will be sent to your connector.

Connector logic

Let's do the main script. Let's start with defining the configuration parameters:

 #      ,       $ScriptPath = $MyInvocation.MyCommand.Path -replace $MyInvocation.MyCommand.Name; #      SCOM $ManagementServer = "scom.contoso.com"; # GUID  ,     $strGuid = "{6A1F8C0E-B8F1-4147-8C9B-5A2F98F10007}"; # email    $emailTo = 'azat.khadiev@contoso.com'; $emailFrom = 'scom@contoso.com'; # smtp server  $Smtp = 'mail.contoso.com'; 

Change email addresses and server addresses according to the infrastructure of your organization.

 #   SDK,          $DLLs = ("Microsoft.EnterpriseManagement.Core.dll","Microsoft.EnterpriseManagement.OperationsManager.dll","Microsoft.EnterpriseManagement.Runtime.dll"); foreach ($lib in $DLLs) { [Reflection.Assembly]::LoadFile($ScriptPath + $lib) | Out-Null } 

With the help of these libraries we will be able to create objects of the SCOM system, thereby working with it. Further:

 try { #    $mg = New-Object Microsoft.EnterpriseManagement.ManagementGroup($ManagementServer); $icfm = $mg.ConnectorFramework; $connectorGuid = New-Object Guid($strGuid); $connector = $icfm.GetConnector($connectorGuid); #     $alerts = $connector.GetMonitoringAlerts(); } catch { Write-Host $_.Exception.Message.ToString(); exit 2; } #     $connector.AcknowledgeMonitoringAlerts($alerts); 

Marked this way with an alert will not get into our connector until it is modified - this is either a change of status or an attribute change. Further:

 foreach ($alert in $alerts) { try { #     ,   ,   $alertContext = [xml]$alert.Context; $alertResolutionStateName = @{0="New";255="Closed"}; #     xml,    XPATH $monitorClass = $alertContext.SelectNodes("//Property[@Name='__CLASS']/text()").Value; $subject = "This is an alert message from SCOM"; $emailBody = "`n" + $alertResolutionStateName[[int]$alert.ResolutionState] + "`n" + $alert.MonitoringObjectFullName + "`n" + $alert.TimeRaised + "`n" + $monitorClass; #    Send-MailMessage -SmtpServer $Smtp -Subject $subject -From $emailFrom -To $emailTo -Body $emailBody #     #$alert.CustomField1 = "Notification sent."; #$alert.Update(); } catch { Write-Host $_.Exception.Message.ToString(); } } 

Thus, we sent a message on each of the alert to the SCOM. Not impressive, right? However, pay attention to the last 3 lines in the try block. Indeed, this way you can write some information to the alert attributes or even close it (that is, set the status to Closed). Now this is more interesting. However, there is one thing: if you change the alert in this way, the next time the script runs, it will again fall into the connector (as it has changed) and you can get infinite processing. Therefore, before the modification, the alert should be checked for the appropriate condition. In our example, it is possible to check that the CustomField1 attribute is empty, otherwise not to modify it.

So, in general, our connector is ready. One script launch processes all alerts available at this moment. For permanent work, you can run it in an infinite loop or set up regular execution in Task Scheduler. This is much easier than maintaining a service written in C #.

Areas of use

Option one. Your organization has a Service Desk system. There is an API for it and you are well acquainted with it. Using this connector, you can configure the integration between the SCOM and your system. If desired, it can be two-way: when closing a ticket, close and alert.
Option two. In your organization, the infrastructure is divided into areas of responsibility. For example, lists of equipment and systems and lists of those responsible are consolidated in one document. Using this connector and this document, you can update the attributes of the alert with certain information. Thus, it will be easier for the operator to process it correctly.

That's all, thank you for your attention.