Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Topic Last Modified: 2012-09-26

When you upgrade from Microsoft Exchange Server 2007 to Exchange Server 2010, there will be a period of time during which both versions coexist in production. You can plan an upgrade path from Exchange 2007 to Exchange 2010 by using the information in this topic, which includes overview information, technical information about message flow in a coexistence environment, and considerations when operating in a mixed version environment.

Important:
If you deploy Exchange 2010 as a new organization, you can't later install Exchange 2007 in the Exchange 2010 organization. This isn't a supported scenario. If you anticipate requiring Exchange 2007 functionality in your organization in the future, you must first install an Exchange 2007 organization and maintain at least one Exchange 2007 server.

The most important point in an Exchange 2010 and Exchange 2007 coexistence scenario is that every Mailbox server needs a Hub Transport server with a matching Exchange version in the same Active Directory site. Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. Therefore, you need to maintain your Exchange 2007 Hub Transport servers in a specific Active Directory site until all Exchange 2007 Mailbox servers are removed from that site. For more details about how messages are routed in a coexistence environment, see "Message Routing Across Versions" later in this topic.

Note:
In-place upgrades aren't supported in Exchange 2010. You need to install new Exchange 2010 servers into your environment, and then phase out the Exchange 2007 servers. For the scope of this document, the phrase upgrade refers to generally upgrading the version of your Exchange deployment and not a specific server.

Transport Server Upgrade Path

Upgrading your Exchange 2007 Hub Transport and Edge Transport servers should be part of your overall upgrade strategy. The recommended order is to upgrade your transport servers after your Client Access servers and before Unified Messaging and Mailbox servers. The Edge Transport servers need to be upgraded after the Hub Transport servers are upgraded. For more information about planning your upgrade, see Exchange 2007 - Planning Roadmap for Upgrade and Coexistence.

Before you introduce Exchange 2010 Hub Transport or Edge Transport servers, make sure that all of your Exchange 2007 servers in that site are upgraded to Exchange 2007 Service Pack 3 (SP3). Exchange 2007 SP3 is required for Exchange 2010 and Exchange 2007 Hub Transport servers to coexist in a single Active Directory site. Exchange 2007 SP3 is also required so that the Microsoft Exchange EdgeSync service works across versions.

If you have Exchange 2007 deployed in multiple sites, you must upgrade your Internet-facing sites first. The order of upgrade for the remaining sites depends on your particular topology and your organization's priorities.

The following process shows the recommended upgrade path for your transport servers in an Internet-facing site. (It is assumed that you are using Edge Transport servers with EdgeSync. If you are using a third-party smart host, you can omit steps 2-6.) The upgrade process is as follows:

  1. Introduce your first Exchange 2010 Hub Transport server to your site. As soon as the Exchange 2010 Hub Transport server is introduced to the site, it will start using the Exchange 2007 Edge Transport server for message delivery to the Internet. The EdgeSync synchronization process will continue to be handled by the Exchange 2007 Hub Transport server.

    Transport server upgrade step 1

  2. Subscribe your Exchange 2007 Edge Transport server to your site again. This action will add your Exchange 2010 Hub Transport server to the Edge Subscription as a source server. Exchange 2010 Hub Transport servers take precedence over the Exchange 2007 Hub Transport server for the EdgeSync source server selection. Therefore, the Exchange 2010 Hub Transport server will take over Edge synchronization, as shown in the following figure. However, because the Edge Transport server is still running Exchange 2007 SP3, the Exchange 2010 Hub Transport server will still replicate full EdgeSync data.

    Note:
    If you plan to add multiple Exchange 2010 Hub Transport servers to your Active Directory site, to save time, you can deploy all the new Hub Transport servers before subscribing your Edge Transport servers.
    Transport server upgrade step 2

  3. Introduce your first Exchange 2010 Edge Transport server to your perimeter network.

  4. Subscribe your Exchange 2010 Edge Transport server to your site. At this point, the Exchange 2010 Hub Transport server will start incremental updates to the Exchange 2010 Edge Transport server, as shown in the following figure.

    Transport server upgrade step 4

  5. Remove the Exchange 2007 Edge Subscription.

  6. Decommission your Exchange 2007 Edge Transport server, as shown in the following figure.

    Transport server upgrade step 6

  7. After all of your mailboxes are on Exchange 2010 Mailbox servers, decommission your Exchange 2007 Hub Transport servers.

