I was recently faced with an uncommon scenario, where I needed a script-based discovery to exit without submitting data. Exiting a script-based discovery without submitting discovery data, even if it’s an empty data item, is not considered a good practice. But in this particular scenario, I understood the reasons and the resulting instance space was minimal, so I was open to finding a trick that would accomplish this without having 21405 events logged on the agent-managed computer at each interval if the instance did not pass the test.

What I discovered was the CommandExecuterEventPolicyType in the System.CommandExecuterSchema. This is a Schema Type defined in the System.Library.

All script-based probes have a default event policy that describes how exit codes, standard error, and standard out are handled by the system. If any of these data streams match an event policy expression, the system will log an event to the Operations Manager log on that agent-managed computer.

For example, the Microsoft.Windows.ScriptProbeDiscoveryBase has a default policy as follows:

<DefaultEventPolicy> 
  <StdOutMatches Operator="DoesNotMatchRegularExpression">&lt;DataItem.+/DataItem\b*&gt;}|{&lt;DataItem.*/&gt;}</StdOutMatches> 
  <StdErrMatches>\a+</StdErrMatches> 
  <ExitCodeMatches>[^0]+</ExitCodeMatches> 
</DefaultEventPolicy>

The process started at 2:04:14 PM failed to create System.Discovery.Data, no errors detected in the output

<EventPolicy> 
  <StdOutMatches>^suppress_event_21405$</StdOutMatches> 
  <StdErrMatches>^suppress_event_21405$</StdErrMatches> 
</EventPolicy>

In this example, the override has been documented by specifying an expression that describes a reason for overriding the policy. This expression will never match actual standard out or standard error, so it serves two purposes.

Overriding a default event policy like this is very uncommon, and I do not recommend it unless you have a good understanding of how it may impact your workflow – but it is a nice trick to use if you find yourself in a unique situation that calls for it.

As a side note – this scenario probably could be handled in a more sophisticated way, by composing a new module that would filter the data stream before it even reaches a discovery module. This way would produce no errors, so overriding event policies would not be required. Food for thought!