A recent question asked to this blog as to whether I thought it a good idea to use a public folder as a repository for a shared calendar. My answer was “no” as I consider using a shared mailbox to be a much better response. That answer deserves some explanation, so here goes.
First, I don’t think it a good plan to make more use of public folders than absolutely possible. Some companies haven’t deployed public folders because they don’t need them to support older clients such as Outlook 2003. These companies can stop reading now as you’ve only one choice in the matter and that’s to use a shared mailbox.
Over the last decade, Microsoft has disappointed companies who do public folders because they haven’t exactly devoted lashings of care and attention to the development and maintenance of public folders. Every release comes complete with the compulsory “don’t worry, public folders aren’t going away anytime soon” announcement, but the future remains uncertain because Microsoft hasn’t added new feature to public folders for years. In addition, Microsoft hasn’t provided a migration path to other platforms (for example, SharePoint) that can move public folder data and applications in a seamless fashion. You therefore conclude that adding more data to public folders at this point might just end up with more of a migration challenge in the future.
On the other hand, mailboxes remain the natural core focus for much of the engineering within Exchange, as evident by the introduction of continuous replication over the past two versions. It therefore seems to be more sensible to use a mailbox-based feature rather than public folders whenever possible.
Second, the management and maintenance of shared mailboxes is easier than public folders. I know that Microsoft released an updated public folder administration console in Exchange 2010 SP1 that addressed some issues that had irked administrators for ages, but it’s still difficult to do something as simple as view the contents of a public folder. By comparison, the auto-mapping feature introduced in Exchange 2010 SP1 means that Outlook will open shared mailboxes automatically if a user is granted full access. I think it’s also easier for users to understand how to use a shared mailbox rather through Outlook.
Third, public folders weren’t strictly designed to host shared calendars. Sure, they’ve been hosting calendars for years and the implementation works, but the latest background features provided in Exchange 2010 don’t function with calendars stored in public folders. By this I mean the Resource Booking Assistant, Calendar Attendant, and Calendar Repair Assistant. Some of these might mean little to you or not deliver much value to the way that you want to use a shared calendar, but I’ll hazard a guess that automating the booking requests that flow into a shared calendar will be valuable to many.
Fourth, there are many more mailbox manipulation cmdlets than public folder management cmdlets. Again, this might not be interesting to you but I thought that I’d make the point anyway.
Fifth, a shared mailbox can store so much more than a calendar. For example, you could associate some shared contacts with a calendar. Sure, you can use another public folder to store contacts that you want to use with a calendar that’s in a separate public folder, but there’s something satisfyingly united about keeping all of the data in one place – the shared mailbox – if only because this makes it easier to move the data should the need arise.
Sixth, using a shared mailbox doesn’t cost you anything extra because Microsoft doesn’t require a CAL (or an Office 365 subscription) for the use of a shared mailbox. Public folders don’t cost you anything either so this isn’t really an advantage. However, I thought it worth making the point because some believe that they have to pay for shared mailboxes.
Last, a shared mailbox is not a public folder so you’ll get better and more complete support from Microsoft should anything go wrong. And you have a go-forward plan for future versions in which you can have confidence, and that’s always a good thing.
Anyway, these are just my views. Feel free to disagree.
– Tony
Thoughtsofanidlemind's Blog 
Great article Tony. Really wishing Microsoft would provide a migration path to Sharepoint for Public Folders so that the rest of us Exchange Engineers could just do away with them. I know many of our brethren find PFs a pain point in our day to day administration.
Great post Tony, the other issue that we were able to resolve via shared folder is to view calander/contacts in mobile devices by just adding another active sync account. Thanks for clarifying that shared folder in office 365 doesnt need another subscrption.
Will definitly share this out.
Thanks,
Zulqurnain Agha.
Good arguments and thoughts, thanks. And then I learned something new – I didn’t know about the automapping feature, I thought it was a bug. Nice to know that its a feature.
Good and useful article, thanks Tony.
However, may be you should double check the CAL requirement. It seams to me that Shared mailboxes require user CAL. In my environment I have 94 user mailboxes and 2 shared mailboxes (as shown in Recipient type details field of EMC) and the license summary shows me that I need 96 licenses. I have Exchange 2010 SP2.
I think you’ll find that the script used by EMC isn’t the most reliable measurement of CALs… For example, the text in Microsoft’s A Guide to Assessing Exchange Server Licensing” states:
Shared mailboxes. A user mailbox shared by more than one user will be counted once, but requires a User CAL for each user. You must count additional users of the same mailbox manually.
So, as long as you have a user CAL for each user who accesses the shared mailbox, you’re fine.
While working with Microsoft Engineering on a problem with automapping (escalated to engineering group), I asked about Public Folders. I was told that “Public folders are going away and support for them will be discontinued”. Now of course that is just one engineer talking, so possibly he does not have the accurate company roadmap…but I have to consider an answer from the Engineering group to be fairly credible.
That said, I hope Microsoft addresses some of the outstanding issues before Public Folders are gone!
— Automapping for group level permissions do not work reliably (I received a script workaround that iterates through members of a group, setting permission on a user-by-user basis…problematic at best for ongoing maintenance as users are added or group membership changes).
— Extraneous folders show up when the shared mailbox is mapped (sent items, deleted items, etc). Annoying at the least, but will be viewed by some users and decision makers as “unacceptable”.
— Permissions are reported incorrectly in Outlook for shared mailboxes where permissions were set by the administrator using PowerShell. I have not yet tried, but suspect this means delegation of permission management to non-administrators may not be possible.
— Standard users do not have the ability to create top-level folders.
— E-mail entry point on a folder-by-folder basis does not seem to be available, preventing tree-structure categorization as available with Public Folders (e.g. “Invoices”, “Timesheets”, “Leave Requests” each with a separate e-mail address and all appearing under a top-level “Accounting” folder).
Bottom line as I see it is Public Folders was a good idea. Public Folders are not just a bunch of extra mailboxes — they are a unique structure element for sharing mail items. Rather than scrap the good idea, Microsoft should spend some time fixing the problems.
You might like to check out Exchange 2013 Preview (made available on July 16). It supports “modern” public folders, essentially a move of PFs from their own database into special mailboxes that are held in normal mailbox databases. None of the issues you have encountered will be fixed with the now-obsoleted “old” public folders, but there’s a chance of having issues addressed for the new variety – if you report these issues to Microsoft after you test against the new version.
TR
Useful information. Thanks for sharing !
Nicely written as always Tony. Very Informative !! Thank you.