Returning failure from powershell in probes

The new powershell modules in R2 open up new possiblities for MP developers. On a resource utilization standpoint they’re better than Windows Scripting Host and powershell is good for interacting with managed code without having to develop a complete assembly.

For this reason I decided to use a PowerShellPropertyBagProbe for an agent task module, I defined my WriteAction type something like this:

   <WriteActionModuleType ID="Progel.Tasks.WatcherRedir.WAType" Accessibility="Internal" Batching="false">
          <xsd:element name="WatcherId" type="xsd:string" />
          <xsd:element name="TaskName" type="xsd:string" />
          <xsd:element name="Overrides" type="xsd:string" />
          <xsd:element name="ScriptTimeout" type="xsd:integer" />
        <ModuleImplementation Isolation="Any">
              <WriteAction ID="ServiceControl" TypeID="Windows!Microsoft.Windows.PowerShellWriteAction">
                </SnapIns>                <Parameters>

I then coded my powershell script to return a non zero exit code in case of error, so that I could track task failure in console. With my surprise the tasks always ended in success even when they had actually failed. I called for help and Cory (from OpsMgr team) pointed out I was missing a tag in my type definition:


The behavior of this configuration is discussed in the documentation for the other modules (i.e.  as follows:

The Microsoft.Windows.PowerShellPropertyBagProbe module supports the following configuration parameters:






Specifies the logical name of the Windows PowerShell script to be run. This value will be used in event logs and debug traces to identify the script.



Contains the Windows PowerShell script to be run.



Optional. Contains a list of one or more Windows PowerShell snap-ins.



Specifies a set of Name/Value pairs to be used by the Windows PowerShell script as parameters. This value can be a literal string, a $Target reference, a $MPElement reference, or a $Data reference.



Specifies the maximum number of seconds to allow the script to execute before the script is terminated.



Optional. Specifies whether to treat script errors as fatal errors instead of warnings. This should always be set to false in the case of discoveries and should only be true for task workflows, to allow the script error to be raised via the task status. The default value is false.


I added the statement to my write action type, but still no luck, even if the task fails it returns in success


After reviewing my code finding nothing wrong I tried to throw an exception from powershell using something like throw “BAD”


Definitely raw but at least I have a visual return the task has failed.

In conclusion, if you need to check for execution result from a PowerShellWriteAction (or back to the roots from a PowerShellPropertyBagProbe derived module) you must:

  1. set <StrictErrorHandling>true</StrictErrorHandling>
  2. throw an exception from powershell

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

  1. #1 by Niraj on November 9, 2010 - 9:55 am

    did you try using EventPolicy tag in the task xml?

    • #2 by Daniele Grandini on November 12, 2010 - 5:20 pm

      The powershell write action module doesn’t expose the EventPolicy tag, the STrictErrorHandling is supposed to do the trick:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: