Exchange Server 2013 Preview

 

Modern Public Folders

Microsoft describes the Exchange 2013 implementation of public folders as "modern public folders." Given that the public folder implementation in Exchange 2010 is based on the same design as originally implemented in Exchange Server 4.0 (circa 1996), it's fair to describe the new approach as "modern," especially because the storage model now uses mailbox databases that let public folders take advantage of the development tweaks Microsoft put into refining mailbox databases over the past three releases.

In Exchange 2013, every public folder mailbox holds a copy of the public folder hierarchy. A single public folder mailbox, which is always the first public folder created in the organization, stores a writeable copy of the hierarchy (the master hierarchy). Changes made to the master copy are replicated to the other mailboxes. Access to public folder content is therefore accomplished by first interrogating the hierarchy, followed by a redirect to the specific public folder mailbox holding the content. Unlike in previous versions of Exchange, content isn't replicated to multiple public folder replicas. It always remains in a single distinct location whose integrity is protected by standard Exchange high-availability features.

Moving to this model has many advantages. Public folders have long been the cockroaches of Exchange -- unloved but ever-present. As such, they haven't received much attention; some would argue that Microsoft dedicated just enough effort to public folders to keep them alive. Modern public folders are stored in mailbox databases and are therefore maintained as a core component. Another major advantage is that public folders now enjoy the high-availability features of DAGs. Of course, public folders have enjoyed a multi-copy replication model ever since Exchange 4.0. However, although public folder replication works, it doesn't offer the same kind of advanced replication and problem-solving features that are available in a DAG, such as block mode replication or single page patching.

Exchange 2013 public folder deployment and management will require different techniques. It's too soon to offer a definitive assessment of possible fault lines, but because of the various methods available for deploying public folders, some hiccups are sure to happen along the way -- possibly related to electronic forms or to other applications that use public folders for storage.

The migration path to modern public folders goes something like this:

1. Move all user mailboxes to Exchange 2013 servers. Users will still continue to access public folders on an Exchange 2010 server. Users whose mailboxes are on Exchange 2010 or Exchange 2007 servers can't access Exchange 2013 public folders.
2. Run the public folder migration script (PublicFolderToMailboxMapGenerator.ps1) to analyze the existing public folder hierarchy and folder content. You can use this script's output to create an initial set of Exchange 2013 public folder mailboxes.
3. Initiate the process to move public folders to Exchange 2013. The Mailbox Replication Service (MRS) creates public folder mailboxes in the target database and performs the initial population.
4. Background synchronization by the MRS continues to keep two sets of public folders synchronized for up to 30 days. Administrators use this time period to prepare for the final switchover.
5. Administrators trigger the final replication phase. This is similar to the existing functionality in Exchange 2010 where an administrator can resume a suspended mailbox move. The MRS then performs a final incremental synchronization to ensure that all of the content in the public folders is completely up-to-date, then switches the AD configuration so that users begin to access the Exchange 2013 public folders. All versions of Outlook supported by Exchange 2013 can access public folders in their new location.
6. After the switchover is complete, an organization can't revert to Exchange 2010 public folders.

Although the new public folders are contained in mailbox databases, their content isn't exposed to discovery searches, nor is it possible to apply mailbox retention policies. Microsoft will offer modern public folders as a new feature for Office 365 subscribers. However, because OWA won't support access to public folders until Exchange 2013 SP1, you’ll have to use Outlook 2013 to access the new repository.

Data Leak Protection

Microsoft did an enormous amount of work on a broad set of compliance features in Exchange 2010, with archive mailboxes, multi-mailbox discovery searches, an upgraded dumpster, and retention policies. Exchange 2013 adds Data Leak Protection (DLP) to its compliance capabilities.

A simple way to describe DLP is that it stops users from doing stupid things such as including data that they shouldn't share in email messages. For example, it's usually a bad idea to send a credit card number in an email message because this data can be misused if the message is intercepted or ends up with an unintended recipient. DLP tries to identify confidential data in email messages and prevent such data from leaving the organization.

DLP works through policies defined on an organizational level. These policies identify the hallmarks of confidential data that should be protected. DLP is very similar to transport rules in that Exchange examines messages as they pass through the transport pipeline to identify policy violations and then takes whatever action is defined by the policy. For example, messages can be suppressed, sent to an authorized intermediary such as a manager, protected against unauthorized access with Rights Management Services (RMS), or returned to the sender with an explanation of why a policy has been violated. Code is built in to Outlook 2013 to make it DLP-aware so that potential policy violations can be flagged as messages are composed.

Exchange 2013 includes a set of DLP policies, such as policies that protect Gramm-Leach-Bliley Act data (for financial services), Payment Card Industry–Data Security Standard (PCI-DSS) data (credit card information), and US personally identifiable information (PII) (data that could identify an individual, such as a Social Security number). Custom policies can be created from scratch or imported from a file. Microsoft believes that ISVs will develop market-specific DLP policies that can be sold to companies.

DLP will be very important for some customers, especially those who work in highly regulated industries. Other companies won't regard DLP as important. Adoption will likely be slow because only Outlook 2013 fully supports DLP, much like Outlook 2010 was the only client that could display MailTips when Exchange 2010 debuted.

Site Mailboxes

In some respects, site mailboxes complicate Exchange's collaboration story, if only because even more choices exist for how the sharing needs of groups of users can be met. Site mailboxes are based on SharePoint 2013 and require Outlook 2013 Professional Plus (or OWA). Cynics might ask why site mailboxes haven't appeared before, because many customers have asked for better integration between SharePoint and Exchange. In this implementation, documents reside in SharePoint, and Exchange looks after calendaring and email. A tight link is maintained between Exchange and SharePoint to ensure that new content is synchronized correctly between the two repositories. No hybrid configurations are supported for site mailboxes, which means that the Exchange and SharePoint servers must be deployed on premises.

Setting up site mailboxes is easy. After they're created, new site mailboxes appear in Outlook 2013 as soon as Autodiscover refreshes the set of resources available to a user. Site mailboxes appear much like shared mailboxes or PSTs, with the obvious difference that any access to a document is processed by SharePoint. The transfer between SharePoint and Exchange is seamless and users can perform all the operations you'd expect, such as dragging and dropping messages from a mailbox to SharePoint or vice versa.

Creating software that meets all possible requirements is difficult in a first release, and site mailboxes are no exception. Several issues exist that could make site mailboxes less successful when deployed.

• Like archive mailboxes, documents associated with a site mailbox that are stored in SharePoint are available only when you're working online. This restriction might not be a huge problem in today's always-connected world; however, there will be times when it's impossible to be online and you might need a document. You can copy documents from SharePoint into a mailbox folder for later use offline -- but how likely will you be to remember to do so before a road trip?
• SharePoint supports document versioning, which is a useful feature for teams that collaborate on complex documents. Outlook doesn't support versioning and can display only the latest version of a document. This isn't necessarily a problem unless you need access to an earlier version, in which case you must access documents in the SharePoint site directly rather than going through Outlook.
• Site mailboxes don't respect Exchange retention policies; in addition, site mailboxes can't have archive mailboxes in the same way that a shared mailbox can. Microsoft designed the retention policy and tag model to deal with personal mailboxes. The Managed Folder Assistant (MFA), which is the Exchange component that processes mailboxes to apply retention policies, has no knowledge of the SharePoint sites that underpin site mailboxes. It would be nice if Microsoft extended the retention model to accommodate site mailboxes in the future so that all of the information available to users could be managed in a single way.

I'm sure that many other operational aspects will be explored as companies deploy site mailboxes. This will certainly be an interesting space to watch.