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.