Before jumping right into all the new features in Microsoft Exchange 2013 SP1, I’d like to point out that the Microsoft service packs of today are different from service packs from the days of old. The reason for this is the new cumulative update (CU) approach that Microsoft is using with solutions like Exchange to enable faster and more consistent updates than previous product releases. While it’s impossible to keep up with cloud-based fixes (these go live at will and take affect globally), the idea is that on-premise Exchange doesn’t have to wait for annual updates but can receive them faster (quarterly) with CUs.
That being said, Service Pack 1 for Exchange 2013 is actually CU 4 (at the same time!). Three previous CUs have been released to provide fixes and tweaks. What makes SP1 so unique in the line-up (and distinct from the previous CUs or upcoming CU5) is that it contains some solid features that indicate a bit of a step up for Exchange 2013 that warrants the SP distinction.
Now that you grasp the new method to Microsoft’s madness with CU updates, let’s dive into the key features we see with Exchange 2013 SP1.
Microsoft Exchange 2013 SP1: New Features and Improvements
Windows Server 2012 R2 Support
There is often a disconnect between the latest flavor of Exchange and the very next flavor of Windows Server. It happen and can be confusing for the IT admin doing the install, but Exchange 2013 RTM didn’t play nice with Server 2012 R2 until the release of SP1. So that means you can install Exchange 2013 SP1 on everything from Server 2008 R2 SP1 and Server 2012 to Server 2012 R2. From an AD perspective you can have servers running everything from Server 2003 SP3 AD through Server 2012 R2 and the domain/forest functional levels can go from Windows Server 2003 domain/forest functional levels through to Server 2012 R2 domain/forest functional levels.
Show Command Logging
One of the cool features with previous Exchange versions that use PowerShell is that you can see the PowerShell commands being used behind the scenes when you run GUI-based administration. But Exchange 2013 RTM not only switches to a new Exchange Admin Center (a web-based console) but it also yanks the PowerShell cheat sheet out from under us. SP1 brings this back with an option called Show Command Logging, that allows you to review the recent commands executed in the EAC (up to 500 commands). That’s good news for folks who don’t stay up late memorizing PowerShell cmdlets. It’s easily accessible by selecting the Help icon and then selecting Show Command Logging (as shown below in Figure 1). Note: You won’t see commands until you open this window first and then begin working in the EAC.
Edge Transport Role Update
With the release of Exchange 2013 we were told to keep using the Edge Transport role from Exchange 2010 on our perimeter networks. My response to that was “Not a problem, I didn’t use an Edge in the first place.” But apparently it was a big deal for some; after being constantly asked for an update like kids in the car pestering their parents – “are we there yet?”– Exchange finally granted us an update with SP1. But herein lies the rub: It’s all configured through PowerShell and the Exchange Management Shell (EMS). For something that is typically a set-and-forget server, it might be a bit intimidating to break out the PowerShell Guidebook, but don’t stress too much. Many in the community are in the same boat, including MVP Prabhat Nigam, who put together a nice step-by-step walkthrough for folks. Once the synchronization is complete you will be able to see the Edge Transport through your Servers feature in the EAC.
MAPI Over HTTP
This is an interesting one because it takes a bit of time to explain, but I’ll try and do it justice in a few sentences. First off, this is an optional client communication method and it requires Outlook 2013 SP1 to work. The goal through this new option is to provide an improved connection experience over the current RPC over HTTP, especially with regard to greater stability and reliability of Outlook/Exchange connections. It’s disabled by default. Learn more about MAPI over HTTP through TechNet.
It’s okay if you aren’t aware what DLP is because it was just released with Exchange 2013. Data Loss Prevention (DLP) is an enhances our ability in Exchange through transport rules to control, protect, and secure our mail environment. Sometimes we are protecting it from outside forces. At times we need to protect people from themselves, such as in the case of users sending out emails with sensitive data (e.g. credit card information, social security numbers, banking information, and so forth). DLP can warn users with policy tips or prevent mail from going out, depending on company policy. SP1 adds some nice new features to DLP including policy tips in OWA, new DLP-sensitive information types for new regions, and DLP Document Fingerprinting (shown below). This last one is a neat new feature that I didn’t see demonstrated until the Microsoft Exchange Conference (MEC). Essentially, you can use a document as your template and then DLP will look to see if that document is being sent and take action on it.
We can discuss the many more little tweaks and such for a long time: ADFS for OWA (supports claims-based authentication), SSL Offloading (terminates load balancer connections), DAGs without Cluster Administrative Access Points (thanks to Server 2012 R2 cluster features), an enhanced text editor for OWA, S/MIME for OWA, and a few other new features.
Truth be told, none of these are features that really wow me. But that isn’t what a Service Pack should be anyway. We’ve grown so accustomed to SPs being better than the original release of a solution, but that isn’t the case here. Yes, there are some solid new features, and it’s nice to be brought more in line with the Exchange Online version through Office 365, but I think the CU approach is a better mindset. No need to wait for a SP to get new features – let’s just get them with each quarterly CU if they are ready for on-premise environments. Nevertheless, we’re still working with people’s entrenched mindsets; so yes, we have a service pack for Exchange 2013, and now you know what it brings to the table. If you are reading this and you’re an Office 365 shop, you’ll find many of these features are already included in your portals (although the OS support and the Edge information won’t apply to you).
Hats off to the Exchange Team for developing cloud-first but not cloud-only (as they’ve promised). I’m looking forward to CU5 and further, as well as Exchange 2015. One day on-premise Exchange may be no more, but until that time I’m going to enjoy this journey and revel in installing each new version – because you never know when it may be the last.
Tagged with Exchange 2013 SP1