Exchange Server 2013 SP1: A Mixture of New and Completed Features

The introduction of MAPI over HTTP (aka “alchemy”) as the preferred interprocess connection mechanism for Outlook and Exchange. The RPC over HTTP mechanism is continued to serve older clients but it is likely that MAPI over HTTP will become the predominant and eventually the sole method to connect Outlook and Exchange in the future. RPC is an old mechanism that struggles with the kind of unreliable and often flaky networks (think public Wi-Fi) that we use so often today and it is hoped that the removal of a layer will make client connections more robust and easier to maintain. MAPI over HTTP used HTTPS, is based on the HTTP 1.1 specification, and clients use POST commands to communicate with Exchange. In effect, MAPI over HTTP makes Outlook connections behave much more like those from EWS, EAS, and OWA clients and should (hopefully) mean that Outlook is better able to cope with scenarios such as resuming from hibernation, network or adapter transitions, network failures, and the like. It might even mean that I never have to use OWA in offline mode again! It's important to understand that Outlook 2013 SP1 is the only client that can connect to Exchange via MAPI over HTTP so this transition will take a long time to become effective for many organizations. In addition to deploying supported clients, you have to make a one-time configuration change to enable MAPI over HTTP. In the meantime, RPCs will continue to flow as before and clients will remain connected. Microsoft plans to enable MAPI over HTTP for Office 365 soon (if they have not done so ny now) and new clients will begin to use MAPI over HTTP as they are deployed. No immediate plans exist for Microsoft to turn off RPC over HTTP within Office 365, but it wouldn't be a surprise if this happened in a couple of years. Stay tuned for an in-depth WindowsITPro magazine article covering the benefits and some of the downsides in this change, but in the meantime if you want to learn more, listen to this Channel 9 program about MAPI over HTTP.

OWA and OWA for Devices can now display DLP policy prompts. This is important because until SP1, Outlook 2013 was the only DLP-aware client and this represented a deployment block for companies who considered the use of DLP to protect against the disclosure of sensitive data through email.

Organizations can add custom documents to the set of DLP sensitive data types used by policies on clients (as messages are composed) or via transport rules (as messages pass through the transport pipeline). This is done by creating a document fingerprint of a sensitive data type such as a tax return form that makes it a known type for DLP checking. The set of DLP templates provided in Exchange 2013 SP1 is extended to accommodate the needs of more countries and regions. See the EHLO blog for more information on the DLP enhancements, which are now also available for Exchange Online tenants in Office 365.

Cmdlet logging is restored for Exchange Administration Center (EAC). The EMC console used by Exchange 2007 and Exchange 2010 has three ways for administrators to see what EMS commands are executed to get work done. These are invaluable in terms of exposing people to cmdlet syntax and values. Exchange 2013 SP1 allows you to enable cmdlet logging and have a separate window where cmdlets are displayed as they are executed by EAC.

Windows 2012 R2 joins the set of supported operating systems. You can now deploy Exchange 2013 SP1 on Windows 2012 R2 servers - and use Windows 2012 R2 domain controllers and global catalogs (and Windows 2012 R2 DFL/FFL). Windows 2012 R2 DC/GC support is also gained by Exchange 2010 SP3 RU5 and Exchange 2007 SP3 RU13. However, Exchange 2007 SP3 RU13 does not support Windows 2012 R2 DFL/FFL and you can't install Exchange 2010 or Exchange 2007 servers on a Windows 2012 R2 server.

Simpler DAGs. If you deploy Database Availability Groups (DAGs) on Windows 2012 R2, you now have the chance to create an "IP-less-DAG" (or, as Microsoft call then, a DAG without a Cluster Administrative Access Point).  This is the continued evolution of the DAG model where Exchange takes on increased responsibility for all aspects of DAG management. With the new mode of DAG, all management is done through Exchange and the Failover Cluster Manager, CNO, network name resource, and DNS entry for the cluster are no longer required. This simplification is welcomed and I'll be commenting on it in more detail in the near future. Remember that the requirement that all of the member servers in a DAG must run the same operating system continues, which means that if you want to deploy Windows 2012 R2, you might have to rebuild DAGs.

S/MIME support returns to OWA (for IE9 and above, but not for Chrome, Firefox, or Safari). This is functionality that was removed as part of the transition in OWA architecture to deal with multiple device display formats. With Exchange 2013 SP1, S/MIME is supported across Outlook, OWA, and Exchange ActiveSync clients. The Set-OWAVirtualDirectory cmdlet has been updated to allow S/MIME to be enabled or disabled on a server.

Firefox browsers that support the HTML5 appcache mechanism can take advantage of OWA’s offline mode.

In another example of functionality being restored, OWA includes a rich text editor that is really very usable (screen shot below). It's not quite Word, but the editor is more than acceptable when it comes to creating nice-looking memos.

The Edge transport role reappears in a new guise. Up to Exchange 2013 SP1, deployments had to use Exchange 2010 Edge servers if they wanted to use Exchange as the point of contact for inbound mail from the Internet. If only because all of its administration has to be performed through PowerShell, the Exchange 2013 version of the Edge transport role is very different to its Exchange 2007 or Exchange 2010 equivalents, so some careful testing and assessment is required before the new servers should be deployed. Some will decry the lack of a GUI and the need to manage the server with PowerShell, but the tasks to set up an Edge server are relatively straightforward and anyway, if you can't handle a few PowerShell commands, maybe you should not be setting up a server that acts as the secure inbound email access point for the organization? 

The Outlook app model is extended to accommodate “compose” apps. In other words, where you could use apps to process data as you read messages (such as extracting an address from a message and displaying it with Bing Maps), apps are now available when you compose messages (see the apps button in the screen shot of the message compose screen above).

SSL offloading is supported, meaning that the SSL encryption and decryption workload for inbound connections to Client Access Servers can be moved to a load balancer.