Working with alerts in System Center Operations Manager using your connector

Article is targeted at people familiar with the product System Center Operations Manager.

Terminology:
SCOM — instead of the full name;
Alert — same as alert. Just a good analogue in the Russian language there.

Introduction

In SCOM, in contrast to many other monitoring systems that alert a separate entity. Depending on settings, the check may be green, but alert and remain active. Alerts are used and processed:
the

the
• operator ()
the
• standard connectors (for example, Command Channel)
the
• external connectors (e.g., connector for synchronization with Service Desk)

the Presence of a Command Channel already provides ample opportunities for working with alerts, but this approach, at first not very beautiful, and secondly not the best for performance. So, let's create your foreign connector that sends emails for any alerts. Yes, there is a standard, however, in the narrative becomes clear that the functionality of our connector virtually no limits. For the impatient: the script lies entirely here.

To create a connector we are using Powershell. Because:
the

the
• it is easier than C#

this script is easier to maintain/modify

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

Add connector

First of all you need to create a external connector for this is also use script. I will not analyze in detail, as these same objects we will use in the main script. The main part of it:

the

$connectorGuid = New-Object Guid("{6A1F8C0E-B8F1-4147-8C9B-5A2F98F10007}");

if ($action -eq "InstallConnector")
{
# connect to 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();
}

Choose an arbitrary GUID, most importantly, to use in the main script of the connector is the same. By the way, the script on the link and remove the connector.

Important. After creating a connector will be available in graphical console SCOM. There you can configure subscriptions to alerts, the procedure is almost the same as for standard connectors. If this is not done, the alerts in your connector to get will not.

Logic connector

Going to do the main script. To begin with, determine what configuration settings:

the

# here I define the path to the script, as there are libraries
$ScriptPath = $MyInvocation.MyCommand.Path -replace $MyInvocation.MyCommand.Name;
# the name of one of your servers SCOM
$ManagementServer = "scom.contoso.com";
# The GUID of your connector you installation script
$strGuid = "{6A1F8C0E-B8F1-4147-8C9B-5A2F98F10007}";
# email addresses for notifications
$emailTo = 'azat.khadiev@contoso.com';
$emailFrom = 'scom@contoso.com';
# the smtp server of the organization
$Smtp = 'mail.contoso.com';

Email addresses and server addresses change according to the infrastructure of your organization.

the

# load library SDK, which lie in the same folder as the script
$DLLs = ("Microsoft.EnterpriseManagement.Core.dll","Microsoft.EnterpriseManagement.OperationsManager.dll","Microsoft.EnterpriseManagement.Runtime.dll");
foreach ($lib in $DLLs)
{
[Reflection.Assembly]::LoadFile($ScriptPath + $lib) | Out-Null
}

Using these libraries we can create a system object in SCOM, thereby working with her. Next:

the

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

# mark the alerts as handled
$connector.AcknowledgeMonitoringAlerts($alerts);

Marked so alert, you will not get more in our connector, until it is modified — either change of status or attribute change. Next:
the

foreach ($alert in $alerts)
{
try
{
# here is the main effect on the alert, in our case, sending letters
$alertContext = [xml]$alert.Context;
$alertResolutionStateName = @{0="New";255="Closed"};
# the context of the alert is plain xml, so you can use 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 the generated message
Send-MailMessage -SmtpServer $Smtp -Subject $subject-From $emailFrom -To $emailTo -Body $emailBody

# here you can change alert
#$alert.CustomField1 = "Notification sent.";
#$alert.Update();
}
catch
{
Write-Host $_.Exception.Message.ToString();
}
}

Thus, we sent a message for each of the alert in SCOM. Not impressive, right? However, note the last 3 lines in the try block. Indeed, thus it is possible to write in the attributes of the alert with any information or even close it (ie set the status to Closed). Now that's interesting. However, there is one more thing: if you change this way of alert, when the next execution of the script, he gets back into the connector (since changed) and you can get infinite processing. Therefore, before modification, you should check the alert in the corresponding condition. In our example, you can verify that the attribute was CustomField1 is empty, otherwise not to produce the modification.

So, overall, our connector is ready. A single run of the script treats all alerts available at this moment. For continuous operation, you can run it in a loop or to set up a recurring execution of the Task Scheduler. It's much easier to maintain than a service written in C#.

applications

first Version. your organization has a Service Desk. It has API and you know him well. Using this connector, you can configure the integration between SCOM and your system. If desired, it may be twofold: when closing a ticket to close and alert.
second Option. your organization's infrastructure is divided into zones of responsibility. For example, lists oborudivaniya and systems, and lists responsible consolidated into a single document. Using this connector and this document, you can update the attributes of the alert specified information. Thus, the operator will be correct to treat it.

That's all, thank you for your attention.

Article based on information from habrahabr.ru