Those of you familiar with public folders know how much of a pain they can be. Microsoft has made promises to do away with them time and time again, yet they are still around and as painful as they have always been. Understandably, it is difficult to do away with support for a feature that is so heavily depended on with legacy systems.  The move to modern public folders with Exchange 2013 made some drastic improvements, but to call them “modern” seems misleading (and even humorous) to me. Public folders are still an ancient way to store anything and everything under the sun in Exchange, creating headaches for Exchange admins for years to come.  But that isn’t what this article is about.

First, Some Background…

I recently worked on an Office 365 migration project for a customer that had Exchange 2007 on-premises. They had roughly 140 servers spread across about 35 sites. They also had over 2.2 million public folders, topping off at just over 90TB. If that wasn’t overwhelming enough, the public folder replicas were split up and spread out all over the world. For example, public folder content for UK users was only in the UK, while public folder content for US users was only in the US.  For sites that weren’t large enough to justify a dedicated public folder server, they had their public folder content spread out in random locations.  I’ll give you a minute to let that set in…
When talking to this customer’s IT staff, they mentioned that they had previously consulted with Microsoft specifically about the public folders issue. They told me that Microsoft had actually stated that they had the largest public folder base they had ever seen. There may be larger ones out there, but Microsoft does not appear to be aware of any.
If you are familiar with the limitations of public folders in Exchange Online, you will know that there is a hard limit of 50GB for each public folder mailbox, and a limit of 1,000 public folder mailboxes in a single tenant.  There is also a limitation to the number of simultaneous connections you can have to a single public folder mailbox, which is 2,000. If you do the math, that still isn’t enough to cram a whopping 90TB into, not to mention the time and logistics it would take to do so even if it you could.
Because of these limitations, a public folder migration was not an option for this customer, and that was probably a very good thing.  But they couldn’t just do away with them.  Of the 60,000 users they have, about one third of them depend heavily on public folders for various reasons.  To complicate matters, Exchange 2007’s end of life was quickly approaching.  In response they stood up an additional 90 Exchange 2010 servers and began creating public folder replicas on these, with plans to eventually decommission all Exchange 2007 public folder servers.  The remaining 2007 servers would be decommissioned once the Office 365 migration was complete. So now we have about 230 Exchange servers spread across the globe, and half of those are hosting public folders.  What to do?  The answer was to migrate all mailboxes to Exchange Online and leave Exchange 2010 public folders on-premises to coexist in a hybrid configuration.

An Overview of Legacy Public Folder Coexistence

As of this writing, Microsoft has only one article to cover legacy public folder coexistence for hybrid deployments.  Legacy refers to both Exchange 2007 and Exchange 2010.  I have used this article a number of times with other hybrid deployments and had great success.  I won’t go into detail, but a high level, configuring hybrid coexistence with legacy public folders consists of the following steps:

• First, a number of prerequisites need to be met. These include:
  • Exchange 2007 must be at least SP3 RU10. Exchange 2010 must be at least SP3.
  • Exchange hybrid must be deployed.
  • Outlook Anywhere must be enabled and internet-facing.
  • Conflicts with mail-enabled public folders should be addressed. This includes duplicate addresses, invalid characters, trailing spaces, etc.
  • For Exchange 2007, you must be a member of the Exchange Organization Administrator role group or the Exchange Server Administrator role group. For Exchange 2010, you must be a member of the Organization Management Administrator role group.  For Exchange Online, you must be a member of the Organization Management role group.
  • Windows Powershell 2.0 and WinRM 2.0 are both required.
  • Outlook 2010 must have the November 2012 public update or later. Outlook 2007 must have the November 2012 update or later.
  • Outlook for Mac is NOT supported.
