Exchange 2007 Transport Rules

Regulatory compliance, corporate policy and this little thing called security are more prevalent than ever and maintaining compliance and security in large Exchange organizations is difficult. This article will go over using transport rules to apply policies to e-mail as it traverses through your Exchange 2007 organization.

Introduction

So what is a transport rule? A transport rule is used to apply policies to messages passing through an Edge Transport or Hub Transport server. These policies can do such things as

• Archive messages
• Apply a disclaimer to all mail leaving the organization
• Redirect messges coming in or out of the organization
• Filter messages containing confidential information

Rule Agents

There are two types of agents that you can use to apply policies to messages, first is the Edge Rule Agent. This agent resides on any and all servers that have the Edge Transport role applied and is primarily used to provide anti-malware services. The other is the Transport Rule Agent which resides on any and all Hub Transport servers in your Exchange organization. The Transport Rule Agent is what you will use to apply the policies required for regulatory compliance, corporate policy and intellectual property protection.

Rule Components

Transport rules and edge rules work in a similar manner but because of some fundamental differences to their intended use there are some differences. That said all rules, whether transport or edge, are made up of the following components.

• Condition – The first component of any rule is the condition. This is what triggers the rule to take effect. In an Exchange organization some of the conditions that you may find are things such as sender, recipient, message header; anything that can identify an e-mail message. If a message is passed through an Edge Transport or Hub Transport server and it does not meet any of the conditions specified, it will pass through and continue on its way. However if one of the conditions are met it will run through the rest of the process.
• Exception – After a condition is met, the message is checked to see if it meets any exceptions. An exception can be used to fine tune a rule with a general condition. If a message meets one of the conditions applied, but also meets the exception it is released for regular delivery; however if it does not then in continues through the rule processing.
• Action – the final stage is the action stage. This is where a message that has met the condition specified, but does not meet an exception has an action taken on it. Here is where a message coming from an external source that contains inappropriate content can be rejected. Another scenario is when an internal user tries to send confidential information to inappropriate people inside or outside your organization.

Create a Rule

There are two ways you can create and/or modify a rule. You can use the classic graphical user interface (GUI) by launching the Exchange Management Console (EMC), or you can use the new Exchange Management Shell (EMS) which is built upon Powershell. Both are extremely easy to use but I do encourage you to try Powershell. In this example we are going to use a rule to prevent an internal user from sending mail to a specific department

The process is pretty straight-forward if using EMC; rules are located under Organization Configuration | Hub Transport (or Edge Server Configuration) | Transport Rules. In the task pane of the MMC console simply click New Transport Rule. Here you must specify a name for the rule, we will use Test Rule in this example, and add any comments you feel necessary. I usually write a brief summary of what the rule does in the comments. Finally you can uncheck the Enabled box if you do not want this rule to be automatically enabled when you are finished creating it.

The next step is to list any conditions which should trigger the rule. You can select one or multiple conditions as you see fit. Once you have selected a condition, or conditions it is one to edit the rule description. If you have ever set up a rule in Outlook, this process is very familiar, select a blue underlined word and click on it to specify the value. You must specify a value for each condition you chose (see Figure 1).

Figure 1: Rule Conditions

Next you must specify the action that should take place (see Figure 2). This process is similar to the conditions as you must then edit the rule and provide values for any exceptions you created.

Figure 2: Rule Actions

The last step is selecting any exceptions to the rule (see Figure 3) before finishing the wizard which will create the rule.

Figure 3: Rule Exceptions

Now that was simple but in you have many rules you want to create using Powershell and the EMS is the way to go. To create the same rule you would run the following command

New-TransportRule -Name 'Test Rule –Comments ‘Test rule for MSExchange.org Demo’  -Conditions 'Microsoft.Exchange.MessagingPolicies.Rules.Tasks.FromPredicate' -Actions 'Microsoft.Exchagne.MessagingPolicies.Rules.Tasks.LogEventAction' –Exceptions

