Updating custom alert fields using subscriptions and powershell

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'"
#Check to see if Custom Field 3 is null - if it is then we need to update on this run.
#If not null then exist script
If (!$alert.CustomField3)
{
$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.

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.

I also included a subscriber and my command channel.

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.

Which quickly results in the alert I’m looking for in the OpsMgr console

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

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.

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.

That’s it – very straight forward but also very useful.  Have fun and let me know if this helps you!

alertupdater.zip

Comments

• Anonymous
  August 16, 2010
  Hi Steve. I have seen scripts like these before, but never ever have these scripts been used by the Command Notification Channel, which is just BRILLIANT! This way you keep it all in one place and add the possibility to use granular targeting and triggers. Wow! Thanks so much for sharing this. Much appreciated.

• Anonymous
  October 31, 2010
  Hi Steve i put this in place, and initially it seemed to work fine. However, now it takes anywhere from 30m to 2 hours to populate the fields. I have noticed that the behaviour of the powershell process has changed. Previously it spawned as and when it was needed, and then closed. Now however it seems to spawn regardless of whether there is a new alert or not, and stays in place for a minute or more. In the meantime another powershell process will spawn for a few seconds and then close. This is markedly difference to the behaviour i had noticed previously. It can also vary in size from 50mb to 150mb, and the other powershell process is alot less than that. If i disable the subscription the powershell process doesn't appear, so it is def the subscription causing this behaviour. Any ideas would be greatly appreciated, as I was hoping to use this for production.

• Anonymous
  November 27, 2010
  I have seen the same problem as Ash. Also when lots of monitored servers are having issues at the same time (like installting a .Net patch which recycles all websites and application pools) the RMS server is not able to handleallthe powershellprocesses. To avoid the problemsI'm running the scriptas a scheduled task evere 5 minutes

• Anonymous
  October 24, 2012
  Command Channel Notification will trigger notification very intermittently. When the alert GUID starts with a number, the PowerShell looks at it as a number and ignores rest of the GUID. If we enclose the alert id variable within a single quote and then a double quote, we can explicitly make it a string. This way, the command channel notification would be triggered every time.

• Anonymous
  March 10, 2013
  Hi what is the use of custom field in custom alert field!!!!!!!!!!!!!! please give your idea.....i donno why we are using custom field

• Anonymous
  October 22, 2013
  Hi, Could you update this script to run on scom 2012?

• Anonymous
  February 09, 2014
  Yes a 2012 version of this script would be nery useful.  Any chance of providing an update