Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2012-03-16
Service Pack 2 (SP2) for Microsoft Exchange Server 2010 gives you the ability to host some of your Exchange users in an Exchange Online organization hosted in Microsoft Office 365 for enterprises while maintaining a seamless messaging experience for all your users. This topic provides an overview of how Transport servers are used in this scenario.
A hybrid deployment requires at least one server running Exchange Server 2010 SP2 in your organization. If you’re currently running a previous version of Exchange, you must add one or more Exchange 2010 SP2 servers to act as gateways to the Exchange Online organization. By doing so, you can enable a hybrid deployment without having to upgrade your entire existing deployment. These Exchange 2010 servers are known as the hybrid servers.
Your organization must contain one or more hybrid servers with the Hub Transport and Client Access server roles installed. The Mailbox server role is also required for Exchange Server 2003 organizations that need to support the exchange of free/busy information between your on-premises Exchange 2003 mailboxes and Exchange Online mailboxes. Adding this hybrid server to your organization is equivalent to introducing your first Exchange 2010 server to your deployment. To learn more about hybrid deployments, see Understanding Hybrid Deployments with Exchange 2010 SP3.
Contents
Edge Transport in a Hybrid Deployment
Mail Flow
Mail flow between your on-premises deployment and your Exchange Online organization is secured and protected by Transport Layer Security (TLS). The TLS endpoint in your on-premises organization must be an Exchange 2010 SP2 Hub Transport or Edge Transport server running Exchange 2010 SP1 or SP2.
Your on-premises organization and Exchange Online organization send messages directly to each other through a secure channel. To enable this mail flow, a dedicated hybrid Send connector is automatically created by the Manage Hybrid Configuration wizard. Only a Hub Transport server running on Exchange 2010 SP2 or Edge Transport source server(s) running on Exchange 2010 SP1 or Exchange 2010 SP2 can be selected for this Send connector. If you’re running Exchange 2010 SP2 in your organization, any Hub Transport or Edge Transport server can act as the gateway to your Exchange Online organization. If you’re running older versions of Exchange, you must deploy hybrid Hub Transport or Edge Transport servers to route messages between your two organizations.
In a hybrid deployment, each organization treats the other one as an internal organization. There is practically no difference between a user hosted on your on-premises servers and an Exchange Online user when Exchange is processing messages. Anti-spam filters are also bypassed for messages between the two organizations.
Secured and Authenticated Mail Flow
Even though messages between the on-premises and Exchange Online organizations go through a logical tunnel, they’re still transferred over the Internet and therefore must be protected against malicious users. Exchange 2010 provides the following protection measures:
- Channel privacy Unauthorized parties
can’t access any captured packets.
- Receiver authentication Senders are
protected from unauthorized parties impersonating valid
receivers.
- Sender authentication Receivers are
protected from unauthorized parties impersonating valid
senders.
Channel Privacy
To protect both the on-premises and cloud-based organizations, Exchange 2010 forces TLS using Secure Sockets Layer (SSL) certificates provided by a trusted third-party Certificate Authority (CA). Self-signed certificates are not supported for channel privacy in a hybrid deployment. All messages sent through the TLS-protected channel are encrypted.
The sending and receiving servers examine the certificate configured on the other server. The subject name, or one of the subject alternative names (SANs), configured on the certificates must match the fully qualified domain name (FQDN) that an administrator has explicitly specified on the other server. For example, if the Exchange Online organization is configured to accept and secure messages sent from the mail.contoso.com FQDN, the sending on-premises hybrid servers must have an SSL certificate with mail.contoso.com in either the subject name or SAN. If this requirement isn't met, the connection is refused.
Receiver Authentication
In addition to the regular certificate checks performed during TLS, the Send connectors that participate in hybrid deployment mail flow also perform domain validation. Domain validation is an additional security feature that reduces the risk of malicious users impersonating a receiving server. When domain validation is enabled on a Send connector, the Transport server performs the following security checks on the outbound connection:
- The communication channel is encrypted using TLS.
- The certificate of the receiving server is validated, and
revocation list checks are performed.
- The Transport server verifies that the FQDN on the certificate
of the receiving server matches the domain configured in the Send
connector properties.
Sender Authentication
To prevent a malicious user from impersonating a valid sender, each message is authenticated to verify that it was submitted by the specified sender. Inside an Exchange organization, sender authentication is verified by using custom message headers added by Exchange servers. For messages that are sent between the on-premises and Exchange Online organizations, these header values are encrypted at the source and then decrypted and verified at the destination. While in transit, these headers can’t be decrypted by any third party that might capture the message.
Mail To and From the Internet
Recipients in the on-premises and Exchange Online organizations typically have the same reply address, such as @contoso.com. Because they have the same reply address, all messages to recipients in both organizations must follow the same inbound route. All inbound messages can be delivered either to the on-premises organization or to the Exchange Online organization. Where you decide to route inbound messages depends on where the majority of your mailboxes are located, whether you have a Microsoft Forefront Online for Protection (FOPE), and other factors.
Messages sent from recipients in the on-premises and Exchange Online organizations can either follow the same or different routes to the Internet. Messages sent from on-premises recipients are always sent directly to the Internet. Messages sent from Exchange Online recipients can either be sent directly to the Internet or routed through your on-premises organization first. You may want to route Exchange Online messages through your on-premises organization if you want to apply compliance policies to them first.
There are many considerations that you need to think about when planning transport for your hybrid deployment, such as whether you use FOPE to protect your on-premises organization, whether you have an Edge Transport server configured, and how you want to route inbound and outbound Internet mail. For detailed information about these considerations and help on deciding which options are best for your organization, see Understanding Transport Options in Exchange 2003 Hybrid Deployments.
Transport Features
This section discusses how various Transport features are used in a hybrid deployment. The information here assumes that you’re running Exchange 2010 for your on-premises deployment because some of the features described here don’t apply to earlier versions of Exchange. To learn more, see the following topics:
 Note: |
