SharePoint vs. Public Folders

When Exchange 2007 released, Microsoft let it be known that Public Folders - long a standard part of Microsoft Exchange - would be "de-emphasized."  This is basically Microsoft's way of getting the band warmed up for a rendition of Kiss Him Goodbye, and a really good sign that it's time to move on, since Public Folders won't be around much longer.

Granted, Service Pack 1 brought back some of the administrative tools used to managed Public Folders, but a lot of the functionality just isn't in Exchange 2007, and will never be.  So, where does an organization turn for Public Folder-like functionality?  Microsoft Office SharePoint Services (MOSS) 2007 offers a way out.

SharePoint has come a long way since the days of Team Services.  The MOSS system can now handle all the Public-Folder system's responsibilities and do much more.  As with Public Folders; you can store shared contact lists, share calendars, trade files and generally make information objects available to anyone who you want, with explicit rules set by you for who can see and change what.  Unlike Public Folders, integration with Outlook is not quite so seamless when using MOSS, and you'll need to take that into consideration as you move toward the new platform.

Public Folders are natively part of Outlook, the end user just browses the tree and picks the folders they want to see. If they have the right permissions, the folders open - end of story.  MOSS must be integrated with Outlook manually, a solution set that requires steps both on the MOSS sub-site in question and in the Outlook client.  The functionality unleashed is much more than you can get with Public Folders (document libraries, wikis, interoperability with literally thousands of Microsoft and 3rd-party titles, etc), but many Outlook users - let's face it - can barely figure out how to get their email. 

It is worth the extra work, however.  Once SharePoint is configured within Outlook, the world of online and offline work, dynamic updates and of course the ability to check files in and out to avoid overwriting other people's changes are all a generation beyond the Public Folder technology.  Some of this function can be created within Public Folders, but they're all native to SharePoint solution sets.

Add in the fact that each week there are more new, solidly built, and widely varied application sets designed to extend MOSS so that it can do more things easier and faster.  There are database hooks, CRM extensions (both for Microsoft Dynamics CRM and 3rd-party solutions) and even systems that can help you create an entire intranets using a WYSIWYG interfaces.  The majority of these solutions simply won't work with Public Folders.

MOSS is slowly but surely assuming its place as the heir apparent to the Public Folder infrastructure present in most existing Exchange organizations.  Integration (with some steps) into both Outlook and Outlook Web Access, clients that run through Internet Explorer (which means Mac ready too) and the ability to create dynamic content without the site administrator being called in for every single update all make the system more flexible and extendible when compared to Public Folders.  MOSS also does all of this without requiring you remove Public Folders from the environment, so you can indeed allow the two tool-sets to co-exist as you move your user-base from one to the other.