OpsMgr Alerts Push Notification to iOS (And Android, And Windows Phone) Devices

Last week, I’ve posted a solution for OpsMgr alerts push notification to Android devices, which was inspired by Stefan Stranger’s post for push notification for Windows Phone devices. Few iPhone lovers at work asked me, “what about iphones?” My response was, “Do I really care?? Why would I spend my time polishing a turd?”

But then I thought, I might as well do it, just to close the circle. Al though I hate any Apple products (except the old 160GB iPod Classic, which I still use), I’ve spent some time to work out how to do the same for iOS devices – Because iOS is still the most popular mobile devices out there…

An iPhone user at work told me he uses an iOS app called Prowl for his NZB or Sick Beard notifications (I wasn’t really sure exactly, don’t really spend too much time watching TV)…

So I’ve modified the PowerShell script to utilize Prowl API as well.

Luckily my partner has a spare first generation iPad doing nothing because she’s now using an iPad 3, I’m able to use this old iPad for testing.

I’ll now go through the steps to setup Prowl first, the command notification channel is pretty much the same with my previous post (I’ll go through what’s changed).

1. Firstly, buy and download Prowl from Apple App Store for $2.99: https://itunes.apple.com/us/app/prowl-growl-client/id320876271?mt=8&ign-mpt=uo%3D4

2. Go to Prowl’s website and register an account: https://www.prowlapp.com/register.php

3. Logon with the account and generate an API Key:

4. Logon to Prowl on your iOS device.

Now the the iOS device is configured.

Below is the updated PowerShell script used for command notification channel:

Param($os,$apikey,$alertname,$alertsource,$alertseverity,$alertTimeRaised,$alertdescription)

# Enter the name of the application the notification originates from.
$application = "OM2012"

# Enter The event that occured. Depending on your application, this might be a summary, subject or a brief explanation.
$event = "OM2012 Alert"

Switch ($alertseverity)
{
"2" {$strSeverity = "Critical"}
"1" {$strSeverity = "Warning"}
"0" {$strSeverity = "Information"}
}

# The full body of the notification.
$description = @"
AlertName: $alertname
Source: $alertsource
Severity: $strSeverity
TimeRaised: $alertTimeRaised
Description: $alertDescription
"@

#description maximum length is 10000, truncate it if it's over
If ($description.length -gt 10000)
{
$description = $description.substring(0,10000)
}
#You can enable the write-eventlog for logging purposes.
#write-eventlog -LogName Application -source MSIInstaller -EventId 999 -entrytype Information -Message $description

# An optional value representing the priority of the notification.
$priority = "-2"

# Specifies the responsetype you want. You can currently choose between JSON or XML (default)
$type = "json"
$os = $os.tolower()
Switch ($os)
{
    "android" {$uri = "http://notifymyandroid.com/publicapi/notify?event=$event&priority=$priority&application=$application&description=$description&apikey=$apikey&type=$type"}
    "windows" {$uri = "http://notifymywindowsphone.com/publicapi/notify?event=$event&priority=$priority&application=$application&description=$description&apikey=$apikey&type=$type"}
    "ios" {$uri = "http://api.prowlapp.com/publicapi/add?event=$event&priority=$priority&application=$application&description=$description&apikey=$apikey&type=$type"}
}

#Invoke-WebRequest -Uri $uri
$response = [System.Net.WebRequest]::Create($uri)
$response.GetResponse()

The script can also be downloaded here.

I have made the following changes to the script:

1. Windows PowerShell version 3 is no longer a requirement.

As we all know, Microsoft has removed Windows Management Framework 3.0 update for operating systems earlier than Windows 8 & Server 2012 from WSUS couple of months ago because it breaks many applications including SCCM, SharePoint, etc.. More Info can be found here. I saw someone posted a question in System Center Central’s forum wanting to install WMF 3.0 on OpsMgr management servers just to run this script. So I replaced the PowerShell 3.0 cmdlet Invoke-WebRequest (which was inherited from Stefan’s original script) with a .NET method in System.Net.WebRequest.

2. The original script was displaying alert severity as number (0 = information, 1 = warning, 2 = critical), I’ve updated it to display the actual severity in English rather than number.

3. the $os parameter supports additional value of “ios”.

The command notification setup is exactly the same as the previous version (except OS parameter now supports “ios”):

In my lab, the script is located on D:\Scripts\MobileDevices-Notification on all my management servers, so the setup looks like:

Full path of the command line:

C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe

Command line parameters:

