Finally moving your Enterprise Public Folders to the cloud? Understand protocols and options (spoiler alert! some are no more than wishful thinking)

If your first thought when you read this blog title, was “but do people still use Public Folders?”, the answer is YES!

Not only corporations still use Public Folders, but also they want to move them to the cloud and keep using them.

For the past year or two, working for a company that owns an outstanding migration product, MigrationWiz, I’ve seen a trend of large organizations worldwide getting to their final stages of the transition to the cloud. Usually, what that means in practical terms, is that they are addressing the more complex and harder to move or coexist workloads, which also translates to Public Folder migrations, amongst other things.

For many years Microsoft made it easy for Microsoft 365 users to access Public Folders on premises, and not that long ago they enabled on premises users to access Microsoft 365 Public Folders.

What Microsoft never supported, although it was technically possible, was two source of authorities for a Public Folder infrastructure, within a Hybrid Deployment. But all this flexibility pushed Public Folder migrations to the back of the “moving to the cloud” workload queue.

So now that we have a little bit of context on Public Folder migrations, lets address the options, when you decide to finally make the move.

How much data do you have to move?

From my experience, there are fundamental differences between two main types of migrations, you might be faced with. My first exercise, when trying to help a customer or a partner, plan their Public folder migration, is to determine if it’s a small or a large migration. Let me share with you where do a draw the line between both:

  • Small migrations: Migrations of up to 50GB of data, 1000 folders and 100k items
  • Large migrations: Anything above that

The main differences between a large and a small migration

Depending on the volume of data, or migration project can be simplified, or very complex. Here’s some bullet points on why:

  • Small migrations can easily be done with lift and shift protocols, like OA (Outlook Anywhere) or MRS (Mailbox Replication Service), however if you are looking at data transformation – this topic justifies a dedicated blog post, so won’t get into much detail on it here, but you can characterize migrating from Public Folders to Shared Mailboxes as an example of data transformation – and/or filtering or mapping the data differently from the source, you should use an EWS based migration product.
  • Small migrations do not require pre migration split work, to balance data between multiple destination mailboxes. In fact the lift and shit protocols do not require that.
  • Remember the wishful thinking mentioned on this blog title? Well trying to execute large migrations with lift and shift protocols, is exactly that. If you think you can migrate 2TB of Public folders with MRS, there’s no better way of saying this so I’ll just go for it: “YOU’RE WRONG”.
  • In addition to the above, large migrations also require pre migration work, that will basically focus on splitting the data into smaller chunks and pointing it to multiple target mailboxes, just so we never rely in the Microsoft auto splitting process for Public Folders.

Available protocols

Now that we outlined some of the biggest differences between large and small migrations, lets talk about the available protocols to migrate:

Outlook Anywhere

Outlook Anywhere is an old legacy protocol, that amongst other things, can be used to migrate Public Folders from Exchange 2010 to Exchange Online. But what are the main problems with Outlook Anywhere?

  • as stated above, the protocol is legacy and Microsoft actually stopped supporting it, in Exchange Online, back in 2017.
  • OA migrations are lift and shift and not feasible for large volumes of data
  • Setting up and/or troubleshooting OA can become complex really fast, in an Exchange version that is EOS since October 2020
  • Previous patching of the Exchange Server can be needed, before proceeding
  • Obviously it goes without saying but, OA does not support EXO (Exchange Online) as source

Mailbox Replication Service

MRS is a well established “migration-ish” protocol, that is very well know for it’s use in Hybrid migrations. For Exchange 2013+ that is the method used. Once again, where can things go wrong here?

  • With MRS, just like with OA, you’ll follow a lift and shift migration and face all the challenges that come with it, for large volumes of data
  • Being a lift and shift doesn’t only make it nearly impossible for some scenarios, it also makes it a non suitable option for mergers, acquisitions, hosted exchange and any scenario where you either have multi tenancy or you don’t want to target the entire Organization, in source or destination
  • The permissions the MRS requires can also be a road block, for the scenarios described in the bullet point above

Exchange Web Services

