A whole new version of Exchange, three years in the making
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.
