Microsoft Exchange Server 2013 : Site mailboxes (part 1) - How site mailboxes work

Up front, the most important point to remember about site mailboxes is that they operate on the principle of keeping the content 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 is optimized for documents, and Exchange is not.

Public folders make excellent repositories for email discussions, but they are a pretty useless repository for document-based collaboration, such as when a group of people works together to author a document or presentation that will go through many editing cycles involving multiple contributors. This can be done by using email, but it’s hard to keep track of the many versions of documents that circulate as message attachments unless someone is designated as the editor in chief. It’s also possible to accomplish a collaborative authoring process by using public folders as long as great care is exercised over when different users access the document to update its content. Unfortunately, humans are often not so good at exercising the necessary care.

Site mailboxes are designed to fill the gap by using the strengths of Exchange (for email) and SharePoint (for document management). In effect, a site mailbox creates a virtual container that includes a shared mailbox and the document libraries on a SharePoint site. A SharePoint site is a website hosted by a SharePoint server that is identified by a virtual URL. Each site can be configured with different SharePoint components to create whatever functionality is required by the site’s users. A site mailbox is an example of a component that can be added to a SharePoint site; tasks, calendar, and wiki apps are other examples.

The shared mailboxes created by the site mailbox app are fully functional mailboxes that have email addresses. The ability to accept email means that the site mailbox can be used as a form of email archive for the project if you add the site mailbox to any distribution groups used for project team communications. Each mailbox contains default folders such as the Inbox and Sync Issues, a folder that is particularly important because it captures problems that occur when Exchange and SharePoint swap information.

A synchronization process creates, populates, and maintains folders in the mailbox to represent the contents of the SharePoint document libraries that are associated with the site. Appropriately, these folders use a document-centric view to display their contents through Outlook rather than the conversation-centric view normally used for email messages in other folders. You don’t realize where the join exists between Exchange mailbox folders and the folders populated through synchronization with SharePoint because Outlook creates the impression that all the information in a site mailbox is held in one place. The fact that two servers work together to manage the site mailbox is immaterial to users. People never worried that old-style public folders used a completely different database and replication mechanism from Exchange mailboxes, so why should they worry that some items are in an Exchange mailbox and some are in a SharePoint site? The point is that they have access to the information they need to perform a task.

Two obvious dependencies leap off the page here. You need to deploy SharePoint 2013 to support the sites, and you need Outlook 2013 to be able to create the invisible join between mailboxes and sites. No other client is currently capable of accessing site mailboxes. Companies might well be considering a deployment of Outlook 2013 alongside Exchange 2013 because this version of Outlook exposes all the functionality in Exchange 2013, but a SharePoint deployment might represent more of a barrier to overcome. Deploying SharePoint requires additional investment in hardware, expertise, and software, and these factors have to be taken into account in any discussion about site mailboxes.

Nevertheless, assuming that all is well, that software and hardware have been procured and deployed, and that SharePoint and Exchange are both humming along like a well-tuned engine, the question of functionality is the next topic of discussion.

The steps required to implement site mailboxes are described on TechNet and in many other web articles and do not need to be repeated here. In summary, the deployment of site mailboxes depends on:

A considerable amount of work and cooperation is necessary between the Exchange and SharePoint administrators to configure the products to work together smoothly to enable the creation and operation of site mailboxes. Do not anticipate that this work can be done without preparation.

SharePoint communicates with Exchange using EWS, which means that you must download and install EWS on your SharePoint servers. It is important for a matching version of EWS to be installed on the SharePoint servers so they can communicate with the mailbox servers. In other words, if the mailbox servers run Exchange 2013 CU2, a matching version of EWS should be installed on the SharePoint servers.

