Configuring an Exchange 2013 Hybrid Deployment and Migrating to Office 365 (Exchange Online) (Part 11)

By /

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

Introduction

In part 10 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we talked about what’s remaining when it comes to completing the Office 365 “Set up domain” wizard, we began configuring back in part 2. Then we will talked about the mail routing options, you have at your disposal in an Exchange hybrid deployment and which one you should select to fit your specific scenario.

In this part 11, we will continue where we left off back in part 10. That is we will enable and configure the Exchange hybrid and have the on-premises hybrid servers, Exchange Online and Exchange Online Protection updated with the specified settings..

Let’s get started.

Enabling Hybrid Mode

So back in part 10 of this article series, I took you through the different mail routing options we have when it comes to Exchange hybrid deployments and told you which mail routing option we will choose for this specific scenario. In this article series, we will have inbound messages route through Exchange Online Protection (EOP) before they reach Exchange Online as well as Exchange on-premises mailboxes. For outbound message routing, we will choose the non-centralized mail transport option, which allows outbound messages from Exchange Online to go directly to external recipients instead of through the hybrid servers in the on-premises Exchange organization.

Let’s get going with enabling hybrid mode. To do so, first logon to one of the Exchange 2013 servers that are to act as hybrid servers. Then open the “Exchange admin center” and click “hybrid” in the bottom of the left pane.

Under the “hybrid” page, click the “Enable” button.

Image
Figure 1: Enabling Hybrid Mode using the Hybrid Configuration wizard

You will then be asked to login to Office 365 before you can continue. Do so by click on “sign in to Office 365”.

Image
Figure 2: Signing into Office 365 with a global admin account

We will be taken to the Office 365 sign in page as shown in Figure 3.

Image
Figure 3: Signing into the tenant using the Office 365 login page

If you now get an error message about cookies not being enabled for your Exchange Administration Center URL, you will need to add it to the local intranet zone or trusted zones in your browser. In addition, I suggest you add the Office 365 login page URL and the Office 365 portal to this zone.

Image
Figure 4: Adding used URLs to the local intranet zone in Internet Explorer

After having added the respective URLs to the local intranet zone, try to authenticate against the Office 365 tenant again. This time it should go a little better. Now you should be able to switch between the “Enterprise” and “Office 365” modes without the need to authenticate.

Image
Figure 5: Switching between “Enterprise” and “Office 365” mode

Let us continue with enabling and configuring hybrid mode by clicking “Yes” on the “Set up Exchange Hybrid”.

Image
Figure 6: Set Up Exchange Hybrid page

On the next page, we see our custom domain, we are to configure Exchange federation for listing. Before clicking “Next” on this page, we need to copy the token and add it as a TXT record in external DNS in order to confirm ownership of the domain.

Image
Figure 7: Confirming domain ownership using a TXT record

When you have added to TXT record to external DNS, go back and click the “Next” button shown in Figure 7.

Image
Figure 8: TXT record added to external DNS

On the next page, we need to specify whether we have Edge Transport server in the perimeter network to route through or if it should go directly to the Client Access server (hybrid servers) on the internal network. In addition, this is where we can choose to use centralized transport (routing mail from Exchange Online through the on-premises hybrid servers).

Since we do not have any Edge Transport servers in this specific scenario or have a need for centralized transport, we will select the first option and leave centralized transport unticked.

Image
Figure 9: Configuring mail routing options

On the next page, we need to specify one or more Client Access servers (hybrid servers) in which the receive connectors for bi-directional mail transport with Exchange Online will be created and configured.

In this specific scenario, we will add both our Exchange 2013 multi-role servers.

Image
Figure 10: Adding Exchange 2013 Client Access servers as bi-directional transport servers

Click “Next”.

Image
Figure 11: Client Access servers added to the hybrid wizard

Now we need to add the Exchange 2013 Mailbox servers that should host the send connectors used for bi-directional transport with Exchange Online. Since we use multi-role Exchange 2013 servers as hybrid servers in this specific scenario, we will add the same servers as those we added to host the receive connectors.

Image
Figure 12: Adding the servers that should host send connectors

When the servers have been added, we can click “Next”.

Image
Figure 13: Servers that should host send connectors added to the hybrid wizard

On the appearing page is where we should specify the certificate to be used with the hybrid configuration. In this specific scenario, we use the wildcard certificate that also was used for the ADFS based federation.

