Are Public Folders Dead?

A client recently informed me that it was suspending use of a tracking application that I'd built in one of its Exchange public folders. The application monitored the status of various reports that the company must make to demonstrate compliance with environmental regulations. The company's IT department had suspended all new support of Exchange Server public folders, and it seemed as though the company would soon be pulling back from public folders altogether. Fortunately, the department I was working with was able to locate a Web-based environmental compliance system, an alternative that hadn't been available when we started the project.

Should you worry about whether your organization will discontinue public folder support or--even more concerning--whether Microsoft will discontinue support for public folders in future versions of Exchange? I'd say "Yes" to the first question but offer a tentative "No" to the second.

Microsoft Office Outlook 2003 users might already wonder about the future of public folders because certain aspects of the new interface make public folders more difficult to use. Earlier versions' Outlook Bar, which provides a convenient way to organize shortcuts to frequently used public folders, has been replaced in Outlook 2003 by a Shortcuts view of the navigation pane. Many users might never discover this view, although they'll probably find the Folder List view. The Calendar, Contacts, and other function-oriented navigation-pane views can't list public folders unless the user adds those folders to the Public Folders\Favorites hierarchy. If a folder in Public Folders\Favorites uses custom forms, though, a user working in Cached Exchange mode might experience forms cache corruption errors or be unable to add any new items to the folder. (Microsoft issued an Outlook 2003 hotfix earlier this month that might alleviate these issues. At the time I write this column, however, Microsoft hasn't yet posted a corresponding article in its Knowledge Base. For more information about the fix, you can contact Microsoft Product Support Services--PSS.)

The handwriting has been on the wall for public folders for a year or two. I first heard a Microsoft speaker strongly discourage use of public folders at the MEC 2002 conference. An administrator who attended the same session was in a state of near panic because her university has thousands of public folders in active use.

That organization might be an exception, though. HP Vice President Tony Redmond, in a speech at the Exchange Connections conference last November, called public folders "a massive underachievement in collaboration," noting that few organizations leverage all features of public folders and that many organizations had a bad experience with public folders. Redmond suggested that organizations to consider moving from public folders to Microsoft SharePoint technologies.

I think there's a simple reason why public folders, as an application platform rather than just a data-storage area, don't receive a lot of support in many organizations and probably never will. Email has become a mission-critical application, and the idea of running a folder-based application--even when the public folder store is on a separate server--makes IT administrators nervous. For this reason, many applications that use public folders, such as the tracking system that my client is abandoning, consist largely of client-side components such as Outlook forms and COM add-ins, even though Exchange has supported folder-level scripts and (in Exchange Server 2003 and Exchange 2000 Server) event sinks for years. Unless your IT department is equipped to rigorously test Exchange folder scripts and event sinks to ensure that they won't negatively affect your Exchange server, IT isn't going to permit such scripts or sinks.

Inside Microsoft, the number of SharePoint sites far surpasses the number of active public folders. SharePoint Team Services, introduced with Office XP, was an instant hit inside Microsoft. The most recent members of the SharePoint family--SharePoint Portal Server 2003 and Windows SharePoint Services--add new capabilities that let users rapidly create collaborative Web sites from a variety of available templates. Given that Windows SharePoint Services is available as a free download for Windows 2003 Server, Windows SharePoint Services presents an ideal opportunity for workgroups to experiment with Web-based collaboration as a possible replacement for public folders. Still, as Redmond noted in his Connections speech, SharePoint lacks two key features that public folders provide: replication and offline use. Outlook 2003 provides a partial solution for offline use: Users can create a read-only, local replica of any SharePoint events or calendar list. Groove Networks ( http://www.groove.net ) also offers an offline solution for SharePoint data.

In the face of persistent whispers that public folders are dead, Microsoft has been trying to reassure customers that it's aware of the many ways in which organizations use public folders and that it recognizes there will always be a need for some kind of public storage. However, Microsoft's recommendation to companies who need to develop new applications against a public store is to use a more "strategic" technology than public folders, one with broad-reaching potential to support many types of applications and one that Microsoft clearly plans to continue enhancing far into the future. Today, that means either SharePoint or Microsoft SQL Server. Down the road, it might include Kodiak, an upcoming Exchange version that will use the unified data store currently under development.

And maybe that's why Microsoft hasn't yet been able to quash the talk of public folders' demise: Organizations don't see a clear migration strategy ahead. Also, Microsoft's track record regarding Exchange application migration isn't stellar. Custom Web form applications built on Exchange Server 5.5 became obsolete overnight when Exchange 2000 debuted without migration tools for those applications. In his speech, Redmond called on Microsoft to address the need for replication and offline-access capability in SharePoint, and doing so would certainly be to Microsoft's advantage. If the software company understood the most common types of public folder applications (e.g., documents, discussion, mailing list archive, tracking, scheduling), it could also provide detailed guidance about how to move or rebuild each type of public folder application on SharePoint or SQL Server. Such topics would make great TechEd sessions and would reassure Exchange administrators that their public folder applications won't become orphans any time soon.

End of Article