Exchange Server 2013 SP1: What's New

In some circles, it has long been an article of faith that a new Microsoft OS or server product should be treated cautiously until the release of the first service pack. Fair or not, this perception has resulted in many customers waiting for service pack releases before beginning a broad deployment of new versions, thereby slowing the deployment of new products. On February 25, 2014, Microsoft released SP1 for Exchange Server 2013. It includes new features, improvements to existing features, and bug fixes for flaws not addressed in previous cumulative updates. In addition to these product changes, SP1 serves as a barometer of how well Microsoft's new servicing model for Exchange is working. Early indications are positive—but will SP1's new features, improvements, and bug fixes be enough to convince you to deploy Exchange 2013? Let's take a look.

SP1 and the Servicing Model

In February 2013, Microsoft announced that it was changing the way it releases Exchange updates. In its blog entry "Servicing Exchange 2013," the Exchange Team stated that the new servicing model would be a predictable schedule of quarterly releases known as cumulative updates. Each cumulative update would include all fixes and patches released since the release to manufacturing (RTM) version. That way, installing the latest cumulative update would bring any previous release of Exchange 2013 up-to-date. The Exchange Team also stated that cumulative updates might contain new features, including features that require Active Directory (AD) or Exchange database schema updates.

This servicing model has had its ups and downs. Although many administrators appreciate the predictability of a quarterly release cadence, others find that quarterly updates arrive faster than their organizational processes allow them to test and deploy updates. Including new features in cumulative updates further complicates deployment, because many organizations have change control policies that govern when new features can be introduced into an existing environment. These challenges notwithstanding, the Exchange world seems to have accepted the quarterly release model and adapted to it, at least for the most part.

You might consider that SP1 is really CU4. After all, SP1 is the fourth major update released for Exchange 2013, and as with previous service packs, it includes all fixes and patches released since RTM, so it's clearly a cumulative update. In fact, the next release planned after SP1 will be labeled as CU5, so that raises the reasonable question of why Microsoft named this release as a service pack. It certainly might have to do with the waiting-for-SP1 issue I mentioned previously.

Software quality has been a separate and troublesome issue for the cumulative update system. On multiple occasions over the past year, Microsoft has had to either delay or remove and re-release updates for Exchange 2013 because of quality problems. For example, in what must have been a major embarrassment for the product team, a week after SP1 was released, Microsoft had to release a fix for SP1 to enable third-party SMTP transport agents to work properly. The released SP1 code contained a typo in a configuration file that prevented the extensions from working. (For more information about the problem and fix, see the Microsoft Support article "Third-party transport agents cannot be loaded correctly in Exchange Server 2013.")

However, it's unfair to suggest that quality is being sacrificed to meet the quarterly release schedule. In addition, because the same code is now being used for Office 365 and on-premises installations, Microsoft has arguably suffered just as much as other customers when a flaw makes it through the release testing process. CU3 has generally been regarded as a good-quality release, and Microsoft has proven that it would rather delay the release of an update to make sure it's solid than release it on schedule but with known problems. SP1 has been functionally very stable in my testing. Even the post-release problem with the transport agents was more of a minor annoyance than anything else, and it was easily fixed. When deployed at customer sites, the functional stability of SP1 should go a long way toward reinforcing Microsoft's message that it places an extremely high value on the quality of its releases.

SP1 Installation

When you download SP1, you'll notice that it's large—about the same size as a fresh install of Exchange 2013 RTM. That's because you can use SP1 to perform an in-place update of any previous version of Exchange 2013 or a clean install on a new server. The installation process is functionally identical in either case—and it's the same as the installation process for RTM: The installer offers to download the needed prerequisites as part of its lengthy pre-install check, then performs the installation, which can take anywhere from 45 to 120 minutes.

Before you install SP1, you need to keep in mind that the installation will wipe out any customizations you've made to configuration files on your servers. For example, if you customized web.config so that your Outlook Web App (OWA) users have access to the integrated Microsoft Lync client, installing SP1 will overwrite your customizations. Make sure you back up these files (typically, web.config and EdgeTransport.exe.config) before performing the installation.

When you install SP1 on a server that contains mailboxes, those mailboxes won't be available during the time that the installation is running. Although it's not strictly required, it's a good idea to put database availability group (DAG) member servers into maintenance mode before beginning the update. You can do this yourself, but an easier route is to use scripts such as those developed by Michael van Horenbeeck.

Because SP1 includes changes to the database schema, installing SP1 will run the Update-DatabaseSchema cmdlet to update the databases in each DAG but not until all the servers in the DAG have been updated to SP1. The update process checks three parameters of each database: MinimumSupportedDatabaseSchemaVersion, MaximumSupportedDatabaseSchemaVersion, and RequestedDatabaseSchemaVersion. Installing a cumulative update or service pack can update MaximumSupportedDatabaseSchemaVersion (if that cumulative update or service pack includes a schema update) and RequestedDatabaseSchemaVersion. If the value of RequestedDatabaseSchemaVersion is larger than the value of CurrentSchemaVersion, the database should be updated the next time it's mounted if all the member servers in the DAG have the correct version of code. For more details about how this works in practice, see the Exchange Team Blog entry "Exchange 2013 database schema updates."

