Each time Microsoft plans to release a new on-premises version of Exchange, it seems a collective sigh of relief comes from a number of administrators not quite ready to move their email into the Office 365 platform.
Exchange Server 2019, expected in the second half of 2018, is a chance for Microsoft to address some of the long-standing requests from administrators and correct some of the issues encountered in the field. The company plans to release a preview version in mid-2018 and, hopefully, it will heed some of the feedback from IT professionals and deliver a solid release.
Here are five areas where I would like to see either improvements or a new way to implement certain features to make the migration to Exchange Server 2019 an easier process.
Undo some architecture limitations
In Exchange 2013, if there was a faulty component, such as a broken Simple Mail Transfer Protocol layer, Exchange would find a route to another Exchange 2013 server and send mail that way while the system tried to fix the problem.
In Exchange 2016, Microsoft took away this feature, and now they isolate servers so this procedure no longer happens automatically.
Well, what does that mean? You have a server that is not functional until you either reboot it or restart the services. Microsoft should look to re-examine this architecture decision and try to restore it in Exchange Server 2019.
Slow down the cumulative updates
Microsoft changed the cumulative update patch cycle to every quarter for Exchange. This includes all of the Exchange versions.
In my experience, the challenge here is when Microsoft fixes issues in one cumulative update, but then something else breaks. Then the company fixes the new issue in a later cumulative update or emergency patch. But when Microsoft releases the next cumulative update, the cycle begins anew with another new issue the administrator must try to correct, or wait until a fix arrives.
My hope with Exchange Server 2019 is that Microsoft will slow down its cumulative updates schedule to something more manageable, such as a release twice a year. Microsoft should include major fixes or enhancements versus using the cumulative update model to install a feature or fix one problem.
The company should spend more time with Exchange MVPs who work in the field and address the more pressing problems they encounter.
Add .NET Framework support
The .NET Framework has been a sore point with Exchange for a long time, starting with version 2010 and continuing with the higher versions.
Microsoft released a new version that either gets downloaded automatically with Windows Update or that an administrator releases with System Center Configuration Manager before the Exchange admin can prevent it. The end result is Exchange Server installs the update and stops working.
In a recent example of this problem, Microsoft released .NET Framework 4.7, which the company said no version of Exchange supports. But version 4.7.1 will work with Exchange 2013 and 2016 if the system is on a certain rollup.
This scenario causes major problems for many organizations. These upgrades to servers should not roll out without proper testing. Some organizations might feel Exchange runs well enough and don't feel the need to upgrade. Many vendors also don't support the new versions of Exchange, let alone the .NET Framework on the latest release.
In Exchange Server 2019, Microsoft should add support for all versions of Exchange when it releases a new version, not just one or two cumulative updates. This will ease the frustration of a forced upgrade.
Another option is to notify the Exchange administrator that an update is available and that they should plan to upgrade to a newer cumulative update.
Ease up on the migration limitations
Every Exchange admin wants to have the latest version of Exchange installed to use the new features. Unfortunately, it's still not easy to migrate to a new version.
You cannot simply bring up a server and install Exchange. You have many things to consider. The first being, "Will my current Exchange installation support a higher version? Also, will my Active Directory version support it?"
For a company on Exchange 2003, it's not possible to move directly to Exchange 2016. First, Microsoft requires an upgrade to Exchange 2010 on the latest service pack and rollup, and then the company can introduce Exchange 2016.
The method is the same for Exchange 2007. You need to introduce an Exchange 2013 server, migrate the older system across, decommission the Exchange 2007 system and then introduce the Exchange 2016 server.
All these migration steps involve quite a bit of work, especially if you have a large organization of more than 5,000 users. There are many tools on the internet that handle migrations without the need to install additional servers, but they come at a price. Microsoft should address these migration limitations in Exchange Server 2019 to streamline these labor-intensive procedures.
Client support issues can tie up administrators
Another common migration problem for administrators is the client limitations when introducing a new version of Exchange. By default, Exchange 2016 has MAPI over HTTP enabled; this is the transport protocol used to connect the Exchange system to the clients.
Exchange 2016 only supports Office 2010 and up, but administrators must apply all the patches and some hotfixes to the clients. This is another reason why a migration to a new version of Exchange is not a quick exercise. If you install the new version of Exchange over the weekend, but don't coordinate these client patches, then Monday morning will arrive and none of your end users will be able to connect to Exchange because they won't have the required hotfix or service pack installed.
I expect Exchange 2019 to have a list of supported clients. I think Office 2010 will be out the mix, and only enterprises on Office 2013, Office 2016 and the upcoming Office 2019 will work with Exchange Server 2019. From my perspective, this represents a sizeable expense to upgrade clients for some companies, as many have a limited budget to work with. Not every organization has the luxury to implement a new version of Exchange.