A new star has appeared on the horizon: Microsoft announced the preview edition of Exchange Server 2013 on July 16 along with the other servers and clients that collectively form the Office 2013 “wave.” The pace will increase at the Microsoft Exchange Conference (MEC) in Orlando on September 24 when Microsoft will release a mass of detail about Exchange 2013 en route to shipping the product in early 2013. One problem that always faces software vendors with very mature products is trying to build a case to convince customers to upgrade. Exchange Server 5.5 did a fine job of processing email when it was launched in 1998. Every version of Exchange since then has continued to add new features that respond to customer demands, reflect the current market, or give Exchange a competitive edge. For example, the Exchange Server 2010 story is focused on high availability because that's a compelling feature for many customers.
Exchange 2013 represents three years of output from a large engineering group and includes numerous changes, improvements, and tweaks that I could discuss; however, I don't have the space to cover everything in detail. Instead, let's concentrate on the features that might convince CIOs to approve an upgrade. Understanding the value that the new features provide will help you decide whether and when to upgrade your environment. Keep in mind that Microsoft is still working on Exchange 2013, and some details might change between the preview edition discussed here and general availability. Learn more at "Migrating an Exchange 2010 DAG to Exchange 2013" and "Exchange 2013 Reduces Number of Mounted Databases to 50."
Deployment Basics
As in Exchange 2010 and Exchange Server 2007, Microsoft doesn't support in-place upgrades for Exchange 2013. Instead, you must deploy on new or reused hardware. Because of a change in the way that Client Access servers process user credentials to comply with a new "serialized common security context" and the need to update Exchange 2010 with new code to interoperate with Exchange 2013, you must upgrade your Exchange 2010 servers to Service Pack 3 (SP3), which isn't scheduled for release until early 2013. You also must install an Active Directory (AD) schema update to prepare the way for new functionality such as "modern" public folders (which I discuss later). If you're still running Exchange 2007, you need to update those servers with a patch that Microsoft has yet to finalize. Exchange Server 2003 servers are no longer supported in an organization after you upgrade to Exchange 2013.
Exchange 2013 supports Windows Server 2008 R2 (SP1 or later) or Windows Server 2012. Although components such as PowerShell 3.0 are exploited, it's not yet clear whether Exchange 2013 will take advantage of some of the advanced new features of Server 2012. For example, database availability groups (DAGs) use Windows failover clustering, which supports up to 64 servers on Server 2012. It would be nice if Exchange 2013 supported more than the current 16-server limit in a DAG. Every AD site into which you deploy Exchange 2013 must have at least one Server 2008 (or higher) Global Catalog (GC) and domain controller (DC), and the overall forest must be at Windows Server 2003 functional level or higher. Exchange 2013 doesn't support read-only DCs (or GCs), nor is it possible to run Exchange 2013 on Server 2012 Server Core.
When you install Exchange 2013, you'll see that server roles have been simplified. We now have Client Access servers and Mailbox servers, both of which are different from their Exchange 2010 or Exchange 2007 equivalents, and both of which have taken over some aspects of the work previously done by Hub Transport servers. Client Access servers are designed to be stateless servers that proxy incoming connections from all protocols, including SMTP. Unlike older Client Access servers, Exchange 2013 Client Access servers support TCP (layer 4) affinity to make load balancing easier. By comparison, Exchange 2010 and Exchange 2007 load balancing is based on layer 7 affinity, so if you use hardware load balancers, you need to check with your vendor to establish whether changes are required to support Exchange 2013. The upshot is that these changes dramatically reduce the complexity of load balancing in an Exchange environment.
Although they appear similar to their predecessors, Exchange 2013 Mailbox servers represent a major evolution of the Exchange 2010 model. All rendering and other processing of messages occurs on Mailbox servers. (Client Access servers perform some of this work in Exchange 2010.) This simplifies processing if a failure occurs because everything switches to the Mailbox server that activates the failed databases. Client Access servers now focus solely on making sure that client connections get to the correct Mailbox server.
Communication between Client Access servers and Mailbox servers is through either HTTP (MAPI RPCs are wrapped in HTTP) for client traffic or SMTP for transport. Exchange 2013 doesn't yet have an Edge Transport server role, but you can continue to use Exchange 2010 (SP3) Edge servers until Microsoft updates these servers.
Microsoft recommends upgrading Internet-facing sites first, followed by internal sites. This approach allows Exchange 2013 Client Access servers to take over the organization's namespace and support incoming connections for both down-level Exchange 2010 and Exchange 2013 servers. Microsoft also recommends that you either install both roles on the first Exchange 2013 server installed or make sure that at least one server of each type is deployed. The reason for this is that PowerShell cmdlets are executed only on Mailbox servers, so you need to have an Exchange 2013 Mailbox server available to be able to manage the environment.
I think most administrators will find it natural to install both roles on all servers. Role separation is most commonly encountered in larger deployments that require this level of flexibility and control. Microsoft's goal is that you should be able to update Client Access servers and Mailbox servers independently. In the future, it should be possible to mix and match Client Access servers and Mailbox servers running different software versions without any problems. Splitting Exchange into thin protocol servers and thick compute engines addresses some of the current complexity, in which all of the Exchange components that interact with a user's mailbox must be upgraded together. The new architecture also delivers a useful benefit for Office 365 because Exchange 2013 will be much easier for Microsoft to deploy and update in its data centers than its predecessors are.
Database Updates
Exchange 2013 continues to use the Extensible Storage Engine (ESE) for its databases, which are populated by moving mailboxes from Exchange 2010 or Exchange 2007 servers. You can't move mailboxes directly from Exchange 2003 servers; these moves must go through an intermediate Exchange 2010 or Exchange 2007 server.
For the third version in succession, Microsoft's Exchange engineers have focused on the efficiency of the Exchange Information Store. All Exchange 2010 and Exchange 2007 Store code has been rewritten in new managed code modules, resulting in a further reduction in the I/O footprint per active mailbox. More memory is used to cache data to avoid expensive disk I/O.
Microsoft learned a lot from Exchange 2010 customer deployments, as well as from the company's own experience running Exchange Online for millions of mailboxes. Multiple disk failures in JBOD arrays (approximately 5 percent for 7.2K rpm SATA drives and 2.75 percent for 7.2K rpm SAS disks) resulted in the frequent need to reseed database copies on replaced disks. Because reseeding operations from a single source is slow, Exchange 2013 can now reseed a database copy from all available copies. According to Microsoft, it's now possible to complete a reseed operation for a 2TB database in approximately 10 hours rather than the 23 hours previously required if three healthy database copies are available. Although not many installations operate 2TB+ databases, I appreciate the fact that operational experience from Office 365 is driving improvements that benefit on-premises customers.
Because of a change in the way mailbox properties and other overhead are more accurately included in the calculation of mailbox size, you can expect to see mailbox sizes grow by approximately 30 percent. No increase in physical database size occurs, but you might have to adjust some assigned mailbox quotas to accommodate the new overhead.
Exchange's Transport Dumpster feature captures and holds copies of messages in transit until the messages are safely committed. Exchange can recover copies of messages from the Transport Dumpster if data loss occurs as a result of a database outage. Exchange 2013 updates the Transport Dumpster feature to better support lagged database copies. A lagged database copy is designed to remain a predefined time period (up to 7 days) behind the live database copy and is intended to provide a backup for database recovery in case a problem occurs that corrupts the live database and its other copies. Exchange 2013 expands the Transport Dumpster feature so that the Transport Dumpster understands when a server supports lagged copies and therefore keeps copies of messages until they're committed into the lagged copy. This change is small but important.
A New Era of Administration
Previous versions of Exchange include a Windows-based administration console. A central theme in Server 2012 is remote administration. Exchange 2010 demonstrates the effectiveness of this approach by using remote PowerShell as the underlying foundation for all of its management interfaces, including the Microsoft Management Console (MMC)-based Exchange Management Console (EMC).
Exchange 2010 also includes a browser-based administration console, the Exchange Control Panel (ECP), which is used as the primary management tool for Exchange Online. The ECP is effective in many respects. For example, its interface is built from "slabs," each of which reveals the necessary UI for specific functionality, such as executing multi-mailbox discovery searches. The ECP exposes slabs based on users' Role Based Access Control (RBAC) membership. For example, a user who is a member of the Discovery Management role group will see the UI to create, execute, and examine mailbox searches. If you're not a member of this role group, the ECP simply rearranges UI elements to disguise the fact that mailbox searches even exist.
Exchange 2013 management is performed through a much-enhanced version of the ECP called the Exchange Administration Center (EAC), which Figure 1 shows.
Figure 1: Exchange 2013's Exchange Administration Center (Click image for larger view)
The EAC uses the same UI framework as the ECP but expands its functionality to include all of the management components that the ECP doesn't support, such as DAG management (see Figure 2) and the wizards that automate many aspects of Exchange server management.
Figure 2: Adding a new server to a DAG (Click image for larger view)
The EAC follows the design principles for Metro-style interfaces, as does the upgraded version of Outlook Web App (OWA). In addition to being more approachable for inexperienced administrators than the EMC's complex layout is, Microsoft notes that the EAC is far more efficient than the EMC at dealing with a large number of objects and is therefore capable of handling even the largest Exchange deployment.
Few will shed many tears at the demise of the EMC. Despite its richness in features, the EMC was slow and unwieldy and had suffered some recent problems when Internet Explorer 9.0 changed an underlying component. It makes more sense for Microsoft to concentrate its efforts on browser-based management tools that can be used on almost any PC, as well as on other devices such as iPads. In addition, the EAC provides the basis for a common administrative platform shared between on-premises and cloud deployments. The only downside is the loss of the EMC's three PowerShell learning tools. Many administrators used the EMC's ability to display the PowerShell code it executed as a way to become accustomed to PowerShell syntax and constructs.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Client Upgrade: A Necessary Evil
Like previous versions of Exchange, you need to upgrade client desktops to the latest version of Outlook to be able to exploit all the features that Exchange 2013 supports. Features such as DLP and site mailboxes simply won't surface in earlier versions. Although Outlook 2013 has some useful new features that make sense (such as the ability to reply to a message within the reading pane) and enhance the user interface (such as the ability to display expanded contact information using data retrieved from multiple social networking sources or the ability to display weather information for meetings), the upgrade to Outlook 2013 will be a hard sell within many companies -- particularly because the new Metro-style UI will provoke worries about user training and support similar to those when Office 2007 introduced the Ribbon interface.
Older clients can connect to Exchange 2013, but this release marks the end of the road for Outlook 2003. Microsoft did a lot of work to retrofit support for Outlook 2003 into Exchange 2010 but hasn't brought that work forward into Exchange 2013. Equipped with the latest patches, Outlook 2010 and Outlook 2007 work just fine as long as you don't want to use the new Exchange 2013 features. It remains to be seen whether Microsoft will issue a service pack or other update to reveal features such as DLP in Outlook 2010 and Outlook 2007 in the same way that the company eventually supported Exchange 2010 archive mailboxes for Outlook 2007.
OWA continues to get better and better. Although some might be enthused by the addition of inline editing for new messages, which Figure 3 shows, the OWA headline feature for Exchange 2013 is the addition of offline access, which OWA switches into if a network connection is unavailable. To some degree, adding offline access is a nod to Gmail, which introduced offline access mode in 2011. Offline storage is standards-based and is managed by the browser you use. If your browser supports HTML5 IDB, OWA will use it for storage; if not, OWA will use WebSQL. You need to be running IE 10.0, Chrome 16.0 or later, or Safari 5.1 or later to use offline access because these are the only browsers that currently support the storage mechanism.
Figure 3: Exchange 2013 Outlook Web App (Click image for larger view)
Even more interesting is the way OWA morphs itself to support three distinct screen form factors (phone, slate, and traditional PC). The UI is Metro-based and touch/gesture-capable across the width of the screen; it has an advanced HTML5-based mode that facilitates video display. The two traditional modes (premium and reach) continue to let OWA support the widest possible range of browsers. Although the OWA support matrix is a tad more complex because of the multiple form factors, IE, Chrome, Firefox, and Safari all support the premium interface.
Exchange Online
Exchange Online is a major part of the Office 365 value proposition, so it's no surprise to learn that Exchange Online will include the new features enabled by Exchange 2013 soon after general availability. Microsoft hasn't set a firm date for the update yet but will advise tenant administrators when to expect upgrades to commence. The company will allow tenant administrators to select the most appropriate upgrade time within a window spanning a couple of months. Tenants can even opt to run a pilot deployment for a select group of users before full deployment begins. This feature is based on scheduling batches of mailbox moves. Exchange 2013 marks the first time that Office 365 has been through a major application functionality upgrade -- so it's good that Microsoft has considered how to minimize disruption for customers during the transition.
The Big Upgrade Question
Exchange 2013 includes numerous improvements that I haven't discussed here. For example, the Exchange content-indexing subsystem is replaced by a FAST-based search engine that extends over Exchange 2013, SharePoint 2013, and Lync 2013 to provide a single enterprise-class search capability across multiple data sources. This upgrade would certainly merit much discussion in another release -- but such are the changes in Exchange 2013 that this improvement is merely mentioned in passing.
As always, when Microsoft releases a brand-new version of a popular server application, we must ask whether there's a compelling reason to upgrade. In this case, the answer for companies running Exchange 2010 is probably No -- unless they have a pressing need to use one of Exchange 2013's new features and the necessary financial and technical resources to deploy new hardware and new software (Exchange and SharePoint), upgrade clients, train and support users, and so on. But if you're running Exchange 2003, it's definitely time to move to new technology, and it makes sense to consider an early upgrade to Exchange 2013. The same argument can be made for Exchange 2007 deployments. Although these servers did a good job in their time, that time is quickly running out.
Of course, companies faced with the complexity and cost of migrating to Exchange 2013 might simply conclude that now is a good time to move some or all of their user population to Office 365. Moving to Office 365 isn't free of charge; costs will be incurred to plan, prepare, and execute all the steps necessary to set up a new tenant domain, establish interoperability with on-premises Exchange, establish single sign-on (SSO) using Active Directory Federation Services (AD FS), move mailboxes to the cloud, and figure out details such as the effect on other applications. But the whole point of going through this pain is that after you migrate to Office 365, Microsoft will take care of the heavy lifting of server and software maintenance from that point on and you'll be able to take advantage of new features and functionality soon after release without having to go through a traditional migration. The steadily improving reliability record of Office 365, combined with the release of Office 2013 apps, will create a real decision point for companies as they chart their long-term future for email services.
Old Habits Die Hard
If you can cope with the migration and can make use of the new features, Exchange 2013 will be worth the effort. The implementation seems solid, and Microsoft has tested the heck out of this release to prepare for its introduction in the Office 365 cloud service. Still, I think most Exchange admins will opt to wait for SP1. After all, in the past three major versions, Microsoft has substantially improved the initial Exchange release with the first service pack. Why spoil what has become such a long-standing habit?
