Real Story Group. Make Better Technology Decisions.

Shawn Shell

Follow Shawn on Twitter @shawnshell

SharePoint vs. Exchange Public Folders

1-Apr-2008

Tags: SharePoint Ecosystem, Marketplace at Large

During the first SharePoint conference of the MOSS era, Microsoft suggested that they were considering deprecating Exchange public folders in lieu of using SharePoint. As Exchange 2007 neared RTM (release to manufacturing - "production"), it became very clear that Exchange without public folders was not going to happen right away, but there was a suggestion, at that time, that perhaps in the "next" release, SharePoint would take over the public folder usage scenarios.

In a recent post on the Exchange Team's blog it's clear that the "next version" of Exchange will continue to support the public folder construct. The Exchange Team went on to state that as a result of this support, public folders would be supported "for 10 years from release" (with a link to Microsoft's support policies).

The Team also clarified guidance on when to use SharePoint vs. when to use public folders. In particular, note the following scenarios are where the Exchange Team thinks Exchange public folders make more sense than SharePoint, at least for existing implementations:

• Calendar Sharing
• Contact Sharing
• Discussion Forums
• Organizational Forms

It's surprising to me that the Exchange team suggests that customers continue to use Exchange public folders for some of these scenarios. If the strategic goal of SharePoint is to connect Office to the Web, shouldn't sharing and discussion boards sit better in SharePoint, where they do not require the Outlook client? And shouldn't customers leverage SharePoint's (justifiably) vaunted Forms Server functionality rather than Exchange?

The Exchange team clearly believes differently, and perhaps they have a point. Because, interestingly, they highlighted some of the weaknesses in SharePoint-based collaboration that we (among others) cited in our SharePoint Report 2008:

• Outlook is more fully integrated with Exchange than SharePoint. Unlike SharePoint -- which requires users to connect individual lists and libraries on a one-by-one basis, multiple connections to Exchange are already built in to the Outlook client. For example, there's no need to connect to individual public folders within Exchange, since they're all simultaneously connected through the public folder hierarchy exposed in Exchange.
• Replication allows Exchange to distribute content and load across a number of servers. Although they didn't state this directly, this also enables better remote access, since replication can push content closer to the consumer. Since SharePoint does not support replication, remote offices (relative to the SharePoint server) may see slow performance.
• There are naming restrictions within SharePoint that don't exist in Exchange. In particular, SharePoint URLs are limited to 255 characters and file names must be free of special characters. This was listed as a consideration for migrating public folders to SharePoint, but it's also a constraint on using SharePoint more generally for other purposes.

In all, the Exchange Team didn't go so far as to say that SharePoint only made sense for document-oriented collaboration and workflow, but they did suggest that replacing Exchange public folders with SharePoint won't be straightforward. This appears to be a Redmond-wide message, as the SharePoint team even cross-posted this entry in their blog. As such, it's likely that, unless Microsoft greatly enhances SharePoint, any fantasies your Exchange administrators harbor around getting rid of public folders won't be realized until well after 2013.