'Microsoft.Exchange.MessagingPolicies.Rules.Tasks.FromScopePredicate'

 -Enabled $true -Priority '0'

Modify a Rule

So now we have our rule in place, what happens if something changes? Perhaps the conditions are too restrictive, or a change in policy requires a modification of an existing rule. Again we have two options, we can use the EMC and do it with the GUI or we can use Powershell and EMS. First let’s take a look at the GUI method.

Open up EMC and drill down to Organization Configuration | Hub Transport (or Edge Server Configuration) | Transport Rules. Select the rule you wish to modify, right-click and select Edit Rule. The wizard will open up and allow you to edit the rule (see Figure 4). Once complete click Update to apply the changes made.

Figure 4: Rule Edits

Using Powershell through EMS you can edit the rule as well. As an example, let’s say we created a rule with three conditions and two exceptions. We have found that we have a bad combination of conditions and exceptions so we want to remove a condition. First we must list the conditions

$TransportRule.Conditions

Next we must specify which condition to remove.  In this example we will remove the 2nd condition.

Set-TransportRule "RULENAME" -Condition @($Condition1, $Condition3).

That is it!

Troubleshooting Rules

Although rules are easy to create and manage, in a complex organization with many rules, issues can occur. When issues do occur you have two options, the Get-TransportPipeline cmdlet within EMS. This command will list all the rules that are enabled, and all the SMTP events since the last time the Microsoft Exchange Transport service was started. This can be an extremely long list so I suggest piping it to a text file.

The other option is to enable Pipeline Tracing. Pipeline tracing is a new feature of Exchange Server 2007 that allows you to trace messages through SMTP as they pass through the rules. Pipeline tracing can be enabled per server on a particular Hub Transport server, or organization wide on all Hub Transport servers in your organization. It can also be enabled on Edge Transport servers as well. Once you have enabled Pipeline tracing, you can view the logs under C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. There are two directories called MessageSnapshots and RulesTracking directory which will contain the logs. Pipeline tracing is a huge topic and best reserved for a future article, I just wanted to make sure you were aware of it in case trouble occurs.

Conclusion

Exchange 2007 message transport is very different than it was in previous versions of Exchange server. These are changes made for the better, allowing for more powerful control over messages coming into, passing through and exiting your organization and will make managing regulatory compliance easier. Not to mention simplifying internal policies and security.

Exchange Server 2003 System mailboxes

In Exchange Server 2003 there are three different types of system mailboxes which are used by different Exchange subsystems.

The three different system mailboxes are:

• SystemMailbox{GUID}
• System Attendant Mailbox
• SMTP Mailbox

SystemMailbox{GUID}

Every private information store in Exchange Server 2003 has one SystemMailbox. The SystemMailbox is created during the private information store creation process and will be deleted when the information store is deleted.

A SystemMailbox consists of two parts:

• The mailbox with its content in the corresponding information store
• An associated directory object in the Microsoft Exchange System Objects – sometimes called MESO

The next figure shows the three different types of system mailboxes.

Figure 1: Different types of system mailboxes

Active Directory Users and Computers

You can see the Microsoft Exchange System objects (MESO) in the advanced view of the Microsoft Active Directory Users and Computers tool.

Figure 2: MESO objects in ADUC

ADSI Edit

You can use ADSI Edit from the Windows Server 2003 support tools to see the system mailboxes that are associated with the private information store.

Figure 3: ADSI Edit

Viewing the contents of the SystemMailbox

Have you ever wondered what content the SystemMailbox has? Have you tried to open the SystemMailbox but without luck? If so, here is the answer. I will show you how to open the SystemMailbox.

There are different tools that allow access to the SystemMailbox and low level access to the store in general. One of the tools is the MAPI Editor, formerly MFCMAPI. Using the MAPI Editor is free. You will find the download link at the end of this article. Before we can start using the MAPI Editor, there are some steps we have to follow:

Enable System Mailbox in ADUC

