Understanding How Transport Rules Are Applied
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2010-01-25
In Microsoft Exchange Server 2010, transport rules allow you to apply messaging policies to messages in the transport pipeline. Actions such as redirecting a message or adding recipients, rights-protecting messages, and rejecting or silently deleting a message can be taken on messages that match the conditions and none of the exceptions defined in the rule.
Given the scope and potential impact of transport rules on messages, it’s important to understand how transport rules work. To learn more about transport rules, see Understanding Transport Rules. For a comprehensive list of transport rule predicates and actions available on the Hub Transport server and Edge Transport server, see Transport Rule Predicates and Transport Rule Actions.
Looking for management tasks related to managing transport rules? Check out Managing Transport Rules.
Transport Rule Scope
Although the procedures used to create and modify transport rules on each server role are the same, the scope of transport rules on each server role is very different.
Transport rule scope
Hub Transport server role
Edge Transport server role
|Agent||Transport Rules agent||Edge Rules agent|
|Rule storage||Active Directory domain controllers||Active Directory Lightweight Directory Services (AD LDS) (local)|
|Rule replication||Active Directory replication||No automated replication between Edge Transport servers|
|Rule scope||Entire Exchange organization||Local to each Edge Transport server|
|Message types||All messages except system messages||All messages|
|Lookup distribution group membership||Yes||No|
|Lookup Active Directory attributes||Yes||No|
|Inspect or modify Information Rights Management (IRM)-protected message content||Yes (requires transport decryption)||No|
Rule Storage and Replication
The transport rules you create on a Hub Transport server are stored in Active Directory and are available after Active Directory replication on all Hub Transport servers in your Exchange 2010 organization. This allows you to apply a consistent set of rules across the entire Exchange organization.
Transport rules created on an Edge Transport server are stored in the local instance of AD LDS. No automated replication of configuration information or transport rules occurs between two Edge Transport servers. You can use distinct sets of transport rules on different Edge Transport servers. For example, if an organization uses a different set of Edge Transport servers for inbound and outbound messages to and from the Internet, different rules can be used on these servers. Rules created on the Edge Transport server apply only to messages that pass through that server. However, if applying the same set of transport rules on all Edge Transport servers is a requirement, you can also clone the Edge Transport server configuration, or export transport rules from one Edge Transport server and import it to other Edge Transport servers. For more details, see Understanding Edge Transport Server Cloned Configuration and Export and Import Transport Rules.
On Edge Transport servers, rules apply to all messages. On Hub Transport servers, rules are applied to messages that meet the following criteria:
- Messages sent by anonymous senders Transport rules are applied to all messages received from anonymous senders. E-mail received from the Internet falls under this category.
- Messages sent between authenticated users Transport rules are applied to the following types of messages sent between authenticated users:
- Interpersonal messages Interpersonal messages that contain a single rich text format (RTF), HTML, or plain text message body or a multipart or alternative set of message bodies.
- Encrypted e-mail messages Messages that are encrypted using S/MIME. Transport rules can access envelope headers contained in encrypted messages and process messages based on predicates that inspect them. Rules with predicates that require inspection of message content, or actions that modify content, can’t be processed.
- Protected messages Messages that are protected by applying an Active Directory Rights Management Services (AD RMS) rights policy template. With transport decryption enabled, the Transport Rules agent on a Hub Transport server can access the content of protected messages. Messages must be published using an AD RMS cluster in the same Active Directory forest as the Exchange 2010 server. With transport decryption disabled, the agent can’t access message content and treats the message as an encrypted message.
- Clear-signed messages Messages that have been signed but not encrypted.
- Unified messaging e-mail messages Messages that are created or processed by the Unified Messaging server role, such as voice mail, fax, missed call notifications, and messages created or forwarded by using Microsoft Outlook Voice Access.
- Read reports Reports that are generated in response to read receipt requests by senders. Read reports have a message class of
Transport Rule Replication
Transport rules configured on Hub Transport servers are applied to all messages handled by the Hub Transport servers in the Exchange 2010 organization. When a transport rule is created or an existing transport rule is modified or deleted on one Hub Transport server, the change is replicated to all Active Directory domain controllers in the organization. All the Hub Transport servers in the organization then read the new configuration from the Active Directory servers and apply the new or modified transport rules. By replicating transport rules across the organization, Exchange 2010 enables you to apply a consistent set of rules across the organization.
|Replication of transport rules across an organization depends on Active Directory replication. Replication time between Active Directory domain controllers varies depending on the number of sites in the organization, slow links, and other factors outside the control of Exchange. When you configure transport rules in your organization, make sure that you consider replication delays. For more information about Active Directory replication, see Active Directory Replication Technologies.|
|Each Hub Transport server maintains a recipient cache that’s used to look up recipient and distribution list information. The recipient cache reduces the number of requests that each Hub Transport server must make to an Active Directory domain controller. The recipient cache updates every four hours. You can’t modify the recipient cache update interval. Therefore, changes to transport rule recipients, such as the addition or removal of distribution list members, may not be applied to transport rules until the recipient cache is updated. To force an immediate update of the recipient cache, you must stop and start the Microsoft Exchange Transport service. You must do this for each Hub Transport server where you want to forcibly update the recipient cache.|
|Each time the Hub Transport server retrieves a new transport rule configuration, an event is logged in the Security log in Event Viewer.|
Transport rules configured on Edge Transport servers are applied only to the local server on which the transport rule was created. New transport rules and changes to existing transport rules affect only messages that pass through that specific Edge Transport server. If you have more than one Edge Transport server and you want to apply a consistent set of rules across all Edge Transport servers, you must either manually configure each server or export the transport rules from one server and import them into all other Edge Transport servers.
Order in Which Transport Rules Are Applied
Transport rules are applied in the following order:
- Message scope The first check performed by rules agents is whether a message falls within the scope of the agent. Transport rules aren’t applied to all types of messages.
- Priority For messages that fall within the scope of the rules agent, the agent starts processing rules based on rule priority in ascending order. Rules with lower priority are applied first. Transport rule priority values range from
nis the total number of transport rules. Only enabled rules are applied, regardless of priority. You can change the priority of rules using the Exchange Management Console or the Exchange Management Shell.
- Conditions Transport rule conditions are made up of predicates.
- Rule with no conditions A rule with no predicates and no exceptions is applied to all messages.
- Rule with multiple predicates For a rule’s action to be applied to a message, it must match all of the predicates selected in the rule. For example, if a rule uses the predicates from a member of distribution list, and when the Subject field contains specific words, the message must match both predicates. It must be sent by a member of the distribution list specified, and the message subject must contain the word specified.
- Predicate with multiple values If one predicate allows entering multiple values, the message must match any value specified for that predicate. For example, if an e-mail message has the subject Stock price information, and the
SubjectContainscondition on a transport rule is configured to match the words Contoso and stock, the condition is satisfied because the subject contains at least one of the values of the condition.
- Exceptions A rule isn’t applied to messages that match any of the exceptions defined in the rule. Note, this is exactly opposite of how the rules agent treats predicates. For example, if the exceptions except when the message is from people and except when the message contains specific words are selected, the message fails to match the rule condition if the message is sent from any of the specified senders, or if the message contains any of the specified words.
- Actions Messages that match the rules conditions get all actions specified in the rule applied to them. For example, if the actions prepend the subject with string and Blind carbon copy (Bcc) the message to addresses are selected, both actions are applied to the message. The message will get the specified string prefixed to the message subject, and the recipients specified will be added as Bcc recipients.
|Some actions, such as the Delete the message without notifying anyone action, prevent subsequent rules from being applied to a message.|
Transport Rules and Group Membership
When you define a transport rule using a predicate that expands membership of a distribution group, the resulting list of recipients is cached by the Hub Transport server that applies the rule. This is known as the Expanded Groups Cache and is also used by the Journaling agent for evaluating group membership for journal rules. By default, the Expanded Groups Cache stores group membership for four hours. Recipients returned by the recipient filter of a dynamic distribution group are also stored. The Expanded Groups Cache makes repeated round-trips to Active Directory and the resulting network traffic from resolving group memberships unnecessary.
In Exchange 2010, this interval and other parameters related to the Expanded Groups Cache are configurable. You can lower the cache expiration interval, or disable caching altogether, to ensure group memberships are refreshed more frequently. You must plan for the corresponding increase in load on your Active Directory domain controllers for distribution group expansion queries. You can also clear the cache on a Hub Transport server by restarting the Microsoft Exchange Transport service on that server. You must do this on each Hub Transport server where you want to clear the cache. When creating, testing, and troubleshooting transport rules that use predicates based on distribution group membership, you must also consider the impact of Expanded Groups Cache.
Create a Public Folder Mailbox
Applies to: Exchange Server 2013, Exchange Online
Topic Last Modified: 2013-02-14
Before you can create a public folder, you must first create a public folder mailbox. Public folder mailboxes contain the hierarchy information plus the content for public folders. The first public folder mailbox you create will be the primary hierarchy mailbox, which contains the only writable copy of the hierarchy. Any additional public folder mailboxes you create will be secondary mailboxes, which contain a read-only copy of the hierarchy.
For additional management tasks related to public folders in Exchange 2013, see Public Folder Procedures.
For additional management tasks related to public folders in Exchange Online, see Public Folder Procedures in Exchange Online.
What do you need to know before you begin?
- Estimated time to complete: less than 5 minutes.
- You need to be assigned permissions before you can perform this procedure or procedures. To see what permissions you need, see the “Public folders” entry in the Sharing and Collaboration Permissions topic.
- For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard Shortcuts in the Exchange Admin Center.
What do you want to do?
Use the EAC to create a public folder mailbox
- Navigate to Public folders > Public folder mailboxes, and then click Add .
- In Public Folder Mailbox, provide a name for the public folder mailbox.
- Click Save.
Use the Shell to create a public folder mailbox
This example creates the primary public folder mailbox.
New-Mailbox -PublicFolder -Name MasterHierarchy
This example creates a secondary public folder mailbox. The only difference between creating the primary hierarchy mailbox and a secondary hierarchy mailbox is that the primary mailbox is the first one created in the organization. You can create additional public folder mailboxes for load balancing purposes.
New-Mailbox -PublicFolder -Name Istanbul
For detailed syntax and parameter information, see New-Mailbox.
How do you know this worked?
To verify that you have successfully created the primary public folder mailbox, run the following Shell command:
Get-OrganizationConfig | Format-List RootPublicFolderMailbox