Exchange Server 2016 has arrived and has been lauded as one of the most reliable releases of Exchange yet. In many ways, it’s an evolution of the core technologies built into Exchange Server 2010 – but the way it’s put together has been revolutionized, making deployment choices much more straightforward.
Exchange Server 2010 has been extremely popular and, for many, was the upgrade point from Exchange 2003. It revolutionized availability with Database Availability Groups and made it possible and practical to deploy site resilient Exchange with relative ease. Six years have passed since its original release, though, and in that time, Microsoft has learned a lot from running the world’s largest Exchange deployment inside Office 365.
Much is new under the hood, including a rearchitected Store engine and better automated availability checks, but some of the most interesting deployments include:
There’s a lot to like in Exchange 2016. The real value is in the simplified architecture, which promotes easier management and better reliability. Email is core to any organization, and you need it to be reliable. The end-to-end improvements all add together to make this happen – whether it’s using the new MAPI/HTTP protocol for client access, or if it’s ensuring databases are less likely to fail.
If you already have a reliable architecture on Exchange 2010, then there is a lot of money to be saved when you next upgrade. The preferred architecture, introduced in Exchange 2013, provides guidance on how to deploy Exchange in a way that provides maximum reliability at a low cost. Lower IO requirements and the ability to realistically avoid the use of RAID means you can make significant savings on disks required and also remove the requirement for traditional backups.
Client access improvements simplify deployments and mean you can have a single name across the entire organization if you want to. Office 365 does this globally with the “outlook.office365.com” name, and it’s practical for your own multi-site deployment, too. Load balancer improvement can in some cases negate the need for a load balancer or make it simpler to manager.
From a client perspective, the new Outlook on the web is a revolution compared to Exchange 2010 and makes OWA in Exchange 2013 look quite antiquated. If you have a large number of OWA users at the moment, the new interface will make a day-to-day difference immediately.
You will lose compatibility with older clients, like Outlook 2003 and Outlook 2007. If you still have versions of Office this old, then you will need to upgrade clients before moving the mailboxes they use.
If you prefer to deploy separate roles, such as separate Client Access Servers, then you lose the ability to separate these. This is a good thing, though, because the reliability and simplicity of Exchange 2016 deployments relies on all the logic for a particular mailbox running from the same host.
Modern Public folders store Public Folder content inside special mailboxes, which are stored on normal mailbox databases. These are replicated using normal Database Availability Groups rather than traditional multi-master replication in Exchange 2010 and earlier. If you have particular Public Folders that are replicated and used across disperse geographies, then you lose the lower-latency access those in-region users have. They will need to connect back to the single active copy.
Applications that rely on MAPI CDO API access to Exchange no longer function. It’s important to ensure your third-party applications support newer APIs, like Exchange Web Services.
OWA is improved, but some things have been removed, including the add new functionality. The ability to add an additional inbox (for example, from a shared mailbox) into users’ own OWA view has been removed. They’ll have to use the more commonly used “Open additional mailbox” feature. If you use Public Folders extensively in OWA, then you’ll need to add your favorites rather than navigating and accessing them on-demand via a tree-view.
If you are running Exchange 2010, you can migrate directly to Exchange 2016. No version of Exchange since Exchange 2000 supports in-place upgrades, so you must implement new servers and storage to migrate to.
If you are running a simple implementation, such as a combined Client Access and Hub Transport, plus a single Mailbox server, then the logical route will be to implement, as a minimum, one Exchange 2016 server:
Larger organizations taking advantage of high availability features should also consolidate as part of the migration but will need to create new database availability groups to migrate mailboxes to. You will implement Exchange 2016 side-by-side with Exchange 2010, then move mailboxes across:
Exchange 2016 allows for a single namespace to be used when migrating to Exchange 2010. If you have upgraded from Exchange 2003 or 2007 to 2010, then not having to implement a legacy namespace will be a pleasant surprise.
As part of the configuration process, you will move your Exchange 2010 HTTPS namespaces, such as “mail.contoso.com” across to Exchange 2016, along with services like Autodiscover. Exchange 2016 will then proxy back client access to the correct server.
As with any major upgrade, you will need to check out a number of key areas. Along with the core requirements stated by Microsoft on TechNet, it’s worth looking at the following areas:
It’s time to start planning to say goodbye to Exchange Server 2010. It has been reliable – but improvements in subsequent versions are compelling and Exchange 2010 is in extended support, meaning it is edging closer to the end of life. Exchange Server 2016 is proving reliable – and of course used by millions of users daily in the Office 365 service. If you are planning to stay on-premises, start your planning now..