Things to be aware of when migrating to Exchange Online

2018 is already knocking at the door and more and more of my customers find their way towards the cloud. On one hand to Office 365, but mostly towards Exchange Online.

During the Ingnite 2017, besides the announcement of Exchange Server 2019, Microsoft finally approved the upcoming support for tenant to tenant migrations.

This helps a lot of decision-makers to go for the cloud and migrate their infrastructure. This, because of the freedom to still be able to change and adjust things after the migration is done. From my point of view Microsoft is on the right path in doing so.

But still one has to be aware that a migration to the cloud can lead to unexpected issues. I’ll describe some little and a big show stopper for you here. Please mention the big one during your migrations!

So far so good. Let’s first start with the little show stoppers.

Little show stoppers

Mailbox permissions

There are a lot of things to keep in mind when migrating to Exchange Online. One is the mailbox delegation and group/shared mailbox ownership. It is not possible to have Send-As rights on an on-premises mailbox for a mailbox which was migrated to the cloud and vice versa!

SMTP address

Furthermore it might be possible, that a mailbox migration to Exchange Online just fails with an error:

In most cases it’s just a simple issue. While looking at the Exchange user object I noticed, that this user doesn’t have an “.onmicrosoft.com” STMP address.

So, what to do now? Very simple! Just go to ‘Add’ and create an additional SMTP address for that user with the ‘.onmicrosoft.com’ domain of your O365 tenant. Afterwards the migration will no longer fail.

Big show stopper – Exchange Web Services

A far bigger thing are 3^rd party systems like ERP’s and others which are accessing Exchange through the Exchange Web Services (EWS).

The challenge

There are two EWS paths. One internal and one external. The challenge here is that applications which are using EWS can whether access on-premises mailboxes (internal), or cloud mailboxes (external). And here comes the solution for this challenge.

The solution in steps

Tell your application to use the external EWS path
Login to Exchange Online Admin Center
Go to “Permissions” -> “Admin roles”
Edit the role “Discovery Management”
Add the following permission to the role: “ApplicationImpersonation”
Add the (service) account, used by your application as a member of the role.

The solution explained

Here’s what we did and why we did it.

First we added the “ApplicationImpersonation” permission to the Discovery Management role. Members of the Discovery Management role group can perform searches of mailboxes in the Exchange organization for data that meets specific criteria and can also configure litigation holds on mailboxes. See https://technet.microsoft.com/en-us/library/dd638105(v=exchg.150).aspx

The Application Impersonation permission is needed for the access through EWS using impersonation. Impersonation enables an account on an Exchange server to perform actions by using the permissions that are associated with another account. See https://msdn.microsoft.com/en-us/library/office/dd633680(v=exchg.80).aspx

In the next step we just added the account used by the application to the Discovery Management role. By this it now can use impersonation through EWS and can also perform mailbox searches.

Test it

To test the mailbox access through EWS you can use the following PowerShell script. It’s using the default EWS dll path from Exchange Web Services API 2.2 is installed. Change the path if needed.

#requires -RunAsAdministrator

$EwsDll = 'C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll' # Path to EWS dll

$Username = '[email protected]' # migrated to Exchange Online - Service account, which is member of the role “Discovery Management”

$Password = 'Pa$$w0rd'

Add-Type -Path $EwsDll

$Service = New-Object -TypeName Microsoft.Exchange.WebServices.Data.ExchangeService

$Arguments = @($Username, $Password)

$Creds = New-Object -TypeName Microsoft.Exchange.WebServices.Data.WebCredentials -ArgumentList $Arguments

$Service.Credentials = $Creds

$Service.TraceEnabled = $True

# Autodiscover approach (RECOMMENDED):

# $Service.AutodiscoverUrl( $Username, {$True} )

# Hardcoding the EWS endpoint:

$Service.Url = "https://mail.Contoso.com/EWS/Exchange.asmx"

$Service | Format-List

# A connection is established and information from the mailbox can be gathered. For example, OOF settings:

$SmtpAddress = '[email protected]' #On-premise mailbox, or Exchange Online mailbox

$Service.GetUserOofSettings($SmtpAddress)

Post Views: 5,050