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

Three months after they shipped Exchange 2013 CU3, Microsoft has announced the release of Exchange 2013 SP1, or cumulative update 4 (CU4) to its friends. The announcement will no doubt come as pleasant relief to those who insist that no Microsoft server product can ever be installed until the first service pack appears. Like waiting for the first cuckoo of spring to sing before planting, such a well-worn adage is challenged in an era when the demands of the cloud mandates that on-premises customers receive quarterly updates, but some people find it hard to shift old habits. In any case, build 847.32 aka Exchange 2013 SP1 is now available for download.

To make sure that those running older versions of Exchange are not left out, Microsoft has also released Rollup Update 13 for Exchange 2007 SP3 and Rollup Update 5 for Exchange 2010 SP3.

I won't bore you with the details of how to install Exchange 2013 SP1 because the upgrade from CU3 was easy (at least for me). A schema extension is required to accommodate new objects and cmdlets and the consequent updates to RBAC roles, so be sure to include this step in your planning. The normal caveats about preparing DAG member servers by putting them into maintenance mode before starting the upgrade and shutting down all Exchange components like EMS and EAC apply. My upgrades occurred without trauma, which was a nice surprise. The sole caveat is to check that all services come back online after the upgrade as the transport services can be picky about restarting.

Looking through the set of features and updates provided in Exchange 2013 SP1, we find a mixture of finishing off important components and extending new functionality. Adding S/MIME support back for Outlook Web App (OWA) is an example of the former; providing the ability to add custom sensitive data types through document fingerprinting for Data Loss Prevention (DLP) is an example of the latter. The full list of updated functionality in SP1 is shown below. Where appropriate, the features are also available to users of Exchange Online in Office 365. In fact, the nature of the development process is that new functionality is slip-streamed into production in the cloud some weeks before it is made available to on-premises customers in an update like SP1. It is therefore quite possible that you have been able to use upgraded functionality for some time, even if you never realized it. 

My personal selection of the most interesting changes in Exchange 2013 SP1 are:

• 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 architectureto 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 ofOWA’s offline mode.
• In another example of functionality being restored, OWA includes a rich text editorthat 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.

Like any service pack, other changes exist that are less important to the general Exchange community but critical to specific groups. For example, authentication is now supported using U.S. Department of Defense smartcards. This definitely won't impact my working life, but it might for those who work with the U.S. military. No doubt many blog posts will fill in the detail of all the other changes in the coming weeks when the finer details of new cmdlets and functionality will be explored. For those who care about these details, Exchange 2013 SP1 includes 981 cmdlets whereas the RTM version has 958.

Naturally, because Exchange 2013 SP1 is also a cumulative update, it includes a large number of bug fixes in response to problems found in testing or reported by customers. For this reason and because a large amount of new functionality is present, you need to test Exchange 2013 SP1 thoroughly before introducing it into production.

I’ll be covering some of these features in detail in separate posts and articles over the next few weeks (or when I get around to it – other stuff happens that deserves immediate coverage and disrupts my writing plans). In the meantime, I am sure that the Interweb will abound with posts providing the opinion and views of those who care to comment whether Exchange 2013 SP1 is worth deploying. At first glance, it is.