Menu Close

Demo Cookdown Management Pack Example


A common requirement for more complex MP’s is cookdown.

Cookdown is a concept where multiple workflows run on a healthservice, and share a common datasource.  When cookdown works properly, the datasource will only execute once, even when called by multiple workflows.  This saves precious resources, as these are commonly script datasources and can consume significant resources when executed.

A good description is documented here:  Management Pack Authoring – Cookdown

I posted a quick and simple script based example of when a script runs to collect data, and both a rule and a monitor share the script.  In this example, we are counting files in a folder.  The script counts the files and outputs the value in a propertybag.  The monitor compares the propertybag value against a threshold, while the rule simply collects the value and maps it as performance data.

You can download the example here: Demo.Cookdown SCOM Management Pack

Some key points to remember with cookdown:

1.  Ensure the multiple workflows do not pass ANY different parameters to the script datasource.  If the parameters are different, cookdown will likely be broken.

2.  On monitors, ensure:  ConfirmDelivery=”false”  When ConfirmDelivery=”true” this will often break cookdown for monitors.

1 Comment

  1. Graham Davies

    As always really useful.

    If I understand correctly then key point 1 means that if I can set an override for the monitor, I need to make the same change (override) on the rule even when the override might not be relevant to the rule e.g. the filecountthreshold ?

    If that is the case then I’d consider putting some knowledge base information on the rule and monitor in the remote chance that someone might actually read it and not break cookdown. This is particularly important if they change the threshold across all objects as this would break cookdown on all monitored entities.

Leave a Reply

Your email address will not be published.