Return to top

Message Routing Across Versions

Due to changes in the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. As a result, to have both Exchange 2010 and Exchange 2007 in the same Active Directory site, you must maintain both versions of Hub Transport servers in that site, as shown in the following figure. The versions of the servers in Site B aren't shown in the figure, because the handling of intersite SMTP traffic is the same as it is in Exchange 2007. The Hub Transport server relays the messages to the Hub Transport server in the remote site for delivery.

Message flow with versioned routing

To enable message flow across versions, a feature called versioned routing is implemented in Exchange 2010. With versioned routing, the routing engine checks the version of a mailbox's home server, along with its Active Directory site. If the version doesn't match, the message is relayed to a Hub Transport server that has a matching version, as shown in the versioned routing workflow in the following figure. Routing is now dependent on both Active Directory sites and Exchange versions.

Versioned routing workflow

When an Exchange 2010 mailbox user sends a message to an Exchange 2007 mailbox user in the same site, the following occurs:

  1. The Exchange 2010 Mailbox server notifies the Exchange 2010 Hub Transport server of the new mail.

  2. The Exchange 2010 Hub Transport server picks up the message.

  3. The routing agent determines that the version of the Mailbox server that's the home server of the destination mailbox doesn't match its own version.

  4. The routing agent locates an Exchange 2007 Hub Transport server in the local site.

  5. The Exchange 2010 Hub Transport server relays the message to the Exchange 2007 Hub Transport server.

  6. The routing agent on the Exchange 2007 Hub Transport server determines that the target mailbox is on an Exchange 2007 Mailbox server in the local site.

  7. The Exchange 2007 Hub Transport server delivers the message to the Exchange 2007 Mailbox server.

Any messages sent from Exchange 2007 mailbox users to Exchange 2010 recipients follow a similar path.

Versioned routing was added to Exchange 2007 in SP2. To have both Exchange 2010 and Exchange 2007 coexist in the same Active Directory site, you must first upgrade your existing Exchange 2007 servers to SP3. When you have Exchange 2010 and Exchange 2007 SP3 in the same Active Directory site, each Hub Transport server handles messages for the Mailbox servers with matching versions. Versioned routing doesn't change the way intrasite messages are routed.

Consider the following when you have Exchange 2010 and Exchange 2007 in the same site:

  • You can't specify an incompatible Hub Transport server as the submission server override for a Mailbox server.

  • For a specific Mailbox server, if you don’t have a matching version Hub Transport server in the local site, any messages sent by users on that Mailbox server will remain on the Mailbox server.

  • For a specific Mailbox server, if you don't have a matching version Hub Transport server in the local site, non-delivery reports (NDRs) will be issued for any messages sent to users on that Mailbox server.

  • Messages sent to mail-enabled public folders are handled the same way messages sent to mailboxes.

Return to top

EdgeSync Differences

The edge synchronization process has been improved in Exchange 2010. In Exchange 2007, EdgeSync replicated all of the configuration and recipient information in its entirety. Especially in organizations with large number of recipients, this took a long time. Exchange 2010 introduces incremental updates for EdgeSync. When you first subscribe an Exchange 2010 Edge Transport server to a site, all the configuration information and recipient data is synchronized. In all subsequent updates, only the changes are replicated. Therefore, synchronization time and network utilization are substantially reduced.

Although Exchange 2007 Hub Transport servers can participate in EdgeSync with Exchange 2010 Edge Transport servers, incremental updates are only available between Exchange 2010 Hub Transport servers and Exchange 2010 Edge Transport servers. By default, when an Exchange 2010 Edge Transport server is subscribed to an Active Directory site that has Exchange 2010 Hub Transport servers, the Exchange 2010 Hub transport servers take over the EdgeSync process. You can fall back to Exchange 2007 Hub Transport servers by disabling the Microsoft Exchange EdgeSync service on the Exchange 2010 Hub Transport servers. However, when you do that, you go back to replicating all data with each EdgeSync update, instead of incremental updates.

