Public Folder Migration
Sticky Bit 4: Migrating On-Prem Public Folders to Microsoft 365
Introduction to public folders in Microsoft 365
Introduced into Microsoft Exchange over 25 years ago, public folders are shared folders that can be accessed by multiple users in an organisation. Viewed via Outlook folder lists, and with a deep hierarchical structure that is easy to navigate, they can be used to store information such as emails, calendars and documents. They can also send and receive mails, making them a convenient way to collaborate on projects or allow a team to view customer correspondence and records.
A few years back, public folders were to be ‘end of lifed’ in on premises Exchange, and were not to be offered in Microsoft 365.
Although Microsoft SharePoint and Teams were tabled as alternatives, these were not popular options for a lot of Microsoft customers because they didn’t offer the same functionality and were viewed as over-complicated.
Also many companies have historically built business processes around public folders, such as this shipping company.
Thankfully, Microsoft changed its position and now you can take advantage of modern public folders – a service in Exchange online that seems to be hanging together reasonably well and growing bigger in capacity all the time.
If you still have ‘legacy’ public folders on-premises and want to migrate them into Microsoft 365, the overall amount of storage available to you will be low on the list of your concerns.
For example, if you have a Microsoft Enterprise plan E1, E2 or E3, you’ll have 100 GB of storage per public folder and a maximum number of public folders: 100,000. This can equate to 100TB in a single Microsoft 365 tenancy!
There are, however, other size-related restrictions and some fundamental differences between the ‘old’ public folder architecture and the ‘new’ architecture to be aware of as you plan a migration.
The Microsoft public folder limits in Exchange online are subject to change, so it’s always worth checking
This article looks at the ‘sticking points’ you may find in a public folder migration project.
But first off, it’s worth getting a bit of background on the modern public folder construct vs traditional public folders:
Microsoft Exchange Server Public Folders VS Microsoft 365
Modern public folder construct vs traditional public folders
The modern public folder service is very different from the public folder architecture that started life in the on-premises Microsoft Exchange environment.
Public folders used to have their own separate database, which featured a replication capability for copying selected content across distributed locations.
By comparison, modern public folders use regular mailboxes (their type is ‘Public Folder’ – just like a Room Mailbox is a Mailbox with type ‘Room’) that are automatically linked together and load-balanced for Microsoft 365 as your public folders grow in size.
Being regular mailboxes they also benefit from being part of data availability groups (DAGs) instead of having to undergo (what some considered to be a painful) public folder replication process.
Here’s how the modern public folder architecture in Microsoft 365 works
- You kick off with a single, Primary Public Folder (PF) mailbox (which can grow up to 100GB in size)
- Microsoft 365 detects when a PF mailbox is approaching the 100GB limit and uses an auto-split feature that creates a linked Secondary PF ‘overspill’ mailbox.
- As the next mailbox fills up, another PF mailbox is added and content is automatically re-balanced across all the mailboxes.
- This expansion continues until you hit an overall limit (at the time of the last update to this article it is 1,000 public folder mailboxes and 100TB in a single Microsoft 365 tenancy).
See this page for the latest info: https://technet.microsoft.com/library/exchange-online-limits(EXCHG.150).aspx - A PF hierarchy is maintained alongside the PF contents in the Primary mailbox.
- This hierarchy is updated to reflect the new location of items as new PF mailboxes are added and as content gets ‘re-balanced’ across the available mailboxes.
- Read-only copies of the PF hierarchy are also stored in each of the Secondary PF mailboxes and these are kept in sync with the Primary using Incremental Change Synchronisation (ICS).
The key thing to note that is as far as users are concerned, although Public Folders in Microsoft 365 comprise multiple, ‘lashed together’ mailboxes, they can be viewed and navigated as a single, logical entity.
This is a really great PowerPoint by MVP Peter Schmidt and Microsoft document that describes the whole thing in more detail
5 tips to help you plan your on-premises Exchange to Microsoft 365 public folder migration
Tips to help plan for your public folder migration
Determine the version of public folders are you using on-prem
You may have already updated to using modern PFs on premises and are using Microsoft Exchange Server 2013 CU15 or later, Microsoft has a public folder migration solution using batch migration scripts.
If you are using ‘old school’ PFs (aka legacy PFs) hosted on Exchange 2010 SP3 RU8, you can follow these instructions for batch migration.
Whichever version you’re migrating from you’ll need to run quite a few separate scripts (including a final synchronisation and switch which requires downtime) which means it can be quite complicated to use.
Do a public folder inventory and have a clean up
Some of our customers store vital customer records in PFs. They also have a lot of rubbish in them and migration is a great opportunity to do a sort out.
Start by doing an inventory of your PFs at a ‘high-level’, and get statistics such as size, item count, owners, permissions and last accessed dates.
In order to make solid and defensible decisions around whether content can be deleted prior to migration you’ll need to do a LOT of deeper digging, however gathering initial meta-data can give you some excellent pointers. For example:
- Removing empty and duplicate folders can be a quick fix
- Orphaned folders with an old last accessed date are a very obvious candidates for a clean up
- Knowing the owner of a PF (assuming it’s not ‘Administrator’) can help signpost who you need to contact in order to see if content can be disposed of
As ever with records disposition decisions, seek to get the relevant data custodians to call the shots – don’t go it alone!
Bear in mind that a potential downside to deleting or excluding older/stale contents from your migration is that you could create an eDiscovery headache later. For example, an HR dispute may refer back to employment terms and conditions, pension fund arrangements, etc, that were published decades ago.
Analyse your PFs for potential problems
Given the inherent differences between the architecture of old PFs and Modern PFs, you’ll need to spend some time eliminating things that will upset the migration process. For example:
- Check for stale permissions
- Check there are no orphaned PF mail objects or duplicate PF objects in Active Directory
- Check PF names – syntax errors in your legacy PF naming convention can cause problems. For example:
- If the name of a PF contains a backslash () it will end up in the parent PF when migration occurs.
- Trailing whitespaces within Mail enabled PFs and commas in the Alias field will also create synchronisation problems.
- Check all mail enabled folders to see that they have the right proxy address.
- If you have any forms, these need to be exported and re-imported into Microsoft 365
- If users have PF ‘favourites’, they will need to document these before you cut over, as they will disappear
Chop up legacy public folders to fit into the new Microsoft 365 model
As we said earlier in this article, Microsoft 365 performs an auto-split and load-balancing function as PFs approach 100GB in size, but this process can take up to two weeks to complete. This is not usually a problem when you are populating a PF during ‘normal use’, but when you’re in a midst of a wholesale migration, you’ll be chucking data into Microsoft 365 PFs at a rate of knots, and Microsoft 365 can’t recalibrate itself fast enough.
Common to all migration approaches, therefore, is the need to take the Microsoft 365 PF size restriction of 100GB per mailbox into consideration and effectively run scripts to ‘chunk up’ your PFs into separate PFs that are less than 100GB in size before you start your move. We suggest you check that your ‘chunks’ are split according to logical subfolders.
Don’t overlook that fact that some of the items in PFs may be archived, as this will not only impact how you do your migration, it will also impact your sizing analysis (as shortcuts to archived items can be a fraction of the actual item size). Check the message class to do this – e.g. IPM.NOTE.EnterpriseVault.Shortcut
There are many other considerations to take on board to ensure the best outcome post-move, such ensuring optimum retrieval times by putting PFs in a geographic location that’s near to users that will be accessing it. Ensuring the number of people accessing PFs is kept below 2,000 per mailbox is also recommended.
Post-move you’ll need to do lots of checking and you might also need to re-mail-enable mail-enabled PFs post migration as this attribute might not get migrated.
You can find other considerations for your public folder migration here
Find a third-party tool or a migration partner
There’s a few tools around that can help you with your migration and the best ones start by enabling you to do an up-front analysis of the state of your PFs so you see (and address) what might ‘trip you up’.
The one we particularly like also has a neat algorithm that lets you map your current public folder hierarchy into new modern public folder arrangement.
Another area where you might need assistance is if you’ve been archiving public folders in the past, for example, using Enterprise Vault or EAS.
At a push you can export archived content to PST files and use these as a mechanism for uploading on-premises PFs into Microsoft 365, but you need to know what you’re doing when it comes to splitting your PFs into ‘mailbox chunks’.
Let our experts help migrate your legacy Public Folders to Microsoft 365 (or elsewhere!)
We can simplify your on-premises Public Folder & Public Folder Archive migrations – or help you migrate to alternative platforms like Azure Get in touch to discuss your options.
