Exchange Server Public Folders: Still Not Dead - 12 May 2011

I've been working on a project lately that has required me to spend a lot of time with public folders in Microsoft Exchange Server 2003. As a result, I've had the opportunity to reflect on public folders, why we still have them, and what's likely to happen to them in the future.

Tony Redmond famously described public folders as the cockroaches of Exchange, and many Exchange administrators view them that way. Over the years, Microsoft seems to have shifted from promoting public folders as a key part of Exchange Server to viewing them as an unwanted wart (SharePoint migration, anyone?) to the company's current stance of treating them as a functional but unlovely component that remains in the product because of customer demand.

The fact of the matter: Public folders still have some unique uses that other Microsoft products don't match. For example, the ability to use a mail-enabled public folder as a shared repository of message traffic doesn't have a good replacement. I use this feature extensively to provide a way for my engineering team to track change notifications in our source code control system; mail-enabled SharePoint libraries, shared mailboxes, and other public folder-ish features wouldn't be an adequate replacement for this functionality.

Of course, many companies still use public folders as shared locations for storing documents. SharePoint offers a wealth of features, such as check-in/check-out capability and version control, that should make these companies jump to use it—but SharePoint is missing one critical component of the Exchange public folder system: Its innate ability to maintain multiple, automatically synchronized replicas.

Making the problem worse, Microsoft still hasn't delivered an adequate solution for migrating public folder–based workflows to SharePoint. It's not that the tools to migrate data don't exist; they do, but they're all from third parties such as Quest Software and Metalogix. The problem is that Microsoft isn’t providing a central source of guidance and best practices to help companies prepare to make this move. Frankly, this doesn't strike me as something that the Exchange team should be doing. If the SharePoint product group was serious about making SharePoint an attractive alternative to Exchange public folders, they should produce and distribute some better tools and guidance for doing so.

Will this change in the future? Who knows? If memory serves, SharePoint was introduced about ten years ago, yet public folders are still with us at least through the end of the Exchange 2010 support lifecycle, and possibly further into the future.

Apropos of the future, the Exchange product group is conducting a survey that, in their words, seeks to help them "learn a bit more about your public folder topologies and usage scenarios." That seems like a pretty clear indication that Microsoft is considering changes for public folders in the next version (or versions) of Exchange. So if public folders are important to you, I strongly encourage you to complete the survey.

After you fill out the survey, I'd love to hear your thoughts on where you stand. Do you use public folders? Would you insist that they be supported in the next version of Exchange, or would you rather see that engineering effort spent on something else instead? Drop me a line and let me know.

Related Reading:

• When Worlds Collide: Federating Exchange Server Organizations
• Exchange 2010 and Outlook 2010: The Return of "Better Together"
• Unified Messaging in Exchange 2010