Many IT departments still like to stick to the adage that a Microsoft product is not complete until Service Pack 1 comes out. While I do not necessarily agree with that, I do have to admit that in the case of Exchange 2013 Service Pack 1 does put back a number of features that were in previous versions of Exchange but did not make it into the release version of Exchange 2013. Exchange 2013 SP1 brings back the following features that were available in Exchange 2010 but not in Exchange 2013 at release; Edge Transport Role, GUI cmdlet logging, and SSL offloading.
In addition to bringing back some features that were left out of the RTM version of Exchange 2013, Service Pack 1 introduces a number of new features and functionality that are completely new to Exchange. Features like MapiHttp, DLP finger printing, loose truncation, and IP-less DAGs are all new to Exchange with this Service Pack.
Exchange 2013 SP1 has just hit the streets, let’s take a look at the new features SP1 brings to Exchange 2013.
Server 2012 R2 support
Exchange 2013 SP1 will introduce support for Exchange running on Server 2012 R2. Server 2012 R2 brings a new of platform improvements that will allow for improvements in Exchange.
Edge transport role
Exchange 2013 SP1 brings back the edge transport role. The edge transport role in Exchange 2013 is pretty much the same as the edge transport role in Exchange 2010.
One of the major features of Exchange 2013 SP1 is codenamed “Alchemy”. “Alchemy” is Microsoft’s codename for the new MapiHttp communications mechanism in Exchange 2013 SP1. Before we can get into Alchemy, we first need to do a quick refresher on Microsoft Remote Procedure Call (RPC).
RPC is a decades old communications mechanism (not protocol) used by Exchange. RPC uses other transport protocols, like TCP, to establish communications channels between the client and the server. Once the communication channel is established, the client and server both use that same transport protocol to send RPCs to each other. For a more complete explanation of RPC, see THIS article on TechNet.
For comparison’s sake, I have listed the two communication paths below.
RPC over HTTP
Application > Client Stub > Client Runtime Library > Client Transport > Server Transport > Server Runtime > Server Stub > Application
Outlook > HTTPS > HTTPS > Exchange
So the biggest benefit of Alchemy is simplicity. If there is one lesson I have learned in the last twenty years it’s that complexity is the enemy of availability.
However, all this does not mean that as soon as you install SP1 to your Exchange 2013 servers you’re going to see improved server function and reliability. The new MapiHttp communication only works between Exchange 2013 SP1 and Outlook 2013 SP1. That means all the RPC components still need to exist on your Exchange servers until Outlook 2013 SP1 is the oldest supported client that connects to your Exchange servers, unless Microsoft adds MapiHttp support to Outlook 2010 in a future update. While it is expected that MapiHttp will reduce the workload on Exchange 2013 servers, thus allowing more and/or larger mailboxes on the same hardware, Microsoft does not currently have any data to support that.
All-in-all I think MapiHttp will turn out to be a positive change for Exchange, but I personally don’t plan on rushing out and turning it on for all my customers. It’ll still be there in a few months, why not wait a while before flipping that switch?
Should you want to turn on MapiHttp, below are instructions on how to accomplish that task.
The process to turn on MapiHttp is pretty simple. There is just one command to run after you upgrade all your Exchange 2013 server to SP1.
Set-OrginizationConfig –MapiHttpEnable $true
You can check is MapiHttp is turned on in your organization with this command
Get-OrgnizationConfig | FL *mapi*
Running the command to turn on MapiHttp can take up to 3 hours to fully take effect in your organization, and of course you Outlook clients need to be Outlook 2013 SP1 to use MapiHttp. Once MapiHttp is fully running in your environment, your Outlook 2013 SP1 clients will discover it through AutoDiscover.
EAC Cmdlet logging
The biggest downside to the new EAC in Exchange 2013 was that it did not support cmdlet logging at release. Exchange 2007 and 2010 both provided a way for administrators to see what PowerShell commands are running in the background for the operations they performed in the GUI. Cmdlet logging in Exchange 2013 SP1 brings this capability back, though not as completely as it existed in Exchange 2010.
Cmdlet logging in Exchange 2013 SP1 does not give you the opportunity to see what PowerShell commands are being run before you commit them, like in Exchange 2010. It does give you a single place to go to see a history of the recently run PowerShell commands from your current EAC session.
DLP Fingerprinting is a feature of Exchange 2013 SP1 DLP that allows for administrators to “scan” a form into Exchange that will allow DLP to identify that form in mail transport and policy based actions on it. For example, a DLP fingerprint policy can be setup for blank tax forms. Once configured that policy would allow Exchange to identify those forms with data filled in and then take whatever action is deemed appropriate.
An example use for DLP fingerprinting would be tax forms. With DLP fingerprinting you can “scan” a tax form, say the IRS form 1040 EZ, into Exchange and then setup a rule that will stop any email messages with attached 1040 EZs from leaving your company Exchange servers.
Loose truncation give Exchange administrators a third option between turning on or off circular logging. Loose truncation will allow administrators to set a maximum amount of drive space that transaction logs can take up before they are truncated into the database.
Loose truncation will not have a lot of utility until backup vendors have a chance to release products that support this configuration.
Exchange 2013 SP1 running on Server 2012 R2 introduces the ability to create and run Database Avaibility groups without assigning an IP address or Cluster Name Object to the DAG itself. When setting up and IP-less DAG, an administrator will use 255.255.255.255 as the IP address for the DAG. This features simplifies DAG configurations, and any opportunity to simplify your Exchange deployment will pay dividends in availability.
Removing the need for an IP address may not seem like a big improvement for a DAG that is built in a single site. The real benefit for IP-less DAGs will be in DAGs that are deployed across multiple sites. Before Exchange 2013 SP1 a DAG would require an IP address to be assigned to the cluster object in each subnet that has a DAG member. That could mean as many as 16 IP addresses would need to be assigned to the DAG itself. That kind of complexity can cause confusion with administrators, especially in an outage situation.
DLP Policy tips in OWA
Exchange 2013 SP1 adds support for DLP policy tips in OWA. This means that users who are sending email from OWA will still see the same policy tips for protected contented that they would see from their supported Outlook clients.
Exchange 2013 SP1 brings back support for SSL offloading.
By enabling SSL offloading, you move the workload of encryption and decryption off your Exchange servers and on to your hardware load balancers. Additionally, handling the encryption at the hardware load balancer allows more advanced load balancing features to be used.