Migrating on-premises mailboxes to Exchange Online
Migrating your user mailboxes to Exchange Online is a significant accomplishment. But then you face a more difficult challenge: migrating your application mailboxes. Careful planning is required because application mailboxes often serve vital business functions.
For example, your company’s application mailboxes may receive important data from printers. But they may also receive alerts from IT security systems. Furthermore, to avoid any business disruption, you must coordinate the migration of these mailboxes with their owners.
This article details the planning requirements to consider when planning application scenarios when migrating on-premises mailboxes to Exchange Online.
Understanding the volume of messaging traffic in your applications
Start by collecting information from Exchange logs about the volume of emails passing through your mailboxes. To catch processes that run less frequently, you may need to examine this data over an extended period of time.
To collect these traffic statistics, you’ll need to gather this information from the Exchange logs. You can do this by running the PowerShell cmdlets below from the Exchange Management Shell. Make sure to change the start and end dates and the Recipients parameter . If you’re using Exchange 2010, you’ll need to replace the Get-TransportService cmdlet with Get-TransportServer :
$usersentresults = Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start "09/14/2021" -End "10/14/2021" -Sender user@domain.com -EventID RECEIVE | where {$_.Source -eq “STOREDRIVER”}
$appsentresults = Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start "09/14/2021" -End "10/14/2021" -Sender user@domain.com -EventID SEND
$mbxrecresults = Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start "09/14/2021" -End "10/14/2021" -Recipients user@domain.com -EventID DELIVER
Write-Output "Count of emails sent by mailbox is $($usersentresults).Count"
Write-Output "Count of emails sent by application is $($appsentresults).Count"
Write-Output "Count of emails received by mailbox is $($mbxrecresults).Count"The above code collects three types of events:
- DELIVER – This event indicates that a message has been delivered to a mailbox. However, there are two send requests above due to how some applications may be configured.
- SEND – This event indicates that the message was sent from an address that does not have an associated mailbox, such as an arbitrary address like noreply@domain.com.
- RECEIVE – This event indicates that the transport service received a message and that a mailbox matches the sender address. Event details may include the storedriver source , which indicates that the Mailbox Transport Submission service submitted a message to the mailbox for delivery.
If you’re sending bulk emails, keep in mind Microsoft’s sender and recipient limits
Next, you need to consider the time limits Microsoft imposes on messages sent and received per mailbox to protect the Exchange Online service. These limits were updated in September 2021.
The most common scenario for exceeding these limits is the use of bulk emails, such as advertisements or marketing messages.
If any of your application mailboxes can’t stay within Microsoft’s limits, you’ll need to plan your strategy for them. You can choose to use a third-party campaign tool for mass marketing and bulk emails, or keep the application mailbox on your last on-premises Exchange server.
Update applications that use EWS
If any of your applications and application mailboxes use Exchange Web Services (EWS) to create and send emails, you will need to update all references to your on-premises EWS endpoint to point to the Exchange Online EWS endpoint, whether or not you use Autodiscover to find your mailboxes in the application.
Additionally, Microsoft announced that it will disable Basic Authentication in Exchange Online starting October 1, 2022.
This change means you need to update the EWS code in all your applications to use OAuth 2.0. Microsoft’s official documents are a good starting point for planning these changes.
For third-party applications and hosted services from a provider, you should ask if OAuth functionality is available. If not, review their roadmap for moving to OAuth.
Update applications that use POP or IMAP
If any of your internal applications and application mailboxes need to access IMAP4 or POP3 in Exchange Online, you’ll need to update them to support OAuth with messages. Similarly, for third-party applications that use IMAP4 or POP3, check when OAuth support will be available.
Your client applications must also support OAuth for POP3 or IMAP4. And Microsoft doesn’t currently plan for Outlook to support POP and IMAP with OAuth. Thunderbird, for example, is an application used to read POP3 and IMAP4 messages that supports OAuth.
There are processes for configuring IMAP4 and OAuth support with Exchange Online. This is extremely useful for updating the configuration after OAuth support is available.
Get ready to move to Microsoft Graph and application access policies
Microsoft announced in July 2018 that EWS would no longer receive feature updates. This is because its strategy for application development is to use Microsoft Graph APIs.
When moving from EWS to Graph APIs, you may need to limit the scope to certain Exchange Online mailboxes.
In an on-premises Exchange environment, you can accomplish this by enabling EWS access to mailboxes through the impersonation application. The code below assigns the ApplicationImpersonation role to a security group. Then it limits the scope of management of that group to certain mailboxes, not the IT/Users organizational unit .
*Note that we could have assigned the role to a specific user or service account instead of a security group.
New-ManagementRoleAssignment -Role "ApplicationImpersonation" -SecurityGroup "ExchSvcAccounts" -RecipientOrganizationalUnitScope "domain.com/IT/Users"In Exchange Online, this is achieved using EWS application policies and Graph API calls.
Conclusion
Migrating on-premises mailboxes to Exchange Online is a critical part of your migration project. However, it’s imperative to understand the volume of email traffic and determine how emails are generated before planning to update internal application code.
