Share via

Things to be aware of while migrating to Exchange Online

  • Article

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 a small 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 small show stopper:

There are a lot of things to keep in mind when migrating to Exchange Online. One is about 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.

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.

https://msb365.abstergo.ch/wp-content/uploads/2017/10/2-1.png

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.

https://msb365.abstergo.ch/wp-content/uploads/2017/10/3-1.png

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

There are two EWS paths. An internal and an 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:

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

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

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

To test the access you can use the following PowerShell script. It’s using the default EWS dll path when the 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 = 'User@Contoso.com' # 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, but any information about the mailbox is unattainable. For example, OOF settings:
 
$SmtpAddress = 'User@Contoso.com' #On-premise mailbox, or Exchange Online mailbox
 
$Service.GetUserOofSettings($SmtpAddress)