Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Microsoft Exchange Server 2010 : Setting Up Transport Rules (part 1) - Transport Rules Coexistence Between Exchange 2007 and 2010 , Transport Rules and Server Design Decisions

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
2/13/2014 3:38:55 AM

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.

Figure 1. Locating the Hub Transport rules in the Exchange Management Console

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.

Transport Recipient Cache in Exchange Server 2010

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.
Other -----------------
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Using SMS Trace (part 2)
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Using SMS Trace (part 1) - Obtaining SMS Trace
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Using SMS Service Manager
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Status Message Process Flow
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Working with Status Message Queries
- Microsoft Systems Management Server 2003 : Filtering Status Messages (part 2) - Status Filter Rules
- Microsoft Systems Management Server 2003 : Filtering Status Messages (part 1) - Configuring Status Reporting Properties
- Exchange Server 2007 : Migrating from Windows 2000 Server to Windows Server 2003 (part 6) - Upgrading Domain and Forest Functional Levels
- Exchange Server 2007 : Migrating from Windows 2000 Server to Windows Server 2003 (part 5) - Moving Operation Master Roles
- Exchange Server 2007 : Migrating from Windows 2000 Server to Windows Server 2003 (part 4) - Replacing Existing Domain Controllers
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server