Microsoft Exchange Server 2007 introduces a lot of changes to the Exchange world. Most of these changes have been well-publicized, such as the move to 64-bit hardware and the introduction of the Exchange Management Shell—based on Windows PowerShell—as a new scripting environment. However, there are other changes that have received less attention because they don't apply universally to every Exchange organization. One of these changes is the shift in how Exchange 2007 uses routing groups: In brief, it doesn't! Let's look at the routing changes in Exchange 2007 and see what you need to do to prepare for Exchange 2007 deployment in environments with multiple routing groups.
Out of Site
Since the release of Windows 2000, Microsoft has provided a set of tools for
working with segmented networks: the Active Directory (AD) site, site link,
and site link bridge objects. These objects provide a way to add knowledge of
the underlying network to an AD topology. Windows uses this information to perform
a variety of tasks. For example, when a computer boots, it can issue DNS queries
to find out which domain controllers (DCs) are in the same site because these
should be more readily available and faster than DCs in nonlocal sites.
You should think of a site as a collection of connected IP subnets. Sites aren't the same as domains; a domain can span multiple sites, and a site can contain multiple domains. However, the design of the Windows site model means that every computer (whether server or client) must be a member of exactly one site. When you set up AD in a new forest, you get a new site named Default-First-Site, and your DCs all go into it unless you manually create new sites. As you create new sites, computers will be assigned to the correct site based on their IP address.
Site links are network constructs that join independent sites. Site links have costs associated with them; using these costs, Windows can construct a least-cost path for specific types of network connections. For example, Windows uses the set of site links you define to find the most efficient path for AD replication. For our purposes, we don't really care what the underlying network implementation of the site link is, merely that a link exists between sites.
Sites and site-link definitions are kept in order by the Windows Knowledge Consistency Checker (KCC) service. Don't confuse this with the Exchange Server 5.5 KCC, nor with the process of the same name in the Exchange Server 2003 and Exchange 2000 Server Site Replication Service (SRS). The Windows KCC is responsible for ensuring that the system's map of which DCs are in which sites is up to date. If the map diverges from the actual network topology, replication problems are likely to occur.
You add new sites and site links by using the Active Directory Sites and Services console, which Figure 1, shows. You specify the sites first, then define links to represent the underlying network connections.
Changes in Message Routing
Exchange 2003 and Exchange 2000 let you define multiple routing groups within
a single Exchange organization. Each routing group has a single computer that
acts as the routing group master, plus one or more routing group members. Within
a routing group, individual servers maintain their own link state table: a series
of vectors that indicate the endpoints of a link, its cost, and its status.
You can view the contents of a server's link state table by using the WinRoute
tool, which you can download from Microsoft's Web site (http://www.microsoft.com/downloads/details.aspx?familyid=c5a8afbf-a4da-45e0adea-6d44eb6c257b),
but it's enough to know that individual servers update their local link state
tables whenever they notice changes to a link's status. When this update occurs,
the server shares its updated link information with its routing group master,
which in turn floods the other servers in the routing group with a knowledge
update.
This architecture offers a flexible way for individual servers to determine which links are available, but it suffers from scalability problems in large networks. Furthermore, it's devilishly difficult to get incorrect or corrupted entries out of all the link state tables in your Exchange organization; to do so, you have to turn off the routing engine service on every Exchange server in your organization, and they all have to stay off until the last server's engine is off. At that point, you can restart the routing engine and allow servers to re-create their local copies of the routing map.
In addition to these problems, it can take a while for changes to the link state table to propagate throughout the organization; routing changes can occur faster than they can be broadcast to all servers in the network. Adding to this complexity, routing groups must be linked by Routing Group Connectors (RGCs), and each connector has to specify at least one bridgehead server on each end. RGCs aren't terribly useful for routing configurations where there's only one path out of a given routing group.
Like Exchange 2003 and Exchange 2000, Exchange 2007 uses SMTP as its primary message transport protocol. However, Exchange 2007 makes some major changes to message routing to both simplify the process and improve its reliability. First, it introduces the Hub Transport server role. Hub Transport servers move messages between Mailbox servers and the outside world; for example, if Alice and Bob are on two different Mailbox servers, any messages that Alice sends to Bob must pass through a Hub Transport server. Also, messages coming in from the Internet must pass through a Hub Transport server even if they've already passed through an Edge Transport server. Even in an organization with a single Mailbox server, you'll still need at least one Hub Transport role. But the Hub Transport role can coexist with other server roles, so you don't need a separate physical server.
The Hub Transport role acts as a sort of universal bridgehead for the site it's in; any Hub Transport server in any site can communicate with any other Hub Transport server in the organization. Mailbox servers will always attempt to route outbound mail to a Hub Transport server in the same site first, and a Hub Transport server has to accept mail for delivery to its same-site Mailbox servers. You don't have to do anything to make this process happen. If the Hub Transport server in the Mailbox server's local site is down, the Mailbox server will attempt to find the nearest Hub Transport server according to the AD site topology.
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.