Exchange Server 2013 implemented a major change for public folder hierarchies and brought us modern public folders. In the previous versions of Exchange Server, public folders were replicated using their own replication technology. Public folders up to Exchange Server 2010 are called legacy public folders.
I outlined the challenges involved in migrating public folders within a local Exchange organization in a previous blog post. Office 365 supports the direct migration of legacy public folders from a local Exchange organization to modern public folders in Exchange Online. Since this is technically a migration across organizational boundaries (so-called cross-forest migration) there are unique challenges that are addressed in this blog post.
Mailbox migration from a local Exchange organization to Exchange Online requires the configuration of a migration endpoint. Exchange Online accesses the locally installed Exchange organization using this Exchange Server 2016 endpoint.
- It should be noted at this point that there is no installable Exchange role "Hybrid Server." When you use the Exchange Server license provided by Microsoft in your Office 365 tenant the operating role is "Hybrid."
The following diagram shows the access paths for migrating mailboxes and public folders from Exchange Server 2010 to Exchange Online. The path for migrating Exchange mailboxes is shown in green, the path for migrating public folders is shown in blue.
Exchange Server 2016 acts as a proxy server for migrating mailboxes and accepts Exchange Online mailbox move requests through the mailbox migration endpoint listening configured for host name ews.varunagroup.de. The migration endpoint for Exchange mailboxes cannot be used to migrate legacy public folders. The legacy public folders are migrated via a dedicated public folder migration endpoint. An endpoint of this type cannot be created manually in the Exchange Admin Center. It is created as part of setting up the migration batch using Exchange Online Remote PowerShell. Setting up the migration endpoint requires a user account (aka migration account) in the local Active Directory that is an Exchange organization administrator.
If you have already removed the external OutlookAnywhere (OA) access to Exchange Server 2010 or have never used it before, you must configure OA access. External availability of an OA endpoint is a prerequisite for legacy public folder migration to Exchange Online.
About the diagram:
For better readability, necessary components for the publication of internal Exchange endpoints to the Internet are not included.
Email Enabled Public Folders
A word about mail-enabled public folders. Email-enabled public folders had their raison d'être in the past but are no longer state-of-the-art in today's world. You should consider replacing mail-enabled public folders with a modern collaboration solution. When you migrate the public folder hierarchy to Office 365, why not move the capabilities to Microsoft Teams?In the example of this article, mail-enabled public folders existed at the beginning of mailbox migration. These were synced to Office 365 using the SyncMailPublicFolders.ps1 script so users with a mailbox in Exchange Online could send emails to mail-enabled legacy public folders. As part of the preparations for the legacy public folder migration to Exchange Online functions of mail-enabled public folders were migrated to shared mailboxes. This included the deactivation of the e-mail functionality of the affected public folders and re-syncing the changes to Exchange Online.
The process of migrating legacy public folders to Exchange Online is basically the same as migrating to Exchange Server 2016 in a local Exchange organization. The major difference is the configuration of the cross-forest migration batch.
The steps are as follows:
- Public folder names must be prepared before the migration files are created. They cannot contain leading or trailing spaces. Furthermore, public folder names cannot not contain "\" or "/" as these characters are identified as folder level separators. Here you need to decide on an alternative delimiter.
You find a PowerShell script for this purpose in the TechNet Gallery.
- Follow the description provided at TechNet to make a recent snapshot of the current public folder environment configuration.
- Download and run the migration scripts provided by Microsoft.
- Verify the limits (quota) for posting messages to public folders in Exchange Online and adjust the settings to match the local Exchange organization settings. Without adjusting the default limits for modern public folders in Exchange Online, there is an increased risk that an error will occur when migrating legacy public folder contents.
- Create the public folder migration endpoint and the migration batch using PowerShell, making sure to use the authentication method that is configured for the on-premises OutlookAnywhere The TechNet PowerShell example configures Basic as authentication method. Alternatively, NTLM can also be configured as authentication method as well. If the legacy public folder hierarchy still has errors, e.g. contains folders with invalid folder names, the batch setup will fail. In this case you must fix the issues and repeat the setup of the migration batch.
- Start the migration batch when your public folder migration project is ready. After starting the migration batch, the initial synchronization of folder contents and the public folder hierarchy is executed. After initial synchronization completion you can check for each destination public folder mailbox if there were content issues and correct any problem that occurred. The public folder mailbox storing the primary public folder hierarchy will list errors related to the hierarchy. An error scenario related to mail-enabled folders is described below. An incremental synchronization occurs every 24 hours.
- The finalization of the public folder migration will take some time. Since during this finalization users cannot store new content in the legacy public folders this finalization must be executed during a maintenance window. Finalizing the migration batch triggers a final synchronization of legacy public folder content. For finalization, legacy public folders are locked for end-user access. For this lock to be applied in a timely manner, you should restart the MSExchangeIS service on the Exchange 2010 servers that host a public folder database.
Recommendation: Copy the legacy public folder databases to another system before finalizing the migration. This allows for access to the legacy public folder content with EDB-aware tools such as Veaam Exchange Explorer. Do not forget to enable circular logging before copying the databases.
- After finalization of the migration batch has finished, you unlock the access to modern public folders and test the access for one or more cloud-based mailbox users.
- The last step of the legacy public folder migration is to indicate the completion to the on-premises Exchange organization. Completing the migration in the on-premises Exchange organization forces the public folder hierarchy to be removed. You will no longer be able to access legacy public folder data using a standard client. After completing the migration make sure that all public folder mailboxes provide the public folder hierarchy. The changes of public folder access is provided to the Outlook clients using the AutoDiscover configuration. Due to AutoDiscover caching in Exchange Online it can take several hours for all clients to use the new configuration. Plan for this extra time when scheduling the maintenance window for finalization.
Migration Errors with Mail-Enabled Public Folders
As mentioned previously, in this migration example all mail-enabled public folders were mail-disabled before migration and the PowerShell synchronization script was used to synchronize the mail-enabled public folders with Office 365. Unfortunately, the script does not take all necessary steps to fully remove the mail-enabled public folder information in Exchange Online.
As a result, the migration batch will run into the following error:
"Error: More than X mail public folders in Active Directory were not linked to any public folder during migration. Mail flow will stop working for these public folders after the migration is finalized. Please check whether these are important"
You must manually delete the synchronized mail-enabled public folders that no longer exist by using the Exchange Online Remote PowerShell. The following example deletes all mail-enabled public folders that were created by using the Sync-MailPublicFolders.ps1 script in Exchange Online.
Deleting a single synchronized folder in Exchange Online
- Get-MailPublicFolder 'My Mail Public Folder' | Remove-SyncMailPublicFolder
Delete all synchronized folders in Exchange Online
- Get-MailPublicFolder -ResultSize Unlimited | Remove-SyncMailPublicFolder
The migrating of legacy public folders to Exchange Online is easy. It requires, that the legacy public folder hierarchy is prepared for migration, and that folder names do not contain any illegal characters. A suitable OutlookAnywhere endpoint must be accessible from the Internet. Without an OutlookAnywhere endpoint and a migration account, the Exchange Online migration batch cannot copy any legacy public folder content.
Challenge mail-enabled public folders and plan to move to more advanced collaboration solutions. Any necessary removal of public folder email addresses must be completed before migrating the public folders. In comparison to a local finalization of a migration to modern public folders, finalizing a migration to Exchange Online takes about four times the time. Keep in mind that after changing public folder access for the mailbox users in Exchange Online, it may take several hours for configuration changes to be recognized by Outlook clients.
Have fun with modern public folders.