# …and why you should not use it

## A Disclaimer

I have had serious doubts about actually writing this article for almost a year now for reasons that I will explain further on. But as others have discovered this “feature” as well–maybe “hack” would be a better name for it–I feel the need to explain how it works and also why you should not use it. Knowledge is power, and even if I advice against using this technique it is also a good way to understand how SCOM uses display-strings in management packs.

## The Good News

Yes, you can use parameter replacement in you AlertName.

With “parameter replacement” i mean using some kind of substitute text, or mnemonic if you like, that at run-time get translated into something useful. If you have written any kind of alert generating rules or monitors, you most like included something like $Data/Context/Property[@Name='SomeDataFromAPropertyBag']$ into your alert description.

In this dialog, you also have the possibility to set the Alert Name. And if you are lazy, like I am, you probably also noticed that it is impossible to insert any kind of dynamic data into that field as well. This is especially annoying when you are writing a management pack that needs to look different in the Alert Views in the console, and you want to monitor 50 different Events or Performance counters or Log entries that are pretty much the same apart from a Name or ID.
Of course I could not refrain from copy-pasting a $Data/Context...$ into the alert name only to realize that it simply is not being parsed and translated into the value of the specified parameter. Over time I have settled for a stand-point that it’s probably a performance issue and I have also used that as an argument for this apparent lack of simplicity that some of my customers have been questioning.

Two, maybe three, years later. Microsoft releases an update to the core agent monitoring packs. Much to my surprise, one performance monitor suddenly generated alerts with a dynamic performance value in the Alert Name. You know, that field that is not gettingt parsed I was mentioning in the earlier paragraph. It actually looked pretty bad and made it very much impossible to practice any kind of alert supression, but still. It actually had a parsed value in the Alert Name.
As the lack of this feature had me irked before, I exported the core MP and started reading through the XML to find out how they did it. To my surprise, it was actually pretty simple if you ditched the Authoring Console and used your trusty text-editor instead.

## How To Do It

In simple terms, if you know your SCOM XML out-side-in, you add the parameters to your “Alert” and modify your DisplayString, the one under LanguagePacks, to call that parameter by it’s relative ID.

Just in case you happen to be a regular mortal, here’s the step-by-step guide. 😉

In this example I have created a silly-simple Alert Generating EventLog rule in wich I have added some parameters to the description. It pretty much looks like this:

Saving the MP at this point I will have a new WriteAlert action with a bunch of parameters and a displaystring with a unique ID.
The resulting XML-code for the WriteAlert action looks like this:

In this slab of code, you’ve got the Parameters, their “relative ID” (the number in the Tag), and also the which is what you would need to search for among the displaystrings. Take note of the you want to use in your AlertName since you are going to need it later. A quick search for “TestMP.MyEventlogAlertRule.AlertMessage” will lead you to the actual message, which should looke similar to this:

You should have one of these for every language you have configured in your management pack.
As you may notice, the Description does not contain any XPaths of any kind but rather references to the parameters defined in the WriteAction. That would be the {X} thingies within the description tags. You may also notice that the AlertParameters starts from “1” while the parameter references begin with “0”. In practice, that means that {0} in the displaystring definition equals to AlertParameter1 and so forth.

Now, with this in mind, adding a Parameter to AlertName if very simple and straight-forward. Simply decide which parameter your want to use and add it’s reference to the Name definition.
So, let’s say I have the above alert message and I want to include UserName in the Alert Name, I would change the tag to:

That’s it folks!
Save the XML, make sure you verify it and import it into your Operations Manager LAB and watch the magic. Just make sure you continue reading this post as the next part about the downsides is pretty important.

## The Downside

The negative effects of using Parameter Replacement in AlertName really boils down to two main perspectives. These are, if I may say to, pretty major and is the reason I have been reluctant on posting this, sort of, how-to.