D:\Scripts\MobileDevices-Notification\MobileDevicesPushNotifications.ps1 ‘<mobile device type>’ ‘<API Key>’ ‘$Data/Context/DataItem/AlertName$’ ‘$Data[Default='Not Present']/Context/DataItem/ManagedEntityPath$\$Data[Default='Not Present']/Context/DataItem/ManagedEntityDisplayName$’ ‘$Data/Context/DataItem/Severity$’ ‘$Data/Context/DataItem/TimeRaisedLocal$’ ‘$Data[Default='Not Present']/Context/DataItem/AlertDescription$’

Startup Folder:

D:\Scripts\MobileDevices-Notification

Note:

The script takes the following parameters (in the correct order):

1. OS: support either “ios”, “android” or “windows”

2. API key: generated from either Notify My Windows Phone or Notify My Android website

3. AlertName

4. AlertSource: Addition to Stefan’s script.

5. AlertSeverity

6. AlertTimeRaised

7. Alert Description: Addition to Stefan’s script.

Command line samples (assuming the API key is 1111111111111111):

For iOS devices:

D:\Scripts\MobileDevices-Notification\MobileDevicesPushNotifications.ps1 ‘ios’ ‘1111111111111111’ ‘$Data/Context/DataItem/AlertName$’ ‘$Data[Default='Not Present']/Context/DataItem/ManagedEntityPath$\$Data[Default='Not Present']/Context/DataItem/ManagedEntityDisplayName$’ ‘$Data/Context/DataItem/Severity$’ ‘$Data/Context/DataItem/TimeRaisedLocal$’ ‘$Data[Default='Not Present']/Context/DataItem/AlertDescription$’

For Android devices:

D:\Scripts\MobileDevices-Notification\MobileDevicesPushNotifications.ps1 ‘android’ ‘1111111111111111’ ‘$Data/Context/DataItem/AlertName$’ ‘$Data[Default='Not Present']/Context/DataItem/ManagedEntityPath$\$Data[Default='Not Present']/Context/DataItem/ManagedEntityDisplayName$’ ‘$Data/Context/DataItem/Severity$’ ‘$Data/Context/DataItem/TimeRaisedLocal$’ ‘$Data[Default='Not Present']/Context/DataItem/AlertDescription$’

For Windows phone devices:

D:\Scripts\MobileDevices-Notification\MobileDevicesPushNotifications.ps1 ‘windows’ ‘1111111111111111’ ‘$Data/Context/DataItem/AlertName$’ ‘$Data[Default='Not Present']/Context/DataItem/ManagedEntityPath$\$Data[Default='Not Present']/Context/DataItem/ManagedEntityDisplayName$’ ‘$Data/Context/DataItem/Severity$’ ‘$Data/Context/DataItem/TimeRaisedLocal$’ ‘$Data[Default='Not Present']/Context/DataItem/AlertDescription$’

On my iPad, when an alert has arrived:

And I can also see the details once I opened Prowl:

Similar to the Android and Windows phone APIs, Prowl has a limitation of 1000 notifications per hour from an IP address. I wouldn’t think any healthy OpsMgr environments would hit that limit.

If you’ve already got the notification channel setup for Android device (from my previous post), you can simply replace the script with the new one. and the same script can be used for iOS and Windows phone devices too.

Summary

At this stage, this script would work on all 3 major mobile device types: iOS, Android and Windows Phone by using 3 different push notification API’s:

Windows Phone: Notify My Windows Phone

Android: Notify My Android

iOS: Prowl

Again, thanks Stefan for his original posts and script. Hopefully this script will be adopted by more people as most of the population is still using iOS and Android devices.

Tags: SCOM, SCOM Notifications

Duplicate OpsMgr Alert Notifications Caused by Service Manager’s OpsMgr Alert Connector And Ways Around It.

Background

Few days ago, I posted an article: OpsMgr Alerts Push Notification to Android Devices. In my lab, I have created a subscription to notify me all new critical alerts using this channel:

In the first few days, I wasn’t paying too much attention when every time I get spammed by these push notifications on my phone, 2 days ago, I realised every new critical alerts gets pushed to my phone twice and two notifications are 1-2 minutes apart:

Cause

After some troubleshooting, I found the Service Manager’s OpsMgr Alert Connector is causing this issue. Well, I wouldn’t say it’s a fault or bug, it’s just the way that OpsMgr alert notifications handles alert.

In my lab, I have configured an OpsMgr Alert Connector in Service Manager. As a result, Service Manager updates the OpsMgr alert with a Ticket ID after the alert is generated:

