Blog

SCOM 2007: How to add Custom Field to monitor

In SCOM 2007 it’s possible to fill in custom fields with rules like you did in MOM 2005 as explained here: http://scug.be/blogs/dieter/archive/2011/05/13/scom-2007-custom-alert-fields.aspx

However this is not possible in monitors because there’s a fundamental change in how the alerts are created. In Rules the GenerateAlert module is used to create the alerts. In this GenerateAlert module it’s possible to pass extra data like the custom fields. In monitors the alert creation is slightly different. The alert is generate with parameters in the monitor itself so it’s not possible to pass extra data.

Case:

For a client I’m migrating MOM2005 to SCOM2007R2 and of course I would like to take advantage of the fact I can create monitors instead of rules. My client has a mainframe based problem management system (could also be any other system which doesn’t have a connector) which uses a mail scrubber to read out mails and scan for specific keywords to create tickets.

Problem:

The specific keywords were passed in MOM through the custom fields. This is also possible in SCOM but only by using rules and not monitors. A solution could be to create a monitor and create a separate alert generating rule for that monitor. This solves our issue but is not manageable because if things change you have to change both the monitor and the rule to make sure they reflect the new situation.

Solution:

Therefore I came up with another solution. Because there are only 15 possible combinations of keywords at my client I choose to use the Subscription / notification channel to insert the keywords in the dbase before I send it to the Problem management system. I could have just passed the parameters to the mail and send it but I prefer to update the dbase as well to also reflect the changes in the alert.

I’ve based my script on the script I used earlier on and is featured here: http://scug.be/blogs/dieter/archive/2011/05/11/scom-dump-alerts-to-text-file-and-mail.aspx

The main difference with the script above is that instead of reading the custom fields out of the dbase I pass them with the Notification Channel. Doing this makes the keywords centrally manageable when the keywords change.

The script:

As mentioned above I mostly reused the script of my previous blog post but for the record I’ll explain the script here once more:

First of all. You can download the script here: http://scug.be/members/DieterWijckmans/files/create_customfields_monitors.zip.aspx

Preparing the environment and reading the parameters:

The main difference with the previous script is the fact that we are not reading the data out of the dbase (in the $_.customfield fields) but inserting the data in the dbase through parameters by using the script.

Parameters: The “param” statement needs to be on the first line of the script. In my case I’m reading 3 parameters: The alertID (which is mandatory for the script), The Problemtype and the Objecttype.

The last 2 fields will be inserted in the $_.customfield dbase fields and are needed by the third party problem management solution to make the proper escalation.

RMS: Read the RMS server name of your environment. If you are using a clustered RMS it’s better to fill in the name of the cluster and comment the automatic retrieval of the name out to avoid problems.

Resolution State: The resolution state needs to be defined here and also defined in the SCOM environment (for more details on how to configure this in the SCOM environment check here: http://scug.be/blogs/dieter/archive/2011/05/11/scom-create-custom-alert-resolution-states.aspx

Loading the SCOM cmdlet

Culture Info: To make sure that the data format is correct you need to fill in the Localization. In my case it’s nl-BE.

Read in alert + fill in custom fields: The alertID which is passed as parameter is read in here and the data is retrieved out of the dbase. The other 3 custom fields which are required by the problem management system are filled in here and updated in the dbase. Technically there’s no obligation to fill in the fields in the dbase but to make sure that the custom fields are filled in when you open the alert in the console I update the alert anyway.

 

scom_custom_fields_monitor0000

Error Handling setup to make sure we have proper error handling
The conversion before dumping the data to the file.

Note that I needed to make modifications to the date format to reflect the localization format here. All the data will be dumped to a file which is kept for future reference. The File path in yellow can be changed to reflect your location.

scom_custom_fields_monitor0001

Mailing section:

Mailing the file to the problem management system or if in case an error occurred alerting the SCOM admin. Make sure you fill in the OK recipient, the NOK recipient and the SMTPserver to send out the mail.

scom_custom_fields_monitor0002

Last but not least we are writing an event in the event log whether the operation was successful or not. This gives us the opportunity to monitor the problem creation script from within SCOM. scom_custom_fields_monitor0003

This solution works for me because I have a limited number of possible combinations.

A couple of things you need to configure before this script can be used in production:

  1. Create custom resolution state in SCOM: http://scug.be/blogs/dieter/archive/2011/05/11/scom-create-custom-alert-resolution-states.aspx
  2. Create a notification channel per combination of the values of the custom fields: http://scug.be/blogs/dieter/archive/2011/05/11/scom-setup-command-notification-channel-subscriber.aspx

command_notification

  1.  
    • The following data is needed for the notification channel
      •  
        • Full Path of the command file: In my case this is PowerShell as I would like to run a PowerShell script: C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe
        • Command Line Parameters: In my case I’m running a PowerShell script and I’m passing the AlertID of the specific alert, problemtype and objecttype as arguments which I’m using in my script. Again you can use any arguments here if you like: C:\scripts\monitorcustomfields\create_customfields_monitors.ps1 -sAlertid ‘$Data/Context/DataItem/AlertId$’ -Problemtype ‘OSSUP’ -Objecttype ‘server’
        • Startup folder for the command line: This is basically the path of your program you want to run. C:\scripts\monitorcustomfields

The script must be run on the RMS (if it’s a clustered RMS make sure that the script is on both clusters in the same location).

Note:  If you want to use more parameters or different names you have the change the following things:

  • In the command line parameters: add –parametername ‘desired value’ to the command line
  • In the script:
    • change the first line in the script to reflect your custom situation: param([string]parametername,…)
    • change the section where the custom fields are filled in to reflect your situation:
      • $oalert.customfield# = desired value

There are 10 customfields available in the dbase so you can pass up to 10 parameters in the script and thus into the customfields.

If you have remarks or questions regarding the script please do not hesitate to drop me a line or contact me on twitter http://twitter.com/#!/dieterwijckmans

Go back to the blog

Enough talk, let’s build
Something together.

Reach out now