Upgrade from Exchange 2003 Transport: Exchange 2010 Help

Upgrade from Exchange 2003 Transport

Applies to: Exchange Server 2010 SP2

Topic Last Modified: 2009-12-09

When upgrading from Microsoft Exchange Server 2003 to Exchange Server 2010, there will be a period of time where both versions coexist in production. You can use the information summarized in the following table to help ensure that message flow isn't negatively affected during this period of coexistence.

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

Summary by feature of required and optional actions for upgrading Exchange 2003 Transport to Exchange 2010

Feature	Required actions for coexistence	Optional actions and best practices
Routing Topology Differences When you plan for coexistence between Exchange 2010 and Exchange 2003, you must understand the differences in how each version determines its routing topology. This section provides an overview of the differences between the topologies, including a discussion of: Routing group connectors Link state updates in a coexistence environment	Specify an Exchange 2003 bridgehead server for the first routing group connector that is created during setup of Exchange 2010. Verify that every Exchange 2003 routing group has at least one connector to another routing group before you introduce the first Exchange 2010 server. Suppress minor link state updates for each server in the Exchange 2003 organization. Make sure that the Exchange 2010 routing group isn't the only communication path between Exchange 2003 routing groups to ensure that major links state updates continue to occur.	Specify more than one source server and more than one target server for the routing group connectors between your Exchange 2010 routing group and Exchange 2003 routing groups to provide redundancy and server availability Create additional routing group connectors between Exchange 2003 and Exchange 2010 to optimize mail flow if necessary.
Send and Receive Connectors Exchange 2003 uses SMTP virtual server interfaces for each protocol to send and receive messages between Exchange servers. The Exchange 2010 Hub Transport servers use an implicit connector called the intra-organization Send connector to route messages between sites.	None. The default configuration of Send and Receive connectors on Exchange 2010 support coexistence with Exchange 2003.	Create explicit Send connectors and Receive connectors if you want to create a connector that sends messages to a specific address space or receives messages from a specific address range.
X-EXCH50 Data Exchange 2003 uses the proprietary verb X-EXCH50 to transmit information about messages and recipients that can't be included in the e-mail message. Exchange 2010 supports a mapping between MAPI and MIME and doesn't require Exch50 data to reliably transmit message properties.	None. The routing group connectors support the propagation of EXCH50 data.	Make sure that the connector permissions allow the routing of EXCH50 data if you're connecting Exchange 2010 to an Exchange 2003 server in a cross-forest scenario.
Message Tracking Significant difference between the versions in that events logged by Exchange 2010 message tracking don't correspond directly to the message tracking events logged by Exchange 2003.	None.	Use the Exchange 2003 message tracking tool to search for messages that are transferred to or received from the Exchange 2003 organization.
Edge Transport Server Coexistence When an Edge Transport server is deployed to support an Exchange organization that hasn't yet deployed Exchange 2010, certain features can't be used.	Create specific Send and Receive connectors on the Edge Transport server and update the configuration of the Exchange 2003 bridgehead servers if you're deploying an Edge Transport server before introducing Exchange 2010 to your Exchange 2003 organization.	Deploy Exchange 2010 Hub Transport servers in your Exchange 2003 organization and then use EdgeSync.

Routing Topology Differences

Exchange 2003 use routing groups to define an Exchange-specific routing topology. Typically, routing groups are used to specify a set of well-connected Exchange servers. Servers in the same routing group can communicate with each other without the use of connectors. Ideally, the routing groups defined in your existing environment are based on IP subnets and closely mirror the Active Directory site configuration.

When more than one routing group is defined in an Exchange 2003 organization, you must manually create routing group connectors to enable mail flow between Exchange 2003 servers in different routing groups. The routing group connector must specify a source server and a target server as the connector endpoints. A routing group connector defines a one-way connection, and a reciprocal connector must be created to establish mail flow in both directions. The source and target servers are the bridgehead servers for the routing group. The bridgehead servers relay e-mail to other routing groups on behalf of other servers in their routing group and receive e-mail from other routing groups for delivery to other servers in their routing group.

In Exchange 2010, you don't have to define an Exchange-specific routing configuration. Exchange 2010 uses the existing Active Directory site topology to define its routing topology. However, you can make Exchange-specific configuration changes to Active Directory sites and IP site link costs to control mail flow. E-mail routed to Exchange servers located in different sites must be relayed by Hub Transport servers. Hub Transport servers send e-mail to Hub Transport servers in remote sites by using the intra-organization Send connector. The intra-organization Send connector is an implicit connector computed by using Active Directory site and IP site link information. To learn more about how Exchange 2010 uses Active Directory sites to route messages, see Planning to Use Active Directory Sites for Routing Mail.

Routing Group Connectors

To support coexistence between these two routing topologies, all Exchange 2010 servers are automatically added to a single routing group when Exchange 2010 is installed. The Exchange 2010 routing group is recognized in Exchange System Manager in Exchange 2003 as Exchange Routing Group (DWBGZMFD01QNBJR) within Exchange Administrative Group (FYDIBOHF23SPDLT).

