In case we only have one hub transport server this would be the only necessary rule action. However we need a second action in case of organizations running more than one hub transport. Since all emails must flow through a hub transport, multiple servers may be necessary to distribute load and fault tolerance. This introduces the risk of emails flowing through more than one hub transport, leading to multiple disclaimer insertions. We thus insert a custom header:

X-MY-DISCLAIMER: ready

This flags the email as processed. We will soon use this to setup an exception for excluding already processed emails. The header name and value are not important as long as these are consistent throughout the rule configuration and the header name starts with 'X-'.

Thus from the action list we also select 'set header with value'. We then click on the 'header' link to specify the header name as 'X-MY-DISCLAIMER' and the 'value' link to set this to 'ready'.

Clicking Next, the wizard moves to the Exception configuration stage. You already know how this goes. Configurations with multiple hub transports will configure an exception excluding emails with X-MY-DISCLAIMER header.

Select the 'except when the text specific words appear in a message header' exception. From the bottom pane click the 'specific words' link setting it to 'ready' and the 'message header' link setting it to X-MY-DISCLAIMER.

We are almost done. Move the wizard to the completion stage so that to create the rule. If at the wizard introductory step the rule was configured as enabled, emails will immediately start being stamped by the disclaimer.

The completion step also provides the Exchange management shell command that was used to create the rule. We could copy this and reuse it to create the same rule at other Exchange installations. This is very handy when moving from the test environment to the live environment. Exactly the same rule can be recreated without rerunning the wizard avoiding any potential configuration differences. Of course the command would still need to be tweaked if it contained domain specific settings not applicable to the new environment.

Final Tips

This completes our disclaimer configuration. As we have seen the Rules Transport Wizard interface mimics the Outlook Rules Wizard logic rendering it immediately intuitive. Once you configure the first rule, it is easy to appreciate how the various conditions, actions and exceptions can be combined for all kind of email processing operations.

We used X-MY-DISCLAIMER for marking processed emails. A similar result was achievable through an exception that looks for the disclaimer text in the message body. This is neater as it avoids inserting the additional header. However let's consider an email conversation with many replies flowing back and forth. The exception may match the disclaimer text of an earlier reply somewhere in the middle of the email text. Some organizations require the disclaimer text to always appear right at the bottom of the email. Thus in such a case the additional header is necessary. Apart for that, the additional header is a more generic solution that you may find applicable in other rules not related to disclaimers.