Answered by:
Add Custom Field

Question
-
Hi all
We're using SCOM 2007 R2 with Seamless Connector for BMC Event Manager integration.
We have to create rules in the Event Manager to separate the events to the right subscribers. For this we need a field with the source data from the SCOM event - par example Exchange, ESE or something like this. So I thought it could be possible to put the source value in a custom field. But I don't find a way for doing this. Or do you have another idea for doing this?
Thanks
kammlu- Moved by Åke PetterssonMicrosoft employee Friday, February 26, 2010 6:32 PM Sounds like a connector question (From:Authoring)
Friday, February 26, 2010 8:37 AM
Answers
-
Hi Kammlu,
We can update alert details using Command Shell. If you can create a Command Shell script with the logic that you require, and update these custom fields using that logic, then one option is to add that script to a notification "Command Channel". You can filter which alerts will be passed through the Command Channel, like any other notification device, subsequently passing the alert through the script and updating the custom fields per your requirements.
HTH, Jonathan Almquist - MSFT- Marked as answer by Jonathan Almquist Wednesday, March 10, 2010 12:58 AM
Saturday, February 27, 2010 7:59 PM
All replies
-
Hi Kammlu,
We can update alert details using Command Shell. If you can create a Command Shell script with the logic that you require, and update these custom fields using that logic, then one option is to add that script to a notification "Command Channel". You can filter which alerts will be passed through the Command Channel, like any other notification device, subsequently passing the alert through the script and updating the custom fields per your requirements.
HTH, Jonathan Almquist - MSFT- Marked as answer by Jonathan Almquist Wednesday, March 10, 2010 12:58 AM
Saturday, February 27, 2010 7:59 PM -
Hi Jonathan
Thanks for your answer.
There isn't a way to change just a rule or monitor? I think there must be something much easier, not?
Thanks
KammluMonday, March 1, 2010 7:20 AM -
Custom Fields cannot be defined on the rule/monitor. They can only be updated after the alert is generated.
HTH, Jonathan Almquist - MSFTMonday, March 1, 2010 5:42 PM -
Custom Fields cannot be defined on the rule/monitor. They can only be updated after the alert is generated.
You can define values for custom fields on rules but not on monitors.
By the way, I'd love to see changes in that area since the way custom fields are currently implemented makes it very difficult to to implement integration scenarios.
JoachimTuesday, March 2, 2010 5:26 PM -
You're absolutely right, Joachim. Not even sure why I added "rules" to that statement. Thanks for correcting me.
HTH, Jonathan Almquist - MSFTWednesday, March 3, 2010 6:09 AM -
Hi all
Thanks for your suggestions.
Hmm changing rules... there are a lot :-) Setting a general field for management packs isn't possible? For example I like to set a field for the exchange management pack with the value "Exchange". Is something like this possible?
Regards
kammluWednesday, March 3, 2010 9:06 AM -
Again...not natively from within the UI. You'll need some other process called outside of SCOM to update the alert details. This can be accomplished with a Command Shell script and a Command Channel notification subscription, for example. Or, if you have a connector that can leverage this logic in its workflows, then use that.
HTH, Jonathan Almquist - MSFTWednesday, March 3, 2010 4:16 PM -
So, now I found my way... A timed rule witch run a powershell script. Easy thing like I was looking for...Friday, March 12, 2010 9:41 AM
-
So, now I found my way... A timed rule witch run a powershell script. Easy thing like I was looking for...
That's one way, but then you're not using the filtering mechanisms native to the notification workflow.
HTH, Jonathan Almquist - MSFTFriday, March 12, 2010 8:38 PM -
I am thinking about using the notification workflow in conjuction with a powershell command to update/populate a custom field. My concern is the performance. If there will be large number of alerts flowing through the notification subscription, will the command/powershell be able to keep up? I realize it will vary based on the environment and the powershell script itself, but generally speaking I am skeptical of a bottle neck ocurring or even bogging down the RMS itself if there are multiple poweshell scripts running often to update custom fields. Any thoughts here?Thursday, April 1, 2010 5:16 PM
-
This is one of those "it depends" answers. As you mentioned, it depends on the volume of alerts flowing through the channel and the complexity (or logic) of the script. Always use criteria where possible, rather than using a "where" clause. Filter alerts as much as possible by means of the internal notifications channel, so as not to bog down the script with unnecessary loops and processing time.
The only way to tell for sure is to create it and sample performance.
HTH, Jonathan Almquist - MSFTThursday, April 1, 2010 8:39 PM -
Thanks Jonathan. This is what I figured. Also good to know about using criteria versus 'where'.
Friday, April 2, 2010 2:56 PM