Architectural changes and brand-new features are hallmarks of the newest release
Microsoft recently released Exchange Server 2013, labeling it "the new Exchange." (This interesting branding decision implicitly labels all other versions of Exchange as "old," with all the negative connotations that label carries.) Understanding what's new in Exchange 2013 requires us to dig into the architectural and feature changes that Microsoft has made -- some (but not all) of which the company is touting heavily.
If you remember Exchange Server 2003, then the major architectural change in Exchange 2013 will seem very familiar. There are now only two roles: the Mailbox server role and the Client Access server role.
This setup is essentially the same as the front-end/back-end architecture in Exchange 2003, although there are major implementation differences. Microsoft decided to split the roles in this way to dramatically simplify implementation at large scales. Tight coupling between the server roles no longer exists: The Client Access server role doesn't keep any state or session data and can be upgraded (or rebooted) independently of the Mailbox server role, and vice versa. This change has several interesting implications:
As is typical for a new release of a major product, Exchange 2013 is full of new features. Knowing what to label "new" can sometimes be difficult because of Microsoft's habit of making major enhancements to existing features, but several genuinely fresh features are included. The most significant one is arguably the new managed availability functionality. Microsoft describes managed availability thusly on the Exchange Team Blog:
Managed availability is a monitoring and recovery infrastructure that is integrated with Exchange's high availability solution. Managed availability detects and recovers from problems as they occur and as they are discovered.
This description neatly captures the major points of managed availability: It focuses on detecting problems that the end user will notice and then repairing them automatically whenever possible. The Exchange 2013 managed availability implementation accomplishes this task by performing several kinds of automated checks that probe various parts of the infrastructure. Based on the results of these tests, a variety of automated responders can take action. These actions can range from restarting the responder service, to taking a protocol on a machine out of service (which allows client traffic to be sent to another machine running the same protocol), to forcing a server reboot and restart. There's also the escalate responder, whose job it is to fire an event that triggers special behavior in System Center Operations Manager or other monitoring software. In this way, Exchange has a customized method for indicating a high-priority failure that requires human intervention. Managed availability represents an ambitious effort by Microsoft to bring high-scale, datacenter-style management to Exchange. This effort offers a lot of potential, although I'm reserving judgment on its worth until I see it proven in the field.
Another major change is the availability of a single integrated e-discovery experience. You can now perform discovery searches that include Exchange mailboxes and public folders, archived Microsoft Lync conversations, and material that's stored in Microsoft SharePoint from a single SharePoint-based interface. Although this feature requires that you deploy SharePoint 2013, organizations that need to perform discovery searches will find this feature valuable because it enables self-service discovery searches for users with appropriate permissions.
Exchange 2013 also includes a group of features that are lumped under the rubric of data loss prevention (DLP). The goal of these features is to reduce the risk that your organization will commit or suffer breaches of sensitive data such as personally identifiable information (PII) of customers, data that must be protected under regulations such as the US Health Insurance Portability and Accountability Act (HIPAA) or European Union Data Protection Directive (EUDPD), or data that you just don't want to be disclosed. DLP features include a robust set of transport rule–like tools for scanning messages for sensitive data, a predefined set of policies for common regulatory requirements, and tools for customizing the included items or building your own.
It will be interesting to see which of these features drive Exchange 2013 adoption. Some are likely to be of interest to a small number of large customers, whereas a few others seem clearly targeted at a broader audience.
The Mailbox server role remains at the core of Exchange. For this release, Microsoft rewrote the Exchange Information Store service (store.exe) completely in managed code, taking advantage of the .NET common language runtime (CLR) memory-management support.
The internal architecture of the Information Store service has changed a good deal as well. There's now a new service, the Exchange Replication service, which controls failover and switchover operations and database mounts and dismounts, plus a service process controller that manages the database worker processes. Each database now has its own worker process, so failure of the Information Store service process should affect only one database at a time. An additional related change has been somewhat controversial: Exchange 2013 is now limited to a maximum of 50 databases per server instead of 100. It remains to be seen how many customers this change affects and whether Microsoft will consider lifting the limit in a future release.
These changes are coupled with several aggressive optimizations to the Store schema itself. Microsoft's goal for this release was to reduce overall I/O operations per second (IOPS) from Exchange 2010 by as much as 50 percent while simultaneously enabling the widespread use of databases up to 100GB. To do this, Microsoft essentially traded off CPU and RAM usage for IOPS. By increasing the degree of physical and logical contiguity in the Exchange 2013 schema, fewer large I/Os will be required -- but an increased amount of CPU will be needed to handle them. Microsoft is expected to update the Exchange Mailbox Role Calculator (familiar from previous versions of Exchange) to take these changes into account.
The Exchange 2013 Store fully supports mixing multiple databases per volume. For example, you can put one active database and multiple passive databases on a single disk. With 8TB drives expected to be available soon, and with the existing recommendation of 2TB as a maximum size for Exchange databases, leveraging both the storage and IOPS potential of large disks by combining databases makes sense. The new Store also implements a new AutoReseed feature. This feature can immediately create a new passive replica of a database on a failed disk by using a spare disk on the server, quickly (and automatically) replacing the failed copy to maintain the correct number of copies in the database availability group (DAG).
In one of the most surprising changes to Exchange 2013, Microsoft has completely re-implemented public folders. The new "modern" public folder system replaces the old multi-master model, which was dependent on the finicky system of public folder replication introduced in Exchange 4.0. The new system is much simpler: Public folders essentially look and act like databases. Public folder databases are stored in DAGs, just as mailboxes are, so you protect public folders against outages by adding multiple replicas of a given public folder database to a DAG. Clients always connect to the active copy of the public folder, which might have implications for scalability in some environments.
As previously mentioned, the new Client Access server role in Exchange 2013 no longer renders data for the client. The only thing it does is perform proxy connections from the client to the appropriate Mailbox server. This proxy-only design eliminates the need for the Client Access server to maintain affinity or state with clients, which in turn enables a much broader range of potential load-balancing solutions. DNS round-robin and Windows Network Load Balancing (NLB) are both fully supported, although neither can recognize the presence of server failures.
Client connections can use IMAP, POP, or Exchange Web Services (EWS), but they no longer use Messaging API (MAPI) RPCs. Instead, all Microsoft Outlook clients must now connect by using the Outlook Anywhere feature (another name for RPC over HTTPS), which wraps MAPI RPCs inside HTTPS packets. This change enables clients to request mailbox connections using a mailbox globally unique identifier (GUID) plus the user principal name (UPN) suffix, without any included reference to a Mailbox server's Fully Qualified Domain Name (FQDN). Mailboxes are much more portable because the Client Access server and its clients no longer need to know or care about Mailbox server names. The complex Exchange 2010 system of interrelated namespaces (and certificates to secure them) is gone, replaced with a dramatically simpler implementation. To facilitate the use of Outlook Anywhere internally, the Client Access server role now supports a new internal hostname (and matching authentication method), which will be used (if defined) for clients on the LAN.
Another pleasant side effect of the change to the Client Access server design is that cross-site access is much simpler. Clients connect to whichever Client Access server is convenient, and the Client Access server can perform HTTP redirects as necessary to find the correct Mailbox server across Active Directory (AD) sites.
The services that the Client Access server offers to clients have changed quite a bit as well. Outlook Web App (OWA) 2013 is completely rewritten and includes some compelling new features, such as greatly improved support for mobile devices such as Apple iPads. OWA 2013 can run offline on supported browsers -- currently, Google Chrome, Microsoft Internet Explorer (IE) 10, and Apple Safari 5.x/6.x on Mac OS X.
The transport process has changed significantly because of the two-role architecture. Whereas Exchange 2007 and Exchange 2010 had a separate Hub Transport role, Exchange 2013 does not. The Client Access server role hosts the new Front End Transport service, which handles all inbound and outbound SMTP traffic. The service doesn't perform any content filtering, although it does provide filtering based on connection, sender or recipient identity, and protocol behavior. The Front End Transport service's role is rather to act as a centralized, load-balanced ingress and exit point for all SMTP traffic. Bear in mind that the Client Access server isn't intended to replace the Edge Transport role, so deploying it in a perimeter network is unsupported.
The new Front End Transport service has a completely new approach to mail acceptance and delivery: It has no permanent queues. When a new SMTP conversation is opened, the service accepts the connection, performs filtering based on the SMTP envelope data, and then determines the route to the "best" Mailbox server before starting the delivery process. The Mailbox server is responsible for accepting and queuing the message. If the Front End Transport service cannot connect to a Mailbox server, or if the server doesn't accept the message, then the Front End Transport service returns SMTP error 421 to the sender, indicating a transient failure that must be retried later. This approach drastically simplifies the Front End Transport service -- at the cost of moving the queuing, redundancy, and delivery logic over to the Mailbox role.
The Mailbox server runs three new transport-related services:
The division of labor between the Client Access server and Mailbox Transport service delivers essentially the same high availability for transport as we had in Exchange 2010, but it's implemented very differently. The Mailbox Transport service persists every submitted message before the message is acknowledged to the sender. If the Mailbox Transport service does not or cannot accept the message, then the Front End Transport service sends a 421 error to the sender and message delivery is re-attempted later. Messages that are successfully submitted to the transport system are maintained until their final delivery, and resubmission of messages that couldn't be delivered because of the loss of a transport database or mailbox database failover and switchover is automatic. This new behavior is known as Safety Net, and it's complex enough that it will probably be the subject of future Windows IT Pro articles and Exchange Team Blog posts.
Interestingly, Microsoft isn't currently shipping an Edge Transport role in Exchange 2013 and hasn't publicly announced whether or when it will do so. Relatively few customers use the Edge Transport role, so Microsoft might have chosen to wait or even bake the Edge functionality into a future version of an Edge-network product such as its Unified Access Gateway (UAG) Server line.
Unified Messaging (UM) is perhaps the area in which functionality has changed the least in Exchange 2013. The Unified Messaging role is now hosted on the Mailbox server. The Client Access server runs the Unified Messaging Call Router service, which accepts incoming calls and redirects them to the appropriate Mailbox server. The Mailbox server itself is responsible for handling all interaction with the caller, including playing a voicemail greeting or Auto Attendant message and recording the caller's voicemail.
The remaining UM changes are all enhancements. For example, the Voice Mail Preview feature is more accurate. (Although Microsoft still doesn't claim that it is 100 percent accurate, nor is it intended to be.) UM can now resolve contacts against all personal Contacts folders in a user's mailbox. Therefore, caller ID resolution now works with external contacts from Facebook, LinkedIn, and other aggregated sources. Like the other Exchange 2013 roles, the Unified Messaging role now fully supports IPv6. Apart from that, users and administrators will probably not notice any major differences in how UM behaves. Administrators will note the addition of a few new Exchange Management Shell cmdlets for managing the UM services and call router settings.
One major issue does face sites that want to deploy Exchange 2013: It cannot yet coexist with Exchange 2010 on-premises. Exchange 2010 coexistence requires Exchange 2010 SP3, which Microsoft has announced but not released as of this writing. Given the troubles with Exchange 2010 rollups during 2012, any prospective deployment of Exchange 2010 SP3 should be approached carefully and with a thorough testing plan. The necessary changes to support coexistence are already deployed on Exchange Online, so if you're willing to move your mailboxes to Microsoft Office 365, you can deploy Exchange 2013 without further delay. This delay isn't all bad, though, because it gives you the opportunity to test Exchange 2013 in a lab environment and get a better sense of its new features and behaviors. It will certainly be interesting to see how customers adopt Exchange 2013 and how Microsoft updates its product guidance and documentation to reflect the lessons learned from that adoption.