Membership information (both users and owners) for the site mailbox is maintained through SharePoint. Users are permitted access to site mailboxes by being added to the membership list of the SharePoint site. Users have to be added individually because gaining access through group membership is not supported. In addition, users must have an Exchange mailbox, and that mailbox has to be on an Exchange 2013 server before they can use site mailboxes through Outlook. Users who have not yet been moved to Exchange 2013 can still interact with site mailboxes by opening the SharePoint site with a browser.

Behind the scenes, SharePoint synchronizes the membership list with Exchange to grant members full access rights to the shared mailbox. Like all other operations affecting the life cycle of a site, provisioning and updates for site membership is controlled from SharePoint, and Exchange does not proactively query SharePoint to discover new site members. After full access has been granted, Autodiscover adds the shared mailbox to the list of resources available to Outlook the next time it queries Exchange for this information, and Outlook opens the shared mailbox as soon as the new resource becomes known.

Outlook 2013 Professional Plus is the only client currently capable of displaying the site mailbox data about document libraries that Exchange retrieves from SharePoint. An Outlook Web App–like interface is available to the email items in a site mailbox if you click the Mailbox link when accessing the SharePoint site in a browser; this invokes an explicit logon to the site mailbox. However, unlike Outlook, Outlook Web App does not include site mailboxes in the set of available resources a user sees when he accesses his personal mailbox, and there are no public plans to change this situation. By comparison, Outlook considers a site mailbox like any other resource available to a user—like a shared mailbox, archive, or PST—so moving information into a site mailbox is as easy as dragging an item from another Outlook resource. In effect, anyone who knows how to work with Outlook can work with a site mailbox, which reduces the cost of deployment and support.

Items can be added to the site mailbox through SharePoint or Outlook by dragging and dropping items into the folders in the document library within a site mailbox or the other (regular) folders in the mailbox. It’s best to maximize the relative strengths of Exchange and SharePoint by putting email items in email folders and documents (such as those received as attachments to messages) into document libraries. This approach means that you’ll be able to use features such as threaded conversations for the messages stored in the site mailbox’s Inbox and version control for the items stored in the document library.

The content stored in site mailboxes is indexed and discoverable by eDiscovery searches. This is because Exchange 2013 shares the Search Foundation technology with SharePoint. Email has long since been indexed and discoverable; Exchange 2013 and SharePoint 2013 combine to make the documents held in site mailboxes discoverable, too—a fact that will surely 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 a message, and Exchange will route the message to the Inbox folder in the site mailbox. Site mailboxes appear in address lists and can be hidden by setting the HiddenFromAddressListsEnabled property to $True. This step is usually taken to prevent users from including a site mailbox in messages when the mailbox is being decommissioned. Messages can still be sent to the site mailbox by using its Simple Mail Transfer Protocol (SMTP) address.

Set-Mailbox –Identity 'Project Alpha' –GrantSendOnBehalfOf 'Paul Robichaux'

The Send As permission can also be assigned for a site mailbox. In this case, you use the Add-AdPermission cmdlet. For example:

Add-AdPermission –Identity 'Project Alpha' –ExtendedRights 'Send-As' –User 'Tony Redmond'

SharePoint documents stored in site mailboxes remain in place when you add them as attachments to messages. A link is added to the message to enable recipients to access the content, but the documents stay in SharePoint rather than being circulated as attachments. It 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 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.)

Items stored in site mailboxes are not subject to Exchange retention policies. All the information held in the site remains under the control of the SharePoint information policy that applies to the site. However, items in a site mailbox can be placed on hold using the SharePoint eDiscovery Center.

The stub items that represent the content of the document libraries can be synchronized down to the client OST like the contents of other mailbox folders if you select the Download Shared Folders check box on the Advanced tab of your Outlook profile. If not, Outlook makes an online connection to the shared mailbox when you want to work with its contents. Remember that only the stub items are synchronized. The actual content of document libraries always remains under SharePoint control. These stored documents can be made available offline by synchronizing the site to create a local copy of the document library on the PC. And, of course, you can always download a local copy of an individual document from SharePoint for use offline.