During the installation of the first Exchange 2010 Hub Transport server in an existing Exchange organization, you must specify an Exchange 2003 bridgehead server to which to establish the first routing group connector. We recommend that you select a bridgehead server located in a hub routing group or in a routing group that has many mailboxes. The routing group connector links the routing group where the Exchange 2003 server resides and the Exchange 2010 routing group. The Exchange 2010 routing group includes all Exchange 2010 servers, regardless of the Active Directory site in which they reside.

Caution:
Don't move Exchange 2010 servers out of Exchange Routing Group (DWBGZMFD01QNBJR), and don't rename Exchange Routing Group (DWBGZMFD01QNBJR) by using a low-level directory editor. Neither action is supported. Exchange 2010 must use this routing group for communication with Exchange 2003.

The Hub Transport server that you're installing and the Exchange 2003 bridgehead server that you select are configured as the source and target servers on two reciprocal routing group connectors. The selected bridgehead server is automatically added to the membership of the ExchangeLegacyInterop universal security group and is granted the permissions needed to send e-mail to and receive e-mail from Exchange 2010. This routing group connector creates a single connection point between Exchange 2003 and Exchange 2010.

You can modify the list of source and target servers by using the Set-RoutingGroupConnector cmdlet in the Exchange Management Shell. It's a best practice to specify more than one source server and more than one target server to provide redundancy and server availability.

Important:
Placing Exchange 2010 servers and Exchange 2003 servers in the same routing group isn't supported.

Every Exchange 2003 routing group should have at least one connector to another routing group before you introduce the first Exchange 2010 server. Event ID 5006 is logged for each Microsoft Exchange message database (MDB) located in a routing group that doesn't have a routing group connector path from the Exchange 2010 routing group. For more information about the Exchange 2003 routing topology, see the Exchange Server Transport and Routing Guide.

If your existing Exchange environment includes more than one routing group, you may want to create additional connection points between Exchange 2003 and Exchange 2010 to optimize mail flow. To create additional connection points, follow these steps:

Determine how you will upgrade the organization to Exchange 2010. The order in which you decommission routing groups will determine which Exchange 2003 routing groups should connect directly with Exchange 2010.
Modify the registry to suppress minor link state updates on all the Exchange 2003 servers. This configuration change prevents connector state messages from being relayed throughout the organization by using link state updates, but doesn't prevent configuration change messages from being relayed. For more information, see Suppress Link State Updates.

Use the New-RoutingGroupConnector cmdlet in the Shell to create all routing group connectors that specify Exchange 2010 Hub Transport servers as source or target servers. Configure a routing group connector from the Exchange Routing Group (DWBGZMFD01QNBJR) to each Exchange 2003 routing group with which Exchange 2010 will communicate directly, and configure the corresponding reciprocal routing group connectors. You can use the Bidirectional parameter with the New-RoutingGroupConnector cmdlet to create both connectors in a single operation. These connectors will enable mail flow between Exchange 2003 and Exchange 2010.

Important:
When you use the New-RoutingGroupConnector cmdlet, the specified legacy Exchange servers are automatically added to the membership of the ExchangeLegacyInterop universal security group, and the permissions required to allow a legacy Exchange server to send mail to and receive mail from an Exchange 2010 Hub Transport server are automatically granted. If you use Exchange System Manager to create a routing group connector between the Exchange 2010 routing group and any Exchange 2003 routing group, this group membership isn't updated and the connector won't work correctly. Therefore, always use the Shell to create or update routing group connectors between Exchange 2010 and Exchange 2003.

Important:

When you use the New-RoutingGroupConnector cmdlet, the specified legacy Exchange servers are automatically added to the membership of the ExchangeLegacyInterop universal security group, and the permissions required to allow a legacy Exchange server to send mail to and receive mail from an Exchange 2010 Hub Transport server are automatically granted. If you use Exchange System Manager to create a routing group connector between the Exchange 2010 routing group and any Exchange 2003 routing group, this group membership isn't updated and the connector won't work correctly. Therefore, always use the Shell to create or update routing group connectors between Exchange 2010 and Exchange 2003.

For more information, see Create Additional Routing Group Connectors from Exchange 2010 to Exchange 2003.

Link State Updates in a Coexistence Environment

When connecting the Exchange 2010 routing group to the Exchange 2003 organization, you must consider the behavior of link state routing. Exchange 2003 servers maintain a link state routing table that's updated through communication with the routing group master. Each connector that has been created between Exchange 2003 routing groups is considered a link. Exchange 2003 servers determine how a message is routed inside the organization by using the cost assigned to these links. If a particular routing group is inaccessible by using the lowest cost route, the link state table is updated by the routing group master to show the state of that link as down. This data is communicated to every routing group in the Exchange organization. When the data is received, the link state table is updated, and another route is calculated.