And in alert history tab, you can see Service Manager updated the alert soon after it was initially raised:

Looks like this issue has been identified for a long time. some one has already posted a thread in TechNet forum back in 2009: http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/4d2f7f8f-c616-483e-a5af-8c77f5d20953/

OpsMgr alerts get processed by notification subscriptions every time they are updated. i.e. If I take a critical alert with resolution state of “New” and set the resolution state to “New” again in the OpsMgr console, it will get processed again by subscriptions:

Therefore I wouldn’t blame service manager for this issue.

Possible Solutions

I can think of 3 possible solutions:

1. Put a 3 minutes delay in the OpsMgr alert subscription since Service Manager alert connector is configured to check OpsMgr every 60 seconds.

2. add another criteria to the alert subscription: with a “%” ticket ID – which means ticket ID must match a wildcard (%).

3. Modify the criteria to notify any new critical alert WITHOUT a ticket ID.

Each option has it’s pros an cons.

Option 1 would wait Service Manager 3 minutes so it can process the alert first. However, if the alert is generated by a monitor and the monitor has a recovery task, the alert is probably already closed after 3 minutes and you will not get notified. this may not be the desired result.

Option 2 would only pick up alerts that have already been processed by Service Manager. This adds a unnecessary dependency. If for some reasons Service Manager is down, Ticket ID field in the OpsMgr alert will not get updated, therefore alert subscription will not pick up the alert.

To me, Option 3 makes most of the sense. The subscription should only pick up the “brand new” new critical alerts, before Service Manager updates the Ticket ID. – But, it’s not that easy to configure. Why? because I cannot specify conditions like “and with a NULL ticket ID” via the OpsMgr Console. As you can see below, I can only specify a wildcard match to ticket ID:

Luckily I can do this outside of the console, by directly modifying the OpsMgr “Notification Internal Library” MP. Kevin Holman has an excellent blog post on this topic: Creating granular alert notifications – rule by rule, monitor by monitor.

So I’ve decided that I’m going to go for option 3. I’ll now go through the steps I took to modify the existing alert subscription.

1. Export AND BACKUP the “Notification Internal Library” MP from the OpsMgr console (Microsoft.SystemCenter.Notifications.Internal.xml)

2. Open Microsoft.SystemCenter.Notifications.Internal.xml with a text editor (i.e. Notepad++).

3. Towards the end of the file, in the <LanguagePack> section, find the <DisplayString> associated to the subscription. Make sure the Name in <Name> tag matches the subscription name in the OpsMgr console, and ElementID starts with “subscription”

4. Change the name in <Name> tag, add “-Do Not Change In UI” at the end (As shown above). this is to remind anyone not to change this subscription in the Operations console after it’s imported back.

5. Find the Rule with the same ID as the ElementID for the <DisplayString> taken from step 3. The rule should be under <Monitoring><Rules> tags.

6. Modify the DataSource module of this rule, Add below expression in <Expressions><And> tag:

<Expression>
<UnaryExpression>
<ValueExpression>
<Property>TicketId</Property>
</ValueExpression>
<Operator>IsNull</Operator>
</UnaryExpression>
</Expression>

Before:

After:

7. Save the changes and import the MP back to OpsMgr management group.

8. Wait few minutes for the new configuration to become active. Once it’s active, you will no longer see the criteria in operations console:

Now, when I test this notification by creating a critical alert (using a test alert generating rule I’ve configured previously), I only get 1 notification pushed out to my phone (and it was pushed out before Service Manager updated it):

More Information

MP Schema Reference:

ExpressionType: http://msdn.microsoft.com/en-us/library/ee692979.aspx

ExpressionType (GroupPopulationSchema): http://msdn.microsoft.com/en-us/library/ff472337.aspx

Note: I used UnaryExpression, which is only listed in GroupPopulation Schema ExpressionType. but it worked in this scenario.

Related Blog Articles:

Using Expressions and Wildcards to create groups, author rules and monitors, create console views and notification subscriptions, and in the Command Shell: http://blogs.technet.com/b/jonathanalmquist/archive/2010/10/13/regular-expression-syntax-in-scom-for-filtering-groups-monitor-elements-operational-views-notification-subscriptions-etc.aspx

Creating granular alert notifications – rule by rule, monitor by monitor: http://blogs.technet.com/b/kevinholman/archive/2008/10/12/creating-granular-alert-notifications-rule-by-rule-monitor-by-monitor.aspx

Tags: SCOM, SCOM Notifications