Continuing in my series of interesting questions from last year and my answers here is one on Sending SMS Notifications for Heartbeat Failures for a subset of mission critical servers. The added wrinkle to this question was they also needed to be certain (due to the security requirements of their environment) that no information regarding servername, IP address, or other info of that nature which might be part of a typical alert description make it into the text alerts.
Text Alert on Heartbeat failures without Confidential information/Server names
SCOM Heartbeat Failure Chain of events:
Above Diagram pilfered with attribution from TechNet.
First you need to setup a new E-Mail Notification Channel
Select Administration
Channels:
New
Select E-Mail (SMTP)
Enter a Channel Name:
Enter a SMTP Server and a Return address (You will likely need an exception that will allow the SMTP server to send messages outside your domain)
Modify the Subject and Message as follows:
E-mail subject:
Alert: $Data[Default=’Not Present’]/Context/DataItem/AlertName$ Resolution state: $Data[Default=’Not Present’]/Context/DataItem/ResolutionStateName$
E-mail Message:
Alert: $Data[Default=’Not Present’]/Context/DataItem/AlertName$
Last modified by: $Data[Default=’Not Present’]/Context/DataItem/LastModifiedBy$
Last modified time: $Data[Default=’Not Present’]/Context/DataItem/LastModifiedLocal$
(Ultimately you could add additional text here as well, the key is that we are pulling out the variables from the Channel that would normally populate the server name when there is a heartbeat failure)
Click Finish
Create a new Subscription
Created by specific rules or monitors — Health Service Heartbeat Failure
With a specific resolution state–New
Add subscribers (If you want it to send text messages you can create new unique subscriber and have an address that consists of the appropriate cell number + service provider combination:
Sprint
cellnumber@messaging.sprintpcs.com
Verizon
T-Mobile
AT&T
For my example I am just using an internal account in my environment.
Select your newly created notification channel. You may want to delay notifications by 15 minutes. That way if the server is down for less than 15 minutes you won’t get a text message at 3 AM.
Click Finish
Now if a server goes offline the console will still generate an alert as before with the server name:
But the e-mail or text message will be generic without any confidential information:
For alerts other than heartbeat you might have to check and craft a slightly modified channel to insure no info you don’t want texted is sent out.
A quick example to illustrate this:
Ultimately $Data/Context/DataItem/AlertName$ will map to a different value for each type of alert. So for the alert below:
That variable maps to:
So Alert Name by itself will not map to anything proprietary like IP Address/domain/computername etc unless you have created a custom alert which contains any of this info in the Alert Name field. Though with that said it may still map to info about specific technologies. So one might be able to use the Alert Name to determine what types of applications you are running which could in some cases be a security concern. To get a sense of the type of values that typically show up in your environment the quick and easy method is to just look at your Monitoring Pane – Active Alerts Name column:
So for my environment you could learn from this info what apps I am running (SharePoint, SQL, ACS), in the case of the Page Life Expectancy you are able to find out the version of SQL etc. If this kind of info isn’t a security concern for your business you could just pass the Alert Name field from any alerts that meet a certain Severity/Priority Criteria. If this type of info is a concern then you need to determine which alerts are ok to pass alert name like Health Service Heartbeat failure and which need to be withheld and then filter your notification subscription criteria accordingly.
If you want a slighter better view of this info you could use PowerShell:
Import-Module OperationsManager
Get-SCOMAlert
Get-SCOMAlert | Select Name
This will give you possible values that could populate that variable. (Keep in mind this will only pull back values that are currently in the OpsDB so this will be all alerts in that DB based on your grooming/retention settings.)