Off-boarding email from Office 365 to Exchange 2013 (Part 1)

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

Introduction

Most organizations moving email to Office 365 are unlikely to consider a return to on-premises. However it’s important to understand that should needs change, it is relatively straightforward to move mailboxes to Exchange 2013.

Our Example Scenario

In this series our example organization is a mid-size company that started up only using Office 365 and has built a new Active Directory and Exchange infrastructure that they intend to migrate accounts and Mailboxes to.

For whatever reason, our example organization has chosen to move away from Exchange Online for email and use the on-premises rights included with their subscription to move mailboxes on-premises.

In preparation they have implemented some based components – Exchange Server 2013 and Directory Sync with Password Sync:

Image
Figure 1: High level diagram of our current environment

In the current form, the on-premises infrastructure shares accepted domains with the Office 365 tenant, but crucially no email routing such as MX records is configured to route via on-premises, and no mail-enabled users or mailboxes have been enabled.

We’ll therefore need to accomplish the following tasks to perform what could be called a reverse Hybrid implementation and begin to off-board mailboxes from Office 365 onto the on-premises servers:

  • Ensure on-premises user accounts, distribution groups and other records, such as contacts are created within Active Directory.
  • Add attributes to the local Active Directory from Office 365.
  • Enable Directory Synchronization with Password Sync to link AD accounts with Office 365.
  • Enable a Hybrid configuration with Office 365 to rich coexistence and provide the ability to off-board mailboxes safely.
  • Via the Hybrid relationship establish mail flow to on-premises via the Office 365 tenant.
  • Switch services like AutoDiscover to on-premises.
  • Migrate mailboxes to the on-premises Exchange 2013 environment.
  • Optionally decommission Office 365 services.

You will see as part of our steps we are implementing Directory Synchronization with Password Hash Sync. If you aren’t familiar with it, this feature allows Office 365 users to log in with their AD password.

This means at the point of implementation of Directory Sync, we’ll ask the users to enter their AD password into clients like Outlook and mobile devices where prompted.

Pre-Requisites

Before we begin setting our Exchange and Office 365 tenant up for off-boarding mailboxes it is important to take a look at the pre-requisites required.

Our first stop is to examine the Office 365 tenant and Exchange 2013 on-premises implementation to ensure we know what the starting state is.

We’ll first log in to the Office 365 and navigate to the Admin portal, then select Domains:

Image
Figure 2: Current accepted domains within the Office 365 tenant

In the list of domains we can see that two domains are configured:

  • exchangelabs.co.uk
  • exchlabs.onmicrosoft.com

The first domain (our Office 365 custom domain) is the one that should be shared between on-premises Exchange and Office 365 and will be used for migration of mailboxes.

We will ensure that it is configured within the Exchange 2013 environment by navigating to the Exchange Admin Center then selecting Mail Flow>Accepted Domains:

Image
Figure 3: Accepted domains within our on-premises Exchange 2013 organization

As we expect, the exchangelabs.co.uk domain is configured in our on-premises Exchange Organization.

The second domain is our tenant domain, and we’ll use a variation of that later for our Remote Domain on-premises to allow mail flow to work correctly in the shared accepted domain namespace.

Next, we’ll examine the users within the Office 365 tenant. We’ll want to make sure that each user we want to migrate is using the accepted domain exchangelabs.co.uk as part of their Office 365 login ID:

Image
Figure 4: Current users within our Office 365 tenant

Any user who doesn’t, apart from the Tenant Administrator account, will need to be updated to use this sign in address before we go any further, assuming that we want to migrate them.

Within the on-premises Exchange 2013 organization we’ll need to check for any mailboxes already present.

As in our scenario we have introduced a new Exchange implementation there should not be any issue as the only mailboxes will be Administrator and other system mailboxes. We can check by navigating within the EAC to Recipients>Mailboxes:

Image
Figure 5: Current recipients within our on-premises Exchange organization

We’ll also need to check within Active Directory to verify that we’ll be able to create users with User Principal Names that match the custom domain in Office 365.

If your AD domain name doesn’t match the UPN suffix the Microsoft Online Services IDs users, you’ll need to add this as a UPN suffix in Active Directory Domains and Trusts.

In our case our Active Directory domain name is exchangelabs.co.uk, therefore we need make no further changes, however if the Active Directory domain name was, for example, exchangelabs.local we’d need to add exchangelabs.co.uk as a UPN suffix:

Image
Figure 6: Addition of an alternative UPN suffix

Our remaining tasks within Exchange and Office 365 make sure that the environments are ready for our subsequent work to implement Exchange 2013 Hybrid, and Azure Active Directory Sync.