Link state routing isn't used by Exchange 2010 Hub Transport servers. Exchange 2010 can't propagate link state updates, and it doesn't recalculate routes. Hub Transport servers always try to communicate directly with other Hub Transport servers. When a connection to a site is unavailable, Exchange 2010 uses the IP site link costs associated with Active Directory sites to determine the closest site at which to queue the message. This behavior is known as queue at point of failure. The message queue generated at the point of failure is put in a retry state.

If multiple paths exist between the Exchange 2010 routing group and any Exchange 2003 routing group, minor link state updates must be suppressed to make sure that message looping doesn't occur when a route is recalculated. We recommend that minor link state updates be suppressed for each server in the Exchange 2003 organization. When link state updates are suppressed, Exchange 2003 servers also queue at point of failure, instead of recalculating the route.

Configuration changes, such as the addition of connectors, are still communicated between Exchange 2003 servers by using link state. However, to ensure that major links state updates continue to occur, you must make sure that the Exchange 2010 routing group isn't the only communication path between Exchange 2003 routing groups. For more information about how to suppress link state updates, see Suppress Link State Updates.

Return to top

Send and Receive Connectors

Exchange 2003 uses SMTP virtual server interfaces for each protocol to send and receive messages between Exchange servers. Configuration is required only when you modify the default values or create connectors specific to another organization.

The Exchange 2010 Hub Transport servers use an implicit connector to route messages between sites. This connector is called the intra-organization Send connector. During installation, explicit Receive connectors are automatically created on each Hub Transport server. One Receive connector is configured to receive SMTP traffic from all sources by listening on port 25. A second Receive connector is configured to receive SMTP traffic from non-MAPI clients by listening on port 587. Explicit Send connectors and Receive connectors are created on Hub Transport servers only when you want to create a connector that sends messages to a specific address space or receives messages from a specific address range. For more information about connectors in Exchange 2010, see Understanding Send Connectors and Understanding Receive Connectors.

Return to top

X-EXCH50 Data

Exchange 2003 uses the proprietary verb X-EXCH50 to transmit information about messages and recipients that can't be included in the e-mail message. The information is transmitted as the Exch50 binary large object. Exch50 contains data such as spam confidence level, address rewriting information, and other MAPI properties that don't have MIME representation. Because X-EXCH50 is a proprietary Extended Simple Mail Transfer Protocol (ESMTP) verb, Exch50 data can't be propagated by a non-Exchange server.

Exchange 2010 supports a mapping between MAPI and MIME and doesn't require Exch50 data to reliably transmit message properties. To correctly coexist with Exchange 2003, Exchange 2010 servers can propagate the Exch50 data to Exchange 2003 servers. On incoming SMTP connections, Exch50-related properties used by Exchange 2010 are promoted to Exchange 2010-equivalent properties. Properties that aren't used by Exchange 2010 but are used by Exchange 2003 are preserved. On outgoing SMTP connections, the Exchange 2010 server can form the Exch50 data by promoting the Exchange 2010 properties and appending them to the preserved Exchange 2003 data.

Routing group connectors between Exchange 2010 and Exchange 2003 are automatically configured to support sending and receiving Exch50 data. If you are connecting Exchange 2010 to an Exchange 2003 server in a cross-forest scenario, make sure that the connector permissions allow the routing of Exch50 data. For more information, see Configure Cross-Forest Connectors.

Return to top

Message Tracking

The message tracking schema in Exchange 2010 is significantly different from the message tracking schema in Exchange 2003. The events logged by Exchange 2010 message tracking don't correspond directly to the message tracking events logged by Exchange 2003. Messages sent and received by Exchange 2010 can only be tracked by Exchange 2010 servers. There is no Microsoft Windows Management Instrumentation (WMI) support in Exchange 2010. Therefore, an Exchange 2003 server can't query for message tracking logs on an Exchange 2010 server. If a message tracking query in Exchange 2010 indicates that the message was transferred to an Exchange 2003 server, you must use the Exchange 2003 message tracking tool to continue to search for the message.

Return to top

Edge Transport Server Coexistence

The Edge Transport server role is designed to provide improved antivirus and anti-spam protection for the Exchange organization. The Edge Transport server also applies policies to messages in transport between organizations. This server role is deployed in the perimeter network and outside the Active Directory forest. The Edge Transport server can be deployed as a smart host and SMTP-relay server for an existing Exchange 2003 organization.

You can add an Edge Transport server to an existing Exchange organization without upgrading the internal Exchange servers or making any organizational changes. Because it deployed outside Active Directory, you don't have to perform any Active Directory preparation steps when you install the Edge Transport server. If you are using the Exchange Intelligent Message Filter in Exchange 2003 to perform anti-spam tasks, you can use the Edge Transport server to provide an additional layer of anti-spam protection.

When an Edge Transport server is deployed to support an Exchange organization that hasn't yet deployed Exchange 2010, certain features can't be used. You can't create an Edge Subscription in this scenario. Therefore, you can't use the Recipient Lookup or safelist aggregation features. For more information about using the Edge Transport server role with an Exchange 2003 organization, see Deploy the Edge Transport Server Role in an Existing Exchange 2003 Organization Before Upgrading to Exchange 2010.

Return to top