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

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

Introduction

In part 27 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 verified the hybrid configuration that has been configured on the on-premises side.

Let’s get going…

Verifying the Exchange Hybrid Configuration Settings in Office 365

Back in part 27, we focused on the Exchange hybrid related configuration settings that were set on the Exchange 2013 servers on-premises by the hybrid configuration wizard (HCW). Of course, the hybrid configuration wizard also configures several settings in the Exchange Online organization in Office 365. Let’s take a look at what was configured. To do so, open the “Exchange admin center” and then click on the “Office 365” link in the top left part of the screen.

Just like for the on-premises Exchange organization, the respective domain used for routing between on-premises and Exchange Online has been added as “Accepted Domains” in the Exchange Online organization in Office 365.

Figure 1: Accepted domains in the Exchange Online organization

For the mailbox-enabled user objects in the on-premises Active Directory that has been synchronized to the Office 365 tenant as mail-enabled user (MEU) objects, the external email address (targetAddress attribute) on the MEU object has been set to “[email protected]”, so that all email messages sent from the Exchange Online organization (and from the Internet since we have chosen to route mail from external senders via Exchange Online Protection) to a user that hasn’t had his mailbox migrated yet is routed to his mailbox on-premises. In addition, the MEU objects in the Exchange Online organization also have a “[email protected]” proxy address, so that email messages sent to a migrated mailbox from a non-migrated mailbox are routed to the mailbox in the Exchange Online organization – again via the external email address (targetAddress attribute) set on the MEU object after the object is converted from a mailbox enabled object to a MEU object. We’ll look closer at this later.

Figure 2: External E-Mail address on MEU object on-premises

Unlike in wave 14 (previous version based on 2010 versions) of Office 365, we no longer configure any remote domains added in the Exchange Online organization.

Figure 3: No remote domains in Exchange Online

And by the way, before you try to find the “Remote Domains” tab in the Exchange admin center (EAC), I should probably tell you it’s not there. You need to use PowerShell for this.

When it comes to connectors, then the hybrid configuration wizard (HCW) has created an inbound and an outbound connector in Exchange Online Protection (EOP) as shown below.

Figure 4: Inbound and Outbound connectors in Exchange Online Protection (EOP)

Note:
Some of you may notice that the UI of the Connectors section has changed. Until recently, the inbound and outbound connectors lived in separate boxes. The reason for this is because it was decided to take a new some simplified approach for creating and configuring connectors. Read more about the change here.

Also, back with FOPE (in previous version of Office 365), the hybrid configuration wizard (HCW) created an inbound and an outbound connector that couldn’t be modified directly via FOPE administration console. In EOP, the connectors can be modified as you wish. Not that you generally should do this, but we have the permissions to modify them as required.

In addition, the connectors created in EOP are configured slightly different than those in FOPE. As some of you may recall, the inbound connector the HCW created in FOPE was locked down so that only the public IP addresses we specified in the Exchange 2010 HCW were allowed to route mail to the Exchange Online organization. And of course forced TLS based on certificate domain matching was also configured.

The outbound connector created in FOPE was configured to point to a specific endpoint FQDN (depending on the on-premises scenario something like hybrid.contoso.com). And again, it was configured with forced TLS based on certificate domain matching.

Figure 5: Inbound and Outbound connectors back in FOPE (wave 14)

In EOP the inbound connector is configured as follows. The “Connector Type” is set to “On-Premises” (can only be seen via PowerShell) and “Retain internal Exchange email headers (recommended)” is enabled.

Figure 6: General configuration settings for the Inbound connector in Exchange Online Protection (EOP)

In addition, we are forcing TLS based on certificate domain matching.

Figure 7: Security configuration settings for the Inbound connector in Exchange Online Protection (EOP)

In EOP, the outbound connector is configured as follows. Just like it’s the case with the inbound connector, “Connector Type” is set to “On-Premises” and again “Retain internal Exchange email headers (recommended)” is enabled.

Figure 8: General configuration settings for the Outbound connector in Exchange Online Protection (EOP)

Furthermore, the connector has been specifically set to send email messages to the “azurelab.dk” domain.

Figure 9: Domain configuration settings for the Outbound connector in Exchange Online Protection (EOP)

On the “delivery” property page, the connector is set to route mail through smart host “smtp.azurelab.dk”, which is the SMTP endpoint for my lab environment.

Figure 10: Delivery configuration settings for the Outbound connector in Exchange Online Protection (EOP)

Also, the connector forces the use of TLS based on a trusted certificate with subject alternative name “mail.azurelab.dk”.

Figure 11: Scope configuration settings for the Outbound connector in Exchange Online Protection (EOP)

Like in the on-premises Exchange organization, an organizational relationship has been created to establish Exchange federation with the on-premises Exchange organization.

Figure 12: Organization and individual sharing policies

Figure 13 below shows the configuration for the organization relationship in detail.

Figure 13: Configuration of the organization relationship in the Exchange Online organization

Just like is the case with Exchange 2010 based hybrid deployments, by default, free/busy is enabled with limited details. In addition, delivery reports, mailtips and photos are enabled. Moreover, a target autodiscover Epr has been set by the HCW. This is the endpoint used to reach out to the on-premises Exchange organization for the configured features, when a request comes from the Exchange Online organization to the on-premises Exchange organization.

Lastly, as you remember we enabled OAuth based authentication, when we configured the Exchange hybrid deployment using the HCW. Because of this IntraOrganizationConfiguration was configured accordingly and an IntraOrganizationConnector was created pointing to our Exchange on-premises environment.

Figure 15: IntraOrganization and IntraOrganizationConnector configuration

This concludes part 28 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: