Can Alert Names contain dynamic data?


A customer wanted to place dynamic data into the Alert Name field.  Can this be done?

Yes, it can.

It works the same way that we display resolved dataitems in the workflow, into the alert description.  For instance, here is an alert description that uses many resolved dataitems from the workflow:



What this does in the XML – is define each DataItem as an Alert parameter in the Alert write action:

<WriteAction ID="Alert" TypeID="Health!System.Health.GenerateAlert"> <Priority>1</Priority> <Severity>1</Severity> <AlertOwner /> <AlertMessageId>$MPElement[Name="opsmgrnet.Custom.Rules.TestRuleEvent100.AlertMessage"]$</AlertMessageId> <AlertParameters> <AlertParameter1>$Data/EventNumber$</AlertParameter1> <AlertParameter2>$Data/LoggingComputer$</AlertParameter2> <AlertParameter3>$Data/EventSourceName$</AlertParameter3> <AlertParameter4>$Data/EventLevel$</AlertParameter4> <AlertParameter5>$Data/EventDescription$</AlertParameter5> <AlertParameter6>$Data/@time$</AlertParameter6> <AlertParameter7>$Target/Host/Property[Type="MicrosoftWindowsLibrary6062780!Microsoft.Windows.Computer"]/IPAddress$</AlertParameter7> </AlertParameters> <Custom1>$Data/Params/Param[1]$</Custom1> <Custom2 /> <Custom3 /> <Custom4 /> <Custom5 /> <Custom6 /> <Custom7 /> <Custom8 /> <Custom9 /> <Custom10 /> </WriteAction>

However, when you look at the DisplayString, which is how the text will be viewed into the console – you will see:

<DisplayString ElementID="opsmgrnet.Custom.Rules.TestRuleEvent100.AlertMessage"> <Name>{0} Custom - Test alert on event 100 from rule {1}</Name> <Description>A test event was detected. The Event ID is: {0}. The Logging Computer is: {1}. The Event Source is: {2}. The Event Level is: {3}. Event Description = {4} Time event generated = {5} Custom IP Address: {6}</Description> </DisplayString>

As you can see, {0} corresponds to the first alert parameter, {1} corresponds to the second, etc…

So – in the Alert Name field, we can do something like this:




Which turns out really nice looking alerts in the console:





Now – the big downside?  Email notifications display this field as text, and do not resolve the Alert Data Items.  Sad smile


Comments (10)

  1. Jonathan says:

    Sure – raise my hopes, then slap me in the face.

  2. Yep! This is also a challenge when using notifications against some of the templates e.g. web application template; within Operations Manager as well as integrations into other help desk ticking systems.

    The only workaround that we have found is to have seperate notification channels for these which doesn’t include the Alert Name but instead includes items such as alert description.

  3. Jon sykes says:

    I submitted a connect request to add support for parameter replacement in subscriptions.

  4. teknoglot says:

    Yes, it is indeed a wanted feature by a number of customers, but I am not sure it would actually be good to have. Wrote a lengthy post on the subject a few years ago over at and I explain my thoughts on why it may be an unwanted feature in the "Downsides" section.

  5. Kevin Holman says:

    @teknoglot – good post!

    We actually used to allow a lot more of this type of stuff, early in the product, when certain fields were changed to not support HTML and other types of data resolution, and the reasoning at that time was that it was an attack vector. That said – if you look
    at the resolved alert description – this uses the same params and does translate correctly in email and connectors…. so I cant see why the alert name has to block this capability.

  6. teknoglot says:


    From what I remember from a discussion in the early days of SCOM 2007, this was not included for performance reasons. When I then saw it in an MP from Microsoft, I had to look it up. But as you say, if this functionality is available for the alert view, why
    is it not through connectors and subscriptions. This becomes especially annoying when you have SCOM and SCSM connected and are using the Cisco UCS management packs that rely heavily on parameters in the alert name. The result is a plethora of SCSM-incidents
    named "{1}: {0} – {2}".

  7. Peter says:

    I’m having some issues with this. The alert description doesn’t get populated correctly and just presents the raw code {0} … Anyone have a pointer to give where I should start troubleshooting? Added pic to make it clear.. Thanks in advance!

  8. Anonymous says:

    In the past I had some customer requirements to monitor many Windows Services  in an easy way. The

Skip to main content