A wise man once said, “There’s no stopping what can’t be stopped; no killing what can’t be killed.”* He may have been talking about a savage race of space aliens that specialize in hunting, but he could have just as easily been talking about public folders. Despite Microsoft’s best attempt to kill them off (or at least seriously discourage their use), PFs have managed to stick around through the last few iterations of Exchange. It’s a testament to their usability and the entrenchment of habits for end users.
Exchange 2007 was supposed to be the death knell for public folders. The core purposes of Free/Busy and OAB had been moved to virtual directories. SharePoint 2007 was ready to take over content storage and collaboration duties. So Microsoft removed the ability to manage them from the GUI, and instead handed admins a neutered and inadequate tool. After a deluge of negative feedback, Microsoft did eventually incorporate PF management back into the GUI – relegated to the amorphous toolbox – but remained staunch in its support of moving to SharePoint as a replacement for PFs. Exchange 2010 introduced DAGs, without support for public folder database replication. Again it was clear that Microsoft wanted to get rid to the nasty PF pest, but users persisted in using them.
Exchange 2013 is the first version that does not support coexistence with Exchange 2003 and also does not support Outlook clients older than 2007. This means that any remaining need for Public Folders from an client perspective are gone (no more Free/Busy or OAB). But I think Microsoft has finally accepted that PFs are not going to go gently into that good night. As a consequence, MS has greatly altered the way in which PFs work.
Rather than having dedicated databases and relying on replication between them, Microsoft has moved public folders into mailboxes. There are two types of public folder mailboxes: a primary mailbox that holds the single, writable version of the public folder hierarchy, and secondary mailboxes that hold a read-only copy of the hierarchy and the content of some of those folders. Because public folders are now mailboxes, albeit special mailboxes, they can be mixed in with other mailboxes on any database. They can also be replicated via the DAG. This is a real boon for management, backup, and restore.
The migration process from Exchange 2007 or 2010 is a bit tricky. Here is the overall outline:
- Run a script to get a copy of the hierarchy in a CSV
- Review the script to see how many public folder mailboxes will need to be created
- Run a second script to create the mailboxes and hierarchy on Exchange 2013
- Sync the content to the new folders
- Lock the public folders and run a final sync
- Test access to the new folders
- Point all mailboxes to the new folders
Director, Cloud Solutions and Microsoft MVP: Cloud (Azure/Azure Stack) & DC Mgmt