In today’s world of monitoring it is not always easy for people from the service desk or even for administrators to identify from which system is this alert being sent, who is responsible for the system and maybe in a multitenant environment to which company belongs this system/alert.
In my case a company which is hosting Active Directory domains and systems for different companys (customers) wanted to have company, server and contact information displayed on the alert notification. E.g. if server1.contoso.com is having a problem, the service desk must be able to identify to which company this server belongs and who they might need to contact.
To keep things as easy as possible I wrote a script which dumps the information into the custom fields of the alert and also sends a mail containing all the needed information.
Steve Rachui has written a blog post about updating custom fields using subscriptions in SCOM 2007 R2.
Based on this I wanted to extend his approach to fit all my needs for SCOM 2012.
What’s going on
First I need a data source where I dump all the information about which server belongs to which company and who is the manager or contact. I decided to use a text file . It looks like this….
If an alert is being generated my script will be triggered and the information is dumped into the custom field1-3 and also into the mail footer.
Here I stopped the DNS Service on host kwsp1…
…and the custom field information. Nice …
But look at my mail….isn’t it just cool?
If you think about it. You can add any additional information to an alert AND mail. This could be detailed company addresses, SLA information, 3rd level administrator information…whatever….
Create a text file company.txt and dump it on your management server’s c:\scripts folder. Enter all information you need according to this format. Add as many lines you need but make sure every server appears only once!
The next thing I set up a command channel according to Steve Rachui to execute my script. It goes like this….
Next you need to set up the subscriber and the subscription. The subscription there you will define when the command will be triggered. In my case I selected all critical alerts…
…and my administrator as subscriber,
Of course as a last step the command channel…
Save this script on your management server e.g. in c:\scripts as AlertUpdateV10.ps1. This script needs the alert id as parameter.
There is now only one problem. The Management Server Action Account will execute this script. And because of that I added the MSAA to the local Administrators group on the management server.
In addition I needed to set up a special permission on my Exchange Server 2010 to allow this account to send mail. If you don’t set this permission you will likely get an error “The server response was: 5.7.1 Client does not have permissions to send as this sender”.
I had to get the name of the receive connector in my case “Default EXC01”.
Then I executed this command in the Exchange Management Shell to set the permission…
add-adpermission “Default Exc01” -User “Domain\MSAA Acount” -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
I am not using this approach in production yet. I am not sure how the performance will be if there are 500 and more monitored systems. I thought it is a great idea so i built it .
Keep on scomming….