A few years back you didn’t have an option to migrate your legacy public folders to Office 365 – in fact public folders on-premises were to be end-of-lifed. SharePoint was initially tabled as an alternative, but this didn’t ‘wash’ with a lot of Microsoft customers because it didn’t offer the same functionality and was over-complicated.
Microsoft quickly changed its position (no doubt following uproar from lots of disgruntled customers) and now you can take advantage of modern public folders – a service that seems to be hanging together reasonably well and growing bigger in capacity all the time. It’s now 50TB in total – only a short while ago it was 2.5 TB!
As you might imagine, there are some caveats, clean-ups and other considerations that come into play if you want to make the move.
But first off, it’s worth getting a bit of background on the modern public folder construct:
The modern public folder service is very different from the public folder database architecture you’ll already be familiar with. It basically uses regular mailboxes that are automatically linked together and load-balanced (for Office 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 painful public folder replication.
Here’s how the modern public folder architecture works:
- You kick off with a single, Primary Public Folder (PF) mailbox (which can grow up to 100GB in size)
- Office 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 50TB in a single Office 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 that as far as users are concerned, although the Public Folder mail 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 that describes the whole thing in more detail:
See also this Microsoft document for details: https://docs.microsoft.com/en-us/exchange/collaboration/public-folders/limits?view=exchserver-2019
Planning Your Migration
Can you migrate?
If you’ve already upgraded to Modern Public Folders on-premises (i.e. you’re using Exchange 2013 or above), Microsoft does not currently offer a ‘native’ migration solution.
At the time of writing you will need to look to a third-party migration solution to help out. If you don’t want to go down that route, the other option is to keep your PFs on-premises and access them from the cloud until Microsoft delivers a solution.
If you are using ‘old school’ PFs (aka legacy PFs) hosted on Exchange 2010 SP3 RU8 or later or Exchange 2007 SP3 RU15, Microsoft has a migration solution using batch migration scripts as described in this article:
You’ll need to run around 11 separate scripts in total (including a final synchronisation and switch – yes – it’s using MRS) which means it can be quite complicated to use.
Using a third-party tools can simplify the process. The tool from Binary Tree is interesting as it performs a two-way PF synchronisation between Exchange on-premises and Office 365. This has the benefit that all users are able to continue to access up-to-date PF content regardless of where they are in the migration process – on-premises or in the Cloud. You can also elect when you migrate yours PFs, as otherwise you would typically wait until you have migrated all your mailboxes into the Cloud.
There’s another neat tool from Exchange Savvy you might want to check out too.
If you’ve been archiving public folders in the past, for example, using Enterprise Vault, you can use solutions like TransVault to move archived content, and indeed regular PFs, to Office 365.
At a push you can also use PST files as a mechanism for uploading on-premises PFs into Office 365, but you need to know what you’re doing when it comes to splitting your PFs into ‘mailbox chunks’ (see below).
Do an 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 Glitches
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 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.
Chunk Up Your Legacy Folders to Slot Nicely into the New Separate Mailboxes Model
As we said earlier in this article, Office 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 Office 365 PFs at a rate of knots, and Office 365 can’t recalibrate itself fast enough.
Common to all migration approaches, therefore, is the need to take the Office 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 here: https://technet.microsoft.com/en-us/library/dn957481(v=exchg.160).aspx
Essential can help you with reviewing your public folders, and includes:
- Storage Trending
- Public Folders by Access Time (Tree View + List View)
- Public Folders by Size (Tree View + List View)
- Top 10 largest folders
- Empty PFs
- Top 25 Public Folder owners
- Public Folders by Last Post
We can also simplify your Public Folder and Public Folder Archive migrations – or even help you migrate to alternative platforms like Office 365 Groups. Get in touch to discuss your options.