Deployment Options for Hub Transport Servers
Applies to: Exchange Server 2010 Topic Last Modified: 2008-12-08
This topic discusses supported topology options for the Microsoft Exchange Server 2010 Hub Transport server role. The Hub Transport server is a required role for an Exchange 2010 organization. Each Active Directory directory service site that contains the Mailbox server role must include one or more Hub Transport servers.
The topology option that you select will affect how the server role is deployed. Configuration of Send connectors and Receive connectors and message transport features will depend on placement of the Hub Transport server relative to other server roles. For a better understanding of how message flow and processing occur, see Understanding Transport Pipeline.
The following topologies are supported:
Exchange 2010 Hub Transport server role in an Exchange 2007 infrastructure
Exchange 2010 Hub Transport server role in an Exchange Server 2003 infrastructure
Exchange 2010 Hub Transport server role deployed on separate hardware
Exchange 2010 Hub Transport server role hosted on the same hardware as other server roles
Note: You cannot install the Hub Transport server role on a server that is configured as part of a cluster.
To complete mail flow configuration for the Exchange organization and to send and receive e-mail to and from the Internet, you must configure Send connectors and Receive connectors that enable at least one Hub Transport server to connect to the Internet. You can configure Internet connectivity for a Hub Transport by using any of the following methods:
You can deploy an Edge Transport server and subscribe it to the Exchange organization. This is the recommended deployment method. By default, when you create the Edge Subscription, the required Send connectors are automatically created. You do not have to modify the configuration of the default Receive connector on the Hub Transport server for this scenario.
You can send and receive Internet e-mail by relaying through Microsoft Exchange Hosted Services or another third-party Simple Mail Transfer Protocol (SMTP) gateway server. In this scenario, you have to create a Send connector and a Receive connector between the Hub Transport server and the external SMTP servers that process and route Internet e-mail.
You can establish Internet mail flow directly through a Hub Transport server. In this scenario, you have to create a Send connector that routes e-mail to the Internet. Also, you have to modify the configuration of the default Receive connector to accept anonymous e-mail submissions. In this scenario, the Exchange 2010 Hub Transport server can be reached directly through the Internet. We don't recommend this topology because it increases security risks by exposing to the Internet the Exchange 2010 server and all roles installed on that server. We recommend that you implement a perimeter network-based SMTP gateway, such as the Edge Transport server, instead.
Note You can install the anti-spam agents on the Hub Transport server role by using the Install-AntiSpamAgents.ps1 script. This script is located in the <system drive>/Program Files/Microsoft/Exchange Server/Scripts folder. After you run this script, all the anti-spam agents are installed and enabled, and the Anti-spam tab is available in the Exchange Management Console for Hub Transport servers. We recommend that you install the anti-spam agents if you select this topology so that the Hub Transport server can provide anti-spam protection for the Exchange organization.
|If you configure an Internet-facing Hub Transport server, you cannot configure a Send connector to attach a particular IP address to messages that are sent from the Hub Transport server. For example, if more than one IP address is assigned to the Hub Transport server, you cannot select which IP address is used by a Send connector to relay e-mail to the Internet. If you use an SMTP relay, such as an Edge Transport server, the IP address of that computer is affixed as the message source.|
You configure fault tolerance and load balancing for Hub Transport servers when you install more than one Hub Transport server in the same Active Directory site. By default, connections to Hub Transport servers are automatically load balanced if more than one Hub Transport server is deployed in an Active Directory site. If one Hub Transport server is unavailable, the operational Hub Transport servers continue to accept connections. If all Hub Transport servers in an Active Directory site are unavailable, messages are queued until a Hub Transport server becomes available or the messages expire.
Load balancing of outbound connections to remote domains is achieved by specifying more than one Hub Transport server in the same Active Directory site as a source server for the Send connector. Load balancing does not occur when the source servers for a Send connector are located in different Active Directory sites.
|If the Hub Transport server is installed on the same hardware as the Mailbox server role, load balancing may not occur. When the Hub Transport server role is on the same hardware as the Mailbox server role, the local server is preferred for all messages that are sent by users who have mailboxes on that server. Therefore, in this scenario, true load balancing does not occur.|
Load balancing of inbound SMTP connections for POP and IMAP client connections to the default Receive connector named "Client <Server Name>" that is created only on Hub Transport servers.
Load balancing of inbound SMTP connections for applications that submit e-mail to the Exchange organization.
NLB should not be used to distribute connections for internal routing between Hub Transport servers.
NLB is a good high availability option for both the Hub Transport server role and the Client Access server role when the Mailbox server role is deployed in a cluster.
For more information about how to configure Network Load Balancing, see the following topics:
For more information, see the following topics: