3. Implement Redundant Transport Servers
When implementing
redundancy for Transport servers, it's important to consider each job
that the server performs. Here are the primary components of Transport
servers that you will want to make redundant:
3.1. Implement Redundancy for Internal Message Routing
When a user sends a message in
Exchange, the message is submitted by the Mailbox server to a Hub
Transport server that is in the same Active Directory site. The Hub
Transport server is then responsible for sending that message to another
Transport server that is considered to be the next hop in order for the
message to reach its destination. So when considering redundancy for
internal message routing, you need to ensure that you have redundant
Transport servers for Mailbox servers to submit mail to. You also need
to ensure that you have redundant servers to receive the messages that
are sent from site to site by the Hub Transport servers that are routing
the messages inside Exchange.
The need for this level of redundancy is evident when you look at the example routing topology in Figure 7.
The Baltimore site only has one
Hub Transport server. If a message is sent from a user in Seattle to a
user in Baltimore and if the Baltimore Hub Transport server is offline,
the message will remain queued at one of the Seattle Hub Transport
servers. However, if a user in Baltimore sends a message to a user in
Seattle and one of the Hub Transport servers in Seattle goes down, the
message will be sent to the other Hub Transport server that is still
functioning. Users in Seattle can still send and receive email until the
problem is resolved and the second Hub Transport server is brought back
online. Leaving only one Hub Transport server in an Active Directory
site introduces a single point of failure for mail routing to that site.
Accomplishing this
level of redundancy for internal message routing is easy. You simply
install multiple Hub Transport servers in each Active Directory site
that contains Mailbox servers. No special configuration is necessary to
have internal message routing redundancy.
3.2. Implement Redundancy for External Message Routing
Ensuring that external
message routing is redundant requires a little more work than internal
routing redundancy. Whether you are using Hub Transport servers for
external messages or Edge Transport servers, implementing redundancy is
the same. There are two facets to consider:
3.2.1. Add Redundancy for Sending External Messages
To send mail outside an organization, you need to have a send connector configured. The send connector determines how mail destined for different
email domains is processed. Each send connector has a list of source
servers, which are the Transport servers that can be used to send mail
for the email domain name specified on the send connector. If there is
only one Transport server defined on a send connector and the Transport
server goes offline, messages destined to that domain namespace will not
be sent. Therefore, it's important to use multiple Transport servers in
a send connector.
To add Transport servers to an existing send connector, use the following steps:
Open the EMC and browse to the Organization Configuration => Hub Transport node in the Console tree.
Click the Send Connectors tab in the Work area.
The configured send connectors for the Exchange organization are displayed in the list.
Select
the send connector that you want to add redundant Transport servers to.
Click the Properties task in the Actions pane on the right.
In the properties dialog box for the send connector, click the Source Server tab.
The current Transport servers configured to send mail for the connector are listed on this tab.
Click the Add button to add an additional Transport server.
In the search dialog box that appears, select the Transport server that you want to add and click OK.
Add any additional Transport servers that you want to include by repeating this step.
When back in the properties dialog box, click OK to makes the changes and close the dialog box.
3.2.2. Add Redundancy for Receiving Internet Mail
When a Transport server is
Internet facing, the Mail Exchanger (MX) records for the domain's DNS
name are configured to point Internet mail servers to the Transport
server. For example, if joe@contoso.com is receiving a message from tim@fabrikam.com over the Internet, the fabrikam.com Mail server queries the contoso.com
DNS domain for MX records to determine which server should receive the
incoming message. Therefore, it's important to ensure that there are
multiple servers that can receive mail based on that MX record lookup.
There are two methods for making MX records redundant:
Create more than one MX record for a DNS domain. Point each MX record to an Internet-facing Transport server.
Create
a single MX record, but point it to multiple host records. Each host
record maps to the IP address of the Transport servers that are
Internet-facing.
When the first approach
is used, a DNS query returns all the MX records. It is then up to the
mail system that is sending the message to select the MX record to use
according to its internal algorithm. There is no guarantee that a
different server will be used each time, as the external server gets to
choose what to use.
However, with the second
approach, only a single MX record is returned. This MX record is the
host record that uses multiple IPs. When the sending server receives the
MX record, it performs a host record lookup and receives the list of IP
addresses behind that host record. The order of the IP list is
controlled by the DNS server, which uses a round-robin ordering or a
random ordering. The sending server chooses the first IP address in the
list and sends the message to that IP address. This method puts the
control in the hands of the DNS server and not the email system. Figure 8 and Figure 9 show how the DNS response is different in these two methods.
In addition to configuring
multiple MX records, you will want to ensure that you have a receive
connector on each of your Internet-facing Transport servers. The receive
connector allows the Transport server to listen for incoming mail on
the port that is configured. Edge Transport servers configure receive
connectors to receive Internet email automatically when the Edge role is
installed. However, if you have Internet-facing Hub Transport servers,
you need to modify the permissions on the default receive connector on
each Hub Transport server that is Internet-facing so that it can receive
messages from the Internet.
