Start Planning Your Exchange 2016 Migration
Exchange Server 2016 has arrived and has been lauded as one of the most reliable releases of Exchange yet, due to revolutionising the core technologies built into Exchange Server 2010, making deployment choices much more straightforward.
The following article is an excerpt from a blog article written by ENow Exchange & Office 365 Solutions Engine Blog (ESE).
What’s new compared to Exchange 2010?
Although Exchange Server 2010 has been extremely popular, Microsoft has learned a lot from running the world’s largest Exchange deployment inside Office 365.
Exchange 2016 brings new features under the hood, including a re-architected Store engine and better automated availability checks. Some of the most anticipated deployments include:
- A beautiful new Outlook Web App – renamed “Outlook on the web”
- A new management GUI
- A move to a single-role server architecture
- Simple namespace planning
- No direct MAPI access to Mailboxes - All access is via HTTPS.
- Removal of traditional public folders
- Better database reliability
- Database auto-reseed
- Drastically lower IO requirements
Will you lose any functionality when you upgrade?
You will lose compatibility with older clients, like Outlook 2003 and Outlook 2007. You will need to upgrade clients before moving the mailboxes they use.
As Steve Goodman says, "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."
Steve Goodman continues: "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."
Importantly, applications that rely on MAPI CDO API access to Exchange no longer function, making it paramount ensuring your third-party applications support newer APIs, like Exchange Web Services.
What upgrade paths can you take?
According to Steve Goodman, "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.