• For Exchange 2010, the CAS role must be installed on the public folder server.
• Remote public folders must be made discoverable. This involves creating a dedicated mailbox database on EACH public folder server.  These databases will have a single public folder “proxy” mailbox on each of them.  This mailbox should be the only mailbox on the database, so be sure to exclude the database(s) from provisioning.  For Exchange 2010 be sure to specify the RPCClientAccessServer as the corresponding public folder server with the CAS role installed.
• Since DirSync does not sync mail-enabled public folders, the Sync-MailPublicFolders script must be run on-premises against Exchange Online. I recommend running this script from one of the public folder servers.  Basically this script synchronizes mail-enabled public folder SMTP addresses to Exchange Online and hides them from the address list.  After the initial sync, a CSV file is generated.  This file contains the details of each success or failure.  Failures can be addressed on-premises and this script can be re-run as many times as necessary.  Think of it as a mini DirSync specifically for mail-enabled public folders.
• Exchange Online must be configured to access on-premises public folders. This is done in Powershell using the following command.  Note that you must wait for a DirSync cycle to run before these mailboxes will show up in Exchange Online as MailUsers.

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox1,PFMailbox2,PFMailbox3
It is a great article, but it does not go into very much detail about what is happening behind the scenes.  There are other articles out there as well, but not many.  I know because I searched furiously while planning for this project.  Of the literature I was actually able to find, none address legacy public folder coexistence on such a grand scale.  This is what led me write this article.  I hope you will find it useful.

A Tip About The Sync-MailPublicFolders Script

The Microsoft article is somewhat misleading about this script since running it is listed as step 4.  In reality, this script doesn’t need to be run at all if you have no interest in Exchange Online users being able email their public folders.  I usually run this last, once basic public folder access has been tested and verified.  If you have 20,000 mail-enabled public folders (as my aforementioned customer did) it may be best to execute this task last.  It can take a while to run and I can almost guarantee you will have errors that will need to be fixed and the script will need to be run again…and again…and again.  The point is, enabling coexistence by creating the proxy mailboxes and configuring Exchange Online is enough to get public folder access established.

Public Folders on Multiple Exchange Versions

One thing I learned early on is that the methods outlined in this article work just fine for a scenario where public folders reside on both Exchange 2007 and Exchange 2010.  The Microsoft article makes it seem as if this is a solution for one or the other, but it is not.  That being said, if you have both version hosting public folders and they contain the same replicas, I would recommend just using the Exchange 2010 servers.  However, if you have content spread across servers and versions, it is perfectly acceptable to configure all of the necessary servers in this fashion.

So How Do I Make This Work on a Ridiculously Large Scale?

Unleash the Potential of Power Platform With a Center of Excellence

Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.

Learn More

If you’re faced with the same challenge that I was, you’re not going to be able to find much about this particular topic.  But the short answer is you follow the exact same steps, just with some tweaking here and there, as well as a ton of careful planning.

Outlook Anywhere and Network Planning

If you recall, Outlook Anywhere is required for Exchange Online to access on-premises public folders.  This is because the Outlook client for a mailbox in Exchange Online uses Outlook Anywhere to proxy a connection to the initial public folder server that will serve the public folder hierarchy.  From there, additional connections are made through Outlook Anywhere via public folder referrals in order to retrieve the actual content from the relevant public folder server.  To give you an idea, it looks something like this:
It’s important to keep in mind that since client connections are terminating at the Outlook Anywhere servers, you don’t have to worry about client traffic traversing the entire network (caveat below).  But that doesn’t mean there isn’t any traffic.  For each public folder request, Outlook Anywhere will proxy the connection to whatever public folder server hosts the requested content.  If you have multiple replicas, the AD site cost will be used to determine which server to attempt a connection to first.  Time and time again I see AD sites brought up and very little planning goes in to intra-site connectivity.  AD site cost planning is crucial if you want your users to have a good experience with cross-forest public folder access.
One thing to note about these connections is that they do have a TTL.  If content from a specific public folder server has not been accessed in a while, that connection will be closed.  I used the illustration above simply to show how ridiculous the public folder connections can get and to highlight how important it is to plan your network routes and costs accordingly.
You may wish to stand up multiple instances of Outlook Anywhere if the bandwidth on your WAN isn’t sufficient to support a high number of connections from a single instance.  For example, creating two or more instances of Outlook Anywhere for US and UK users (e.g. usmail.domain.com for US and ukmail.domain.com for UK) would keep Outlook Anywhere traffic relatively local.  Although I haven’t personally tested it, geo load balancing could be another possible approach to this.
Another note regarding the caveat I mentioned above:  If a public folder server does not have a proxy mailbox associated with it, Outlook will attempt to make a RPC/TCP connection directly to that server.  This may be an acceptable solution in scenarios where all clients that access public folder content reside inside the network and have a route to that server.  However, I recommend using the proxy mailboxes.  This will insure that public folder traffic flows as expected.

