Full of the collaboration joys, I leapt into action to configure a new SharePoint 2013 server and connect it to Exchange 2013 so that I could experience the delights of site mailboxes, the new method to facilitate better team working for those who have to slave over hot documents for hours. After much effort and a fair amount of swearing, I concluded that this activity is a prime candidate for automation. SharePoint and Exchange might agree to communicate now but it's just too hard to make everything work together as smoothly as you'd imagine they should. Perhaps it's just me. But I think not.
site mailboxes, a new way of document-centric collaboration that bridges the gap between Exchange and SharePoint. To use site mailboxes, you need to deploy alongside Exchange 2013 and use Outlook 2013 as the client. Outlook is clever enough to mask the join marks between the email items stored and managed by Exchange and the documents held in SharePoint, with each site mailbox using a form of shared mailbox in Exchange and a SharePoint site.supports
So good so far and we’re off to a new era of collaborative bliss – or maybe not, as I pointed out last September. The real fun begins when you attempt to install all of the necessary bits to make site mailboxes a reality. All I can say is that the process is exhausting, complicated, and creaky. In fact, it’s remarkably similar to the convoluted steps that were necessary to configure hybrid connectivity between Exchange and the cloud before Microsoft introduced the Hybrid Configuration Wizard (HCW) in Exchange 2010 SP2. If ever an opportunity existed for Microsoft to automate the setup of a feature, it’s to be found in the steps necessary to configure site mailboxes.
The first issue is the documentation. TechNet is full of information about SharePoint 2013, including the process required to configure site mailboxes. The problem with the way that TechNet describes matters is that frequent side trips are necessary to master the essential detail of the various steps. I found that the description provided by Scinaptic was easier to follow, especially for a SharePoint novice.
Even equipped with as much knowledge as the Internet could provide, the process of installing SQL Server, SharePoint 2013, various updates, Exchange Web Services, and different scripts will take some time. You should allow several hours to read the available material, collect all the necessary bits, and then build a plan of campaign.
And then – and only when totally prepared – you can launch into the joyous process of server installation, including a tour of the seemingly infamous SharePoint User Profile Synchronization service, a component that can only be described as “temperamental”. Quite why any process might need “up to 10 minutes” to start on modern computers is beyond me, especially when zero feedback is provided as to what’s happening when the service attempts to start.
There are copious examples of complaints on the web about this service disappearing up its back end when attempting to start (this article explains some of the complexity under the surface). In my case, after a couple of server restarts and a few IIS resets to boot, the User Profile Synchronization service eventually agreed to cooperate and started. This was quite a moment for all involved.
The rest of the configuration procedure is tedious and boring. More than a few situations occur when you will have a chance to go have a coffee, even one that requires a barista a few minutes to prepare your selected brew, as SharePoint seems to spend a long time reassuring you that it’s doing something and then nothing much happens. But it does in the end and eventually all of the steps will be complete and you’ll be able to burst into the new world of cross-product collaboration.
Even with some site mailboxes in place (this blog from Microsoft Consulting Services provides a useful approach to automating the creation of new site mailboxes), you will probably wonder “why did I bother”? All of the effort and expense of deploying site mailboxes (remember, you’ll need additional hardware to support SQL Server and SharePoint 2013) is hardly rewarded by the feature set. Sure, it’s a nice integration between the two repositories but my feeling is that more work is needed before site mailboxes deliver a clear and obvious advantage over shared mailboxes or even modern public folders (or ancient public folders for that matter). And both shared mailboxes and public work out-of-the-box free of charge. Right now, the added functionality in site mailboxes doesn’t justify the extra cost and effort.
Unless of course you’re antenant who has been upgraded to the Wave 15 products (a process that is now ongoing), in which case Microsoft has done all the hard work to configure everything for you. Setting up site mailboxes on Office 365 is much easier than on-premises (is there a hint here?) and you might well decide that there’s an advantage to using site mailboxes, especially if you already use SharePoint for document management and have upgraded your clients to Outlook 2013.
Site mailboxes might just be another example of technology whose first version works well when everything is aligned (stars, wind, temperature, etc.) but really needs some more work to blunt the sharp edges before it will be deployed generally. Microsoft can do a lot to help site mailboxes succeed by increasing the level of automation in configuring servers to support site mailboxes and indeed, to add support for site mailboxes to Outlook Web App.
Follow Tony @12Knocksinna