For more information about EdgeSync, see Understanding Edge Subscriptions.

Return to top

Transport Rules and Journaling in a Coexistence Scenario

If you already use transport rules or journaling in your Exchange 2007 organization, make sure that these features continue to function during the coexistence period, regardless of which Hub Transport server processes a specific message.

The following significant changes were made to transport and journaling rules in Exchange 2010, which have an impact when managing these features in a mixed environment:

  • Format changes   Exchange 2010 transport rules support a series of new predicates and actions. To support these new predicates and actions, the format of how transport rules are stored in Active Directory has been modified. Exchange 2007 Hub Transport servers can't process these new predicates and actions. For a complete list of predicates and actions available in Exchange 2010, see Transport Rule Predicates and Transport Rule Actions.

  • Storage location in Active Directory   To prevent the Exchange 2007 Transport Rules agents from loading and attempting to process the rules created in Exchange 2010, the Exchange 2010 rules are stored in a separate Active Directory container. The same situation applies to journaling rules.

Copying Existing Configuration to Exchange 2010

When installing Exchange 2010, if the Setup program detects the existence of Exchange 2007 transport rules, these legacy rules are automatically exported to a temporary location and subsequently imported to the Exchange 2010 transport rule container in Active Directory. This process happens automatically without any user interaction.

Note:
If there are any existing Exchange 2010 transport rules, Setup won't migrate Exchange 2007 rules because the migration overwrites all existing Exchange 2010 transport rules.

Similarly, all Exchange 2007 journal rules are converted and copied to Exchange 2010 journal rules during setup. For more information, see Export and Import Exchange 2007 Journal Rules.

Maintaining Transport Rules and Journaling in a Mixed Environment

The automatic import of rules to Exchange 2010 is only performed during initial setup. During the initial setup, the set of transport rules and journal rules for Exchange 2010 and Exchange 2007 will be synchronized. Going forward, if you make any changes to an existing rule, or create a rule, the rule will be changed in a single location based on the management tool you use. For example, in Exchange 2010, if you use the Exchange Management Shell to create a rule, only the Exchange 2010 rule container in Active Directory will be updated. Similarly if you use the Exchange Management Console (EMC) on an Exchange 2007 server to change an existing rule, only the Exchange 2007 version of that rule will be modified.

To ensure that your transport and journal rules remain consistent across versions, any changes you make must be made twice; once with Exchange 2010 management tools, and once with Exchange 2007 management tools.

Return to top

Maintaining DSN Settings in a Mixed Environment

In Exchange 2010, the internal and external DSN settings are configured for your entire Exchange organization. In Exchange 2007, these settings were configured on a per-server basis. As a result, these settings are stored in different configuration objects in Active Directory, and just like transport rules, need to be managed separately in a coexistence scenario.

Specifically, the following settings were moved from the Set-TransportServer cmdlet to the Set-TransportConfig cmdlet in Exchange 2010:

  • ExternalDelayDsnEnabled

  • ExternalDsnDefaultLanguage

  • ExternalDsnLanguageDetectionEnabled

  • ExternalDsnMaxMessageAttachSize

  • ExternalDsnReportingAuthority

  • ExternalDsnSendHtml

  • ExternalPostmasterAddress

  • InternalDelayDsnEnabled

  • InternalDsnDefaultLanguage

  • InternalDsnLanguageDetectionEnabled

  • InternalDsnMaxMessageAttachSize

  • InternalDsnReportingAuthority

  • InternalDsnSendHtml

If you need to change any of these settings in your organization, you must make the change once for the organization using the Set-TransportConfig cmdlet in the Exchange 2010 Shell and once for each Exchange 2007 Hub Transport server in the organization using the Set-TransportServer cmdlet in the Exchange 2007 Shell.

Return to top

Message Tracking Across Versions

Exchange 2010 provides improved message tracking capabilities. End users, as well as administrators, can now track the messages they have sent using the Delivery Reports tool in the Exchange Control Panel.

