Just recently I had an issue at a client where there was a need to rethink the notification possibilities due to various issues. I’ve developed a powershell script to gain more control over the notification process.
My Client is using an in-house developed and maintained problem management system installed on a mainframe platform.
The alerts which need escalation are detected in SCOM and then sent by mail to a Lotus Notes system. The data is then read through a connector between the mainframe system and the Lotus Notes dbase. The mail is scrubbed and through a series of scripts on the mainframe the key fields of the mail are detected and filled in in the ticket….
So far so good… BUT because of the use of different systems there was an issue with encoding. The mails were sent in UTF8 encoding and correctly decoded when viewing in the Lotus Notes Client but stayed encoded in the Lotus Notes Dbase and therefore the scrubbed text was all scrambled and unusable for the problem management system.
After various attempts to mail in different encoding formats I decided to rethink the notification and detach it from the SCOM system to get more freedom in testing.
The following Powershell script together with a custom notification channel did the trick:
It’s constructed in 3 sections: preparation + composing file, mailing and error handling for reporting reasons.
You can Download the script here.
First of all we are preparing everything to execute the script.
The areas in yellow need to be customized for your environment.
Variables which need customization:
$rootMS: Is used to read the RMS name (if the RMS is a single server you can use the first method, mine is on a cluster so I filled in the name to avoid issues with the RPC server when reading the name through WMI.
$NotifiedResState: Just pick any number which is not already in use. We’ll have to make the resolution state in SCOM afterwards.
$CultureInfo: Make sure you fill in the correct locale info to get the date / time format correct. For a list of all culture info check here: Table
In this part of the script we are reading in all the different desired elements of the Alert and write them in a TXT file. You could however leave the txt file option out and just write this to a string but I prefer to keep the txt files for backup to check whether a ticket was raised at any given time.
Variables which need customization:
$strResolutionState: Because the resolution state is a number in the dbase and not the word itself we need to translate the number to the correct word. This way we’ll get the resolution state name in our mail instead of the number. You need to fill in the resolution state number you’ve chosen earlier + the text you’ve associated with it in SCOM. Check below on how to implement this setting in SCOM.
$strobjectname: Because not all the desired info was in the alerting I had to use 3 custom fields to get the mails to contain compliant info for the custom made problem management system. CustomField2 is reading out the NetBIOS name. Because I don’t need the full name (servername.domain.locale) but just the server name I’m splitting the name and using just the first part in the variable $Objectname
$FilePath: The file path is constructed out of 2 parameters from the alert to create a unique name and avoid overwriting an existing txt file. You need to use the time raised of the event because if you use the Get-Date function to get the current date and time it will generate 2 files if the time changes during the process.
Off course you can adapt the different fields + structure at your liking but for our problem management system this format had to be strictly followed to be able to scrub the mail.
Note: CustomField1 and CustomField3 are static text passed by the alert generated rule.
In the last part of the script you need to send out the mail to your destination.
I’m using static parameters here because the destination will not change that often. However If you have multiple destinations it’s best to use a variable and pass it when you are running the notification command from SCOM.
Variable which needs customization:
$Sender: Fill in the From email address
$OKRecipient: This will be the email address where you want to send the mail to when everything went fine
$strOKSubject: Define the subject for the mail when everything was fine.
$ErrRecipient: This will be the email address where you want to send the mail with the error.
$strErrSubject: Define the subject for the error mail
$strErrBody: Small body to notify something went wrong along the way.
Note: due to my issues in my customers environment with encoding I’ve used a command line mail utility which I’ve used quite often and is platform independent: blat. It’s a lightweight mail utility which can be downloaded here: Blat Download
More info on Blat can be found here: Blat Info
The install + config info for blat on the RMS is at the end of the blog post.
Last but not least I’m writing an event in the event log for successful and unsuccessful script runs. This can be used to set up alerting in SCOM to give you a quick warning when the ticketing is not working anymore.
At the end we unload the snap-in to have a clean system and avoid error messages when running the script the next time:
In order to use this script some things need to be configured in your SCOM environment + on your RMS:
Any tips or hints on improving this script are always welcome…