The two types of transport rules (Edge Transport and
Hub Transport rules) in Exchange Server 2010 give you the ability to
define and automatically enforce messaging policies within your
organization. In Exchange 2010, transport rules are enforced on the Hub
Transport and Edge Transport roles. You can use transport rules to
append disclaimers to messages, search messages for certain types of
content, apply ethical walls, append classifications, insert text into
a message, apply Rights Management Service templates, and more.
If you remember (from just a few pages ago), we
mentioned that all messages are handled by the Hub Transport server. A
major reason for this change was to allow the Hub Transport server to
trigger all these powerful transport rules that you will create for
your organization.
You can create and manage transport rules in both
the Exchange Management Console and the Exchange Management Shell. In
the EMC, transport rules are found under the Organization Configuration
properties and under the Hub Transport subcontainer, as shown in Figure 1.
Although you use the same processes to create and
manage the rules on both roles, the actions you can take, and the way
the rules are stored, are different. Transport rules are similar to
mailbox rules, but they are applied at the server level to all traffic
that goes through that server.
Like mailbox rules, transport rules have three parts:
Conditions identify the message properties
that trigger the application of the rule to a given message. If you
define no conditions, the rule will apply to all messages.
Exceptions
identify message properties that exempt a given message from being
processed by the rule even if it matches the defined conditions.
Exceptions, like conditions, are optional.
Actions
modify the properties or delivery of messages that match the conditions
without matching the exceptions defined by the rule. In a given rule,
there must be at least one action, and you can have multiple actions.
Transport rules on a Hub Transport server are
defined and stored in the Active Directory; each Hub Transport server
in the organization sees the entire set of defined rules and attempts
to match them against all messages. This allows you to define a single,
consistent set of message policies throughout your organization.
Technically, you can define an unlimited amount of transport rules.
However, because of management performance issues, Microsoft recommends
a total of 1,000 transport rules in your organization. That may seem
like a lot, but in large enterprises, you often need hundreds of
transport rules to fully define the automated policy restrictions
required.
|
Exchange Hub Transport servers maintain a local
cache of recipients and group memberships queried from Active
Directory. The cache is maintained to minimize further queries to
Active Directory. By default, the recipients in the cache are refreshed
every 3 hours. This information can be particularly useful when
troubleshooting transport rules that are not applied consistently in
your organization.
The cache refresh interval can be changed by modifying the AppSettings section of the EdgeTransport.Exe.Config file on each Hub Transport server. You need to modify the value for the Transport_IsMemberOfResolver_ExpandedGroupsCache_ExpirationInterval
property. Note that the minimum value for this property is 5 seconds
and the maximum is 24 hours. The default maximum size for the cache is
32 MB. This value can also be modified from the EdgeTransport.Exe.Config file.
|
1.
1.1. Transport Rules Coexistence Between Exchange 2007 and 2010
There are some specific issues related to
coexistence between Exchange Server 2007 and Exchange Server 2010, when
it relates to transport rules.
Exchange 2007 transport rules created using the
Exchange 2007 Management Console or Management Shell are stored in
Active Directory under the "Transport" container which is represented
under the Configuration name context as CN=Transport, CN=Rules, CN=Transport Settings, CN=<org name>, CN=Microsoft Exchange, CN=Services.
Transport rule agents running on Exchange Server 2007 hub transport
servers retrieve their rules from this "Transport" container.
To prevent the Exchange 2007 transport rules agents
from loading rules created in Exchange Server 2010, a separate Active
Directory container is created to separate the transport rules based on
the version of Exchange used to create them.
During Exchange 2010 server installation, a new
Exchange Server 2010 transport rule container is created. This new
container is located in Active Directory under the Configuration name
context as CN=TransportVersioned, CN=Rules, CN=Transport Settings, CN=<org name>, CN=Microsoft Exchange, CN=Services.
Provisioning a separate Active Directory container
for the new Exchange Server 2010 transport rules prevents legacy
Exchange 2007 servers from loading rules that they are unable to read.
In the case that an Exchange 2007 organization already has existing
transport rules that they need to function in the new Exchange 2010
environment, Exchange Server 2010 provides two methods to migrate
existing legacy transport rules to Exchange Server 2010: Automatic and
Manual migration.
Automatic migration is performed during Exchange
Server 2010 setup. If the setup program detects the existence of legacy
rules, those rules are copied to Exchange Server 2010.
Manual migration is performed by exporting and
importing transport rules between the two messaging platforms.
Automatic migration of transport rules is only performed during the
initial installation of an Exchange 2010 server, so new transport rules
created after the setup process has run will not be read by Exchange
Server 2010 Hub Transport servers. The same problem exists from
Exchange Server 2010 to Exchange Server 2007.
To overcome this limitation, Exchange administrators
can manually migrate a Transport Rule collection from Exchange Server
2010 to Exchange Server 2007, or from Exchange Server 2007 to Exchange
Server 2010 by using the Export and Import PowerShell tasks.
Just as with Exchange Server 2007, the Import- and Export-TransportRuleCollection
cmdlets are used by administrators to migrate or back up transport
rules. However, in Exchange Server 2010, these tasks have been updated
to allow the migration of transport rules.
The updated tasks must be run from the Exchange
Server 2010 Management Shell in order to move/copy transport rules
between Exchange Server 2007 and Exchange Server 2010.
You should be aware that importing a transport rule
collection will overwrite any preexisting Exchange Server 2010
transport rules, except for one special case: if an existing Exchange
Server 2010 transport rule has any 2010 specific predicate or action,
that Exchange Server 2010 rule will be left untouched. The remaining
Exchange Server 2007 rules will be imported into the Exchange Server
2010 collection.
1.2. Transport Rules and Server Design Decisions
A number of factors will come into play when you are
sizing and making server design decisions around Transport servers. The
number of messages per hour and the number of transport rules will
affect your design decisions regarding the amount of RAM and number of
processors that are on the Hub Transport servers. An organization that
sends 2,000 messages per hour and has 10 transport rules will need far
less computing power (and fewer Hub Transport servers in each site)
than an organization that sends 10,000 messages per hour and has a few
hundred transport rules.
Because rules are stored in the Active Directory,
modifications to your transport rules are subject to your normal AD
replication. Depending on your site topology, it may take some time
before your current changes replicate fully throughout your
organization.
If you have Exchange Server 2003 servers in your
organization, they will not make use of your transport rules. If acting
as bridgeheads, these servers may represent a significant loophole in
your messaging policy enforcement. Likewise, Exchange Server 2003
servers do not pass all messages through a Hub Transport server, so you
may notice that some policies are not applied consistently until all
mailboxes are on Exchange Server 2007 or Exchange Server 2010 servers.
In contrast, transport rules for Edge Transport
servers are defined on a per-server basis and stored in the local ADLDS
database on the Edge Transport server. Thus, though you have no
replication delays to worry about, you do have to manually maintain a
consistent set of rules on your Edge Transport servers or you'll find
you have some interesting discrepancies to track down at a later date.
If you have multiple Edge Transport servers, I
recommend creating an EMS script to manage your transport rule
configurations. Not only can you easily reuse this script on each Edge
Transport server to maintain consistency, but the script makes for
great documentation on what your current configuration is. Keep in mind
that Edge Transport rules do not synchronize to Hub Transport servers
during the Edge Synchronization process.
Another design decision point for Exchange Server
2010 Transport rules is one of those features that requires previous
implementation of non-Exchange components. Specifically, a Windows
Server 2008 server with the Active Directory Rights Management Service
role needs to be available to provide enhanced security through message
encryption and authorization. Exchange is now RMS (or AD RMS) aware,
ensuring that an administrator can create transport rules that can
leverage built-in or custom RMS templates.
