Let's start with a review of how Exchange 2010
delivers messages in a single Exchange organization. While similar to
Exchange Server 2007, the message-routing architecture is sufficiently
different from earlier versions of Exchange 2000/2003 (which is the
version from which more administrators are moving to Exchange Server
2010) that it deserves additional mention.
You should understand a few important points about the basics of Exchange 2010 message routing:
All messages must go through the Hub Transport server role.
The Active Directory site architecture is used as a boundary for message routing.
All Active Directory sites that contain a Mailbox server must also have a Hub Transport server and a Client Access server.
One of the nice features of Exchange Server 2010 is
that as long as your Active Directory site architecture has been
properly configured, you will not need to worry about message-routing
architecture design.
1. Basics of Exchange Message Routing
In earlier versions of Exchange, the message-routing
architecture was based on a structure that was defined by the
administrator. For example, in Exchange 2000/2003, the message-routing
architecture was defined by a collection of servers separated by
full-time and reasonably good available bandwidth. This collection of
servers is called a routing group. Prior to Exchange 2000, all servers were grouped together into a single collection of servers called a site.
In Exchange 2000/2003, the administrator could
define the routing groups and move servers between routing groups based
on their message-routing requirements. Messages were then delivered
between routing groups using some type of connector. The most common
connector for routing groups is a connector called the routing group connector (RGC), which uses RPC or SMTP to deliver messages.
Exchange Server 2007 changed this by relying on the
Active Directory site architecture rather than requiring administrators
to create a separate routing infrastructure for their organization.
Exchange Server 2010 builds on this major architectural change and
continues to rely on Active Directory sites for message routing. Figure 1 shows a simple Active Directory site topology that consists of three Active Directory sites.
In Figure 1,
each Active Directory site has a Mailbox server and a Hub Transport
server. The Hub Transport server will always attempt a direct delivery
of a message to a Hub Transport server in a remote Active Directory
site even if that remote Active Directory site does not have an Active
Directory site link directly to it. If you are still running any
Exchange 2003 servers, though, they retain their routing group
architecture and have routing group connectors to the Exchange 2010 Hub
Transport servers.
|
For some companies, the default site routing mechanism is not adequate.
Earlier, we briefly described a major architectural
change for Exchange Server 2007 that was also adopted by Exchange
Server 2010. This change is direct point-to-point connection
(notwithstanding the underlining network infrastructure) for email
delivery, which basically summarizes the desire
of an Exchange server to deliver a message to its final destination
site. If that delivery is not successful, a Hub Transport server will
try to contact another Hub Transport for queuing and later delivery.
By default, Exchange Server 2010 Hub Transport
servers always attempt to directly deliver a message to a remote Hub
Transport server (in another Active Directory site). This feature
ensures the quickest and most direct delivery of email messages to
remote sites. The Hub Transport server ignores the Active Directory
site link costs (and possibly your underlying network topology) and
performs direct delivery. Note that Active Directory site link costs
are relevant if the final destination is unavailable, and then the next
site along the least cost route is contacted for email queuing. The
servers in that site will then attempt to redeliver the message to the
final destination based on its configured intervals.
We recently consulted for a company that required
all email be delivered through a "hub" site. This is still possible by
modifying the behavior of the Hub Transport delivery mechanism using
the Set-AdSite Exchange Management Shell cmdlet. To make this functionality work, we followed these steps:
Enable the hub site functionality using a command similar to this: Set-AdSite SiteName -HubSiteEnable $True
Ensure
that the Active Directory site link costs truly represent a "least
cost" route from the remote sites to the hub site. Why? Well, the override feature of a hub site only
works if that hub site is within the least cost path, as defined by the
Active Directory Site Link costs. If the Hub Site is not within the
least cost path and you don't want to disrupt your Active Directory
replication topology, you can also create an Exchange-specific site
link cost. The Exchange-specific site link cost is set by using a shell
command such as this one: Set-AdSiteLink -Identity SiteLinkName -ExchangeCost CostValue
Luckily, the environment that we were working with
already had the hub site within its least cost path, so that second
command was not necessary. After the modifications were made, the
Exchange routing topology resembled the underlying network
infrastructure of routers and WAN links.
So Microsoft recommends that you implement hub site
routing only if your network topology requires it, such as when you
have a firewall between all the remote sites.
|
The Hub Transport server role is at the center of
the message-routing architecture for messages being delivered
internally as well as messages leaving the organization. All messages
are processed by the Hub Transport server role regardless of whether
they are being delivered locally or remotely. Figure 2 shows an example of the Hub Transport server sitting at the center of the message delivery universe.
The Hub Transport server role handles
categorization, rule processing, transport-level journaling, and
delivery for mail that is intended for local delivery and Mailbox
servers in the same Active Directory site. The Hub Transport server
uses the messaging API (MAPI) and RPCs to communicate with the Mailbox
server role. If a message is to be delivered to a Mailbox server in a
remote Active Directory site, the Hub Transport server delivers the
message via SMTP to a Hub Transport server in the remote site; the
remote Hub Transport server then delivers the message to the local
Mailbox server via RPC.
The Exchange Server 2010 Hub Transport server
handles message categorization. The Categorizer component figures out
where the message is going next. Messages arrive in the submission
queue, and the Categorizer picks up the message and processes it. Here
are some of the steps involved in message categorization:
Expand any distribution lists, if applicable, by querying the global catalog.
Resolve recipient addresses to determine which recipients are local, remote, or outside the organization.
Apply message transport rules to the message.
Split the message into multiple parts if the message is going to both local and remote recipients; this process is called bifurcation.
Examine
the message sender, recipients, message header, body, and attachments
and apply message transport rules that apply to that message.
Convert
the message to the appropriate message format (Summary-TNEF, MIME, or
UUencode) depending on the destination of the message.
Determine the next "hop" for the message.
Place the message into appropriate local or remote delivery queue.
With a few exceptions, such as application transport rules, the Categorizer function has not changed from Exchange 2000/2003.
As messages are moved within your organization's
infrastructure, they are protected with different types of encryption.
The encryption used is either RPC encryption or Transport Layer
Security (TLS) encryption. Figure 3 shows different paths the message may take and how it is encrypted.
As messages are transmitted via MAPI over RPC
between Mailbox servers and Hub Transport servers, RPC encryption is
automatically used. When a message is transmitted from one Hub
Transport server to another, the Hub Transport servers transport the
message using SMTP, they authenticate using Kerberos, and the data
stream is encrypted using TLS. When messages are transmitted from a Hub
Transport server to an Edge Transport server, SMTP is used for message
transfer, mutual authentication using certificates is used for
authentication, and messages are encrypted using TLS. Optionally, an
organization that is sending messages to another organization also
using Edge Transport services can configure authenticated connections
and TLS encryption to these remote organizations.
There are so many things that have changed in
transport settings and transport configurations in Exchange Server
2010, that I like to keep a little "Cheat sheet"; a list of changes
that are very relevant for administrators of previous versions of
Exchange. We usually provide this list to our students, when we teach
an Exchange class, and they find it very useful.
Hub Transport servers never connect to other Hub transport servers in the same site.
Hub Transport servers always communicate over SMTP to Hub transport servers in other sites.
Hub Transport servers always communicate over RPC to Mailbox servers in the same site.
If
you install multiple Hub transport servers in the same site, Mailbox
servers will automatically load balance the connections between the Hub
transport servers.
When the Mailbox
server and Hub Transport server roles coexist on the same server, the
Mailbox server will always attempt to use another Hub Transport server
in the site, instead of the locally installed Hub Transport server.
Hub Transport servers encrypt all connections, by using Mutual TLS, to other Hub Transport servers in other sites.
Hub
Transport servers handle all email messages sent between all users,
even two users who have mailboxes in the same Mailbox database.
Client Access servers never communicate with Hub Transport servers.
