Please Note: This is a prerelease post and information in this post may not be applicable to the product when it is launched.
EDIT: Exchange Team has published a detailed post over here http://blogs.technet.com/b/exchange/archive/2012/11/08/public-folders-in-the-new-office.aspx .
Despite of Microsoft’s thought of deprecating public folders from Exchange Server 2007 and later version; they stayed as a part of the product. Although, there has been no graphical user interface to manage public folders in Exchange 2007 and onwards, PowerShell has always been a good alternate way around to it. Public Folders are normally looked at as a great single place of collaboration for employees of any organization. I personally know some very huge software companies which use public folders for their project related work instead of using SharePoint team sites; even though they have a decent SharePoint 2010 deployment. What makes Public Folders a favorite choice for a lot of users is their accessibility within outlook. One does not need to logon to a different place just to collaborate with different teams or within the same team but members sitting at different locations. They can simply change their mouse cursor position from emails to public folders and they can view collaboration data within outlook.
Due to many reasons MS has been trying to deprecate the use of public folders but they somehow do not seem to be going away. Above one was just one of the examples of why they may still exist J
To know what has changed with public folders in Exchange 2013, one must know how it worked in legacy versions of exchange. I am sure these are some basics but I think they must be revisited once again before trying to learn new way.
Until Exchange 2010
Although there is a huge change in the way public folders were managed in Exchange 20003 compared to Exchange 2007 and Exchange 2010, basic architecture of the public folders did not change. Public Folder database is a little differentiated architecture of exchange database that can hold only public folders hierarchies and public folder contents.
A separate table within the database used to maintain the security permissions on folders and contents. This table would determine who has access to what content and what the level of access is.
In Exchange 2003 it was directly handled by the mailbox servers; in exchange 2007 and later it was handled by hub transport role in conjunction with mailbox server role which hosted a public folder database and participated in replication. One of the major advantages of this model is to avoid unnecessary client connectivity traffic going across an active directory site. For example: in an environment with multiple exchange servers deployed across multiple active directory sites, users in any particular active directory site can get their public folder data easily available within that site if the mailbox server within that site is configured with a public folder database and required public folders are replicated to it. This model does pose a limitation in consistency of data availability in public folders in case of a site level failure or a planned DR drill. An administrator has to manual changes for making the public folder database available to end users in an event of site level or complete server level failure.
Every administrator who has dealt with public folders and multiple copies of public folders have experienced the public folder replication issues. This replication is purely based on a SMTP traffic channel between source and destination. Although, SMTP is one of the native protocols that exchange supports by default; troubleshooting public folder replication can be a really time consuming and painful job.
In Exchange 2003 and Exchange 2007 an outlook client would connect to a public folder database using direct RPC connection to the public folder database name it discovered from the mailbox database properties of database where connecting user’s mailbox is.
Exchange Server 2010 introduced two new concepts called DAG and CAS Array. These two concepts changed the way outlook connects to a mailbox. To maintain the high availability and to decrease end user service disruption, Exchange 2010 CAS servers and mailbox servers use RPC Endpoints between clients, mailbox servers and mailbox database copies. Outlook uses these RPC endpoints on Client Access Server to connect to a mailbox but uses a direct RPC connection to a public folder database, which it discovered from the mailbox database properties.
You must have noticed the trend in public folder architecture by now. Exchange 2013 takes it even further and introduces few more changes those make public folders look a little weird and hard to understand. A lot of experienced administrators also looked little confused about this. Also, Microsoft does not have a very good documentation about public folders yet. I will try to post my findings based on my own research on public folders in my labs J
In next post, I will write more about what has changed; how it works and definitely; how it adds value over existing public folder architecture. So, stay tuned and do let me know in case someone might want read something specific about public folders.