Auditing transport rules
Transport rules contain an Audit setting that is often misunderstood and unchecked without realizing the implications.
Unchecking this box has quite adverse effects on future reporting and troubleshooting for the transport rule. While this may be desirable, I see a lot of organizations unchecking this box and not realizing what the impact will actually be.
By default, newly created transport rules have the Audit this rule with severity level box checked, and the severity level is set to Not specified. When looking at this option, two questions come to mind.
- What does the checkbox actually do?
- What do the various audit severity levels actually do?
I’m going to break the above two questions into their own sections.
What does the Audit checkbox actually do?
Now this is really important, so I’ll put this on its very own line.
The checkbox controls whether this rule will appear in reports and message traces.
If you uncheck this box, there will be no trace of this rule triggering anywhere. If the rule has triggered, you will see no evidence of this in reports or the message trace, and not even in the extended message trace. This obviously will have a huge impact on troubleshooting if you are looking to see if this rule has triggered or not.
Example
Consider the following transport rule.
If a message is sent from an external sender, this rule will prepend text in front of the subject. This rule also has Auditing disabled. Let’s take a look at a message trace for a message that triggered this rule.
We can see that the rule triggered based on the modified subject. However, there is no trace of the rule triggering in the details of the message trace.
Similarly, when looking at an extended message trace, we will also see no evidence of the rule triggering. The following was extracted from an extended message trace for this message.
Note: A triggered transport rule will show up in the extended message trace under the custom_data column as S:TRA=ETR|ruleID… , and this is not present in the above screenshot.
Finally, and this won’t come as a surprise, if we view a report of the above rule it will not show when or if it has triggered.
The reason for this behavior comes from a privacy perspective. It is meant to be used by organizations that have mandates in place that prevent tracking this type of information.
This behavior is noted in the TechNet article Transport rule actions.
If you clear the Audit this rule with severity level checkbox, rule matches will not show up in the rule reports.
To wrap this section up, unless you need to disable auditing, I would recommend not unchecking this box. It’s incredibly hard to troubleshoot something that does not appear in any logs.
Audit severity
The second item we need to investigate is the severity level that’s associated with the audit option. By default, a new rule will have this set to “not specified,” but you can change it to the following options.
These levels impact how the rule will show up in reports, that’s it. When viewing reports, you can filter based on audit level. If you only want a report to display triggered rules that have an audit level set to either medium or high, you can set that filter like this.
Rules that have an audit level set of “not specified” will show up in reports as having a “low” severity set. Regardless of the set severity, as long as the Audit check box is checked, there will be logs of the rule triggering (message trace, extended message trace, reports).
Summary
Unless you are mandated to not record data on transport rules triggering, I’d recommend not unchecking the Audit checkbox on any transport rule. Unchecking this box will make troubleshooting that involves transport rules very difficult.
