Alert Parameter Replacement Failure Alert

A little troubleshooting tip for you here.  You likely will not see this alert unless you’re authoring a management pack and didn’t get the alert description parameters quite right.  If you see this alert generated by a sealed vendor management pack, there isn’t much you can do, unless you are so bold as to unseal the management pack and modify the workflow, or you change the Alert Description per Marius’ instructions here.

Keep in mind that if you unseal a vendor management pack, you will lose upgrade functionality without having access to the original encryption key to reseal.  Not to mention, the vendor might not support the management pack in this case.

Let’s get started…

In the Alert Description, you’ll see something similar to the following.

What we’re interested in here is the workflow and failing replacement parameters.  Highlight and copy the Workflow name, and paste the name into this Command Shell script. 

get-Monitor -criteria "Name = '[workflow name]'" | Select DisplayName

Now run this in the SCOM Command Shell to find the friendly display name of the monitor.

If you do not get a result, replace get-Monitor with get-Rule, since this could be a problem with a rule configuration rather than a monitor.

Copy the results from the Command Shell window, and depending on whether it was a monitor or rule, find it in the Authoring space in the Operations Console.

Open the properties of this monitor (or rule), and click on the Alerting tab.  In the Alert Properties you’ll see some Alert Context parameters, which will be filled in during runtime of alert generation.

In this particular example, you know that $Data/Context/NumSamples$ is not a valid parameter.  This was the bad parameter replacement in the original “Alert Parameter Replacement Failure” alert that led you down this path.

Clicking on the Configuration tab doesn’t help very much, because NumSamples in configuration is misleading.  Even though this is in configuration, it doesn’t necessarily mean this is the parameter output during runtime.

What now?  Two options.

1 – Completely remove $Data/Context/NumSamples$ from the monitor/rule configuration and live without this data in the Alert Description.  End of story.

2 – If you have an idea of what this data is supposed to map to, and you really want to see this data in the Alert Description, then continue reading to understand how to find this parameter.

What we need to do is examine the runtime output of this workflow, so we can correlate the actual parameters we need to use in our Alert Description.  The Authoring Resource Kit contains a couple tools that are very useful in capturing this runtime data.  Steve Rachui composed a series about analyzing workflows; Workflow Analyzer and Workflow Simulator.  For brevity, I will not delve into these tools in detail.  Read Steve’s series for a good primer.

I chose to examine runtime using the Workflow Simulator from the Authoring Console in this post.  So I open the Authoring Console and load the Management Pack in which this monitor is defined.  I find the monitor, right-click on it and select Simulate.

Here is the monitor runtime output.

As we can see here, SampleCount is the correct parameter replacement.  This is what I need to put in the Alert Description of my monitor, instead of NumSamples.

Different module types output different types of data and parameters, and sometimes you’ll need to see runtime data to identify what parameters are available for use in Alert Descriptions.  Using the Authoring Resource Kit tools, these parameters can be easily spotted.