There are no hard-and-fast rules controlling which servers to update first. The emerging best practice seems to be to first update any dedicated Client Access servers (if you have any), including hybrid servers used for communications with Office 365, then update your DAGs, either in parallel or one at a time.

One oddity noted during the beta testing of SP1 is that under some conditions, the Exchange transport services won't restart properly after the service pack installs. You can manually restart the transport services yourself. However, there's another solution: Although Exchange service packs don't require that you reboot servers after updating them, it's generally a good idea to do so—and it frees you from having to manually restart the services.

The Invisible Groundwork

As with any service pack, SP1 concentrates on fixing existing bugs. Microsoft doesn't always release a complete list of all the fixes included in cumulative updates for Exchange, but with the SP1 release, it did in the Microsoft Support article "Description of Exchange Server 2013 Service Pack 1." The list makes for interesting reading, although most administrators won't run into more than a few of the listed items. If you aren't having a problem with a bug, the fix for it might as well be invisible to you.

There are two other categories of "invisible" changes included in SP1, and they both relate to changes made to support Office 365. Microsoft has been very public with its plans to put new Exchange features into Office 365 first, so some SP1 changes are related to features that aren't yet announced or enabled. For example, in January 2014, the Office 365 team announced that a new feature for OWA known as People View would be rolled out "in the next several months." The code for People View is obviously part of the OWA code base, so it's reasonable to assume that the code was included in SP1, even if the feature isn't available for on-premises Exchange servers yet. The other category of invisible SP1 changes relates to feature changes or bug fixes that pertain only to Office 365 operations and interoperability. Because Microsoft is running Office 365, administrators won't see these changes exposed directly.

New Features in SP1

SP1 strikes a balance between features that will be of interest to administrators and those that will be of interest to end users. Some features could've easily been predicted (such as support for Windows Server 2012 R2), whereas other features are surprising.

One surprise is the introduction of a new feature code-named Alchemy, properly known as MAPI over HTTP. Notice that "RPC" isn't included in that name. When MAPI over HTTP is enabled, Outlook 2013 SP1 and later clients can connect to Exchange 2013 SP1 (and Office 365) servers using pure HTTP Secure (HTTPS), into which Messaging API (MAPI) is tunneled. Unlike remote procedure calls (RPCs), HTTPS works reliably over both flaky and mobile networks, as demonstrated by the solid performance of Exchange ActiveSync (EAS) and Exchange Web Services. Reconnection is faster, too. In addition, doing away with RPCs dramatically simplifies troubleshooting. There's no requirement to tunnel RPC traffic, which means that you don't need any workarounds to get RPC traffic through various kinds of firewall devices.

Outlook 2013 SP1 and later will send a new header in their Autodiscover requests. If the server supports MAPI over HTTP and it's enabled, the Autodiscover manifest will include a URL to the new emsmdb virtual directory and prompt the user to restart Outlook. After the restart, the user's Outlook profile will be updated to use that virtual directory as an endpoint.

On the negative side, Microsoft has stated that MAPI over HTTP uses more bandwidth in exchange for its improved performance, but it hasn't said how much more bandwidth or how much performance improvement you get in return. It remains to be seen how this feature will impact live deployments.

