Following their EHLO teaser from a few weeks back, Microsoft delivered a lot more information about what on-premises customers can expect in Exchange 2016 in roadmap and architecture sessions at Microsoft Ignite in Chicago today. The product is still tracking for a release towards the end of this calendar year and I expect to see it in October if previous release patterns are followed.
Overall, today’s news was positive for on-premises customers who might have doubted Microsoft’s commitment to their cause given the focus on their “mobile first, cloud first” strategy. Microsoft has obviously used an enormous amount of engineering resources to harvest developments that are tried and tested in Exchange Online and package then technology in a suitable form for on-premises deployment. I can’t see how this work would have been done if a strong commitment existed to upgrade on-premises customers, even if the commitment was not voiced or emphasized during the session.
When you operate at the scale of Exchange Online, you have to pay attention to detail. It is that attention to detail that allows Microsoft to manage 1.2 million database copies spread over more than 50,000 mailbox servers and attain a 99.99% SLA. Still, you can always do better and small and incremental improvements contribute significantly when scaled up to the size of Exchange Online.
Given the number of databases in operation, most of the technology transfer from Exchange Online to Exchange 2016 comes in the area of high availability and follow in the footsteps of other recent transfers such as the simplified DAG (Exchange 2013 SP1) and support for the DAG witness server (FSW) in an Azure datacenter.
Exchange 2016 database failovers are rated at 33% faster than Exchange 2013 (which is kind of important when you have 3.5 million failovers/switchovers per month), disk IOPS are reduced to a point where Exchange must now be barely sniffing at disks, and new features such as automated database repair to detect and fix divergent copies are welcome. In fact, anything that helps customers to automate operations like the cloud is appreciated, like the new Get-MailboxServerRedundancy cmdlet, which scans the members of a DAG to report which servers are in good shape. The cmdlet can be used to identify servers that are ready for upgrade too. Exchange 2016 will support BitLocker encryption to protect data at rest.
DAGs remain limited to 16 member servers, each of which can support up to 100 database copies. DAGs cannot support mixed software versions so you will have to deploy brand new Exchange 2016 DAGs and move mailboxes to the new servers. To save on the overhead of content indexing within a DAG, indexing is now done for passive copies instead of being replicated from the active. Apparently this change saves 40% of the internal transmission between member copies in a DAG.
To kill the normal rumor that emerges at this time, Ross Smith IV was happy to inform his audience at the Exchange 2016 architecture session that Exchange 2016 continues to use ESE and will not move to SQL because “SQL squeals like a pig and our storage engine is both ESE and performs like a jet engine.” No further comment is required.
I found some of the statistics cited by Karim Batthish, whose CV cited a previously unknown career as a dragon slayer, to be quite fascinating. We’ve known for quite a while that Outlook search is unreliable, basically because Windows Desktop Search was never built to deal with the kind of volumes seen in today’s mailboxes. Microsoft has measured the success of user searches within Exchange Online and discovered that across 600 million searches, many use just one word to look for an item and one in eight searches return exactly nothing.
It would be nice if users could improve their knowledge of how to conduct searches but that’s not going to happen in a month of Sundays, so Exchange 2016 will step in to fix the problem in a couple of ways. First, if you use Outlook 2016 and are online, the searches will happen on the server rather than on the client. This is sensible because it avoids the potential of overlooking items that haven’t yet been indexed on the client. It also means that consistent search results will be returned by Outlook and Outlook Web App (OWA). Speaking of OWA, it will benefit from search terms being proposed to users to help them find items – and fuzzy searches are now supported.
OWA 2016 looks good. Its design is clear and crisp and includes new functionality such as advanced attachments (meaning that you can send a link to a file stored in OneDrive or a SharePoint library – including hybrid configurations where Exchange is on-premises and the documents are in Office 365). A sweep function is borrowed from Outlook.com to help users clean up mailboxes (but do they care?), and thumbnail pictures are shown of graphic attachments to help users understand what attachments contain. All in all, OWA 2016 seems like a good place to work – as does the Windows 10 Outlook universal app, which continues to use ActiveSync to connect to Exchange.
In terms of development, Microsoft is making a big investment in REST-based APIs across Office, so Exchange 2016 will use new mail, contact, and calendar REST APIs. These APIs will eventually replace Exchange Web Services (EWS) and are already in use with Office 365, so development can start now. Unsurprisingly, the increasingly obscure MAPI/CDO API is unsupported by Exchange 2016.
Outlook 2016 will be the most functional client for Exchange 2016, but recent versions of Outlook 2010 and Outlook 2013 will be supported too (the exact detail is still to be determined). MAPI over HTTP becomes the default connectivity protocol for Outlook and will be configurable on a per-user basis.
The roadmap presentation discussed some cloud connection scenarios where on-premises customers can gain benefit by using cloud services in tandem with Exchange 2016. Some of these are familiar, like Exchange Online Archiving, Exchange Online Protection and the new Advanced Threat Protection service. Some are new, like an advanced eDiscovery service powered by the technology acquired with Equivio last January.
On the deployment front, Microsoft is emphasizing standardization heavily. All Exchange 2016 servers will be multi-role (the CAS is no more) and the preferred architecture is deemed to be the right way to deploy Exchange, a point heavily stressed by Ross Smith IV. Co-existence is also simplified as you can introduce an Exchange 2016 server into an existing organization and client connections will flow to the new server without the need to make any namespace changes.
Messaging architects might not like being told by Microsoft how to plan their deployments, but it makes a lot of sense to base plans on the firm foundation of an endorsed and supported architecture and only deviate from that approach when a firm and obvious business or technology need exists. It’s also true that reducing the number of server roles to just one (not counting the Edge transport role) and supported operating systems to Windows 2012 R2 or Windows 10 removes some of the levers that architects have had to cope with in the past. In mixed organizations, Exchange 2016 will only co-exist alongside servers running Exchange 2010 SP3 RU11 and Exchange 2013 CU10 (or later releases). Of course, we haven't seen Exchange 2013 CU9 yet, but it is coming and so is CU10.
Those who hate standardization might reflect on the lesson from the cloud that smooth, reliable, and predictable operations are much more feasible when hardware, software, and processes and procedures are standardized. That’s one good reason to use the preferred architecture.
All in all, I liked what I heard about Exchange 2016. But I was disappointed that Microsoft failed to use the opportunity to clearly and firmly state their commitment to on-premises servers. That would have been good to hear.
Follow Tony @12Knocksinna