With Exchange Web Services the approach to migrate the data will be completely different. EWS will target each item in the source and create it in the destination (obviously this is done in batches of items). What that gives you is a whole bunch of options, such us:

  • When to migrate which data (folders, items) and to where (i.e PF to Shared mailboxes)
  • Split the source data to optimize speeds
  • Resume the migration from where it failed, when it does (believe me, at some point if your structure is huge, it will fail)
  • Migrate Terabytes of data
  • Scope source and destination permissions as needed
  • Target Public Folders in Hosted Exchange, per tenant
  • Migrate from Exchange Online

The bottom line

I hope that now that you read this, if you’re thinking about moving your decades old Public Folders into M365, at least you know the options you have.

There are pros to MRS (not so much to OA, to be honest), and if you have 5GB of PFs to migrate, an up to date Exchange with hybrid in place, then you can use it, but this blog post is focused in Enterprise customers, with hundreds of GBs or even TBs of data to move, and being very pragmatic, from my knowledge, that’s just not possible to do, with MRS.

Do let me know if you have any questions. Thank you for reading!

Exchange Online: The end of RPC over HTTP

And that’s it, more than 3 years after Microsoft launched MAPI over HTTP (the replacement for RPC over HTTP – aka Outlook Anywhere), now it’s time to announce that in October 31st 2017 the RPC over HTTP feature will be deprecated in Office 365.

Some of my thoughts on this, and things you should consider..

How about Exchange On-Premises?

The deprecation of RPC over HTTP is announced just for Exchange Online. What does that mean to Exchange on premises deployments? Probably that in a future Cumulative Update the feature will be discontinued, but for now, all stays the same with on-premises.

When Microsoft launched Exchange 2016 they listed the RPC over HTTP feature as de-emphasized and not discontinued. ¬†That basically meant that it still works and it’s still supported.

That doesn’t mean that this will always be the case, and with this announcement coming now to Exchange Online, maybe a new Exchange 2016 CU will remove the RPC over HTTP feature, or maybe this is just Microsoft not publishing the rpc virtual directory anymore, in Exchange Online. I guess that at some point we will find out, but for now all supported versions of Exchange also support RPC over HTTP in an on-premises deployment.

My personal opinion is that it won’t take long for RPC over HTTP to be also deprecated i

Check the matrix below for current connectivity supportability:

Product Exchange 2016 RTM Exchange 2013 SP1 Exchange 2013 RTM Exchange 2010 SP3
Outlook 2016 RTM
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 SP1
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 RTM Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and updates KB2956191 and KB2965295 (April 14, 2015)
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and earlier Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2007 Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere

Any versions of Outlook being affected?

The simple answer is yes. All versions will be affected. Outlook 2007 will stop working (remember Office 2007 is out of extended support), and all other versions need to be properly updated, to the minimum versions described on the table below:

Office version Update Build number
Office 2016 The December 8, 2015 update
  • Subscription: 16.0.6568.20xx
  • MSI: 16.0.4312.1001
Office 2013 Office 2013 Service Pack 1 (SP1) and the December 8, 2015 update 15.0.4779.1002
Office 2010 Office 2010 Service Pack 2 (SP2) and the December 8, 2015 update 14.0.7164.5002

Read the Microsoft article for more details on the above.

Why MAPI over HTTP?

Let me bullet point some main reasons:

  • Better connection resiliency
  • Additional secure sign-in scenarios (multi-factor authentication)
  • Better foundation for third-party identity providers
  • Less complexity as it doesn’t depend on RPC technology
  • With less complexity the Exchange team can innovate more quickly
  • Fits into today’s reality with clients connecting from all sorts of different networks

So in a nutshell, it’s more secure, more flexible and reliable in terms of connectivity, and it’s less complex.

For more information read this amazing blog post from the Exchange product team, around MAPI over HTTP.

What should an Exchange Online administrator start doing, right now?

Identify the Microsoft Outlook versions and builds that his users have and use to connect to Exchange Online.

How? Using the PowerShell is the best method. Here’s an example command that you can run:

Get-Mailbox | Search-MailboxAuditLog -LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like “*Outlook*” } | select MailboxOwnerUPN,Operation,LogonType,LastAccessed,ClientInfoString | export-csv .\OutlookConnections.csv

I will write a blog post soon with more details, screenshots and eventually a script to gather and export all if this information.