This is the third post in a guest series I’m doing here on Email Management in SharePoint. The second post was Myth #1.
In early 2006, the Exchange Team at Microsoft outlined their thoughts about the future of Public Folders in a blog post titled “Exchange 12 and Public Folders.” It was intended to let customers know that Microsoft was de-emphasizing Public Folders for certain applications, but many misunderstood this to mean that Public Folders were dead.
Microsoft’s position was clarified in March 2008 in a post titled “Updated Exchange Public Folder Guidance,” which encourages use of SharePoint for new deployments and migration where overlap exists. This blog confirmed that Microsoft will continue to support Public Folders in the next release of Exchange and for an additional 10 years from its release.
This post also provides the first scenario-based examples where Public Folders and SharePoint are compared. I know both the SharePoint team and the Exchange team were involved since I was on the SharePoint team when it was designed and played a role in getting it cross posted on the SharePoint team blog.
Above is my version of the table in the blog post. I’ve changed some of the wording to make it easier to understand, with a bit of commentary emphasis on really investigating SharePoint functionality when both Public Folders and SharePoint have overlap across a scenario. SharePoint is “strongly encouraged” for most application development, though in some instances there still may be some advantages to Public Folders. For example, the capabilities of team calendars in Exchange vs SharePoint should be compared against the specific requirements of the application. Also, if you are looking at email-enabled lists in SharePoint, you may find that public folders are a better match for your requirements.
While de-emphasizing Public Folders, Microsoft didn’t stop evolving them altogether. For example, in Exchange 2007 there were new ways of managing the Public Folders with Powershell cmdlets. Please note that the functionality and features require investments on the part of the customer. However, the current guidance is that Public Folders are now in maintenance mode.
It’s illustrative to look at what Microsoft IT is doing internally with Public Folders. They decided to impose constraints both on time and size to limit the growth of the stores. Microsoft IT also turned off replication to reduce the unnecessary growth of storage. New folders were locked down to exception-based requests, with new provisioning requests pointed to SharePoint (with the common exception of distribution list archiving).
So why is Microsoft IT moving more content to SharePoint? In contrast to Public Folders, SharePoint was designed as an application platform and it’s important to note that this is the continuing direction of Microsoft. Both Windows SharePoint Services and Office SharePoint Server are major investments for them and they will continue to augment their functionality to support the common scenarios of customers.
While Exchange Public Folders were previously the endorsed solution by Microsoft for sharing email, SharePoint is now the recommended solution. If you are still considering Public Folders, it’s important to understand it has several well known limitations and challenges, described below.
- Public Folders and custom applications built on them are the bane of the life of an exchange administrator. Control, performance, scale, and replicating chaos are a number of common concerns. Public Folders require heavy upfront and ongoing management.
- Security is also often a concern due to the public nature of email-enabled Public Folders. Organizations are exposed to large risks if the random content flying around in emails is not controlled, so Public Folders need to be carefully managed. Security and liability are definitely something to be considered in all cases where email content is stored. It’s important to understand who has rights to store email on the server.
- Public Folders can also be an HR nightmare. These “public” social dumping grounds often become a place where pictures and music are exchanged. As well, DLs (Distribution Lists) can get buried in group and team email-enabled security groups.
Bottom line: if you are deploying both Exchange 2007 and SharePoint technologies (WSS or SharePoint Server), it doesn’t make sense to build up a huge Public Folder deployment. It’s confusing to users and additional overhead for the team managing Exchange.
But should you use Public Folders when you are doing a Groupwise, or Lotus Notes migration? For nearly all your Notes applications you should seriously look at SharePoint. For email it’s a no brainer… it’s Exchange. For discussion groups and archiving, you’ve got a decision to make. When migrating to SharePoint, you should do it with an understanding of what you get out of the box, and what you get with a partner. Most gaps you find in SharePoint are filled by a very solid partner ecosystem.
One last point. If you plan to customize SharePoint sites and site templates, have a look at this blog post on Features and Solutions. Features allow reusable pieces of functionality to be created and deployed to other sites, without modifying site templates. Solutions allow you to package Features in a cabinet (.cab) file and define important metadata about those Features.
Truth: The Exchange Team will include public folders in the next version and at a minimum support them for 10 years after the release. However, they encourage you to seriously consider SharePoint for application development.