There are many things to like about Exchange 2013’s “modern public folders.” It’s good to be able to move away from the separate public folder database and integrate everything under the comforting blanket of protection afforded to mailbox databases through the Database Availability Group (DAG). Likewise, it’s good to discard the old public folder replication model that seemed oh-so-cool when it debuted with Exchange 4.0 in 1996 but has proven over time to be a black box that almost no one understood, especially when things went wrong.
The goodness of the new model will only be attained after new public folders are created and deployed. Companies that have long run Exchange will look forward to whatever migration facilities Microsoft cares to ship along with Exchange 2013. There’s a ton of work to do here to analyze existing public folder hierarchies and folder contents in preparation for the migration, then to decide on the layout of the new public folders when moved to Exchange 2013. For example, how many public folder mailboxes are required to host the hierarchy and data of the new public folders that we want to create? Given that new public folders use a single master model (only one public folder mailbox contains a writeable copy of the hierarchy – the others are just read-only copies), what databases should host these mailboxes and how should they be protected by a DAG?
I suspect that sorting out a deployment plan for new public folders will be a slow process because administrators and consultants will need time to fully understand how to use the migration scripts and probably even more time to understand the data contained in public folders, including any applications that depend on these folders.
In fact, I predict that public folder migration will be a rich vein of potential work for both third-party software vendors, who might build better, more automated, and easier-to-use migration tools than Microsoft will deliver, and consultants, who will be brought in by companies to figure out the best migration path. I’m sure that the MEC session (E15.352) “Public folder migration in the new Exchange” will be well attended.
Of course, companies who listened to the stark predictions and mutterings in dark corners about public folders ever since Microsoft first realized that they had a problem bringing public folders forward (in the era of Exchange 2000), never deployed public folders and so will be able to consider whether they should now use public folders. The same is true for Office 365 tenants, who have not been able to use public folders with Exchange Online.
Even companies who are able to use modern public folders from scratch face two issues that deserve discussion. The first is how to reconcile public folders with site mailboxes, another new feature that Microsoft is shipping in Exchange 2013. Site mailboxes depend on SharePoint 2013, so if you want a shared repository that simply needs Exchange, public folders seem the better bet. On the other hand, if you’ve invested heavily in SharePoint, then site mailboxes appear more interesting, especially now that Exchange 2013 offers discovery search facilities that extend across both Exchange and SharePoint repositories. MEC offers session E15.212 “Site mailboxes in the new Exchange”, which might cast some light onto the issue.
In my mind, the biggest influence over when modern public folders can be deployed into production is client access. Outlook 2013 can access new public folders and site mailboxes out of the box, but deploying a new version of Outlook, even with Microsoft’s “click to run” technology and all the Office 2013 deployment tricks that they will make available to customers, is still problematic. You see, it all comes down to the humans who have to use and support the software. People do get set in their ways and like (or perhaps tolerate) how their current client works. Client updates provoke the need for training and often increase the number of support calls that flow into help desks as users look for advice how to perform tasks that are subtly different in the new client. Consider the furore over the introduction of the ribbon in Office 2010. It’s a very sensible piece of user interface engineering when you get used to it, but until then… Now think about the new “Metro” (to use a banned phrase) interface used by the Office 2013 applications. I think that its deployment will be relatively slow, at least until administrators and support personnel have mastered the new software.
But there’s always Outlook Web App (OWA) you cry! Yes indeed, Exchange 2013 delivers a smarter OWA (again) that is capable of delivering a really nice interface for PCs, smartphone, and pad computers. But the interface is currently devoid of any trace of modern (or old) public folders, nor do site mailboxes appear. It’s all very curious, but given that all we have currently available is a preview version of Exchange 2013, this deficiency might be addressed before the product ships. If not, no doubt public folders will appear in OWA in Exchange 2013 SP1.
I’ve often referred to public folders as the cockroaches of Exchange – unloved, unwanted (by Microsoft), but very difficult to exterminate. New public folders are more interesting. I hope that their time in the limelight lasts longer than their predecessors.
Follow Tony @12Knocksinna
