Why we shouldn’t care that Exchange 2016 really is Exchange 2013 SP2

The great and the good in the worlds of Exchange and SharePoint gathered together in the Signature Room on the 95^th floor of Chicago’s Hancock Building on May 3 to celebrate the coming out of Exchange 2016 and SharePoint 2016. It was a nice night, full of discussion about our favorite product, and it was a fine start to the week of Ignite.

We went away from the evening with a t-shirt with the 3 of 2013 struck out for 6 (I took the picture of the logo with the very useful Office Lens application). I guess the idea was to indicate that the products were evolving from the 2013 versions, but as Ignite progressed, the nagging feeling grew that Exchange 2016 is really just Exchange 2013 Service Pack 2 (SP2). There’s no real surprise here. It’s hard to keep on innovating when a product is twenty years old and the Exchange 2016 sessions at Ignite conveyed a strong impression that this release is all about tidying up, refining, and transferring some technology from the cloud to keep on-premises customers happy.

Consider the evidence. Tuesday’s major Exchange 2016 overview featured a demo that was painfully constructed to emphasize on-premises servers, some interesting factoids about how users search, the advent of the “Sweep” and “Undo” features for Outlook Web App (Sweep is surely a poor substitute for Clutter and CTRL/Z has been available in Outlook for a while now), lots of mentions of technology transfer from cloud to on-premises (that I really like), and some new eDiscovery capabilities from Equivio.

There’s nothing in the list for Exchange 2016 to match the thunder of PowerShell support in Exchange 2007, the arrival of true high availability through Database Availability Groups in Exchange 2010, and the automation of Managed Availability and the transition to web-based management consoles in Exchange 2013. So far, Exchange 2016 was good, clean, honest progress but nothing earth shattering will be delivered in late 2015 when the software will be available. We were surely missing something.

In fact, the most interesting thing about the overview presentation might have been the sheer number of people who showed up. If anyone at Microsoft thought that customers were not interested in on-premises software, their delusion was well and truly addressed by the size of the audience. This session attracted nearly two thousand in a very large theater; the others also had overflowing rooms.

And so we went to the Exchange 2016 architecture session. Ross Smith IV worked the crowd and kept them happy and entertained. The preferred architecture is emphasized, multi-role servers are back and the CAS is gone, protocol simplification is good, MAPI over HTTP is the default client protocol for Outlook, Windows 2016 server is supported, and I/Os continue to be reduced. MAPI/CDO is dead and replaced by Exchange Web Services or the new REST API. And you’ll need the Office WebApps server to render Office format attachments in a nice way. Hmmm… we must be overlooking something good in that list.

On to Exchange 2016 deployment to learn that it’s much simpler to deploy Exchange 2016 than previous versions. Just slot those puppies in and they work with their Exchange 2013 cousins. The transition path from Exchange 2010 to Exchange 2016 is like it is for Exchange 2013, a new Offline Address Book (OAB) is being introduced, .NET Framework 4.5.2 is needed. OK, some great detail here but we’re still getting a feeling that a certain amount of character substitution of 2016 for 2013 was also in play.

Surely there must be something to learn about in the area of virtualization? Well, Microsoft announced that they’ll be happy to support customers who want to deploy Exchange 2016 on Azure IaaS virtual machines, even if the cost-benefit equation is unproven for such deployments (see my notes on this topic from last year). Microsoft won’t support Exchange 2016 when deployed on Amazon Web Services, but I guess Amazon will as they have for both Exchange 2010 and Exchange 2013. Nice as it is to run a demo or test environment on Azure, it’s still pretty obvious that the most cost-efficient platform is well-designed physical servers, a fact reflected in the way that Microsoft eschews virtualization for its Exchange Online servers.

As we came away from Ignite, the feeling was pretty strong that Exchange 2016 really is Exchange 2013 SP2. There’s nothing wrong in this because we are, after all, just talking about arbitrary labels placed on a software release. Calling this version Exchange 2013 SP2 might make on-premises customers unhappy if they thought that Microsoft wasn’t paying attention to their needs, and calling it Exchange 2013 Premium-Super-Release would be plain silly. So we’ll be content with Exchange 2016.

And don’t get me wrong. I prefer a solid release that is stuffed full of good details like stopping content index replication traffic getting in the way of data replication in a DAG or making database failovers significantly quicker. There’s lots of value to be gained from the pursuit of excellence in detail.

Exchange 2016 might just be the first version of Exchange to be deployed en masse without obeying the “never deploy RTM code and wait for the first service pack” mantra since Exchange 5.5, some 18 years ago. Breaking that habit is a feature that any software release would be proud to claim.

Follow Tony @12Knocksinna