First, we have to enable the SystemMailbox in Active Directory Users and Computers. This is required because we need a configured MAPI profile to access the mailbox later via MAPI Editor.

Disable Hide from the address book

The next step is to disable the Hide from Exchange address lists setting in Active Directory Users and Computers. This is required because without disabling this setting we cannot see the mailbox in the MAPI profile.

Figure 4: Disable Hide from address lists

Grant Full Mailbox Access (Send AS / Receive AS)

The account which opens the SystemMailbox requires full mailbox access, so you have to set the required permissions in ADUC (Active Directory Users and Computers).

Copy the Pre Windows 2000 logon name to clipboard

Because we need to create a MAPI profile for the SystemMailbox you have to take note of the Pre Windows 2000 logon name. The easiest way is to copy the name to the clipboard.

Figure 5: Pre Windows 2000 logon name

Create an Outlook Profile

As a next step you must create an Outlook profile for the SystemMailbox. Use the pre Windows 2000 logon name, as shown in the following screenshot.

Figure 6: Create a MAPI profile for the SystemMailbox

MAPI Editor

Now it is time to use the MAPI Editor to grant access to the content of the SystemMailbox. After downloading and extracting the MAPI Editor files you can start the MAPI Editor.

Figure 7: Microsoft Exchange Server MAPI Editor

To log on to the SystemMailbox click – Sessions – Logon and Display Store Table – and select the previously created MAPI profile and log on to this profile. You will need permissions to access the mailbox. You can read more about how to grant permissions to a mailbox in the link at the end of this article.

Figure 8: General SystemMailbox overview

Double click the SystemMailbox and navigate through the Root Container to the “Top of the Information Store”. Here you will find the Inbox and other relevant mailbox properties.

Figure 9: SystemMailbox Inbox

To see the emails in the SystemMailbox Inbox click Special Folder – Inbox as shown in the following screenshot.

Figure 10: General SystemMailbox overview

System Attendant Mailbox

Every Exchange Server has a System Attendant (SA) mailbox. The System Attendant mailbox will be created when the System Attendant service is created during the Exchange installation process.

The System Attendant Mailbox also consists of two parts:

• A mailbox object in the first private information store
• A configuration object in the configuration partition of Active Directory

The System Attendant Mailbox has the following functions:

The System Attendant Mailbox contains the folder SpecialPrivateFolderForFreeBusyStorage, for Free/Busy information for Microsoft Outlook and CDO Applications (Collaboration Data Objects) which will be temporarily stored in MSExchangeFBPublish.

The System Attendant Mailbox will also be used to send and receive Exchange monitoring messages for the Link Monitoring Service. You can find this function in the Exchange System Manager under Tools – Monitoring and Status.

Open the System Attendant Mailbox

The System Attendant Mailbox has no deactivated user account like the SystemMailbox so it is not so easy to open the mailbox. You must use MFCMAPI (Microsoft Foundation Classes API) to open the System Attendant mailbox.

SMTP Mailbox

Every private mailbox store contains an SMTP mailbox to store temporary messages. The SMTP mailbox will be generated when the private information store is created and mounted.

Every SMTP mailbox consists of two parts:

• SMTP mailbox in the corresponding private information store
• Active Directory object of class Mailgateway under –MailOrganization name – Connections.

The following screenshot shows the SMTP maibox of the first private mailbox store.

Figure 11: SMTP Mailbox

Open the SMTP Mailbox

You can also use the MAPI Editor to open the SMTP mailbox.

Figure 12: SMTP Mailbox properties

The following screenshot shows the TempTable space of the SMTP mailbox and the MTS-IN and MTS-OUT queue.

Figure 13: SMTP Mailbox TempTable properties

The folders MTS-IN and MTS-OUT are used by Exchange Deployment Kit (EDK) connectors to transfer messages between the MTA (Microsoft Exchange Transport Agent) and the Exchange Server information store (store.exe). They are also used for X400 connectors, Exchange site connectors, and fax connectors.