Public Folders in Microsoft Exchange are a complex topic regardless of size. However, for very small environments – a few dozen total folders and less than 1GB of data – it may be simpler and easier to export to PST and import afterwards; but such an approach will require manual actions and scripting to handle permissions and mail-enabled public folders. For larger implementations, software is best to be used as it can automate much of the activity required and can add logic and intelligence to the project that would be difficult to perform manually or by scripting.
The complexity of public folders is influenced by several key components of the public folder system, differences between legacy and modern public folders, Office 365 nuances, limits, and restrictions, and daily business use.
The Public Folder system in Exchange is one that allows an almost limitless quantity of folder count and depth. Implementations that have 100s, 1000s, or 10s of 1000s of folders in the hierarchy add to the complexity of a migration project. Folder permissions and inheritance – which is misleading at best since permissions only inherit on creation – further add to the complexity. Lastly, the ability to have some public folders “mail enabled” extend the complexity to a greater level.
Office 365 Geo Tenants
Office 365 provides a special tenant called a Multi-Geo Tenant that allows for the placement of user and shared mailboxes in specific geographic world-wide regions so that end-users are physically closer to the data they will access. Physical proximity to data influences network latency and responsiveness for mail clients (Outlook, OWA, etc.). However, this feature is NOT available for public folder mailboxes. This means that public folder mailboxes will be hosted in the primary data region of the tenant (usually the region where the tenant was first created). Users that are at great distances from this region will have a much slower and less response experience when working with public folders than those users in the same data region.
Legacy public folders can have multiple public folder databases in which several copies of folder contents can exists as ‘replicas’, but this is a per-folder setting such that it is possible to have some folders with contents only on one database while other folders have contents replicated between multiple databases. It is also possible to have some folders’ contents with a single copy on one database while other folders’ contents have a single copy on another database ending with no single database having a copy of all data.
Modern public folders have new and different complexities. Public folders are contained in one more “Public Folder Mailbox” objects. As mailbox objects they inherit the limits and features of mailboxes as well. One of the major complexities with this new architecture is the replication of the PF hierarchy. Similar to legacy public folders, the public folder hierarchy is replicated to every PF mailbox. However, the contents of any single folder will only ever exist on one mailbox. There is no longer an ability for multi-master replication of contents. For an in-depth explanation of *most* of the operations of modern public folders, refer to these Microsoft articles:
Mail-enabled public folders have a complexity unto itself. Mail-enabled public folders are influenced by specific folder permissions as well as common mail enabled object features like delivery restriction, moderation, and forwarding. The loose coupling between Active Directory – where mail-enabled properties reside for public folders – and the folder hierarchy increase the complexity of public folder substantially, especially when there are 100s or 1000s of objects. For more detail on this topic, review this Priasoft article: https://www.priasoft.com/the-secret-challenges-of-mail-enabled-public-folders-in-microsoft-exchange/ .
Limits of modern public folders add another layer of complexity that cannot be dismissed. If this is an unfamiliar topic, a read of the following Microsoft article about limits is important to understand: https://docs.microsoft.com/en-us/exchange/collaboration/public-folders/limits?view=exchserver-2019. There are slightly different limits between Exchange 2013, 2016, and 2019. It is expected that Exchange 2025 will keep the same limits and Exchange 2019. Legacy public folders did not have the same limits – and in many cases no limits at all – and as such it is common for there to be conflicts between legacy and modern public folders in this topic. Such must be identified and remediated.
A good migration solution for public folders must be aware of all of the above elements.
