The
Hub Transport server is part of the internal Exchange Server
infrastructure. The Hub Transport server role handles all internal mail
flow, applies transport rules and journaling policies, and delivers mail
to the Mailbox server role for placement in the user’s mailbox. It also
receives Internet mail from the Edge Transport server role, though the
Hub Transport can also be configured to receive mail directly from the
Internet. It is the evolved form of the bridgehead server in Exchange
Server 2003, which was really the name of a configuration rather than a
specific server component. The Hub Transport server has been developed
to provide a number of key features that Exchange Server customers have
long been clamoring for, such as disclaimers and transport rules.
The Hub Transport server provides four major services:
These services
can collectively check mail for any problems such as spam or viruses,
check mail for appropriateness, append any information that the
organization needs, and finally route mail to the correct destination.
New to Exchange Server 2010 is the Shadow Redundancy feature, which
ensures delivery of messages by retaining a shadow copy and verifying
delivery before releasing the shadow copy.
There should be a Hub
Transport server in every AD site where there is a mailbox server for
mail to flow and route correctly. Additional Hub Transport servers can
be deployed for fault tolerance and load balancing, especially when
paired with an Edge Transport server.
Mail Flow
The Hub Transport
server is responsible for processing all mail that is sent within an
Exchange Server 2010 organization. There is no exception to this. This
allows the Hub Transport server to accomplish its other functions, such
as categorization and routing.
It is important to
understand that there are no exceptions to this rule. Thus, all mail
flows through the Hub Transport servers. This ensures that the features
that Hub Transport servers provide, such as transport rules,
disclaimers, and journaling, are applied uniformly across the entire
Exchange Server 2010 infrastructure.
Categorization
The
categorizer does all the address lookups, route determination, and
conversion of the content of messages. It is at this stage that the
various agents, such as the transport rules agent and the journaling
agent, process mail as well. It determines where the messages are
destined to and what transport rules and journaling policies apply to
the messages.
Although
antispam and antivirus protection is provided by default at the Edge
Transport server role, the Hub Transport server role can also be
optionally configured to perform the scanning. This would take place at
the categorization stage as well.
Routing
The Hub Transport
server determines the path to route mail to. This applies to all
messages that are not destined for mailbox servers in the local site.
Messages that are destined for a mailbox server that is in another AD
site are routed to a Hub Transport server in that site, whereas messages
destined for external recipients are routed to Edge Transport servers.
Microsoft Exchange Server
2010 is AD site aware and uses the AD site topology for routing
internally. It computes the most efficient—that is, lowest cost—route
based on the sites and site links that it reads from Active Directory.
Note
It is critical to define
the sites and the subnets that are associated with the sites for
Exchange Server 2010 to route mail properly. These are fundamentally
Active Directory design and deployment tasks, but not having it done
properly can result in incorrect routing of email.
This is true for all
Active Directory–aware applications, such as Exchange Server 2010,
System Center Configuration Manager (SCCM), distributed file system
(DFS), and even Active Directory itself. Without a properly designed and
deployed site and subnet infrastructure, they will fail or perform
inefficiently.
The Hub Transport
servers are intelligent and understand the architecture of the network
based on the information in the sites and IP site links. If a message is
destined for two different recipients, the Hub Transport servers will
delay bifurcation of the message until the last possible hop.
This is illustrated in Figure 1.
The user Chris in San Francisco sends a message to Sophia and Mike, who
are in different locations (London and Frankfurt) and, thus, in
different AD sites. A single message is routed through the transport
from San Francisco to New York until it reaches Paris, which is the last
possible hop for the message to split. The Paris Hub Transport server then bifurcates the message and sends one to London and one to Frankfurt.
Delivery
If the categorizer
determines that the recipient of the messages is on a mailbox server in
the local AD site, the message is delivered directly to the mailbox
server.
Shadow Redundancy
The Shadow Redundancy
feature in Exchange Server 2010 gives message routing a fault tolerance
capability. The concept behind shadow redundancy is that a message is
not deleted from the queue until the next hop has confirmed delivery to
the subsequent hop. If confirmation is not received, the message is
resubmitted. If the next hop server is down, the message is resubmitted
to another server.
Note
Assured delivery
requires that there be redundant Hub Transport and Edge Transport
servers to resubmit to if a failure of any given transport server
occurs.
The components of the shadow redundancy follow:
Primary Message— The original message submitted to transport for delivery.
Shadow Message—
The copy of a message that a transport server retains until it confirms
that all the next hops for that message have successfully delivered it.
Primary Server— The transport server that is currently processing a message.
Shadow Server— The transport server that holds shadow copies of a message after delivering the message to the primary server.
Shadow Queue—
The queue that a transport server uses to store shadow messages. A
transport server will have separate shadow queues for each primary
server to which it delivered the primary message.
Discard Status— The information a transport server maintains for shadow messages that indicates when a message is ready to be discarded.
Discard Notification— The response a shadow server receives from a primary server indicating a message is ready to be discarded.
Shadow Redundancy Manager— The transport component that manages shadow redundancy.
Heartbeat— The process of transport servers verifying the availability of each other.
A mail flow with
shadow redundancy is given in the following example. In the example,
Chris with mailbox on Exchange Server 2010 mailbox server MB1 is sending
a message to Michelle with a mailbox on Exchange Server 2010 mailbox
server MB2. There are two Exchange Server 2010 Hub Transport servers:
HT1 and HT2. The process is as follows:
Chris submits message— The message is submitted to MB1. MB1 becomes the primary server for the message.
Note
Client submissions
such as MAPI, Windows Mobile, or SMTP client are not redundant until the
message is successfully stored on the mailbox or hub transport server.
Then the Exchange Server high-availability features take effect.
MB1 submits to HT1—
The message is submitted by MB1 to HT1. HT1 becomes the primary server
and MB1 becomes a shadow server. However, HT1 subsequently fails and
never acknowledges the delivery of the message to MB2. MB1 times out and
becomes the primary server.
MB1 submits to HT2— The message is resubmitted by MB1 to the redundant HT2. HT2 becomes the primary server and MB1 becomes a shadow server.
HT2 submits to MB2—
The message is submitted to by HT2 to MB2. MB1 confirms that HT2 has
delivered the message, deletes the message from its shadow queue, and is
no longer a shadow server.
Michelle receives message— The message is received by Michelle.
The process is diagrammed in Figure 2.
Shadow redundancy gives
the Exchange Server 2010 self-healing capabilities for mail flow. It
enables the infrastructure to intelligently fail over between redundant
paths if messages have not been delivered in a timely manner.