|---|
| The features discussed in this section are only available in a hybrid deployment. |
Transport Rules and Journaling
Transport Rules and Journaling rules aren’t synchronized between your on-premises deployment and your Exchange Online organization. Therefore, you must ensure that you keep any rules that you have implemented consistent in both organizations.
Delivery Reports
Users can track messages they’ve sent and received in a hybrid deployment as long as delivery reports are enabled for the corresponding organizational relationships for both the on-premises and Exchange Online organizations. By default, this feature is enabled in a hybrid deployment. However, keep in mind that if you have older versions of Exchange in your on-premises deployment, the delivery reports will not show the final delivery to recipients hosted on the legacy servers, but rather that the message was transferred to the legacy Exchange system. This isn’t a limitation of the hybrid deployment; it’s because of changes in the message tracking implementation in Exchange 2010. For more information, see the “Message Tracking Across Versions” section in Upgrade from Exchange 2007 Transport.
MailTips
MailTips are designed to work seamlessly in a hybrid deployment. If an on-premises user addresses a message to a recipient in your Exchange Online organization, your local Client Access servers contact the Client Access servers in the Exchange Online organization and requests MailTips data for the message. Upon this request, the Client Access servers in the Exchange Online organization processes the MailTips request, evaluates the message for any MailTips, and returns all applicable MailTips to your on-premises Client Access servers. The process is the same when a user in your Exchange Online organization addresses a message to an on-premises recipient.
In a hybrid deployment, keep in mind the following differences regarding MailTips:
- The External Recipients MailTip is evaluated only in the local
organization. This is because the Exchange Online organization
can’t determine which recipients would be considered external for
an on-premises user.
- Number of external recipients in a group MailTip is only
evaluated for the local groups using the local Group Metrics data
for the same reason.
- The Oversize Message MailTip is evaluated both locally and in
the remote organization. Therefore, it’s important to make sure
that the message size restrictions for your on-premises
organization match those configured for your Exchange Online
organization to avoid an inconsistent experience for your
users.
- All objects in the remote organization are represented as
mail-enabled objects in the local organization. For example, a
mailbox in your Exchange Online organization is represented as a
mail user in your on-premises organization. Because all objects can
have Custom MailTips, you potentially can configure two different
Custom MailTips for the same recipient. In this case, only the
local Custom MailTip will be shown. On-premises users will see the
Custom MailTip configured for the on-premises object, and
cloud-based users will see the Custom MailTip configured for the
Exchange Online object.
- It’s also possible to have a mismatching configuration for
moderated recipients or restricted recipients. For example, an
on-premises mailbox may be restricted, but the corresponding mail
user in your Exchange Online organization may not be restricted. In
this scenario, the Restricted Recipient MailTip will be shown even
for an Exchange Online user. The Moderated Recipient MailTip
functions in a similar fashion.
MailTips are configured to work in a hybrid deployment by default. However, it’s possible to customize the way MailTips are handled if you want different experiences for your on-premises and Exchange Online users. For more information, see the “MailTips Architecture” section in Understanding MailTips and “Use the Shell to configure MailTips for organizational relationships” section in Configure Organizational Settings for MailTips.
Message Moderation
Hybrid deployment message moderation functionality relies on the following requirements:
- Synchronization of moderation attributes of mail-enabled
objects.
- At least one arbitration mailbox created in your on-premises
organization.
- At least one arbitration mailbox created in your Exchange
Online organization.
- Preservation of the headers and TNEF format between the two
organizations.
When you configure a hybrid deployment with Office 365, all the requirements above are met. You don’t need to do anything additional for message moderation to work.
Edge Transport in a Hybrid Deployment
Mail flow in a hybrid deployment requires an Exchange 2010 SP2 server as the TLS endpoint for your on-premises deployment. This is typically an Exchange 2010 SP2 Hub Transport server in your on-premises organization. However, if you don’t want to expose your internal Hub Transport server directly to the Internet, you can use an Exchange 2010 SP2 Edge Transport server as the TLS endpoint. If you use an Edge Transport server, that server will handle mail between your on-premises organization and the Exchange Online organization on behalf of the Hub Transport server. You can also elect to use an Edge Transport server for handling mail sent to and from Internet recipients for your on-premises organization.
To learn more about Edge Transport servers in your hybrid deployment, see:
If you’re using Exchange 2007 Edge Transport servers in your organization, they must be upgraded to Exchange 2010 SP2 if you plan to use them in a hybrid deployment.