What are we to make of the latest attempt by Microsoft to achieve collaborative nirvana in the shape of Exchange 2013 site mailboxes as described in a recent EHLO post? Those of us experienced enough to have gone through many false dawns in the past might be forgiven to being a tad cynical about the promises of collaboration bliss, the easy interaction between SharePoint and Exchange, the completeness of discovery searches across multiple repositories, and the excellence of the Outlook 2013 user interface, but that’s not a reason to consign site mailboxes to the wastebasket, at least not at this point.
Everyone will have their own definition of what collaboration means and how this can be best achieved within Exchange. Some believe that email (still the collaborative application par excellence) is good enough, provided it is used well. Others consider public folders to be capable of satisfying the needs of their organization and look forward to the advent of “modern” public folders in Exchange 2013. And there are many who have invested heavily in SharePoint and are annoyed that Microsoft has not been able to connect Exchange to SharePoint in any coherent manner since SharePoint was first released some eleven years ago.
I doubt that site mailboxes will do much for anyone who is focused on email or public folders. There is sufficient in Exchange 2013 to keep these folk happy and anyway, the thoughts of having to deploy SharePoint 2013 into production (with its attendant cost in hardware, software, and operations) just to get what could be described as a puffed-up version of public folders is enough to make a hard-core Exchange administrator freeze in their tracks. Note that I am not calling site mailboxes “puffed-up” in any shape or form. It merely crosses my mind that you could be unkind enough to apply this epitaph to the new software if you made a judgment solely based on what’s written about the new technology rather than enjoying its full glory when deployed.
Apart from the need to deploy SharePoint, the dependency on Outlook 2013 for a user interface will furrow additional brows. The word is that Outlook Web App (OWA) will ignore site mailboxes until Microsoft gets around to upgrading OWA in Exchange 2013 SP1, so you’re left with a situation where you have to deploy a new desktop client to make use of the new functionality. This isn’t so bad if you like what you see in Office 2013, have a need to use some of the spiffy new functionality (I like in-line editing of replies in Outlook 2013 and Word 2013’s ability to begin an editing session by offering me the chance to move to the spot where I last finished), and have the chance to deploy Office 2013 to users. However, most companies won’t find themselves in such a position and will therefore find Outlook 2013 to be a prerequisite too far.
But assuming that all is well, that software and hardware has been procured and deployed, and that SharePoint and Exchange are both humming along like a well-tuned engine, we turn to the question of functionality. The EHLO blog is the most comprehensive public document posted by Microsoft on the topic of site mailboxes to date. Here are ten important points that we can learn from the post.
“The content is kept where it belongs”. In other words, Exchange looks after email and SharePoint takes care of documents. This is an appropriate and intelligent division because SharePoint can’t do email for nuts and Exchange isn’t much better at dealing with documents. The post makes the point that the relevant stores are optimized. Exchange for email; SharePoint for documents.
“Exchange synchronizes just enough metadata from SharePoint to create the document view in Outlook”. Here’s where the dependency on Outlook 2013 surfaces as it’s the only client capable of understanding the data that Exchange retrieves from SharePoint.
“Filing an email or document… is as simple as dragging… into the site mailbox”. This is good because users should find it easy enough to understand how to populate a site mailbox. Outlook 2013 presents site mailboxes as “just enough mailbox” (like an archive mailbox, for instance), so users should quickly understand how to access and use the data held in the site mailbox. Behind the scenes a fair amount of magic takes place to keep Exchange and SharePoint synchronized, but that’s not the point here.
If you’ve invested in setting up processes for creating SharePoint sites at the enterprise level, you can have those processes create site mailboxes at the same time that a classic SharePoint site is created.
Site mailboxes are discoverable by multi-mailbox searches. This comes about through the replacement of Exchange’s old (and creaking) MSSearch component with the Search Foundation technology shared with SharePoint and Lync. Email has long since been indexed and discoverable; Exchange 2013 makes the documents held in site mailboxes discoverable too, something that will bring joy to lawyers.
Site mailboxes are mail-enabled objects and behave in the same way as mail-enabled public folders. In other words, you can add a site mailbox as an addressee to an email and Exchange will route the message to the site mailbox.
Documents stored in site mailboxes remain in place when you add them as attachments to messages. Links are added to the message to allow recipients to access the content, but the documents stay in SharePoint rather than being circulated as attachments. Again, this makes perfect sense to have a single definitive source for a document that’s intended as a collaborative object, as long as the recipients have sufficient network connectivity to be able to access the document when they need to (the old replication model for public folders, although derided by many, at least had the singular advantage of making content available “close” to users).
Logically Outlook 2013 provides an Outlook-style interface to a site mailbox and doesn’t support some of the more advanced SharePoint functionality that you can use with documents. For example, accessing prior versions. To get around the problem, you can access the underlying SharePoint site from Outlook in a browser session and thus access the advanced features.
Site mailboxes will be available to Office 365 tenants too. I suspect that Office 365 tenants will find it easier to adopt site mailboxes if only because Microsoft takes care of all the heavy lifting to deploy and manage Exchange Online and SharePoint Online. If you’re an Office 365 tenant, all you should need to use site mailboxes is to deploy is Outlook 2013.
The whole point about site mailboxes is collaborative authoring. In other words, a group of users want to work on something such as a Word document or PowerPoint presentation that will go through many editing cycles involving multiple contributors. This can be done with email, but it’s hard to keep track of the many different versions of documents that circulate as message attachments unless someone is designated as the editor-in-chief. It’s also possible to accomplish collaborative authoring using public folders as long as replication is flawless (or a single copy of a public folder is used) and great care is exercised as to when different users access the document to update its content.
The promise of site mailboxes is that they will be better a much better collaborative tool than public folders in many different ways. Their Achilles Heel is the requirement to deploy additional software and a brand-new client. It will be interesting to see how site mailboxes are deployed and used in production and whether after a year or so of real-life use, customers who deploy site mailboxes have gained the promised advantages.