For Exchange Hybrid, we need to make sure that pre-requisites for Hybrid Mode are fulfilled, such as having working external access to Exchange AutoDiscover and Web Services, firewall ports opened to allow inbound and outbound SMTP traffic to flow between Office 365 and our on-premises organization and outbound HTTPS connectivity from Exchange and Microsoft Online Services Directory Sync.

Part one of my series Using the Hybrid Configuration Wizard in Exchange Server 2013 covers these pre-requisites in more detail.

Finally, we’ll need to enable Active Directory Synchronization in our Office 365 tenant to enable Azure Active Directory Sync to connect to and alter Office 365 accounts, and prevent further changes to user account properties from being performed via the Office 365 portal. We’ll find the option to enable Directory Sync within Office 365 Administration>Users>Active Users as shown below:

Image
Figure 7: Enabling Active Directory Synchronization

Choose Set up, then on the next page choose Activate.

Exporting User, Contact and Group Information

Before we can install and enable the Azure Active Directory Sync Tool (DirSync) we should create local Active Directory accounts to match the accounts within Office 365.

Although we can’t retrieve the password for each Office 365 user, we can retrieve other user details which we’ll use as the basic properties for user accounts, contacts and distribution groups. We are only looking to export basic information here, so if you have advanced properties set you may need to alter the set of data you collect.

To accomplish this task, we’ll use PowerShell to connect to Exchange Online and retrieve the data we need. We’ll then use that information to create our on-premises accounts.

First open up a PowerShell prompt and enter the following commands, as detailed on the Microsoft article Connect to Exchange Online using remote PowerShell

$cred = Get-Credential

$session = New-PSSession -ConfigurationName Microsoft.Exchange -Authentication Basic -ConnectionUri https://outlook.office365.com/powershell-liveid/ -AllowRedirection:$true -Credential $cred

Import-PSSession $session

After connecting to the service, we’ll export information into several XML files. These files contain the output PowerShell objects, allowing us to store the data in the original format they were returned in.

Get-User -ResultSize Unlimited | Export-Clixml .\Users.xml

Get-Mailbox -ResultSize Unlimited | Export-Clixml .\Mailboxes.xml

Get-Recipient -ResultSize Unlimited | Export-Clixml .\Recipients.xml

$DGs = Get-DistributionGroup -ResultSize Unlimited

$DGs | Export-Clixml .\DistributionGroups.xml

$DGMembers = foreach ($DG in $DGs) { Get-DistributionGroupMember -Identity $DG.Identity | Select @{Name=”Group”;Expression={$DG.Name}},PrimarySMTPAddress }

$DGMembers | Export-Clixml .\DGMembers.xml

After exporting the information , we’ll end our Exchange Online session using the following command:

Remove-PSSession -Session   $session

You’ll see the expected output below:

Image
Figure 8: Output from our data collection commands on Office 365

The results of these scripts should generate four files:

  • Users.xml – containing base user information
  • Mailboxes.xml – containing detailed mailbox information
  • Recipients.xml – containing more information about Mailboxes, Mail-Enabled Users and Contacts
  • DistributionGroups.xml – containing basic information about Distribution Groups
  • DGMembers.xml – containing a list of group memberships

Keep these results safe, as we’ll use the data in the next part of the series to create new AD accounts.

Summary

In the first part of this series we’ve checked over basic pre-requisites and exported account information from Office 365. In the next part of this series we’ll import user accounts into our on-premises systems and then implement the Azure AD Sync Tool.

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

About The Author

6 thoughts on “Off-boarding email from Office 365 to Exchange 2013 (Part 1)”

  1. Hi Steve,

    Nice article. I have run through pretty much all the steps in this entire series before finding your article.

    I have a bit of a weird situation. My customer was setup in 365 manually and have existing local AD users. Do you know if its possible to link the existing 365 mailboxes to existing users?

    I have the accounts linked and password sync working but exchange isn’t able to see the remote mailboxes (EAC only shows the admin account under recipients > mailboxes) and im unable to move the mailboxes from 365 to on prem as the exchange GUIDs dont match.

    Im assuming i need to link the existing mailboxes to local users so they should up in EAC as remote mailboxes and then I should hopefully be able to move the mailboxes (I may need to update the GUID so it matches).

    Any help/thoughts are greatly appericated.

    Regards

    Jeremy

  2. Hey Steve. What an awesome article, it really saved my butt. I’m having an issue specifically reconnecting users with Mac Outlook and iOS after the migration offboarding, and DNS change of mx and autodiscover to point to the on-prem server. It’s telling me “account blocked”. Any ideas?

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