1. Transport Improvements in Exchange Server 2010
Before we delve into how internal email routing
works, it's worth noting a few of the many improvements Exchange 2010
delivers in comparison to earlier versions of Exchange.
Prior to Exchange Server 2007, all messages were
processed by the same server that connected MAPI clients, managed the
information store, and hosted Outlook Web Access. This all-in-one
approach worked well for many years, but it couldn't scale with the
growing needs of organizations that had become increasingly dependent
on their messaging systems. To remedy this, Microsoft abstracted all
message-processing and delivery functions into the Hub Transport server
role. The Hub Transport server role processes all messages regardless
of their source or destination—even if they're in the same mailbox
database or on the same server. At first blush, this may seem
inefficient compared to routing in previous versions of Exchange. But
when you take into account features like message classification,
transport rules, and journaling, it makes sense for the Hub Transport
server to offload some of the Mailbox server role's burden. Actually,
those transport features have made it essential for the Hub Transport
server to now handle all messages in flight. Exchange Server 2010 lets
you do a lot with a message while it is in transit .
The Hub Transport server role can share a server
with any other server role, except for Edge Transport servers. This
means that if a Mailbox server does not also host the Hub Transport
server, then the entire message is transferred to the Hub Transport
server over the network via remote procedure calls (RPCs), categorized,
and finally routed to the appropriate location. This is true even if
that location is the same mailbox database from which the message
originated. This is one of the reasons that it is so critical to have a
Hub Transport server in each Active Directory site that contains a
Mailbox server. One of the design goals (well, not a goal, but a direct
result) was to abstract message transport functions out of the Mailbox
server completely. To properly control message flow, all messages
should be processed by a standard group of servers, exactly the same
way. As long as there are any types of transport functions being run by
the Mailbox server role, this goal cannot be met.
Also, the message transport architecture needs to be
able to treat all messages equally when processing transport rules and
other transport agents. Otherwise, transport rules would apply only to
server-to-server messages. By having the entire message sent through
the Hub Transport server, you can apply rules or functions not only to
the message header, but also to the entire message body and attachments.
Looking back to earlier versions of Exchange, administrators used routing groups (called sites
in Exchange 5.5) to build their email routing systems. Routing groups
allowed organizations to engineer a message transport solution unique
to their topology, but they were often superfluous to another
underlying architecture, Active Directory (AD). Exchange Server 2010
leverages your existing infrastructure by defining an AD site as the
natural boundary for the email routing infrastructure. As long as your
AD topology (including sites, site links, and site link costs) is
correctly designed, Exchange will automatically discover the most
efficient way to route email. However, between sites Exchange servers
will always initiate a point-to-point connection for message delivery,
rather than playing Pass-The-Message-Along with other Exchange servers.
Many Exchange administrators were puzzled by the
fact that Exchange 2000 and 2003 depended on Internet Information
Server (IIS) for SMTP services (which was not the case in Exchange
5.5). Happily, Exchange 2007 replaced IIS virtual SMTP servers with
send and receive connectors for establishing SMTP connections—all of
which is managed from within the Exchange Management Console (or
Shell). This means that IIS is no longer required by Exchange Server
2010 Server to perform email routing.
In maintaining the spirit of separating tasks, the
Edge Transport server role is the one server dedicated to message
delivery and filtering tasks. This hardened Exchange server's purpose
is to accept and deliver Internet email and perform message hygiene functions (such as antispam, content filtering, and antivirus) on messages before they enter the internal network.
The Edge Transport server is separated from the rest
of the Exchange server roles because it does not communicate directly
with Active Directory but utilizes an Active Directory Lightweight
Directory Services (LDS, previously known as ADAM) directory database
stored locally on the server. The Edge Transport server role was
designed to exist in a perimeter network/demilitarized zone (DMZ)
segregated from the internal network. Both the Edge Transport and the
Hub Transport servers facilitate transport in an Exchange organization.
Unlike a front-end server in Exchange
Server 2003, an Edge Transport server does not require connectivity to
your internal AD infrastructure to route email and only requires
minimal ports to be opened from your internal network (where your Hub
Transport servers reside) to the DMZ.
