Migrating a standalone Office 365 tenant to Exchange 2010 (Part 6)

By /

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

Introduction

In the first two parts of this series, we looked at how we can simply migrate a few accounts between an Office 365 tenant and an on-premises Exchange organization where no co-existence is set up or required; for example if you have a business unit on Office 365 and a couple of staff move across and need to be moved to an unrelated Exchange organization.

Parts three to five look at a more complicated scenario; we’ve got an entire company on Office 365 and we’ve setup a new Exchange organization that we’ve decided to move the users onto – a full migration back from the cloud. So far, we’ve populated Active Directory and Exchange, set up the Windows Azure Active Directory Sync tool (DirSync) and after configuration and testing synchronized both Exchange and Office 365.

In the final three parts of this series, we’ll update AutoDiscover records, configure our organization using the Hybrid Configuration Wizard, update mail routing, move mailboxes from the cloud and look at decommissioning our Office 365 tenant.

AutoDiscover

Because our Office 365 organization before this point (and still) only exists in the cloud, the AutoDiscover DNS record that helps clients find their mailbox will point to Office 365. As we’ve created our remote mailboxes objects on premise, we should be able to change the DNS entry for AutoDiscover to point to our on-premise Exchange 2010 organization.

First of all, it’s important to note that we’re assuming that best practices for Exchange 2010 deployment have been followed and a suitable Subject Alternative Name (SAN/UCC) SSL certificate is in place with our external names for Exchange 2010. If it isn’t – this will show up when we check the pre-requisites a little later on.

Changing the AutoDiscover record itself is relatively straightforward; we’ll need to update the CNAME record so instead of being set to point at autodiscover.outlook.com it points at our Exchange on premises organization. You’ll see below the initial state of the AutoDiscover record in our third-party DNS management console:

Image
Figure 1: Viewing the existing AutoDiscover CNAME record

And then, after changing it to resolve to mail.exchangelabs.co.uk, our external namespace for on-premises Exchange 2010:

Image
Figure 2: Updating the existing AutoDiscover CNAME record to resolve to on-premises Exchange

After making this change, we’ll expect the AutoDiscover process to change for users currently in Office 365 as follows:

  1. Device attempts discovery for [email protected], an Office 365 mailbox and sends username and password to https://autodiscover.exchangelabs.co.uk/AutoDiscover/AutoDiscover.xml
  2. Exchange on-premises knows this is a Remote Mailbox and provides details of Jim’s Office 365 service domain email address [email protected].
  3. Device re-attempts discovery for [email protected] with the same credentials, attempting authentication against https://autodiscover-s.outlook.com/AutoDiscover/AutoDiscover.xml via AutoDiscover redirection.
  4. Device receives details for accessing the Office 365 mailbox.

The caveat to be aware of here is that for AutoDiscover to function correctly for users in the cloud, not only must the username (the User Principal Name on-premises, and Microsoft Online Services ID in Office 365) match, but the password must match also. Because we didn’t know the users passwords in Office 365 when we created the local Active Directory accounts, our approach was to reset passwords when migrating mailboxes. This means AutoDiscover technically works correctly, but it’s only going to function correctly on a per-user basis when we get ready to move their mailbox to on-premises Exchange.

Pre-Requisites for the Hybrid Configuration Wizard

Before we run the Hybrid Configuration Wizard, it’s important to make sure we validate that the on-premises Exchange organization we’re going to move mailboxes to is ready. Moving from the cloud is similar to moving to the cloud, as you’ll typically have a period of co-existence and you’ll of course need mail routing to work correctly.

We’ll follow the first part of the series Using the Hybrid Configuration Wizard in Exchange 2010 Service Pack 2 to cover the pre-requisites to ensure that connectivity is correctly functioning.

Pre-creating our Federation Trust and confirming domain ownership

During the Hybrid Configuration Wizard a new Federation Trust is usually created for the Exchange organization if one doesn’t already exist, and during the wizard you’ll be prompted to update DNS records. Therefore it’s not a bad idea to pre-create the trust and validate our domain before we continue.

To perform these steps, we’ll open the Exchange Management Console and navigate to the root of Organizational Configuration, then choose New Federation Trust from the Actions panel:

Image
Figure 3: Creating a new Federation Trust

Follow the simple wizard through to create the federation trust certificate which will be used as the basis for organizational availability and calendar/contact sharing.

We’ll then open the Exchange Management Shell and use the Get-FederatedDomainProof cmdlet to get the DNS Text (TXT) record we’ll need to add to our external DNS zone for exchangelabs.co.uk:

Get-FederatedDomainProof -DomainName exchangelabs.co.uk | fl Proof

You’ll see the encoded text output, which will be unique for your domain and be used to prove ownership:

