Preservation Policies in Office 365
Preservation policies were introduced almost a year ago as part of the Compliance Center in Office...
Many companies use old-style public folders, known as legacy public folders, on Exchange Server 2010. Often, the public folder hierarchical structures have grown uncontrollably for years. And not only in terms of data volume but also in the number of folders and the folder depth in the public folder hierarchy. For these reasons, many companies fear legacy public folder migration to modern public folders.
On January 14, 2020, Exchange Server 2010 reaches the end of support. Up to that date, you should have migrated the existing public folder hierarchy to Modern Public Folders in Exchange Server 2016/2019 or Exchange Online. After this date, your Exchange Server 2010 systems are in an unsupported state and pose a risk to the secure operation of your IT platform.
Migration of all public folders, without a revision of the contents and folder structures, should not be done.
Migration of legacy or modern public folders to Exchange Online must be well considered and prepared.
The preparation of public folders for a migration, regardless if migrating on-premises only or migrating to Exchange Online, must consider the following actions and considerations:
Conversion and cleanup of the mail-enabled folders ensure secure delivery of email messages during the migration and finalization phase of the public folder migration. Regardless of whether you migrate the public folders to Exchange Server 2016/2019 or to Exchange Online, the delivery of emails is paused. After completion of the public folder migration batch queued email messages are rerouted to the new public folder environment and delivered to the target folder. This is not acceptable for time-critical e-mail messages.
The information about a mail-enabled folder is not stored within the public folder hierarchy only. A mail-enabled folder has a corresponding Active Directory object stored in the MESO container. If the permission for Exchange Server has been customized for this container, the Active Directory object is not correctly removed or modified when disabling the mail-enabled public folder. If you disable a mail-enabled public folder, the Active Directory object remains in the MESO container and causes problems when migrating to Exchange Online. This error is not noticeable in an on-premises Exchange Server environment. This misconfiguration lies dormant underground, waiting to be discovered.
The cleanup of folder permissions to group-based permissions results in standardization and simplification of public folder access. Even with a purely on-premises operation of public folders, you profit from this change in permission assignment. However, if you plan to migrate the public folders to Exchange Online, this transition is a must. Customizing folder permissions after migrating to Exchange Online is a challenge. If the folder hierarchy is relatively flat and contains few folders, you will not have any problems recursively adjusting folder permissions using PowerShell or the Exchange Online Admin Center.
Especially in sales-oriented companies, public folder hierarchies have grown uncontrolled over the years. I had the pleasure of making a special experience with a folder hierarchy consisting of about 120,000 folders after migrating to Exchange Online.
The following is a simple example screenshot of a sales-based public folder hierarchy.
If you want to use Remote PowerShell to set folder permissions in such a folder hierarchy, you will run into problems when executing the cmdlets.
Due to the special mode of operation as a SaaS-offering, there are clear limits to the processing of cmdlets in a Remote PowerShell session of Exchange Online. You can execute a maximum of 120 destructive cmdlets every 60 seconds. If you exceed this threshold, your cmdlets will be delayed by so-called MicroDelays. Destructive cmdlets are defined as cmdlets, such as adding or changing settings, as set *, remove *, new *, or add * cmdlets.
You add public folder permissions by using the Add-PublicFolderClientPermission cmdlet. Modifying existing permissions always consists of two configuration steps, the removal of the old permission (Remove-PublicFolderClientPermission) and the addition of the new permission. This results in two destructive cmdlets for each updated permission.
This problem not only affects you when running a remote PowerShell session but also when you update permissions using the Exchange Online Admin Center (EAC). The difference is that the Admin Center displays a “Success” message that makes you believe that the new permissions for all folders have been updated. Reality has shown that the PowerShell cmdlets executed in the background are limited by the same thresholds.
Alternatively, you can update the permissions using Exchange Web Services (EWS). There are professional software solutions available to help you update the permissions using EWS. However, there are thresholds for the EWS protocol in Exchange Online as well. The software tries to avoid reaching the limits by adding short delays between each set of permission updates. This results in a much longer runtime when adjusting a larger number of permissions.
My recommendation is to prepare your on-premises public folder hierarchy and the assigned permissions before migrating legacy public folders to modern public folders to Exchange Server 2016 or to Exchange Online. The result is a hassle free migration of public folders. The clean-up of assigned permissions ensures that you only must maintain group memberships after the migration.
ENow's reporting capabilities help prepare organizations for public folder migrations. One of the many challenges many organization face is not knowing what they have and if that information is still used today. ENow's last "Public Folder - Last Access Report" allows admins to easily identify the last time end users have accessed folders.