My script failed but my Task says it succeeded

Published Feb 14 2019 08:21 PM 32 Views
First published on TECHNET on May 08, 2008

Task Status has two states Success or Fail, the way this is mapped from the 4 states that the module can return is that only Fatal Errors result in Failed tasks.  Since this module is used in both rules and tasks and in the rule case we do not want to unload we only return Fatal Errors if the problem is deemed to be unrecoverable, meaning the next time the module runs there is no chance it will complete successfully.

So the trick is to make the module return Fatal Error.  This is difficult at best in RTM, however in SP1 there is a reasonable way to accomplish this.  On the Module there is an ‘EventPolicy’ element, this element drives when the Script and Command Executor modules create events in the event log, but it also controls how those events are reported to the engine.  Which means that you as an MP author have control over how errors are reported.  This element is defined as:

<xsd:complexType name="CommandExecuterEventPolicyType">


<xsd:element minOccurs="0" maxOccurs="1" name="Severity">


<xsd:restriction base="xsd:integer">

<xsd:minInclusive value="0"/>

<xsd:maxInclusive value="2"/>




<xsd:element minOccurs="0" maxOccurs="1" name="StdOutMatches" type="PolicyExpression"/>

<xsd:element minOccurs="0" maxOccurs="1" name="StdErrMatches" type="PolicyExpression"/>

<xsd:element minOccurs="0" maxOccurs="1" name="ExitCodeMatches" type="PolicyExpression"/>



Basically this element contains a ‘Severity’ element, as well as a ‘StdOutMatches’, ‘StdErrMatches’, and a ‘ExitCodeMatches’ elements.

The values for Severity are as follows:



Problem is expected and did not result in loss of data.

Data Loss


This is the default value, the problem resulted in data being dropped or not created.  For instance an unexpected script error caused data to not be generated.

Fatal Error


This means the problem is unrecoverable and should result in the module being unloaded.

The values for the remaining fields are all the same:

<xsd:complexType name="PolicyExpression">


<xsd:extension base="xsd:string">

<xsd:attribute name="Operator" type="PolicyOperatorType" use="optional"/>

<xsd:attribute name="CaseSensitive" type="xsd:boolean" use="optional"/>




<xsd:simpleType name="PolicyOperatorType">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="MatchesRegularExpression"/>

<xsd:enumeration value="DoesNotMatchRegularExpression"/>



The ‘Operator’ attribute indicates that you either want to create an event on ‘MatchesRegularExpression’ or ‘DoesNotMatchRegularExpression’ (defaults to matches), the ‘CaseSensitive’ attribute indicates if your expression is case sensitive (defaults to true or case sensitive), and the inner text of each element is a regular expression in Atl syntax (see for more information).

So to put this all together, to make your task fail if for instance you hit a script error you could simply add the following XML to your script module configuration:


<!-- Report a Fatal Error -->


<!-- Report an Error if there is anything in StdErr

Cscript.exe writes out unhandled errors to StdErr so

Any text here indicates an unhandled error -->



Also keep in mind that the script modules already have defaults for these.  And that overriding is done per field, so in other words if you only modify the Severity in the EventPolicy then it would simply override this field, the defaults for the StdOut, StdErr, and ExitCode would still apply.  The defaults look like this for the WriteAction and Probe which produces ‘System.CommandOutput’:


Version history
Last update:
‎Mar 11 2019 08:02 AM
Updated by: