Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 24)

If you would like to read the other parts in this article series please go to:

Introduction

In part 23 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we ran the IdFix DirSync Error Remediation Tool to discover and remediate any invalid Active Directory objects. We then enabled the Azure Active Directory Synchronization tool and began the actual synchronization to the Azure Active Directory tenant.

In this part 24, we will continue where we left off in part 23.

Let’s get going…

Exchange Hybrid Mail Flow Scenarios

An important decision we need to take before we move on to the next phase, which is enabling the Exchange hybrid deployment itself, is the mail flow scenario we wish to use.

When it comes to how inbound messages from the Internet should be delivered to mailboxes in your environment, no matter if they are located on-premises or in Exchange Online, you can choose to keep the existing mail routing that is in place. That is, you can select to have all inbound messages from the Internet go through SMTP gateways in the on-premises perimeter network (such as Edge Transport servers, SMTP servers or third party solutions), directly to the Exchange Client Access servers or Hub Transport servers (remember with Exchange 2013, we no longer have the Hub Transport server role) on the internal network, or perhaps to a 3rd party online filtering service.

Note:
If you decide to keep the existing mail flow, that is have all mail route through your on-premises environment before it reaches one or more mailboxes on-premises or in Exchange Online, you can leave the MX record unchanged.

From my personal experience, most organizations choose to keep the existing mail routing because of one or more of the following reasons:

Compliance policies Organizations that need to apply compliance policies to messages sent to mailboxes on-premises as well as in Exchange Online.
3rd party application integration Organizations that have an on-premises or online service based application that need to manipulate or journal messages in transit.
Switch MX record at a later stage Organizations may not wish to switch the MX record to Exchange Online Protection until the migration to Exchange Online has been completed.

If you decide to route inbound messages destined for an on-premises mailbox or a mailbox in Exchange Online through the existing mail route, the mail flow is as follows:

Sender from external organization sends an e-mail message to a recipient with a mailbox in the on-premises Exchange organization or in Exchange Online.
The e-mail message is either received by a:

- third party filtering service on the Internet
- SMTP servers in the perimeter network
- by the Exchange Client access or Hub Transport servers on the internal network

When the Client Access server or Hub Transport server in the on-premises organization receives the e-mail message depending on whether the destination mailbox is located in the on-premises Exchange organization or in Exchange Online, the e-mail message is routed to the on-premises mailbox servers on which the mailbox database holding the mailbox is stored or if the recipient has a mailbox in Exchange Online, it is routed on to Exchange Online Protection (EOP) based on the external e-mail address (targetAddress attribute) of the on-premises mail-enabled user object (MEU object) representing the mailbox in Exchange Online.
If the recipient has a mailbox in Exchange Online, Exchange Online Protection (EOP) routes the e-mail message on to a Client Access Server.
The Client Access server in Exchange Online delivers the e-mail message to the respective mailbox server that currently have the active copy of the database in which the mailbox is stored.

Figure 1: Inbound & Outbound Routing via on-premises Hybrid servers

Note:
When moving a mailbox from on-premises Exchange to Exchange Online in a hybrid deployment, the mailbox-enabled user object in the on-premises Active Directory is converted to a mail-enabled user object once the mailbox move has completed.

If you wish, and more importantly, are ready to route messages coming from the Internet through Exchange Online Protection (EOP) before they are delivered to either Exchange Online or on-premises mailboxes, you need to switch the MX record for your respective domain to point to EOP. Doing so will have all e-mail messages coming from the Internet to route through EOP, where spam and malware infected messages are filtered, prior to being delivered to the Exchange Online or on-premises mailboxes. A big pro of doing so is that you typically can get rid of the existing either Internet based filtering service or perimeter network based filtering servers and any unnecessary complexity, you have in place.

Note:
If you have compliance requirements such as journaling of all inbound e-mail messages, be aware that you can configure Exchange Online to achieve this. Over the recent years, a lot of energy and resources have been put into including features that can help fulfil legal and compliance requirements both for small and large organizations.

When choosing to route inbound messages destined for an on-premises mailbox or a mailbox in Exchange Online directly through Exchange Online Protection (EOP), the mail routing is as follows:

Sender from external organization sends an e-mail message to a recipient with a mailbox in the on-premises Exchange organization or in Exchange Online.
The e-mail message is received by Exchange Online Protection (EOP).
If the recipient has a mailbox in Exchange Online, EOP routes the e-mail message to a Client Access server in Exchange Online (If the mailbox is store in the on-premises Exchange organization, go to 5.)
The Client Access server in Exchange Online delivers the e-mail message to the respective mailbox server that currently has the active copy of the database in which the mailbox is stored.
If the recipient has a mailbox in the on-premises Exchange organization, EOP either routes the e-mail message to an Edge Transport server in the on-premises perimeter network or directly to an Exchange Client Access server on the internal network (if the latter, go to 7.).
The Edge Transport server routes the e-mail message to an Exchange Client Access server on the internal network.
The Client Access server delivers the e-mail message to the respective mailbox server that currently have the active copy of the database in which the mailbox is stored.

Figure 2: Inbound & Outbound Routing via Exchange Online Protection

When it comes to outbound mail flow, that is messages sent from internal users in Exchange Online or the on-premises Exchange organization to external recipients, we have the option of having Exchange Online Protection and the on-premises Client Access server (or if used the Edge Transport server) route the e-mail message directly to the external recipient. This is also known as non-centralized transport.

When choosing to route outbound messages from an internal Exchange Online or on-premises mailbox directly to the recipient, the mail routing is as follows:

Internal sender with a mailbox in Exchange Online or on-premises Exchange organization sends an e-mail message to external recipient.

- If the internal sender has a mailbox in on-premises Exchange organization, go to 2.
- If the internal sender has a mailbox in Exchange Online go to 4.

If the internal sender has a mailbox in on-premises Exchange organization, the e-mail message is submitted from the respective Mailbox server to a Client Access server
The Client Access server routes to recipient (could be via an SMTP server in perimeter network or a filtering service on the Internet).
The e-mail message is submitted from the respective Mailbox server to a Client Access server in Exchange Online.
The Client Access server routes the message to Exchange Online Protection.
Exchange Online Protection routes the e-mail message to the destination.

Alternatively, messages sent from internal users in Exchange Online or the on-premises Exchange organization to external recipients, can be routed through the on-premises Client Access servers (or if used the Edge Transport server) prior to reaching the external recipient. This is also known as centralized transport.

When choosing to route outbound messages from an on-premises mailbox or Exchange Online mailbox through the Client Access servers in the on-premises Exchange organization and from there on to the external recipient, the mail routing is as follows:

Internal sender with a mailbox in on-premises Exchange organization or in Exchange Online sends an e-mail message to an external recipient.

- If the internal sender has a mailbox in on-premises Exchange organization, go to 2.
- If the internal sender has a mailbox in Exchange Online go to 4.

The on-premises Mailbox server submits the e-mail message to a Client Access server in the on-premises Exchange organization.
The Client Access server routes to recipient (could be via an SMTP server in perimeter network or a filtering service on the Internet).
The e-mail message is submitted from the respective Mailbox server to a Client Access server in Exchange Online.
The Client Access server routes the message to Exchange Online Protection.
Exchange Online Protection routes the e-mail message to hybrid servers in on-premises organization (could be via an Edge Transport server in the perimeter network).
The hybrid server routes to recipient (could be via an SMTP server in perimeter network or a filtering service on the Internet).

In this article series, we will route inbound mail through Exchange Online Protection (EOP). Outbound mail will be routed directly to the destination, which means outbound messages coming from Exchange Online won’t route through the on-premises Exchange hybrid servers.

This concludes part 24 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.

If you would like to read the other parts in this article series please go to: