Back to blog

Are shared mailboxes the right destination for your public folder data?

Sep 5, 2017 by Emma Robinson

As we’ve discussed in previous posts, there are various potential locations for legacy public folder data in Office 365, and choosing the most appropriate target can be a challenge. It really depends on what you’re planning to move, and how it is being used.

What are shared mailboxes?

One possible destination for public folder data is shared mailboxes. This is a feature that enables a group of users to see and send e-mail from a common mailbox. There are plenty of use cases for this functionality – many companies use it to offer support or help desk services, to ensure that all communications and exchanges are tracked and widely visible.

Read more Optimizing PowerShell for large Office 365 tenants

As a useful and commonplace feature in both Exchange and Exchange Online, it’s likely you’re familiar with either using or managing shared mailbox functionality – but here are a few fundamental points about shared mailboxes in Exchange Online

  • Shared mailboxes do not require a specific/additional licence for the functionality, but as the user has to sign into their own mailbox in order to access them, they will need a subscription or licence to access shared mailboxes and use them.
  • You will need an an Exchange Online Plan 2 license or an Exchange Online Plan 1 with Exchange Online Archiving if you want to use In-Place Archiving or put a shared mailbox on In-Place Hold or Litigation Hold.
  • Shared mailboxes have a maximum size of 50GB.
  • Shared mailboxes do not offer self-service, and can only be created and managed by an Exchange admin.

What makes shared mailboxes a good destination?

The shared mailbox feature in Exchange Online can be used to share events, tasks and contacts. One of the key benefits of migrating legacy public folder data to shared mailboxes is that users get a very similar UI experience.

Here are a few reasons why shared mailboxes could be the right target:

  • Both shared mailboxes and public folders support ‘Send as’ and ‘Send on behalf of’ permissions.
  • Custom replies and forms are also supported by both solutions.
  • Shared mailboxes can also expose additional folder types and Outlook functionalities where public folders cannot.
  • Cross-premises (hybrid) access is supported for shared mailboxes.

Potential use cases

The following use cases demonstrate where shared mailboxes can be used for similar purposes to public folders, and could be a suitable replacement option:

  • Shared mailboxes can be used effectively as a central email repository for sharing and storing mail items.
  • Shared mailboxes can be used as a distribution list archival.
  • They can be used to store PSTs or personal archives.
  • Shared mailboxes could be used to store a Contacts list – however this would only be a suitable option for smaller teams (explained further in the limitations below).
  • Finally, the feature could be used to store a Tasks list.

Are there any limitations?

There are some limitations to shared mailboxes which should be noted. As we mentioned above, an Exchange Admin needs to create the shared mailbox, whereas public folders can be created and managed by end users. This means that public folders offer a ‘self-service’ approach, which is handy for the user but also delivers a level of freedom which can be a double-edged sword. End users can create and manage their own public folders, boosting productivity and autonomy by saving admin time and involvement. However, this also means that hierarchies are often left to grow and grow, without centralized management.

The result? Many organizations have huge public folder hierarchies, full of stale, unused content, and it’s very difficult to clear up, consolidate and migrate the relevant data. If you need to exert a level of control over how collaboration channels are created, used, and managed – perhaps this is not a limitation for you, and shared mailboxes are a good option for ensuring that data is less able to accumulate or get out of control again.

A somewhat related consideration is quotas and storage space. The shared mailbox size limit is 50GB, so if your public folder is larger than this you may need to split up the structure into smaller public folders pre-migration before you move them across. As we’ve pointed out, public folder hierarchies can amass huge volumes of data, which could make migrating to shared mailboxes impractical, or even impossible in some cases.

Read more Optimizing PowerShell for large Office 365 tenants

Shared mailboxes are not able to scale as effectively as public folders. They can have significant performance issues if large groups of users need simultaneous access. This means that to guarantee good performance, the feature is only suitable for smaller teams (that are planning to stay that way) – which is something that should be considered.

Unlike public folders, shared mailboxes can often have issues with ‘Sent’ and ‘Deleted’ items, which can be addressed, but should still be explored before choosing the feature (support articles and workarounds are linked here). It is also not possible to see ‘per-user read status’ on items. This means that a mail item will show as ‘read’ for everyone who has access to the shared mailbox if one person has viewed it. This is a feature that is often sought after for certain use cases in public folders, so if it is required going forward – then shared mailboxes aren’t the right migration option for you.

Finally, one of the biggest issues with shared mailboxes is mobile access (although public folders do not have this either). While this is clearly not a consideration that is specific to public folder migrations into shared mailboxes, as more and more users need to work on the move, and often across different devices – it is definitely something to consider before you choose to implement this feature.

What if they’re not the right option?

If shared mailboxes aren’t the right choice for some or all of your legacy public folder data, there are various other options out there that offer different feature sets, and could be better suited. This blog series will continue to explore the viability of potential targets, so make sure you check back over the coming weeks.