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:sequence>
<xsd:element minOccurs="0" maxOccurs="1" name="Severity">
<xsd:simpleType>
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="0"/>
<xsd:maxInclusive value="2"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<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"/>
</xsd:sequence>
</xsd:complexType>
Basically this element contains a ‘Severity’ element, as well as a ‘StdOutMatches’, ‘StdErrMatches’, and a ‘ExitCodeMatches’ elements.
The values for Severity are as follows:
|
Warning |
0 |
Problem is expected and did not result in loss of data. |
|
Data Loss |
1 |
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 |
2 |
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:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="Operator" type="PolicyOperatorType" use="optional"/>
<xsd:attribute name="CaseSensitive" type="xsd:boolean" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:simpleType name="PolicyOperatorType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="MatchesRegularExpression"/>
<xsd:enumeration value="DoesNotMatchRegularExpression"/>
</xsd:restriction>
</xsd:simpleType>
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 http://msdn.microsoft.com/en-us/library/k3zs4axe(VS.80).aspx 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:
<EventPolicy>
<!-- Report a Fatal Error -->
<Severity>2</Severity>
<!-- 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 -->
<StdErrMatches>\a+</StdErrMatches>
<EventPolicy>
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’:
<DefaultEventPolicy>
<!-- Report events as DataLoss -->
<!-- Ignore StdOut -->
<StdOutMatches />
<!-- Event on ANY text in StdErr -->
<StdErrMatches>\a+</StdErrMatches>
<!-- Event on ANY non-zero ExitCode -->
<ExitCodeMatches>[^0]+</ExitCodeMatches>
</DefaultEventPolicy>
And they look like this for the Probes which produces ‘System.Discovery.Data’, and ‘System.PropertyBagData’:
<DefaultEventPolicy>
<!-- Report events as DataLoss -->
<!-- Event if the StdOut does not contain a DataItem
Whenever data is not produced by script -->
<StdOutMatches Operator="DoesNotMatchRegularExpression"><![CDATA[<DataItem.+/DataItem\b*>}|{<DataItem.*/>}]]></StdOutMatches>
<!-- Event on ANY text in StdErr -->
<StdErrMatches>\a+</StdErrMatches>
<!-- Event on ANY non-zero ExitCode -->
<ExitCodeMatches>[^0]+</ExitCodeMatches>
</DefaultEventPolicy>