A few days ago, Microsoft released the public preview of Exchange 2016 to the world. For many messaging professionals, this is usually an exciting time. But is it really? I remember when Exchange 2007 'hit the market.' I spent quite a few long days and nights discovering the new features and dramatically changed architecture. Pretty much the same happened when Microsoft unleashed Exchange 2010. The newly minted Database Availability Group kept many people – including myself – fascinated and busy for a long time. One of my fondest memories about that time was a hefty, yet in hindsight very funny, discussion that followed a technical presentation at my former employer.
Anyway, I'm dwelling here... When Exchange 2013 came along, I didn't feel as excited as before. Maybe it was because I was lucky enough to have been on the TAP program and had deployed Exchange 2013 before it RTM'ed. Or maybe it was because early versions of Exchange 2013 did not live up to expectations from both a feature and quality level. Who's to say?
As Exchange 2013 matured, the excitement gradually came back. Although there have been some glitches along the road (think about SP1 and a certain transport-related bug!), it's been one of the better Exchange versions that ever hit the market. The geek in me still loves the deeply technical aspects of the Database Availability Group, the architectural components and the (sometimes challenging) interoperability with legacy Exchange versions. The question is whether that is what you should be excited about. If you would have asked me a few years ago, I would undoubtedly have said yes. However, today, the playing field is different. Exchange is a very mature product. It's been around for a long time, and the Exchange team has always been at the forefront of innovation. Take a look at how the principle of the Database Availability Group is now also used in other products, or just ask some people on the PG how Active Directory came to life…. ;-)
In a way, Exchange Online is also a true member of the Exchange (Server) family. I deliberately put the word server in parentheses because the aspect of a server becomes less and less important. As a result, I'm personally inclined to be less and less excited about it, too. Maybe that is because I've been 'with my head in the clouds’ for a while now? I don't think so. When you take a look at what Exchange 2016 has to offer from a functionality point of view, one you can but be excited about what (new) capabilities it will bring for your end users. That is what’s worth getting excited about. There are many underlying improvements to the architecture and HA features, too. But in the end, those features just contribute to the end user experience, which is key.
If you are not looking to move to Office 365 and will still be deploying Exchange 2016 on-premises, your inner geek will definitely be satisfied. Although Exchange 2016 isn't dramatically different from Exchange 2013 (just take a look at the build number, which is 15.1 and not 16!), there's enough to keep an eye out for from a technical perspective. For instance, we find ourselves again with a single server role: the mailbox server. So no more CAS and no more discussions on whether to deploy single-role or multi-role servers. That's a topic that has been beaten to death already!
One thing I do want to point out is the interoperability with legacy versions – more specifically, with Exchange 2013. Next to a new hybrid configuration wizard experience, which I hope to see in the final version of Exchange 2016, the change I love the most is the easy upgrade path from Exchange 2013. As demonstrated at Ignite, Exchange 2016 servers can coexist with Exchange 2013 servers in the same ‘Client Access’ array. I'm not referring to the CAS Array object – which was removed in 2013 – but rather the load-balanced array of servers. Up until Exchange 2016, you always had to make sure that client traffic was received by the highest Exchange server versions first. For example, in an Exchange 2010/2013 coexistence, all client traffic had to flow through Exchange 2013 first because Exchange 2010 did not have the required logic to route traffic to Exchange 2013. The same is true for 2013/2007 or 2010/2007, etc.
Now, Exchange 2013 (with CU9 or later) can also route traffic to Exchange 2016. This means you can gradually introduce new Exchange 2016 servers into the environment and no longer need to do a cutover from a client connectivity point of view. If you are still running Exchange Server 2010, you won't be able to benefit from this enhancement, though. The good news is when the next version of Exchange Server hits the market, this problem will likely resolve itself for good (assuming there will be another version and that it will not support Exchange 2010. That is, of course, to be expected, given the history of Exchange release so far. As far as I can remember, a new version has always supported up to n-2)!
Anyway, I think I've rambled enough. Let's take a look at some of the improvements Microsoft built into Exchange 2016, shall we?
- Search Improvements
Search has been somewhat of a troubled subject in Exchange, especially from an end user perspective. I hear a lot of people complain about slow searches, but even more so about the inconsistency of searches when using different clients. Much of this can be attributed to the fact that a local Outlook client will first use the Windows-based search and local-index to return results. Only when a user clicks ‘get more results…,’ which almost never happens, is the server-side index used. As of Outlook 2016, this behavior will change. Outlook 2016 will, when connected to Exchange, use the server-side search first. The result will be a faster and more reliable search than before.
How is it faster you may wonder? For a more in-depth explanation, take a look at this session from Ignite in which Karim Batthish talks about the various improvements to the search infrastructure. For those interested, many improvements were also made under the hood to reduce the amount of bandwidth needed to maintain the content index in a Database Availability Group. This was made possible by removing the need for a passive copy to talk to the active copy to update the content index. Instead, the index is built based on the passive copy itself. Searches are returned faster, too, by trying to predict what you are searching for. Karim does a great job explaining how Microsoft uses data from Office 365 to understand how people search and how that influences the way Exchange 2016 handles searches.
- Document Collaboration
If you are using Office 365, chances are you already experienced a lot of the document collaboration features that will be available in Exchange 2016. The ability to automatically send links instead of attachments is pretty interesting as well as the side-by-side view of documents in OWA. The latter part requires you to deploy the ‘Office Server’ which – to my knowledge – has not been released as a preview yet. The implications of having to install this server or the fact that it requires affinity when you add multiple servers in a load balanced array are somewhat of a let down from an architectural standpoint. Nonetheless, you do get a pretty nice experience in place. Personally, I would recommend each of my customers upgrade to Exchange 2016 to install the Office Server. I just can't see how one would want to miss out on the new feature(s) it adds.
- Auto-Expanding Archives
Truth be told, I might have missed an announcement at Ignite, but I was not expecting this feature in Exchange 2016; I have yet to finish viewing a few more sessions. The feature is said to automatically provision an additional archive if the primary one reaches 100GB. While juggling numbers this high is probably good from a PR perspective, I am struggling to find good use cases with this. Based on the customers I have interacted with, I have yet to find a single user that has a mailbox spanning more than 150GB – that is without taking into account 'special' mailboxes like journaling mailboxes or application mailboxes. I'm not saying they don't exist; I just don't think there are many of them out there. That being said, the amount of data we store in our mailbox is growing, so maybe this feature will grow on me over time (pun intended!)
Maybe it's because of my current role, but I LOVE the fact that Microsoft is introducing REST APIs to the on-premises version of Exchange. From an application development point of view, this opens up many opportunities and makes coding new features for Exchange much easier. At the moment, there isn't much information available on the REST APIs or what functionality they will provide. I can only assume they will provide similar capabilities as Office 365 (mail, calendar contacts, etc.). I'm sure as we get closer to RTM, the TechNet documentation for Exchange 2016 will be updated as well. A more interesting question is what will happen to EWS over time? I wouldn't be too surprised to see these REST APIs take over the lead as the preferred way to extend on-premises Exchange. Until then, EWS is still very much alive and kicking.
With the introduction of these APIs, Microsoft also (finally) dropped support for MAPI/CDO. There's still a lot of third-party product out there that uses the MAPI/CDO library, so make sure you're not using one of them!
There's a LOT more in Exchange 2016 to discover - too much to cover in a single article. I'm confident that over the course of the next few weeks and months, more information will become available and we will see many more how-to articles. I believe I spotted one already yesterday…
I definitely plan to write about more about Exchange 2016 in the coming weeks and months. For now, I suggest you download the preview and play with it a little. There's no better way to learn how something works than to actually use it! Do not forget that, unless you're part of the Technology Adoption Program (TAP), you should not use the preview in production. Labs only!
As my friend and Exchange MVP @ExchangeServerPro would say: