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

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 article we went for the simple approach – you’ve got a few mailboxes you need to quickly and simply pull over from an Office 365 tenant into your unrelated Exchange organization. We didn’t worry about hooking up the two organizations together – we simply grabbed the mailbox and asked Office 365 to push it to the on-premises Exchange organization.

For the remaining parts of this series, we’re going to look at how to do perform a full off-board migration. Your scenario might be a merger or acquisition, or equally it might be that you’ve started off with Office 365 and found Exchange would be better for you if ran on-premises. One of the great things about Exchange is that you have that choice – Users of competitor products simply don’t have that choice, unless they want to buy expensive migration software or lose message fidelity.

Our Example Scenario

For the rest of this series, we’ll focus on a single scenario that we’ll looking to accomplish. Our company, aptly named Exchange Labs started life using Office 365. After a period of fast expansion, the CIO of Exchange Labs has decided that the organization would be better served by running Exchange in-house, using an on-premises solution.

At the beginning of the project, Exchange Labs didn’t have an in-house Active Directory or Exchange infrastructure, and these have been implemented ready to add user accounts to. The topology of the Exchange Labs infrastructure is fairly simple at present:              

Image
Figure 1: High level diagram of our current environment

In the diagram above, you’ll see that both our Exchange Online and Exchange On-Premises share an accepted domain. At the moment however, the on-premises domain isn’t sending or receiving email from the internet, and is simply set up in a new Active Directory environment ready to attempt to connect with our Office 365 tenant. All inbound mail destined for exchangelabs.co.uk is destined for Office 365.

Our set of requirements is also equally simple, though slightly harder to achieve.

  • Create on-premise user accounts in Active Directory to match the users in Office 365.
  • Synchronise the on-premises Active Directory with Office 365.
  • Configure a Hybrid environment so that users can be gradually migrated from Office 365.
  • Leave inbound mail flow as it is, with inbound mail delivered to Office 365 first until all users are migrated to on-premises Exchange 2010.
  • Migrate mailboxes to the on-premises environment without affecting mail delivery of fidelity of user mailboxes.
  • After migrating users on-premises, implement Active Directory Federation Services 2.0.

If you’re wondering why we’ve chosen to implement AD FS 2.0 last in this scenario you probably aren’t alone. As our scenario is based upon a fresh Active Directory and Exchange implementation, each user will not know his or her password until their mailbox is migrated.

However once the mailbox migration is complete, we’d expect that end-user workstations will also be migrated to the domain and at that point all users will know their Active Directory passwords and will benefit from a single-sign on experience.

Pre-Requisites

Before we begin, we need to make sure a few things are in order. First of all, let’s take a look at both our Office 365 tenant, and Exchange on-premises organization to ensure we know what we’re dealing with.

First in the Office 365 tenant, we’ll examine the domains registered:

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

We’ll see in the tenant, two domains are registered:

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

The first domain is the one we’ll be moving accounts from Office 365 to on-premises Exchange to, so we’ll double check that it’s correctly registered in Exchange 2010, by opening the Exchange Management Console and navigating to Organization Configuration>Hub Transport and selecting Accepted Domains:

Image
Figure 3: Accepted domains within our on-premises Exchange 2010 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 Microsoft Online Services 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.

Back on the on-premises Exchange organization we’ll need to examine the users present within Exchange already. As our scenario is one where we’ve built a fresh Exchange 2010 organization this shouldn’t be an issue; however if you’re combining organizations you’ll need to make sure you aren’t going to face any duplicate users. A quick look at in the Exchange Management Console, within Recipient Configuration confirms we’ve only the two standard Administrator and Discovery Search Mailboxes:

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

Further verification within Active Directory also confirms that we’ve got a clean set of user objects too:

Image
Figure 6: Examining user objects using Active Directory Users and Computers

Our final task within Active Directory is to verify that we’ll be able to create users with matching User Principal Names. If your 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 7: 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 Hybrid Mode, and the Windows Azure Active Directory Sync tool (DirSync).

For Exchange Hybrid mode, 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 DirSync. Part one of my article Using the Hybrid Configuration Wizard in Exchange 2010 Service Pack 2 – Planning looks at these pre-requisites in more detail.

Finally, we’ll need to enable Active Directory Synchronization in our Office 365 tenant to enable DirSync 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 DirSync within Management>Users as shown below:

Image
Figure 8: Enabling Active Directory Synchronization

Choose Set up, then on the next page choose Activate. It may take up to 48 hours to enable the ability to perform synchronization.

Exporting User, Contact and Group Information

Before we can implement DirSync we need to create local Active Directory accounts to match the accounts within Office 365, otherwise DirSync will be unable to match accounts correctly to our existing users in 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 Exchange Online PowerShell to connect to Office 365 and retrieve the data we need, before creating users, contacts and groups based upon that information.

First open up a PowerShell 2.0 prompt and enter the following commands, as detailed on the Microsoft article Connect Windows PowerShell to the Service:

$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -Authentication Basic -ConnectionUri https://ps.outlook.com/powershell -AllowRedirection:$true -Credential $cred
Import-PSSession $session
After connecting to the service, we'll export information into a number of XML files which contain the object-based information:
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
Finally, we'll end our Exchange Online session using the following command:
Remove-PSSession -Session $session

You’ll see the expected output below:

Image
Figure 9: 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

You’ll find additional Microsoft-supplied scripts that enable you to customise or extract further data on Microsoft Technet, within the Sample PowerShell Scripts for Office 365 Deployment page.

Summary

In part three of this series we’ve began our migration of a standalone tenant to on-premises Exchange, by checking through our requirements, verifying a number of pre-requisites and exporting user information from Office 365 ready to import into Exchange 2010. In the next part of this series, we’ll create corresponding local information and initiate directory synchronization between on-premises Exchange and Office 365.

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