In the last part of this series of articles I demonstrated setting up a Hybrid configuration between on-premises Exchange Server and Office 365. With the Hybrid in place it’s time to start planning to migrate mailboxes and cut over services such as mail flow.
Currently the organization is in a state where:
- All mailboxes are on-premises
- All remote clients connect to the on-premises servers
- All mail flow runs through the on-premises Exchange organization, via the Edge Transport server
Where want to be is a state where:
- Mailboxes can be on-premises or in the cloud, depending on the business needs
- Cloud mailbox users can connect to their cloud mailbox, but on-premises mailbox users continue to connect to on-premises servers
- Mail flow is going through Office 365 to take advantage of Exchange Online Protection
Rather than just barrel ahead with changing MX records and migrating production mailboxes, it is a good idea to do some testing first. In this article I’ll test the Hybrid configuration by:
- Creating a test mailbox in Office 365
- Verifying mail flow between on-premises Exchange and Exchange Online is working
- Verifying that the client experience of Exchange Online is working (e.g. GAL visibility, free/busy lookups, ActiveSync device redirection)
- Moving a test mailbox from on-premises Exchange to Exchange Online
Let’s get started.
Creating a Mailbox in Office 365
With the Hybrid configuration in place we can use the Exchange Admin Center to create new Office 365 mailboxes.
For my environment I just need to make sure that I choose an Organizational Unit that is included in my Azure AD Connect synchronization. Aside from that, fill out the other details such as name and password as you normally would.
Switching to the Office 365 section of the Exchange Admin Center, we can see that the new mailbox is not immediately visible.
Directory synchronization of the new user needs to occur, and an Office 365 license needs to be assigned. We can wait for the next directory synchronization cycle to occur, or force a synchronization immediately to speed things up. I prefer to wait, because it allows me to verify that directory synchronization is working fine on its own.
When directory synchronization has occurred the new user will be visible in the Office 365 admin center, and can be assigned a license there.
Alternatively, use PowerShell to connect to Office 365 and assign the license, by setting the location for the user and then assigning the appropriate SKU.
PS C:\> Connect-MsolService PS C:\> Get-MsolAccountSku AccountSkuId ActiveUnits WarningUnits ConsumedUnits ------------ ----------- ------------ ------------- exchangeserverpro:ENTERPRISEPACK 25 0 0 exchangeserverpro:PLANNERSTANDALONE 300000 0 0 PS C:\> Set-MsolUser -UserPrincipalName firstname.lastname@example.org -UsageLocation "AU" PS C:\> Set-MsolUserLicense -UserPrincipalName email@example.com -AddLicenses "exchangeserverpro:ENTERPRISEPACK"
Within a few minutes the mailbox should be visible in the Exchange Admin Center.
Launching Outlook on a computer will verify whether Autodiscover is able to configure the Outlook profile to connect to the cloud mailbox. Note that the user will need to provide their credentials to authenticate to Exchange Online. Thanks to password synchronization they can use the same email address (which should match their UPN) and password as they use on-premises, and save the credentials to avoid being prompted every time.
Verifying Mail Flow
Now that I’ve got a working mailbox in the cloud it’s time to do some mail flow tests. Simply put, the cloud mailbox should be able to send and receive emails for on-premises mailboxes, as well as external mailboxes.
To test this I’ve added another mailbox to the on-premises environment. I’m using a brand new mailbox for this because I will be migrating it to the cloud later as a test of the migration process, and it’s faster to migrate a nearly empty mailbox. However, if I was interested in testing migration throughput, I would use mailboxes with more content in them.
Keep in mind that any on-premises mailbox user you create needs time to synchronize to Azure AD before the cloud mailbox user will see them in the GAL.
Sending an email from the cloud mailbox to an on-premises and and external recipient should do the trick.
When the emails arrive simply reply to them to confirm the return path is working as well.
You should also run the message headers through the message analyzer at ExRCA.com so you can verify that the path the emails took was the expected path.
Verifying the Client Experience
By testing the mail flow we’ve already confirmed that GAL visibility for the on-premises and cloud mailboxes is working as expected. Another aspect of the client experience is free/busy lookups between on-premises and cloud mailboxes. To test this we can simply create a new meeting request in Outlook, and have each mailbox look up the availability of the other.
If free/busy lookups are working then you shouldn’t see any of the “No Information” indications for any of the recipients. To take it a step further, book one meeting between the two recipients and then create another meeting request, and you should see the existing meeting in their free/busy info.
Note, free/busy lookups need to be working in both directions, so make sure you test this from both sides of the Hybrid environment.
We still want to test ActiveSync redirection for mailbox users. ActiveSync redirection will automatically reconfigure an on-premises mailbox user’s mobile device to point to Exchange Online after they are migrated to the cloud. So in order to test this, we need a mailbox with a mobile device already connected to it (which I have already set up), and then we need to perform a mailbox migration.
Migrating a Mailbox to Exchange Online
Since I already have a test mailbox, Hybrid Test 1, on-premises with an Outlook profile and a mobile device connected, it will be a good candidate to test the mailbox migration process.
To initiate a mailbox migration use the Exchange Admin Center. Select the Office 365 section, and navigate to Recipients -> Migration.
Start a new migration batch to “Migrate to Exchange Online”.
The migration type is a “Remove move migration”. Step through the wizard, adding the test mailbox to the migration batch, creating a migration endpoint if necessary, and giving the migration batch a name. You will also need to specify an email address to be notified when the batch has completed. For test migrations I prefer to simply allow the migration batch to automatically complete.
Wait for the migration batch to complete, then restart the Outlook client for the migrated mailbox user. Autodiscover should reconfigure them to connect to Exchange Online, and their mobile device should also be automatically updated the next time it tries to connect. In reality this may not work immediately, but should begin working after a short wait.
After completing the migration you might also like to re-test mail flow and free/busy, just to be sure there’s no lingering issues.
In this article I’ve demonstrated techniques for testing a Hybrid configuration, so that you can be confident that the end user experience will be good when you perform your mailbox migrations to the cloud. In the next part of this series, I’ll move the organization another step closer to the end goal by demonstrating the cut over of mail routing to Exchange Online Protection.