Exchange 2007 Transforms Message Routing

Next, Microsoft eliminated the concept of routing groups altogether. Exchange 2007 still has a single default routing group, provided for coexistence with Exchange 2003 and Exchange 2000, named DWBGZMFD01QNBJR (which happens to be EXCHANGE12ROCKS shifted down one character). All the Exchange 2007 servers you add will end up in this default routing group; there's no supported way to put them into a legacy Exchange 2003 or Exchange 2000 routing group. If you have more than one legacy Exchange routing group, you'll need to expend some effort to provide coexistence between those routing groups and Exchange 2007's routing behavior. During installation of Exchange 2007, you'll be asked to choose a bridgehead server in the first Exchange 2003 or Exchange 2000 routing group; this step is required so that the Exchange 2007 installer can create an RGC to link the Exchange 2007 routing group with your existing routing groups. You can create additional RGCs to get more granular control over the routing process if you like. For best message routing, Microsoft recommends that you create additional RGCs from each of your existing routing groups to the Exchange 2007 routing group, essentially making it the hub of a hub and-spoke routing topology. Using this topology reduces the number of hops a message has to take between different legacy routing groups.

There are a few other site-related changes in Exchange 2007:

• Public folder referrals have changed. Exchange 2003 and Exchange 2000 use a complicated algorithm to find the least-cost replica for a given mailbox client. That algorithm is dramatically simplified in Exchange 2007: The Information Store (IS) builds a list of all the public folder databases it can find, ranking them by access cost; databases in the current site are least expensive, and the rankings for the rest of the list are controlled by the site-link costs.
• Unified Messaging (UM) servers use site membership to find the best Hub Transport server for delivering a message to a particular user mailbox.
• Client Access servers use site membership to determine whether a user request should be redirected to another Client Access server. For example, say user A has a mailbox in site 1, but she connects to a Client Access server in site 2. The site 2 Client Access server can detect that the user's mailbox is in site 1, so it will redirect the request to a site 1 Client Access server.

How Messages Flow
Remember that a Hub Transport server must touch every message sent between two Exchange 2007 users, even if the users are on the same Mailbox server. With that in mind, we can explore some of the interesting differences in Exchange 2007 message routing. There are really only two possible scenarios: Either the sender and recipient are in the same site, or they're in different sites.

Consider the simplest case: two users on the same Mailbox server. User A's message is submitted to the IS, which routes it to the Hub Transport server (which, in this case, is probably on the same physical server), which routes it to B's mailbox. Site information doesn't play an obvious role in this process, but the Hub Transport server still has to check AD for site data to determine whether B's mailbox is in the same site. From this, you can easily see that the same-server and same-site cases are essentially the same and will work the same way.

The more complex—and interesting— case is when the sender is in one site and the recipient is in another. In this case, the sender's client submits the message to the sender's Mailbox server, which then sends it to the Hub Transport server in its local site. That Hub Transport server attempts to find the most efficient path for the message, beginning by computing the cost of all possible routings and using the resulting list of routing costs to attempt the least expensive connection directly to the target site's Hub Transport server. The routing engine prefers direct connections whenever possible, so if two routes with equal costs exist, the routing engine will choose the one with the shortest number of hops.

Because sites and site links were originally designed for finding local services, Windows doesn't have a concept of a service-related cost for sites or site links: The cost associated with a link is essentially fixed. However, you can set an Exchange-specific cost on site links by using the Set-AdSiteLink Exchange Management Shell cmdlet. If you specify an explicit Exchange cost for a site link, Exchange uses the cost for routing-cost calculations. However, other Windows services (notably AD replication) ignore the Exchange-specific cost.

The Exchange cost comes into play in scenarios where the destination Hub Transport server isn't directly reachable, which can happen for two reasons:

• The link to the target site is down. Consider three sites, A, B, and C, where each site is connected to the other two. Usually a message can go directly from A to C, but if the A to C link is down, the Hub Transport server can route the message A to B to C to deliver it.
• You've set up a hub site, which is essentially the equivalent of an Exchange Server 5.5–style hub-and-spoke topology. All messages go from the originating Hub Transport server to the hub site, then to their destination. The Exchange 2007 documentation is pretty clear about the utility of this topology; it warns that hub sites "should only be used when it is required by the network topology, such as when firewalls exist between Active Directory sites and prevent direct relay of Simple Mail Transfer Protocol (SMTP) communication" (http://technet.microsoft.com/en-us/library/0f697cee-bcaa-4c69b80c-7a2afd1817d2.aspx). To establish a hub site, you have to use the Set-AdSite cmdlet through Exchange Management Shell.

Preparing for Sharing
When you add the first Exchange 2007 server to an existing Exchange organization, Exchange 2007 setup asks you to pick a target bridgehead server in the existing organization. The server you pick is used to establish an RGC, so plan ahead to make sure that you're selecting a server in a routing group with good connectivity. All messages you send between mailboxes on the Exchange 2007 server and the existing servers will pass over this connector. All Exchange 2007 servers go into the Exchange 2007–specific DWBGZMFD01QNBJR routing group; you can't put them anywhere else. This can lead to undesirable routing because all messages between the Exchange 2007 and legacy Exchange parts of your organization have to traverse that connector, no matter where the servers are physically located. To work around this problem, Microsoft recommends that you create additional RGCs between DWBGZMFD01QNBJR and target routing groups; to do so, you'll use the New-RoutingGroupConnector Exchange Management Shell cmdlet.

You also have to consider link state updates from Exchange 2003 and Exchange 2000 routing groups. If you have only one RGC, link state updates won't be a problem. However, if you have multiple connectors, link state changes will be propagated only among your Exchange 2003 and Exchange 2000 servers. The Exchange 2007 Hub Transport role doesn't understand link state updates and won't accept them when offered by legacy servers, so the Hub Transport servers might attempt to route messages over connectors that are currently down. This can lead to slow delivery times at best or message loops at worst. Microsoft recommends setting the SuppressStateChanges registry subkey (described in detail at http://www.microsoft.com/downloads/details.aspx?familyID=62fb1297-4c6b-4d84-84cc060989f2f305) to turn off connector-status change messages. When you do so, Exchange 2003 and Exchange 2000 will essentially act like Exchange 2007 in that they'll rely on only route-cost information and not route-status information when making routing decisions.

When you move mailboxes from Exchange 2003 and Exchange 2000 servers to Exchange 2007, you'll need to decommission the older servers; as you remove them, they'll be removed from the routing topology. However, you'll need to remove RGCs manually as you remove individual legacy Exchange routing groups, as well as remove any RGCs between your Exchange 2007 pseudo–routing group and the rest of your organization. This is a straightforward process, but it requires you to watch message flow carefully to ensure that you're not stranding messages on a server or preventing flow from other servers that may depend on a particular connector or bridgehead.

A Better System
Message routing has changed significantly in Exchange 2007 as Microsoft added the Hub Tranport server role and eliminated routing groups altogether, but the changes offer a better system for moving messages. However, efficient message flow will depend on having a proper AD site design. If you're not confident that your site topology maps correctly to the layout of your network, you should begin correcting it now to smooth your Exchange 2007 upgrade process.

End of Article

   Previous  1  [2]  Next