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

By /

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

Introduction

In part 11 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 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 12, we will continue where we left off back in part 11. That is we will finish the configuration for the custom domain in Office 365, for which Exchange hybrid should be set up.

Let’s get started.

Creating DNS Records in External DNS

So back in part 11 of this article series, when we set up the Exchange hybrid, you probably noticed that although the Exchange hybrid wizard completed successfully, we got an informational notice that said Office 365 was unable to communicate with the on-premises Autodiscover endpoint and that this issue usually is caused by incorrect DNS or firewall configuration. So in my specific case, the explanation is simple. I haven’t created the Autodiscover record in external DNS yet.

So before continuing, let’s make sure Office 365 can resolve our Autodiscover endpoint. I’ll do this by logging in to the web interface of the external DNS provider I use and then add an A-record (autodiscover.clouduser.dk) pointing to public IP address that NATs to the VIP address associated with the Exchange 2013 server in my lab environment. I do not use TMG , UAG, ARR or a third party solution to publish my server as I do not have any requirements for pre-authentication. In fact even though, I used TMG or another solution I wouldn’t be able to use pre-authentication for Autodiscover or EWS for that matter as it simply isn’t supported when setting up an Exchange hybrid.

Image
Figure 1: Creating the Autodiscover A-record in external DNS

In addition to publishing Autodiscover, it’s also important that Outlook Web App (OWA), Outlook Anywhere (OA), Exchange Active Sync (EAS) and Exchange Web Services (EWS) is accessible from the Internet. In my lab these services can be reached via “webmail.clouduser.dk”.

Image
Figure 2: URL used to reach OA, OWA, EAS and EWS

With the Autodiscover service now being accessible from the Internet, let’s move on to the next step, which is to have the “Set up domain” wizard in the Office 365 portal to verify the required outbound connectors have been created by the hybrid configuration wizard.

To do so, select the respective custom domain and then under “step 2”, click “done, go check”.

Image
Figure 3: Verifying outbound connectors has been created by the HCW

So as we can see, the “Set up domain” wizard in my scenario verified outbound connectors are set up for the domain with success.

The “Set up domain” now recommends we run the Microsoft Remote Connectivity Analyzer in order to verify that the required DNS records are in place. They are in this case as OA, OWA, EAS, EWS and Autodiscover are accessible from the Internet.

Let’s click “next”.

Image
Figure 4: Verification of outbound connectors successful

This brings us to “step 3” which also is about adding DNS records to the external DNS provider. All records except the last are Exchange Online specific:

  • MX Record Because we wish to route inbound mail for both users with a mailbox in Exchange Online and users with a mailbox in the on-premises Exchange organization through Exchange Online Protection (EOP) part of Office 365, we need to change our MX record so that it points to the address listed under MX in Figure 5 more specifically “clouduser-dk.mail.protection.outlook.com”. Bear in mind that the MX record is tenant specific.
  • Autodiscover CNAME record In scenarios where all user mailboxes have been moved to Exchange Online, we can switch the autodiscover record to point directly to Exchange Online instead of at the on-premises Exchange organization. In our case, we will have user mailboxes in both Exchange Online and the on-premises Exchange organization over a period (which is the case in most scenarios that involve an Exchange hybrid), so we’re not interested in pointing the autodiscover record at Exchange Online as that would break autodiscover lookups for on-premises user mailboxes. Said in another way, we will skip this step. If we wanted to point autodiscover to Exchange Online, we would need to direct “autodiscover.clouduser.dk” to “autodiscover.outlook.com” using a CNAME record.
  • TXT record You probably already have an SPF TXT record in place, that includes the public IP addresses associated with your Edge servers in the perimeter network or directly to the Exchange servers on the internal network. In short, an SPF TXT record helps to prevent other people from using your domain to send spam or other malicious email. Sender policy framework (SPF) records work by identifying the servers that are authorized to send email from your domain. We need to add “spf.protection.outlook.com” to this record.
  • MSOID CNAME record This record was added as an additional record recently. As mentioned, it’s not Exchange Online specific but is used by Office 365 to direct authentication to the correct identity platform (there are two OrgIDs in Office 365 now). For my tenant, I would need to create a CNAME record that redirect “msoid.clouduser.dk” to “clientconfig.microsoftonline-p.net”.

Image
Figure 5: Required Exchange Online and authentication DNS records

In the following figures, you can see the DNS records created on my DNS provider.

Image
Figure 6: MX record pointing to Exchange Online Protection (EOP) in Office 365

Image
Figure 7: SPF record

Image
Figure 8: Authentication CNAME record

In Figure 9, we can see each created record is returned, when doing an NSLookup.

Image
Figure 9: NSLookup for MX, TXT and CNAME records

After creating the required DNS records and we have made sure they have replicated, let’s click “done, go check”.

Image
Figure 10: Clicking “done, go check” to verify the required DNS records are in place

If DNS records have replicated, you will now see this page shown in Figure 11. Notice, we get an error informing us the autodiscover record couldn’t be found. This is expected if you do not point autodiscover to Exchange Online. When dealing with Exchange hybrid scenarios, the error can be ignored.

Image
Figure 11: Autodiscover record pointing to Exchange Online missing

Click “close, and return later” and then “cancel”.

We have now set up the custom domain for Exchange hybrid purposes.

This concludes part 12 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