Delivery Reports enable end-to-end message tracking from a single location, providing detailed delivery information including when a message was marked as read. In Exchange 2010, a new message tracking remote procedure call (RPC) and Web service interface was implemented to support Delivery Reports. These interfaces don't exist in Exchange 2007 and therefore the Delivery Reports feature doesn't extend to the Exchange 2007 infrastructure in a coexistence scenario. However, it's possible to use the message tracking tool in Exchange 2007 to track messages between versions.

The following table shows what to do when tracking messages in a mixed environment.

Tracking messages in a mixed environment

Sent from Sent to Tracking Tool

Exchange 2010 mailbox

Exchange 2010 mailbox

Use the Delivery Reports tool in Exchange Control Panel.

Exchange 2010 mailbox

Exchange 2007 mailbox

Use the Delivery Reports tool in Exchange Control Panel. The tool provides message tracking information to the point where the message is transferred to the Exchange 2007 server. No further tracking information will be available for that message.

Alternatively, you can use Tracking Log Explorer in Exchange 2010 or message tracking in Exchange 2007.

Exchange 2007 mailbox

Exchange 2007 or Exchange 2010 mailbox

Use Tracking Log Explorer in Exchange 2010 or message tracking in Exchange 2007.

To learn more about message tracking in Exchange 2010, see Understanding Message Tracking.

Return to top

Exchange 2010 Transport Features in a Coexistence Scenario

For the most part, new transport features in Exchange 2010 only function within the realm of Exchange 2010. When to start using the new features depends on the needs of your organization. You can wait until the upgrade is complete, or start as soon as you introduce Exchange 2010 to your environment. To decide when to use the new features in a mixed environment, consider the following information.

Moderated Recipients

Exchange 2010 introduces moderated recipients, so that messages sent to specific recipients can be subjected to an approval process. If you plan to use moderated recipients in a coexistence scenario, be aware of the following issues, which depend on the type of recipient:

  • Mailboxes   You can only enable mailboxes on Exchange 2010 Mailbox servers for moderation. After you enable a mailbox for moderation, you must make sure that it isn't moved back to an Exchange 2007 Mailbox server.

  • Distribution groups and dynamic distribution groups   The messages to a moderated distribution group go through the approval process only when that distribution group is expanded on an Exchange 2010 Hub Transport server. Because the distribution group can be expanded on any server, we recommend waiting until all your Hub Transport servers are upgraded to Exchange 2010 before using moderated distribution groups.

  • Mail contacts and mail users   Hub Transport servers route messages based on the external e-mail address specified for each mail user or mail contact. Because it isn't possible to force messages for these recipient types to go through an Exchange 2010 Hub Transport server, you may not want to enable these recipient types for moderation in a mixed environment.

If you enable a recipient for moderation, make sure that the designated moderators use a client that can display the “approve” and “reject” options for an approval request. We recommend that all moderators use Microsoft Office Outlook 2010 or Outlook Web App in Exchange 2010. Both of these clients have built-in user interfaces that allow moderators to make decisions on messages.

Note:
If your moderators are using Outlook 2007 or Outlook 2003, the moderation request will show up as voting buttons in the message that they receive. They will still be able to moderate messages using the voting buttons. However, for the best user experience, consider upgrading their clients to Outlook 2010 or later.

To learn more about moderated recipients, see Understanding Moderated Transport.

Shadow Redundancy

Exchange 2010 introduces shadow redundancy to provide redundancy for messages for the entire time they are in transit. The solution involves a technique similar to the transport dumpster. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting successful delivery, the message is resubmitted for delivery to that next hop.

Shadow redundancy is enabled by default on Exchange 2010, and it ensures that messages are redundant only while being transferred between Exchange 2010 servers. After that message is transferred to an Exchange 2007 server, it's no longer redundant. Therefore, to ensure that a message that originates on an Exchange 2010 server stays redundant until it's delivered, make sure that it doesn't get transferred to an Exchange 2007 server. For example, if you are using a hub site that has Exchange 2007 servers, messages between two spokes won't be redundant even if they both have Exchange 2010 servers.

To learn more about shadow redundancy, see Understanding Shadow Redundancy.

Return to top