The certificate should be issued by a trusted CA provider. When the respective certificate has been selected, click “Next”.

Image
Figure 14: Specifying the certificate to be used for Exchange federation

Sidebar: Exchange Hybrids with multiple SMTP Domains

When we had to configure Exchange 2010 hybrid servers against the previous version of Exchange Online, when our on-premises Exchange organization had multiple SMTP domains (address spaces), we needed to include all the SMTP domains in the SAN certificate that were used for the on-premises Exchange > Exchange Online federation. If we only included the “primary” SMTP domain, autodiscover would be in a broken state for external users that had a different primary SMTP address (i.e. “[email protected]”) than for the one included in the certificate (i.e. “clouduser.dk”).

In addition, we had to publish the autodiscover endpoint for each SMTP domain. This is because external users must have an SMTP address (i.e. “[email protected]”) that can be used to lookup autodiscover information (i.e. “autodiscover.office365lab.dk”).

Note:
The SRV based autodiscover redirect method is not supported for on-premises Exchange > Exchange Online federation. Also, in order to use the CNAME based autodiscover method, you would need to have all domain names present in a SAN certificate.

So at the end of the day, you had to do the following:

  • Include “autodiscover.domain.com” for each SMTP domain in the SAN certificate
  • Publish ”autodiscover.domain.com” for each used SMTP domain

There are organizations that use lots of SMTP domains (some are in the hundreds!) and as you can see, for these types of organizations, this isn’t really a feasible solution.

Now here is the good news! This all changed with Exchange 2013 CU1. With Exchange 2013 CU1, we now have the option of adding multiple SMTP domains to our Exchange federation/hybrid configuration and we can specify which of these domains should act as the “autodiscover” domain. By doing so we can eliminate the need for both adding “autodiscover.domain.com” for all SMTP domains to a SAN certificate as well as the need for publishing autodiscover for each of these.

Cool stuff eh?

To configure an SMTP domain as the autodiscover domain, you can use the following command:

Set-HybridConfiguration –Domains “domain1.com, domain2.com, domain3.com”, “autod:domain.com”

Below I’ve just two domains and specified one of them to be the autodiscover domain.

Image
Figure 15: Configuring an autodiscover domain

After having run the command, you can run “Get-HybridConfiguration | fl” to see the domains as well as which one is configured as the autodiscover domain.

Image
Figure 16: Autodiscover domain configured

Minor but extremely useful new feature in Exchange 2013 CU1. Oh and by the way, this feature has also been backported to Exchange 2010 SP3 RU1 in case you have to base a hybrid setup on Exchange 2010 hybrid servers.

Okay, let’s switch back to our hybrid mode configuration shall we?

We now have to specify the FQDN (in this case “smtp.clouduser.dk”, which is our MX record pointing directly to the Exchange 2013 Client Access servers) to which the Exchange Online Protection (EOP) service in Office 365 should connect for secure mail transport to the on-premises Exchange organization.

After having entered the FQDN, click “Next”.

Image
Figure 17: Specifying the FQDN for secure mail transport to the on-premises Exchange organization

We now need to specify the credentials for an on-premises AD user member of the Organization Management group.

Do so and click “Next”.

Image
Figure 18: Specifying the credentials for an on-premises AD user member of the Organization Management group

Then we need to specify the credentials for a global admin account in Office 365.

Do so and click “Next.

Image
Figure 19: Specifying the credentials for a global admin account in Office 365

We have now completed the hybrid configuration and all there is left to do is to click “Update” in order for the specified hybrid servers on-premises, Exchange Online and Exchange Online Protection to be updated with the specified configuration settings.

Image
Figure 20: Updating the Exchange hybrid configuration and enabling hybrid features

The update process will go through several processes. It will connect to the Office 365 tenant, configure recipient settings, create the organization relationships, configure mail flow and more.

Image
Figure 21: Connecting to the Office 365 tenant

Image
Figure 22: Configuring recipient settings

Image
Figure 23: Configuring organization relationship

Image
Figure 24: Configuring mail flow

After a few minutes, it should complete with the page shown in Figure 25.

Image
Figure 25: Hybrid configuration update complete

Good job mate. You can now lean back and be proud of the progress you made so far.

This concludes part 11 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

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

About The Author

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top