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.
Previous
Register