Image
Figure 4: Using the Exchange Management Shell to retrieve the proof TXT record for our shared domain

The full proof string, as a single line, should then be added to the external DNS zone, as shown below:

Image
Figure 5: Creating the proof TXT record in external DNS

In the example above, you’ll see we already have an existing TXT record for the Sender Policy Framework (SPF) record recommended by Microsoft when configuring Office 365. An SPF record let’s receiving mail servers know which sender IP addresses should be trusted for this domain.

It’s advisable to update this to either add the Exchange on-premises outgoing IP addresses (recommended) or remove the SPF record entirely (not recommended, but many organizations don’t use SPF records). In the context of the Federation Proof TXT record, you will be pleased to know that multiple TXT records for one hostname or domain name are valid in DNS and do not affect the validation process.

Running the Hybrid Configuration Wizard

With our pre-requisites checked off and our Federation Trust ready to go, we’re ready to run the Hybrid Configuration Wizard to join up our Exchange on-premises organization with our Office 365 tenant.

First, open the Exchange Management Console, and within Organization Configuration, we’ll ensure the Hybrid Configuration tab is selected, then choose New Hybrid Configuration:

Image
Figure 6: Creating the Hybrid Configuration object

After the simple wizard completes, the basic object that will store settings for the Hybrid Configuration Wizard will have been created. We’ll then add our Office 365 tenant to the Exchange Management Console by right-clicking on the root Microsoft Exchange node and choosing Add Exchange Forest:

Image
Figure 7: Connecting the EMC to Exchange Online

The Add Exchange Forest window will open, allowing you to enter a friendly name for our Office 365 tenant. Under Specify the FQDN or URL of the server running the Remote PowerShell instance, select Exchange Online from the drop-down list, then hit OK:

Image
Figure 8: Selecting Exchange Online and entering a friendly name for the connection

After entering Administrator credentials for the Office 365 tenant, it should be displayed within the Exchange Management Console underneath our on-premises Exchange organization in the list. We’ll then return to our on-premises Organizational Configuration node, and choose Manage Hybrid Configuration from the Actions panel:

Image
Figure 9: Initiating the Hybrid Configuration Wizard

After the Manage Hybrid Configuration wizard opens, choose Next to skip the introduction and on the Credentials page, enter both on-premises and Office 365 organizational administrator credentials:

Image
Figure 10: Entering on-premises and tenant credentials

On the Domains page, we’ll select the Office 365 tenant domain we’re sharing with our new on-premises Exchange organization:

Image
Figure 11: Selecting the shared accepted domains

On the Domain Proof of Ownership page you’ll see the Proof record we pre-created in the previous section:

Image
Figure 12: Verification of the federation proof TXT record

Under Servers add in your on-premises servers that will act as the “Hybrid” servers for the configuration. For a multi-role Exchange implementation this may be the Exchange 2010 servers in your internet-facing site, but for more complex implementations you may have dedicated client access and hub transport servers:

Image
Figure 13: Selecting the servers to participate in the Hybrid relationship

On the Mail Flow Settings page, we’ll enter the public IP addresses that are used to send mail to Office 365 – the inbound to Office 365 connector. The outbound connector requires the fully qualified domain name (FQDN) that will be used by Office 365 to relay mail to on-premises recipients:

Image
Figure 14: Entering inbound and outbound SMTP information

On the Mail Flow Security page, we’ll enter our final settings. First, we’ll select the transport certificate to be used for mail flow. This certificate, installed on all of the servers that will send and receive mail between Office 365 and on-premises will be used by our Exchange send and receive connectors, and the common name of the certificate will be configured on Office 365’s Forefront Online Protection for Exchange to secure mail.

For the Mail Flow Path, we can leave outbound mail flow from Office 365 as-is and choose to Deliver internet-bound messages directly using the external recipients’ DNS settings. This ensures that messages sent by users while they are still on Office 365 will continue to flow directly out to external recipients rather than route through our on-premises Exchange infrastructure first:

Image
Figure 15: Selecting mail security and flow options

After entering the desired configuration, we’ll then allow the Hybrid Configuration Wizard to execute:

Image
Figure 16: The HCW in progress

We’ll expect this to take a number of minutes to complete, and like any task may fail. If you do experience issues, a good place to start is Part 4 of the series Using the Hybrid Configuration Wizard in Exchange Server 2010 SP2.

Summary

In this part of this series we’ve updated AutoDiscover to point to our on-premises environment first, ensuring that federation features can be configured correctly and assisting with getting ready to move mailboxes from the cloud. We’ve then checked pre-requisites and implemented a Hybrid Configuration. In the final part of this series we’ll update mail routing, move mailboxes from Office 365 and examine how to decommission our Office 365 tenant.

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

About The Author

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

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