The big Exchange 2013 public folders question: migrate or remove?

If you're upgrading to Exchange 2013 or migrating from on-premise Exchange to Exchange Online, will you migrate or remove public folders? Here's what to do after making that decision.



Microsoft introduced public folder technology in its early versions of Exchange to provide users with an easy and effective way to collect, organize, and share information with other people. Legacy Exchange public folders use a multi-master model with folder hierarchy and referral techniques that are not terribly efficient but produce a great, simple user experience that couldn't be better integrated. Exchange 2013 retains the usability and improves the back-end by moving public folders to mailbox databases that can reside in highly available Database Availability Groups (DAGs).

Beginning with Exchange 2007, Microsoft started trying with mixed success to move customers from Exchange public folders to SharePoint for collaborative group workspaces. Some companies that started using public folders loved them and invested a lot of business processes in that technology; other organizations just never created any public folders and simply don't use the feature. Most Exchange organizations have some public folders with varying rates of usage. Figure A shows a typical public folder view from an Outlook client.

Figure A


A typical public folder view from an Outlook client.

Public folders in Exchange 2013

If your organization is upgrading to Exchange 2013 from earlier versions or migrating from on-premise Exchange to Exchange Online (Office 365), you must make a decision about public folders: migrate or remove. Public folder functionality exists in Exchange 2013 for Outlook integration, simple sharing scenarios, and allowing large audiences to access the same data. However, architecture changes in how public folders work means that previous versions of public folders can't be directly upgraded in Exchange 2013. In fact, you can't upgrade an Exchange 2007 or 2010 organization to Exchange 2013 unless you remove the public folders first.

Since Exchange 2013 public folders and legacy public folders can't exist in the same Exchange organization simultaneously, there's no coexistence between versions. Migrating public folders to Exchange Server 2013 or Exchange Online is currently a one-time cutover process.

Migrate public folders to Exchange 2013 or Exchange Online from previous versions

If you must retain public folder functionality in your Exchange 2013 organization, you have to export your Exchange Server 2010 SP3 or Exchange Server 2007 SP3 RU10 public folders first. (Any Exchange 2003 public folders must be upgraded to later versions first and then exported.) You can find detailed instructions and scripts on TechNet. The same scripts are used to migrate public folder content to Exchange Online public folders in Office 365.

High-level steps in the folder migration process are:

  1. Download the migration scripts.
  2. Prepare for the migration.
  3. Generate the .csv files.
  4. Create the public folder mailboxes on the Exchange 2013 server.
  5. Start the migration request.
  6. Lock down the public folders on the legacy Exchange server for final migration (downtime required).
  7. Finalize the public folder migration (downtime required).
  8. Test and unlock the public folder migration.

Remove public folders from Exchange

Most organizations running any version of Exchange that wants to upgrade to Exchange 2013 will need to safely remove legacy public folders, either to install Exchange 2013 or to migrate public folders to Exchange 2013. Note the warning that Outlook versions prior to Outlook 2007 won't be able to connect to Exchange after public folders are removed. Tip: If you're running BlackBerry Enterprise Server (BES), configure BES to run without public folders.

TechNet has detailed steps on how to remove Exchange 2010 public folders. High-level steps in the public folder removal process are:

  1. Delete unnecessary public folders.
  2. Move the public folder replicas to another server.
  3. Associate mailbox databases with another default public folder database.
  4. Remove the public folder database.
  5. Delete the public folder database files manually.

Figure B shows the desired dialog box when you are ready to successfully remove the last public folder from the organization. You get to this dialog box when all public folder replicas are confirmed to be removed from the organization.

Figure B


The successful removal of the last public folder database from an Exchange 2010 organization.

As a last resort, if the Exchange UI and PowerShell can't purge all the traces of the public folder hierarchy, you can manually delete public folder database data from the Active Directory configuration container using the ADSIEdit utility at the following location.

 CN=Microsoft Exchange
 CN=Administrative Groups
 CN=Exchange Administrative Group (FYDIBOHF23SPDLT)