Public Folder Proxy Mailboxes – A Little More Info

So what purpose do these “proxy” mailboxes serve anyway?
When Outlook makes its initial Autodiscover query, a small section of the XML response contains a <PublicFolderInformation> section that returns one of the public folder proxy mailbox’s SMTP address.  This is the mailbox that Outlook will make the initial proxy connection to retrieve the hierarchy.  It looks something like this:

 
 
This tells Outlook which public folder mailbox (and thereby which public folder server) to make the initial connection to in order to retrieve the hierarchy.  When you only have two or three public folder mailboxes, this response may be insignificant.  But when you have over 100 proxy mailboxes, returning the correct one becomes much more important, especially when trying to control client traffic.  How is the proxy mailbox determined?  Answer:  IT’S COMPLETELY RANDOM!!!
Remember, the user’s mailbox resides in Exchange Online.  Exchange Online has no insight into which AD site is best suited for serving the hierarchy.  Because of this, Autodiscover will insert a completely random public folder SMTP address into the XML response.  However, this behavior can be changed with a little manipulation through EXO Powershell.
Running the following Powershell command will return 2 properties, DefaultPublicFolderMailbox and EffectivePublicFolderMailbox:

Get-Mailbox exo_mailbox | FL DefaultPublicFolderMailbox,EffectivePublicFolderMailbox

The output looks something like this:

 
 
DefaultPublicFolderMailbox is technically used for modern public folder access in Exchange Online.  It can be set per user mailbox to tell Autodiscover which SMTP address to return in the PublicFolderInformation section of the XML response.  EffectivePublicFolderMailbox is a property that cannot be set, but it is populated with one of the remote public folder proxy mailboxes that is set in the Organization Config, and as stated previously, it is completely random.  The Microsoft article mentions nothing about this, but I found that you can force Exchange Online to return a mailbox of your choosing by setting the DefaultPublicFolderMailbox attribute.  Changing the DefaultPublicFolderMailbox property changes the EffectivePublicFolderMailbox property as well.  The following Powershell command will set the DefaultPublicFolderMailbox attribute for a mailbox:

Set-Mailbox exo_mailbox -DefaultPublicFolderMailbox pf_mailbox

It looks something like this:

 
 
The mailboxes are blurred out for privacy, but I can assure you they are the same.  Now the DefaultPublicFolderMailbox property is set, as well as the EffectivePublicFolderMailbox.
Setting this property isn’t a requirement unless you want to control which public folder server the Outlook client makes the initial connection to in order to retrieve the hierarchy.  For large scale deployments, I would recommend using a public folder server located in the same site as your Outlook Anywhere instance(s).  This will keep that initial traffic local.  The downside is that this property must be set for every mailbox in Exchange Online where you want to control this behavior.
A side note:  For modern public folders in Exchange Online, you can set the IsExcludedFromServingHeirarchy property on individual public folder mailboxes.  However, you cannot do this for the public folder proxy mailboxes located on-premises.  This is because they are synchronized as MailUsers.  They are not modern public folder mailboxes in Exchange Online.  We are essentially “tricking” Exchange into thinking that they are.

Conclusion

The Microsoft article does a great job at providing the necessary steps to get public folder coexistence working with legacy public folders. As I said, I have used it many times and always had great success.  But it seems to be targeting IT professionals dealing with small public folder deployments and it doesn’t really explain what is happening in the background.
I hope this article has been helpful. Hopefully more literature will be released on the subject. Until then, happy public folder coex planning!