Architectural changes and brand-new features are hallmarks of the newest release
Mailbox Server Changes
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: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.
Client Access Changes
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.