We help Microsoft-centric enterprises fully adopt the cloud & adapt to new ways of working.
\

CATEGORY

Hybrid

Essential has worked on some of the largest Public Folder migration projects in the world.  Here’s a few tips from our gurus:

A few years back you didn’t have an option to migrate your legacy public folders to Microsoft 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 100TB in total – it started out at 2.5 TB and then 50TB so it’s always worth checking here Exchange Online limits – Service Descriptions | Microsoft Docs!

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 vs traditional public folders:

The Modern Public Folder service is very different from the Public Folder database architecture in an on-premises environment.  It basically uses regular mailboxes 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 painful public folder replication.

Here’s how the modern public folder to Microsoft 365 architecture 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 that as far as users are concerned, although the Public Folder to Office 365 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:

https://www.slideshare.net/petsch/modern-public-folders

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 updated to using modern PFs on premises and are using Exchange Server 2013 CU15 or later, Microsoft has a public folder migration solution using batch migration scripts as described in this article:

https://docs.microsoft.com/en-us/exchange/collaboration/public-folders/migrate-to-exchange-online?view=exchserver-2019.

If you are using ‘old school’ PFs (aka legacy PFs) hosted on Exchange 2010 SP3 RU8, you can follow these instructions for batch migration.  

https://docs.microsoft.com/en-us/exchange/collaboration-exo/public-folders/batch-migration-of-legacy-public-folders?view=exchserver-2019

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 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 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 Office 365
  • If users have PF ‘favourites’, they will need to document these before you cut over, as they will disappear

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

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’.

Get in touch with our team for a chat to see if we can help with your public folder migration (or at least point you in the right direction).

Let us migrate your Public Folders to Microsoft 365 (or elsewhere!)

We can simplify your Public Folder & Public Folder Archive migrations – or help you migrate to alternative platforms like Azure  Get in touch to discuss your options.

There’s two things to bear in mind when it comes to migrating mailbox permissions to Office 365:

Number 1 – You won’t get an ‘easy ride’

The process of switching across permissions as you move to Office 365 is not usually plain-sailing. There are always caveats and exceptions which mean you’re going to have to roll up your sleeves and:

  • Do the groundwork to understand what types of permissions you’re migrating, and
  • Pre-empt and be prepared to fix up what doesn’t get migrated post-migration.

This is the only way to ensure a smooth user experience and avoid a deluge of calls to your help desk. In brief, the following scenarios apply to the different migration approaches you might take (some exceptions are outlined later in this article):

  • If you’re planning a Cut-Over or Staged migration approach, using DirSync or the Azure AD Connect tool to provision mailboxes copies any folder permissions and delegate access permissions that exist on on-premises mailboxes into the cloud. Send As or Full Mailbox Access permissions, however, aren’t replicated. This means you’ll need to re-apply these permissions manually as each group is moved over.
  • If you’re running in a Hybrid environment and you’re using MRS to transition mailboxes, this does not (as yet) automatically synchronise Send As permissions. So any usage of this permission must be sussed out in advance and manually re-applied to the relevant mailboxes.
  • If instead of using MRS you plan to use a 3rd-party tool to do your mailbox migration, you will need to be prepared to have to manually re-apply all permissions post-migration unless the tool can do it for you.

 

Number 2 – You’ll need to migrate sharers together

Unless you’re planning to migrate everyone in your organisation to Office 365 over the space of a weekend (e.g. using a Cut-Over migration), you’re always going to have co-existence issues when it comes to permissions working ‘across the divide’. This is because most permissions between individuals and shared mailboxes only work when both the ‘granters’ and the ‘grantees’ (if you will) are in the same ‘place’ – i.e. all on-premises or all in the Cloud. Some permission combination only work one-way – i.e. from on-premises mailboxes accessing a shared mailbox in the cloud, but not the other way around.

If you’re migrating in a Hybrid environment, the good news is that Microsoft now officially supports folk that have been granted Full Mailbox Access to continue ‘business as usual’ regardless of where they are in the migration process. However, given that Send As or Send on Behalf permissions are commonly set up on team mailboxes or between a manager and a personal assistant, this is not in reality going to get you very far. For example, without Send on Behalf being migrated, someone on the help desk may be able to see support emails post-migration, but no longer be able to respond to them if the Help Desk mailbox is still physically on premises.

So, the top tip is to move any ‘sharers’ to Office 365 together, that is, in the same batch.

In order to tackle both of these scenarios you need to be able to assess exactly what permissions are in place.
This is a good blog that explains how to extract the on-premises permissions information you need for review.
https://blogs.technet.microsoft.com/zarkatech/2015/06/11/migrate-mailbox-permissions-to-office-365/

The scripts offered in this blog let you extract permissions into a CSV file, which you can then automatically apply to Office 365 using remote PowerShell using scripts.

So what are the exceptions and other things to watch out for?

As we alluded to earlier, there are always exceptions and complications. For example:

  • Non Mail-Enabled Objects: Any permissions on non-mailbox objects (such as distribution lists or a public folder) are not migrated automatically. Therefore, you need to be able to identify and recreate these permissions in Office 365 using the Add-MailboxPermission or Add-RecipientPermission cmdlets.
  • Distribution Group Permissions: If distribution groups are used to assign permissions, you will need to drill into who is a current member of the group to ensure they are included in the same migration batch. Also you may find you have nested groups, in which case you will need to drill into these also to get the complete picture.

 

Other best practices:

Keep Users Informed on What Might Happen to Their Permissions as They Migrate – the Auto Mapping feature is unsupported when used between mailboxes in on-premises Exchange and Office 365 organisations. This is the service that ensures the mailboxes, calendars, etc. that users have permissions to are automatically added to their Outlook profile. For this reason you may wish to advise users to create a pre-migration inventory of what they have access to so they can re-subscribe post-migration.

Don’t Cancel Meetings – When deciding which mailboxes to move together, make sure you consider any shared Calendars. On a similar subject, to ensure your room booking processes continue to work seamlessly make sure resource mailboxes have all the correct permissions and In Policy booking settings (e.g. automatically accept a room booking within office hours/weekdays). If you have an individual that is set up as a delegate on a room resource mailbox (for example, with the purpose of approving or turning down booking requests), you will need to make sure you migrate that individual along with the room resource.

Have a Permissions Clear Out – As with moving house, migrations are a great opportunity to take stock of what you no longer need. This applies to getting rid of excess access rights.

You should grant minimal access to as few people as possible to accomplish the task at hand. For example, users might grant delegation rights when simply using sharing folder permissions will suffice. Delegate access rights arguably carry more powers than just the ability to review and manage a co-worker’s mail folder. With delegate access a co-worker can send emails and accept meeting invitations on behalf of an individual. They might also be configured to receive copies of meeting invites.

Also note that the administrator applied ‘Send As’ permission can be problematic from a security auditing perspective as it can be difficult to determine who sent an email in the event of a legal investigation. Was it the manager or one of their PAs?

PS – You might consider it a good idea to turn off the feature in Office 365 that allows users to share their Calendars externally.

Don’t Move Backwards – If you discover you’ve moved a manager into the Cloud and not their assistant, it’s not a good strategy to move the manager’s mailbox back down on-premises. It’s always better move the PA across as soon as possible.

Don’t Take it For Granted Microsoft has Everything Sewn Up A relatively recent bug in Exchange and Office 365 meant that – thanks to delegated access rights – emails could be accessed via OWA and effectively deleted from a mailbox without trace, even when the mailbox in question was on litigation hold.

http://windowsitpro.com/blog/owa-bug-compromises-item-preservation-litigation-and-place-holds

This should be fixed at the time of writing, but it highlights the importance of being able to understand what permissions are in place. For example, at the time of the bug being reported a suggested workaround was to disable OWA access for users on In-Place Hold.

Consider Access to Archived items – If you’re migrating archives as part of your migration, ideally you need to ensure that users can still access the archives they could view and search pre-migration, post-migration. This should include items (shortcuts) that were forwarded, for example.

Also typically the archives you move should mirror the batches of mailboxes you move, but if possible, archives can be moved first.

What customers have done in their projects

Keeping track of permissions is clearly a challenging concept and an area that can constantly evolve especially if changes are being made prior to a migration.

In line with the scripts and articles mentioned earlier, a large majority of customers we speak to prefer to proactively manage permissions and ensure there is constant visibility both pre- and post-migration.

To gain this consistent visibility and maintain full control, our customers opt for Mailscape 365 which delivers real time monitoring and intelligent, interactive reports can be scheduled through a web based dashboard to help you work out your array of permissions, including the more tricky delegate permissions before they come back to haunt you. These can be sent as a PDF or CSV which you can use in your scripts.

A few key reports are included below:

You can also do a cross reference with Office 365 once the users are migrated:

  • Office 365 Recipient Permission Report
  • Office 365 Send on Behalf permission report

Mailscape also monitors and reports on your on-premises Exchange system and other technologies such as Skype for Business, SharePoint, Active Directory and much more, so if you would like to learn more and take a test-drive or see a demo, get in touch.

Migrating Mailbox permissions to Office 365

Mailscape also monitors and reports on your on-premises Exchange system and other technologies such as Skype for Business, SharePoint, Active Directory and much more, so if you would like to learn more and take a test-drive or see a demo, get in touch.