I’m sure that you all enjoyed the breaking news about the restrictions that exist for public folder mailboxes and the public folder hierarchy in the new, improved, and much-hyped modern public folders implemented in Exchange 2013 (and Exchange Online in Office 365). That is, if you like having the wind taken out of your sails, which happened to me because the news completely undermined advice that I had given to others for the best possible reasons (i.e. I knew nothing about the restrictions until I saw the TechNet article).

Since the news broke last Tuesday, I have received many messages from companies that are worried about their migration to Exchange 2013 or Office 365 (both on-premises and cloud platforms share exactly the same limitations) and the prospect that they now face of having to conduct a major “find and prune” exercise in their public folder hierarchy before they can move off Exchange 2010. It’s pretty common to find companies that have hierarchies spanning tens of thousands of folders and some that have hundreds of thousands of public folders. Clean-up could take some time.

You might wonder why any company would have so many public folders. I think there are three main reasons.

First, when they were introduced, public folders were the cornerstone of Microsoft’s collaborative answer to Lotus Notes. Notes had terrible email but great application development capabilities. Exchange was exactly the reverse. But we only discovered this after the weakness of the public folder application development environment (a 16-bit electronic forms development tool) and the problems that existed in public folder replication. Remember, early Exchange functioned in a world where pervasive networking was not yet in place. But many companies who deployed Exchange early bought into the collaboration story (Microsoft has never been incompetent at selling a great story) and applications such as travel requests, time recording, requests for equipment, and so on were churned out. The applications might have gone away but the public folders that held their data might still be present.

Second, the advice provided to people who deployed public folders was non-existent in the early days. The result was that public folders became a Wild West kind of place with folders being created at the drop of a hat with no logic driving their creation, position in the hierarchy, access control, use, or lifecycle. Because mailbox quotas were so small at the time, some saw public folders as a great place to dump material that they couldn’t keep in their mailbox. Folders proliferated as repositories for email discussion groups, teams, collaborative document creation (a very bad use due to the total inability to lock documents against changes), and other reasons. The average lifespan of a public folder resembled that of the mayfly in some cases as folders were created, used once, and then left to fester forgotten in the hierarchy.

Third, Microsoft never provided good management facilities for public folders. Some tools came out of the Microsoft support groups, like PFDAVAdmin and ExFolders, but in the early days of public folders there was nada. Once public folders started to expand, they did so like rats procreating, and no one was aware of the true nature of the problem until performance started to suffer or replication refused to work (all too often). It would have been nice to have had a tool that was capable of generating reports on the public folder hierarchy and listed all the folders, their owners, some view on their content, last accessed date, and so on, but this was never part of Exchange. You could browse the hierarchy using the management console (later a separate console), but this was only satisfactory for demo situations when the hierarchy spanned less than a few hundred folders.

Given these factors it is truly surprising that public folders have retained so much support within the Exchange community. I can only conclude that the reason is that public folders have been the only supported collaboration platform within Exchange since 1996. It’s sad but true.

In any case, there is no doubt that a great deal of rubbish exists in most public folder hierarchy. By this, I mean:

• Folders that no one owns (they have all left the company)
• Folders that no one wants to use (the information is long since obsolete)
• Folders used by applications that no longer work
• Folders that might contain useful information but no one has accessed it in over a year (or more)

The good news about the restrictions for modern public folders is that it will force companies who want to migrate off Exchange 2010 or Exchange 2007 to Exchange 2013 to go through a clean-up process. The only reason why this is good news is that the outcome will be a slimmed down hierarchy that will then be easier to move and should, if under the limits dictated by Microsoft, be supportable.

The bad news is that the process to identify and prune the unwanted folders is intensely manual and excruciatingly boring. Apart from PowerShell scripts, no tools exist to parse the public folder hierarchy and generate reports. And the PowerShell scripts that are in the public domain are simple so the reports that they generate are not filtered and do not focus on the need to clean.

You can write your own scripts to look for the kind of folders described above. However, in many cases some investigative work will be necessary before a decision can be reached to prune a folder. Why was a folder created? Is the data contained in the folder useful in any way? Who can tell IT whether the information is valuable or not? These are all questions whose answers are highly specific to the company who owns the folders and it is hard for a tool to offer any more than an indication that a folder is a candidate for pruning. For instance, a folder that has not been accessed for three years might contain information required by a department in case it is audited by a regulatory authority. The IT Department might not know this and a script would certainly only identify the folder as a candidate for clean up because of its lack of activity, but there would be hell to pay if you deleted it and the relevant department had an audit.

Of course, you can decide to wait on the basis that Microsoft will fix the performance problems that obviously impose the restrictions in a future cumulative update for on-premises Exchange 2013 or for Exchange Online in Office 365. This is certainly a reasonable tactic to adopt for now as I’m sure that Microsoft will respond to some of the pain now emerging from customers who realize the impact of the restrictions.

And if you attend the Microsoft Exchange Conference (MEC) in Austin (March 31-April 2), you might find that these sessions are interesting places to ask questions about the limitations and how to move forward with migrations.

Modern Public Folders migration and Office 365 (Monday, 4:30pm)

Experts Unplugged: Public folders and site mailboxes (Tuesday, 9am)

Unfortunately I won’t be able to get to the first session as I’ll be chairing “Exchange Unplugged: Top Support Issues” at the same time. Given its title, it would be no surprise if the topic of public folders came up there too. By or at MEC, Microsoft needs to answer questions like:

• Why do these limitations exist? Is it a fundamental weakness of the new architecture or some performance bottleneck that can be addressed in the code.
• Why has the problem only emerged now and why didn’t Microsoft communicate this knowledge to customers before the TechNet page appeared in February 2014 (the limits were documented for Exchange Online but not for on-premises)
• What steps are now being taken to address the issues and raise the limitations to more acceptable values? When will customers be able to take advantage of this work?
• How will Microsoft validate that any changes that are made to modern public folders will be able to successfully deal with the largest anticipated public folder migration by customers to either on-premises Exchange 2013 or Exchange Online?

I’m sure that you can think of a few more salient questions that could be addressed to the Exchange product group. Thinking caps on!

Follow Tony @12Knocksinna