Backward Compatibility with Exchange Server 5.5

Exchange Server 5.5 relies on Gateway Address Routing Table (GWART) to select routes in an Exchange organization. This method uses a distance vector routing algorithm, which is susceptible to routing loops in certain situations. Exchange Server 2003, however, uses a link state table that is stored in memory, together with Dijkstra's shortest path algorithm, to select routes. However, for backward compatibility, Exchange 2003 must generate a GWART, so that Exchange 5.5 servers can use Exchange 2003 connectors. Also, the routing engine must incorporate existing Exchange 5.5 connectors in the link state table, so that Exchange Server 2003 servers can use these transfer paths.

Generating the GWART

The Exchange MTA generates the GWART. The Exchange MTA communicates with the routing engine through the routing interface wrapper, MTARoute.dll, to obtain routing information. It then writes this information to the gatewayRoutingTree attribute of an object named legacy GWART, which resides in the administrative group of the Exchange server. The MTA also updates the GWARTLastModified attribute to indicate the most recent changes. The Site Replication Service (SRS) replicates the GWART object to the Exchange 5.5 directory. After this, Exchange 5.5 servers can include Exchange Server 2003 connectors in their routing decisions.

Routing Issues in Mixed Mode

Site Replication Service also replicates Exchange Server 5.5 connector information to Active Directory. Therefore, servers running Exchange Server 2003 can route messages across Exchange Server 5.5 connectors. This allows Exchange Server 2003 users to send messages over any existing connectors, such as connectors not available in Exchange Server 2003. This includes connectors such as Connector to Microsoft Mail for PC Networks. The functionality of routing groups in a mixed-mode environment, in which some servers are running Exchange Server 2003 or Exchange 2000 Server, while other servers are running Exchange Server 5.5, is limited in the following ways:

• Routing groups cannot span multiple administrative groups. This is because the routing topology in Exchange Server 5.5 is defined by sites. Sites in Exchange Server 5.5 provide the functionality of both the administrative group and the routing group in Exchange Server 2003. This difference in routing topology limits the functionality of routing groups in a mixed-mode environment.

• You cannot move servers between routing groups that exist in different administrative groups.

• Exchange Server 5.5 connectors with a local scope are available to all Exchange 2003 users in the organization, because this connector scope has no counterpart in Exchange Server 2003. In Exchange Server 5.5, you can specify connector availability at three different levels: organization, site, and server location. In Exchange Server 2003, only the organization and routing group (site) scopes are available.

Topology Updates

Because Exchange Server 5.5 servers do not use a link state table, routing groups with a routing group master running Exchange Server 5.5 (that is, sites without a server running Exchange Server 2003) do not send topology updates. To address this issue, routing group masters periodically obtain the routing group topology for all Exchange Server 5.5-controlled routing groups from Active Directory and then replicate this information across the Exchange Server 2003 routing topology.

You can configure the following registry key on a routing group master to determine when the routing engine reads topology information from Active Directory.

ReloadOsInterval

Broken Link State Propagation

Servers running Exchange 2003 do not expect servers running Exchange 5.5 to exchange link state information with them. However, when a bridgehead server running Exchange 5.5 in an Exchange routing group is replaced with a server running Exchange 2003 and is designated as a bridgehead server, the routing group begins to participate in the propagation of link state information. It no longer has a major version number of zero. A major version number of zero indicates a server that does not participate in link state information or does not exchange link state information. All servers running Exchange 5.5 have a version number of zero, because they do not exchange link state information.

When a routing group propagates link state information, its major version number increases. Bridgehead servers in other routing groups expect to receive link state changes from this routing group. However, a problem occurs if you revert the bridgehead server to Exchange Server 5.5, because the bridgehead server then has no link state table. Other servers still expect the bridgehead server running Exchange Server 5.5, formerly the bridgehead server running Exchange Server 2003, to participate in link state propagation. Therefore, other servers wait for this server to give them updated link state information. When this occurs, this routing group becomes isolated and does not participate in dynamic link state updates in the organization.

The following figure illustrates a situation in which this isolated routing group can be problematic. Specifically, because the Exchange 5.5 bridgehead server in the Exchange 5.5 routing group was formerly and Exchange 2000 or Exchange 2003 bridgehead server, the other servers expect it to participate in link state propagation. In Figure 5.13, the Exchange Server 5.5 Internet Mail Connector and Exchange Server 2003 SMTP connector both use a single smart host to route mail to the Internet. The smart host becomes unavailable. Therefore, the bridgehead server running Exchange Server 2003 marks the route through its SMTP connector as unavailable. However, because the bridgehead server expects the server running Exchange 5.5 to send link state information about its routing groups and connectors, it assumes that the route through Internet Mail Connector is available and attempts to deliver messages through this route. After one failure, the server running Exchange 2003 detects a possible loop and does not attempt delivery through this route.

Servers running Exchange 5.5 and Exchange 2003 connecting to a smart host

Link state propagation can also be broken if a firewall that is blocking link state propagation is added to the system. For example, ports 25 and 691 are required within a routing group and port 25 is required between routing groups. Also, the Extended Simple Mail Transfer Protocol (ESMTP) command X-LINK2STATE must not be blocked by a firewall.

To resolve this problem, the following solutions are available:

• Upgrade the Exchange 5.5 bridgehead server to an Exchange 2000 or Exchange 2003 server, or use another Exchange 2000 or Exchange 2003 server to send link state information for this routing group again. Either of these options provides the preferred and simplest resolution.

• To reset non-connected routing groups to link state major version number 0, shut down all Exchange servers in your organization simultaneously, and then restart all Exchange servers.

• Configure the firewall so that link state propagation is not prevented.

For more information about isolated or disjointed routing groups and the major version numbers, see Microsoft Knowledge Base article 842026, "Routing status information is not propagated correctly to all servers in Exchange 2000 Server or in Exchange Server 2003."