Tag Archives: MimboloveSCOM Notifications

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

Written by Tao Yang

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

IMG_0004

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:

image

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:

IMG_0007

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

IMG_0008

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.

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

Written by Tao Yang

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:

image

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:

image

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:

image

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

image

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:

image

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.

image

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

image

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:

image

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”

image

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.

image

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:

image

After:

image

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:

image

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):

image

image

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

OpsMgr Alerts Push Notification to Android Devices

Written by Tao Yang

Update 07 April 2013: I’ve updated this script again to support iOS devices and removed the requirements for PowerShell version 3. The updated script can be found here here.

Background

Stefan Stranger has written a 2-part blog post on how to use Windows Phone push notification for OpsMgr alerts. Stefan’s posts can be found here:

Part 1

Part 2

I got so excited about this idea, but I’m a big fan for Android when comes to mobile devices. I am currently using a Samsung Galaxy Nexus phone and a Samsung Galaxy Tab 2 10.1 tablet – both of them are Android devices. So I’ve spent some time to see if I can do the same for Android devices.

It turned out, there is also an app for Android devices, called “Notify My AndroidSmile. And the API’s for both apps are the same.

Setup Instructions

It’s pretty much the same way to get this setup for Android devices. I’ll now go through the steps to configure push notification for Android devices (and also for Windows Phones):

1. Install “Notify My Android” on Android devices via Google Play

2. Sign up – either from android device or from https://notifiymyandroid.com

3. Generate an API key from https://notifymyandroid.com, under “My Account”

image

Note:

Stefan mentioned the “Notify My Windows Phone” app costs $1.99. “Notify My Android” app is actually free from Google Play, HOWEVER, after you’ve signed up, your account is only a trail account. the limitation for the trail accounts is that you only get 5 push notifications per day. Premium account has removed this limit It costs one-off payment of $4.99 to upgrade to premium account. the upgrade payment can either be made via Google Play on your android devices or using PayPal via the website. I upgraded my account via Google Play (as I thought it’s easier than using PayPal).

As I have 2 Android devices, I don’t need to create multiple accounts or generate multiple API keys. Once I’ve logged in on both devices using my premium account, the push notifications get delivered to both devices at the same time.

4. copy this script to a unique location on all OpsMgr management servers in the Notifications Resource Pool (by default, this resource pool contains all management servers). In my lab, I have copied the script to D:\Scripts\MobileDevices-Notification on all my management servers. Below is what my updated script look like:

#Requires -Version 3

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"

# The full body of the notification.
$description = @"
AlertName: $alertname
Source: $alertsource
Severity: $alertseverity
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"}
}

Invoke-WebRequest -Uri $uri

I’ve modified Stefan’s script (used in OpsMgr command notification channel) a little bit. Below is a list of what’s changed in my version of the script:

  • supports both Windows Phone’s “Notify My Windows Phone” app and Android’s “Notify My Android” app.
  • Script is more generic as the API key is not hardcoded in the script, instead, it’s passed into the the script as a parameter.
  • Push notification messages contain additional alert information – alert source, alert description. – As both app’s API’s supports maximum 10,000 characters in notification description, the script will truncate the message to 10,000 characters if it’s over the limit.
  • Additional parameters are required to be passed into the script. – therefore the OpsMgr command channel is different than Stefan’s version.

5. Setup command notification channel:

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 “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.

The command line parameter can be populated by using pre-defined OpsMgr variables:

image

6. Follow Part 2 of Stefan’s original post to setup Subscriber and Subscriptions.

I cannot test my version of the script against Windows phones because I don’t have one. But I’m fairly confident it should work. From what I can see, the API’s for both apps are exactly the same. Well, the only difference is the URL’s for API calls:

image

I think in real world, this is a very cost effective solution for alerts notification to mobile devices. According to the API documentations, multiple API keys can be used in a single API call. When using multiple API keys, the API keys needs to be separated by comma. Again, I have not tested this scenario against my script because I don’t really want to spend another $4.99 for another premium account.

If it’s required to setup push notification to multiple people (different mobile devices types, different notify app accounts and different Microsoft / Google accounts, thus different API keys), separate command notification channels need to be created (one per API key or group of API keys).

Below are what I get on my Android devices:

On the phone:

Screenshot_2013-03-31-00-33-07

On the tablet:

Screenshot_2013-03-31-00-37-03

Limitations

According the the FAQ pages on both websites, there are some limitations that are worth mentioning:

Notify My Windows Phone:

Are there any limitations to the amount of messages I can send?

Yes – The Microsoft Push Notification Service throttles notifications at 500 per 24 hours per device. The messages will however be stored temporarily at NotifyMyWindowsPhone, so they can be retrieved manually by hitting refresh from within the Windows Phone App.

Notify My Android:

Is there a rate limit for using the public API?

Yes. Right now the limit is set to 800 API calls per hour from a given IP. Remember that you can notify multiple API keys on a single API call. Please check the API documentation for more details. Very few applications managed to reach that limit so far, but if you hit the cap too often, feel free to contact us and ask for a developer key.

In my opinion, if you get over 500 messages a day on your Windows phone or 800 in one hour on android devices, there are something seriously wrong with your infrastructure Sad smile or you might want to re-configure alert subscriptions to only notify really critical alerts.

Credit

Big thanks to Stefan for providing such an wonderful solution in the first place. Thumbs up