To take advantage of MAPI over HTTP, you need to enable it for your organization using the Set-OrganizationConfig cmdlet. It can't be enabled on individual servers. Perhaps worst of all, after you enable the feature, connected Outlook users will receive the dreaded dialog box that tells them to restart Outlook because the Exchange administrator has made a configuration change—a surefire generator of support calls and user discontent. For these reasons, I expect the adoption of MAPI over HTTP to be fairly slow until there's more real-world data about how it performs. If you decide to enable it, be sure to read the release notes, which point out a potential performance problem (and the required fix) for servers that were upgraded to SP1 from a previous cumulative update. (For much more information about MAPI over HTTP, see Tony Redmond's article "Exchange Server 2013 Transitions from RPC to HTTP.")

There are several other new features in SP1 that will appeal mostly to organizations that are using particular specialized features in Exchange:

SP1 also has some new features for end users, the majority of which are actually in OWA:

Figure 1: New Rich-Text Editor in OWA

It's possible that there are other embedded features (such as People View, which I mentioned previously) in SP1 that Microsoft hasn't announced or enabled yet. We'll have to wait and see.

Two Features That Are Back

Some time ago, Microsoft announced that the Edge Transport role would be returning to Exchange 2013, and sure enough, it shipped as part of SP1. The Exchange 2013 version offers the same feature set as the Exchange 2010 version, but it's been updated to work with the Exchange 2013 transport engine.

Relatively few customers have deployed the Edge Transport role to date in Exchange 2010 environments. The reason is simple: There are many excellent anti-spam and anti-malware servers and services (including Microsoft's Exchange Online Protection) and the Edge Transport role doesn't offer anything particularly compelling to entice customers away from other solutions. However, with the advent of Office 365, it does have one extremely attractive feature: You can put an Edge Transport server in between your on-premises Exchange 2013 or Exchange 2010 servers and Office 365. Microsoft doesn't support the use of third-party message hygiene or relay servers between on-premises and cloud servers in hybrid Exchange deployments, but you can put an Edge Transport server in between on-premises servers and the cloud and use its transport, filtering, scanning, and routing features on inbound and outbound mail. This is a big deal to organizations that need mail filtering and processing in the perimeter network. Now that there's a 2013 Edge Transport role, you can expect to see it appear in enterprise hybrid tenants without delay.

Another feature that has returned thanks to SP1 is Exchange Management Shell (EMS) command logging in EAC. The log provides an easy way to see what EMS commands run when you take specific actions in EAC, making it valuable both as an audit trail and a learning aid. For example, the log in Figure 2 shows that several Get cmdlets were run, along with some explicit cmdlets triggered as the result of administrator actions in EAC. By default, the log contains the last 500 commands executed and is updated as long as EAC is open. Closing an EAC session removes the log contents.

Figure 2: EMS Command Logging Returns in EAC

Enhancements to Existing Features

There are relatively few enhancements to existing features in SP1, but the enhancements made to the Data Loss Protection (DLP) feature and to DAGs are worthy of mention.

DLP. The DLP engine has been enhanced with new DLP rule sets for additional regions and countries. In addition, you can now upload a document template (such as an order form or health record form) and use it as a "fingerprint" that the DLP system can use to recognize potential leaks of sensitive information.

Another DLP enhancement is that OWA can now display Policy Tips driven by the DLP features in Exchange 2013. This brings OWA to parity with Outlook 2013, which means that users who can't or don't want to use Outlook 2013 can still get DLP notifications. Because the OWA for Devices applications render content using the server-side OWA engine, those clients can also display Policy Tips. (For more information about DLP, see Tony Redmond's article "Exchange Server 2013 Data Loss Prevention.")

DAGs. You can now create a DAG that doesn't have an IP address, cluster name, or network name associated with it. This probably won't be a popular option for a while because you can't change an existing DAG into a nameless one (or vice versa). In addition, you can create such a DAG only when all the member servers are running Server 2012 R2. Removing the administrative access point from DAGs in this manner means you no longer need to pre-stage IP addresses or cluster name objects (CNOs), and you don't have to care about which specific subnet a given server is in if your DAG spans multiple subnets. In addition, now that there's no dependency on a CNO, damage to or removal of the CNO can't affect the cluster or the DAG on which it depends.

Another enhancement is that DAGs can now take advantage of the dynamic witness and dynamic quorum features of Server 2012 R2, as explained in some detail by Microsoft's Scott Schnoll in his blog "Windows Server 2012 R2 and Database Availability Groups." Because Server 2012 R2 enables dynamic quorum and dynamic witness by default on newly created Windows Failover Cluster objects, creating a new DAG on Server 2012 R2 servers will result in Exchange using these features automatically. Exchange 2013 SP1 will also take advantage of the new method that Server 2012 R2 uses for detecting when a cluster is hung and needs to be restarted.

The other DAG-related change worth noting is the emergence of a new method for deciding when to truncate transaction logs. Known as loose truncation, this method is designed to handle the case where one copy of a database in a DAG goes offline. In Exchange 2013 and Exchange 2010, the active copy of a database isn't allowed to truncate its transaction logs if one or more passive copies of the database are suspended. All the passive copies will continue to accumulate logs, as long as there's an active copy. Therefore, having a passive copy that's offline for an extended time can cause disk space shortages. With loose truncation enabled (it's off by default), you can change this behavior to something closer to the way that circular logging works in earlier versions of Exchange. Each copy manages its own set of logs, truncating as necessary when space runs low, but still respecting the loose truncation settings that govern the minimum number of logs to keep. TechNet provides a good explanation of loose truncation in "Managing Mailbox Database Copies."

A Solid Release

One of the big advantages of the new servicing model is that software updates can be tested in Office 365 before being released for on-premises customers. Before its official release, SP1 had already been running on Office 365 for quite some time. In addition, the SP1 pre-release code was put into production at several large enterprise customers participating in a beta-testing program (i.e., the Technology Adoption Program, or TAP). The early signs from these programs are quite promising, which is great news given the number of customers who routinely wait for SP1 before deploying any new release. In addition, the ability to run on Server 2012 R2, the new DLP capabilities, and the presence of the Edge Transport role will all help unblock deployments for certain customers. Overall, SP1 is a solid feature release and, if its quality proves out, should noticeably help accelerate the rate of Exchange 2013 deployment.