Microsoft released Service Pack 1 -- also known as Cumulative Update 4 -- for Exchange Server 2013 in February...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
of this year. Admins anticipated this update, as the Service Pack 1 era typically precludes the start of many migration projects. It's time to take a closer look at what's new in Exchange 2013 SP1 and what you can expect from its features.
MAPI/HTTP will replace RPC/HTTP
Microsoft introduced a new connection model for Outlook clients as an alternative to RPC-over-HTTP, which Exchange 2013 used until now. This new model, named MAPI/HTTP, changes how data is transmitted to and from Exchange. In essence, Outlook Anywhere and MAPI/HTTP both use Messaging Application Program Interface (MAPI).
The only exception is that Outlook Anywhere MAPI is encapsulated in remote procedure call (RPC) packets prior to shipping them over TCP to Exchange. This encapsulation creates a certain overhead, but it's important to remember that RPC is an old technology. According to Microsoft, by removing RPC in server and client communication, complexity and other issues are greatly reduced. Connections should also be created more quickly than before.
Even though MAPI/HTTP looks promising, I don't expect it to be widely deployed anytime soon. Outlook 2013 SP1 clients are the only ones to support it, and it's disabled by default. More importantly, Microsoft has provided little to no guidance on the effect it could have on the network, so I wouldn't feel comfortable deploying it right away. As with many new technologies, I have no doubt the details about MAPI/HTTP will be unraveled over time. Until then, I'll closely watch support forums to see how others experience it.
Support for Windows Server 2012 R2 is included
Even though Windows Server 2012 R2 has been available for a while, official support for Exchange 2013 only came with Service Pack 1. This means you can run Exchange 2013 SP1 on a server with Windows Server 2012 R2, and use the OS on your domain controllers.
Using Windows Server 2012 R2 as the underlying operating system for Exchange allows you to benefit from the OS' improvements. More specifically, the failover clustering features have once more been enhanced and allow you to leverage new features, such as clusters without an administrative access point or dynamic File Share Witness.
If you want a more technical background, I suggest reading this article.
Exchange Administration Center command logging returns
The Exchange 2010 Management Console had a great feature that let you see what PowerShell cmdlets Exchange executed in the backend; many admins were upset this feature didn't make it to Exchange 2013. Perhaps it was passed over because the Management Console was ditched in favor of the fully Web-based Exchange Admin Center.
The Command Logging feature is back in Exchange 2013 SP1 (Figure 1). From the EAC options menu, you can launch the Command Logging window and view the currently running cmdlets. But the feature can still use some improvement. Commands are shown using mailbox globally unique identifiers instead of display names or aliases, which makes identifying what command was executed against which mailbox a little harder.
Edge Transport also returns
Bringing back features is a main theme for Exchange 2013 SP1. The Edge Transport role, although not frequently used, also found its way back into the product. Many admins might not care because of the product's limited use, but Edge Transport has significant value in hybrid deployments. Additionally, the directory integration allows you to easily do directory-based Edge blocking, a feature sometimes also referred to as LDAP-filtering in similar third-party options.
But this isn't all good news. PowerShell adepts among us won't have much trouble managing the renewed Edge Transport roles, but anyone looking for a graphical user interface (GUI) might be disappointed since it currently doesn't exist. Even though there's only limited configuration involved, I liked the GUI because it was easier to work with -- especially since you didn't have to do much with the Edge Transport in the past.
S/MIME for OWA makes a comeback
Like the command logging feature, S/MIME for Outlook Web App (OWA) came back after it disappeared in the RTM release of Exchange 2013.
DLP gets a boost
Exchange 2013 first introduced the data loss prevention (DLP) feature, which allows you to detect when sensitive information is being sent, and then takes appropriate, preconfigured actions. As with many features, the initial DLP implementation was good, but lacked some functionality; plus, the behavior wasn't consistent across Outlook and OWA. Now, OWA also shows policy tips so the gap between both clients is closing.
As an extension to the DLP feature, you can create document "fingerprints" to help you craft policies that detect specific data. Before this, adding data types -- which you could see as regular expressions to detect content -- was a tedious and time-consuming process. This feature saves you time as you upload a document to be used as a fingerprint against the data passing through Exchange.
Support for SSL offloading
I'm not a big fan of Secure Sockets Layer (SSL) offloading -- mainly because it requires additional configuration on the Exchange side and introduces additional complexity. SSL offloading is the process in which you configure a load balancer to decrypt SSL traffic, but not to encrypt it when sending traffic to Exchange. There are definitely times when SSL offloading has it merits, for instance, to decrypt and then re-encrypt traffic when your load balancer can't handle the load.
A major issue overshadows the release
Unfortunately, a nasty bug has overshadowed the Exchange 2013 SP1 release. Shortly after its release, admins reported that the Transport Services wouldn't start; this would be the case when a third-party transport agent was implemented.
In the following days, Microsoft released a KB article with a workaround for the issue, so take this into consideration when deploying SP 1. After all, what good is an Exchange Server if it can't route email?
About the author:
Michael Van Horenbeeck is a technology consultant, Microsoft Certified Trainer and Exchange MVP from Belgium, mainly working with Exchange Server, Office 365, Active Directory and a bit of Lync. He has been active in the industry for 12 years and is a frequent blogger, a member of the Belgian Unified Communications User Group Pro-Exchange and a regular contributor to The UC Architects podcast.