Stubbing is OK when Microsoft does it in Exchange 2013 site mailboxes

Microsoft has long frowned on database stubbing, the process used by third-party products to remove large items or attachments from mailbox databases, leaving a much smaller “stub” to act as a pointer to the location of the complete item in an external repository. In early versions of Exchange, when disks were expensive and mailboxes small, it made sense to move stuff out of the active database, especially if the material needed to be retained for a period to satisfy legal or regulatory requirements. Stubbing became one of the basic technical approaches taken to Exchange archiving in products such as Symantec’s Enterprise Vault and GFI MailArchiver. That approach continues today.

Third-party software vendors say that stubbing is good for Exchange because it allows their products to reduce the load on Exchange mailbox servers. They also point to the advantages in terms of compliance of being able to harvest information from Exchange into a repository where email can be combined with data taken from other sources such as SharePoint sites or file shares to provide a comprehensive view of the documentation available to a company.

Microsoft’s view of stubbing was clearly stated by Perry Clarke, GM for Exchange mailbox server, when he said in 2010 “I consider the stubbing approach it be one of those kluges that occur in the software industry regularly that are done out of necessity.  In Exchange 2003 and earlier, to avoid the tyranny of tape back-up solutions for an online Exchange store, they were about the only thing many customers could do.  Even so, a tiny fraction of customers ever deployed solutions based on this approach.  Those that did were not very happy but realistically didn’t have any alternatives.  Now that there are real alternatives, the complexity, fragility, incompleteness and expense of stub solutions should make anyone thinking about deploying them pause and think for a very long time.”

To be fair to Perry, his view is very understandable. Microsoft has expended huge engineering effort and no small amount of dollars to make the Exchange Store into a much more flexible repository that is capable of running on cheap storage solutions. Exchange 2013 is happy dealing with 100GB mailboxes and offers archive mailboxes and a range of other compliance features to meet the demands of customers. All good stuff, but not a reason to get rid of stubbing, which continues to be a reasonable approach in certain circumstances.

Microsoft must agree with this statement because they use stubbing in Exchange 2013. I’m sure that you are staggered by that fact, but here’s the proof.

Site mailboxes are a big new feature in Exchange 2013. Their value is in bridging the world of email (Exchange) and documents (SharePoint) to provide a unified view of all of the information that a project team might want to share between members of the team. Outlook 2013 (Professional Plus only) provides the intelligence to stitch together the shared mailbox provided by Exchange 2013 and the site provided by SharePoint 2013. The good news is that it all works, if you have the patience to configure everything necessary to make Exchange 2013 and SharePoint 2013 communicate together.

Exchange synchronizes with SharePoint to make items stored in document libraries in the underlying site available in folders in the shared mailbox. A separate folder is created and populated for each document library.  The synchronization is done using SharePoint 2013's representational state transfer (REST) API and occurs on a frequent basis. Some might be surprised that Exchange Web Services (EWS) is not used to synchronize data, but this is because Exchange synchronizes with SharePoint rather than SharePoint synchronizing with Exchange, which is where EWS would be a natural choice.

If you poke around under the cover using MFCMAPI (the screen shot illustrates the properties of an item in the Documents folder, corresponding to a document library of the same name), you find that synchronization creates a set of stub items, each representing the real item that stays firmly located in the SharePoint site. In essence, the stub items are used as a container for the properties of the documents synchronized from SharePoint. Having the set of stub items in the folder allows Outlook to display the view of the folder much faster than if it had to consult SharePoint each time a user accessed the site. If the user asks Outlook to open an item, a connection is made to SharePoint to retrieve the full content.

All of this sounds very much like the way that the add-ins for Outlook provided by third-party archive vendors work. Could it be that Microsoft approves of stubbing for certain purposes? Maybe so. Or perhaps it’s a case that stubbing is OK when used by Microsoft to avoid keeping potentially large items in a mailbox database but not if it conflicts with functionality (like archives) that exist in the product.

You’ve got to smile when stuff like this comes to light. At least, I’m sure that the marketing people who sell third-party archiving products for Exchange will smile.  

Follow Tony @12Knocksinna