Migrating your user mailboxes to Exchange Online is a significant accomplishment, but afterward you face a more difficult challenge: migrating your application mailboxes. Thorough planning is required because application mailboxes often serve vital business functions.
For example, application mailboxes in your organization can receive important data from printers and electronic fax systems, alerts from IT security systems, reviews from customer service applications, and more. Moreover, to avoid business disruptions, you need to carefully coordinate the migration of these mailboxes with their owners.
This article details the planning requirements and key factors to consider as you plan the various application, authentication, and mail flow scenarios you may encounter when migrating on-premises application mailboxes to Exchange Online.
Understand the email traffic volume of your applications
Start by gathering information from the Exchange message tracking logs about the volume of emails that your application mailboxes send to and receive from your applications. To ensure that you catch processes that run less often, you may need to look at this data over an extended period.
To collect these traffic statistics for a selected time period, you will need to gather this information from the Exchange message tracking logs, and you can do so by running the following PowerShell cmdlets below from the Exchange Management Shell. Be sure to change the Start and End dates and 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 code above collects three types of events:
- DELIVER — This event indicates a message was delivered to a mailbox. However, there are two send queries above due to how some applications might be configured.
- SEND — This event indicates the message was sent from an address that does not have a mailbox associated with it, such as an arbitrary noreply@domain.com type of address.
- RECEIVE — This event indicates a message was received by the transport service and that there is a mailbox associated with the sender address, The event details might include the source storedriver, which indicates the message was submitted by the mailbox to the Mailbox Transport Submission service for delivery.
If you send bulk email, keep Microsoft’s sender and recipient limits in mind.
Next, consider the hourly limits that Microsoft imposes on send and receive messages per mailbox to protect the Exchange Online service. These limits were updated in September 2021.
The most common scenario where these limits are exceeded is the use of bulk email, such as mass advertisements or marketing messages.
If any of your application mailboxes will be unable to stay under Microsoft’s limits, you need to plan your strategy for them. You might opt to use a third-party campaign tool for mass marketing and bulk emails, or to keep the application mailbox on your last on-premises Exchange server.
Update applications that use EWS
If any of your applications and application mailboxes are using Exchange Web Services (EWS) to create and send emails, you will need to update any 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 it will be disabling basic authentication in Exchange Online effective October 1, 2022 with the exception of SMTP Auth. (This change was originally planned for 2020 but was pushed back due to the pandemic.) For more information about what to expect, this Practical 365 podcast featuring Microsoft’s Greg Taylor can provide additional insight.
This change means you need to update the EWS code in all your in-house applications to use OAuth 2.0 for authentication. The official Microsoft docs provide a good starting point for planning these changes.
For third-party applications and hosted services from a vendor, you should ask your vendor whether OAuth functionality is available in their product today. If it is not, investigate their roadmap for moving to OAuth, as well as for moving from EWS to the Microsoft Graph API which is discussed in the next section.
Update applications that use POP or IMAP
If any of your in-house applications and application mailboxes need to access the IMAP4 or POP3 protocols in Exchange Online, you will need to update them to support OAuth with messages. Similarly, for any third-party applications that need IMAP4 or POP3, work with your vendor to see when OAuth support will be available.
Your client applications must also support OAuth for POP3 or IMAP4, and there are no plans from Microsoft at this time for Outlook to support POP and IMAP with OAuth. Thunderbird for example, is a client app commonly used to read POP3 and IMAP4 messages that does support OAuth.
While it’s unlikely that your applications will leverage a client like Thunderbird to perform those tasks, there are processes in place to configure IMAP4 and OAuth support with Exchange Online – extremely useful if you need to update configuration of your applications after OAuth support has been added.
Prepare to move to Microsoft Graph and application access policies.
Microsoft announced in July of 2018 that EWS will no longer receive feature updates, since part of their long-term strategy for application development in gathering data from Microsoft 365 is to use the Microsoft Graph APIs.
As you move from EWS to Graph APIs, you may need to restrict the scope to certain mailboxes in Exchange Online and to individual tasks within a mailbox.
In an on-prem Exchange environment, you can accomplish this by enabling EWS access to mailboxes through application impersonation. The code below assigns the ApplicationImpersonation role to a security group and then restricts the management scope of that group to a particular set of mailboxes, and not the entire environment, or the IT/Users organizational unit.
*Note that we could have assigned the role to a particular user or service account instead of a security group.
New-ManagementRoleAssignment -Role "ApplicationImpersonation" -SecurityGroup "ExchSvcAccounts" -RecipientOrganizationalUnitScope "domain.com/IT/Users"In Exchange Online, the same result can be achieved using a combination of EWS application access policies and Graph API calls.
Conclusion
Moving your application mailboxes to Exchange Online is a vital part of your migration project, but it’s imperative that you gather email traffic volume and determine how the emails are generated before planning to update internal application code or test feature functionality of third-party products. By simply including the considerations outlined here in your planning process, you can help ensure success in anticipation of the deadline in October 2022.
