Update Custom Alert Fields Using Subscriptions and Powershell

Article
1/17/2024

Alerts in OpsMgr have lots of good information on them already – but wouldn’t it be cool if you could add your own custom information to the custom alert fields of the alert? There are lots of reasons why this might be useful – you might just want to add extra information to an alert – or extra context, you might want to use the custom field data as criteria for forwarding alerts to another ticketing system or you might want to use the custom alert data to decide notification routing.

I set this up recently and modifying the custom alert fields of an alert isn’t difficult. The solution makes use of subscriptions and a simple powershell script. Let’s walk through how to set it up.

First, I need a powershell script that will take an alert ID as input and operate on that alert to update the custom alert fields as needed. My script is below – it doesn’t include any error checking but works nicely – I call it alertupdater.ps1 and the script is also attached to this post.

The script is very simple but there is one important point worth commenting on in this script – note the use of the –criteria option with get-alert. Using –criteria instead of a where statement improves the efficiency of the script significantly. A where clause is the equivalent of a select * statement in SQL – all the results are returned and then sorted. The –criteria statement is equivalent to a select * … where statement in SQL – returning only the data of interest. When you consider that most environments have hundreds or more alerts in the DB at any given time, efficiency gains are important.

#Get alertid parameter
Param($alertid)
$alertid = $alertid.toString()
# Load SCOM snap-inn
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
$server = "localhost"
#Connect to SCOM - change management server to your RMS
new-managementGroupConnection -ConnectionString:steveracrms.startrekng.com;
set-location "OperationsManagerMonitoring::";
# Update alert custom field
$alert = Get-Alert -Criteria "Id = '$alertid'"
$alert.CustomField1 = $alert.NetBIOSComputerName
$alert.CustomField2 = $alert.NetBIOSDomainName
$alert.CustomField3 = $alert.PrincipalName
$alert.CustomField4 = "RESERVED FOR FUTURE USE"
#This will set the management pack name that houses the rule/monitor as custom field 5
if ($alert.IsMonitorAlert -like 'False')
    {
        $alert.CustomField5 = ((get-rule $alert.monitoringruleid).getmanagementpack()).displayname
    }
else
    {
        $alert.CustomField5 = ((get-monitor $alert.problemid).getmanagementpack()).displayname
    }
$class = get-monitoringclass $alert.monitoringclassid
write-host $class.name
$alert.CUstomField6 = $class.name
$alert.CustomField7 = $alert.Category
$alert.CustomField8 = "RESERVED FOR FUTURE USE"
$alert.CustomField9 = "RESERVED FOR FUTURE USE"
$alert.CustomField10 = "RESERVED FOR FUTURE USE"
$alert.Update("")

The script is called through the subscription system so the first thing I need is a command channel that will execute the script. There are a few different ways that a command channel can be configured but I like to call powershell directly as shown.

http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-59-74-metablogapi/0184.image_5F00_thumb_5F00_1.png

There are several quotation marks in the command line so I’ve listed the text again below in case you want to copy/paste in your environment. Note the highlights above – these are single quotes that go around alert ID as it’s passed to the script. Make sure you include these because if you don’t the alert ID won’t be handled correctly in all cases and the script will not run consistently.

Full path of the command file: *c:\windows\system32\windowspowershell\v1.0\powershell.exe
*Command line parameters: *-Command "& '"C:\alertupdater.ps1"'" '$Data/Context/DataItem/AlertId$'
*Startup folder for the command line: c:\windows\system32\windowspowershell\v1.0\

Next, we need a subscription based on whatever criteria are important to you. In my case I setup a very simple environment where my subscription will fire on any new alert generated from an event 8888 as shown.

http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-59-74-metablogapi/3312.image_5F00_thumb_5F00_2.png

I also included a subscriber and my command channel.

http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-59-74-metablogapi/8117.image_5F00_thumb_5F00_3.png

http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-59-74-metablogapi/8688.image_5F00_thumb_5F00_4.png

OK, everything is setup – time to test things out. As mentioned above I have a sample alert rule that will trigger on an event 8888 – I use Event Creator from the MOM 2005 resource kit to create that event in the application event log.

http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-59-74-metablogapi/4401.image_5F00_thumb_5F00_5.png
Which quickly results in the alert I’m looking for in the OpsMgr console

http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-59-74-metablogapi/8105.image_5F00_thumb_5F00_8.png

If we look at the custom alert fields on the alert right after it is written we see that they are blank.

http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-59-74-metablogapi/8611.image_5F00_thumb_5F00_7.png

Why are these fields blank? Remember – the script to modify this data is run through the subscription system. Even though we have configured the subscription to run right away we will see a slight delay – sometimes up to a minute. Once the powershell script runs the custom alert fields are populated as expected.

http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-59-74-metablogapi/8623.image_5F00_thumb_5F00_6.png

OK, well and good – but what if you set this up and you don’t see it working? Then it’s time to troubleshoot. The major question – is the subscription working and trying to launch the command channel or not? There are a few ways to go about answering this question – one of my favorites is to use process monitor to see if the powershell process is getting spawned. If we can figure that out we will know if the problem lies in the powershell components or the notification components. Below is a screenshot of process monitor and the filter I use to hone in on just the powershell process.

http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-59-74-metablogapi/5315.image_5F00_thumb_5F00_9.png

That’s it – very straight forward but also very useful.

ref: Steve Rachui and http://blogs.msdn.com/b/steverac/archive/2010/08/17/updating-custom-alert-fields-using-subscriptions-and-powershell.aspx

Share via

Update Custom Alert Fields Using Subscriptions and Powershell

Additional resources