Microsoft’s servicing model for Exchange 2013 and 2016, and presumably for all future versions of Exchange Server, involves quarterly releases known as cumulative updates (CUs).
Each CU release is supported for three months after the release of the nextCU. In effect this means a CU is supported for six months. This allows customers time to test and validate new CUs before deploying them to their production environment. It’s quite common for customers to run “one CU behind”, or N-1, as a way of reducing the risk of upgrades. In other words, they’re waiting to see whether any major issues are reported by other customers before they deploy the update themselves.
Because CUs become unsupported after six months, Microsoft removes them from the download center. The removal takes place three months after support ends, so a CU is available for a total of nine months. At any given time you can expect to find only the three most recent CUs for each of Exchange 2013 and 2016 available for download. For example, today the latest CU for Exchange 2016 is CU8. The download center has CU8, CU7, and CU6 available, but not CU5 or earlier.
This creates some problems for customers who are not updating their Exchange servers often enough:
- The Exchange servers will be running an unsupported build. This in itself is not a huge problem. The server won’t suddenly explode just because the build it’s running isn’t supported any more. But, the server may be vulnerable if there have been security updates included in new CUs. Integration with third party products may also become unstable, as can hybrid configurations with Office 365. And Microsoft Support may require you to update to a supported CU before they can help you with a problem that you raise a support ticket for.
- CU installs, when the customer eventually gets around to them, will be riskier. Microsoft tests N-2 upgrade scenarios. For example, when Exchange 2016 CU8 is released, it has been tested for upgrades from CU7 and CU6, which are the two previously supported CU builds. Upgrading from CU5 or earlier, while still supported, hasn’t been tested. So you as the customer are taking on more risk.
- Updating while staying within supported Exchange and .NET Framework configurations becomes complicated. Exchange needs to run on supported versions of the .NET Framework for performance and stability. In recent years, Microsoft has been very clear in their guidance to customers about which .NET FX versions to use, and which to avoid. When a newer .NET Framework version is going to be necessary, Microsoft gives advance warning of the change on the Exchange team blog. For example, in December 2017 support for .NET FX 4.7.1 was added for Exchange 2013/2016, and Microsoft advised that .NET FX 4.7.1 will be required for the June 2018 CU releases, providing customers ample time to plan the update.
That last point has been the source of some discussion lately, because it is becoming a real problem for customers who have not been staying up to date with CUs and are running on older, unsupported builds. Granted, it is a self-inflicted wound, but it’s a problem nonetheless.
The problem is that customers running out of date Exchange builds need to navigate their way to the latest CU while staying within the boundaries of supported .NET Framework versions. MVP Michel de Rooij provided an example in his blog post. A customer running Exchange 2013 CU6 with .NET FX 4.5.1 needs to go through a multi-step upgrade process to get to the latest CU available today (Exchange 2013 CU19):
- Upgrade to Exchange 2013 Cumulative Update 15
- Upgrade .NET Framework to 4.6.2
- Upgrade to Exchange 2013 Cumulative Update 19
- Optionally, upgrade .NET Framework to 4.7.1
The first roadblock with that upgrade path is that Exchange 2013 CU15 is no longer available for download. In any scenario such as this where an intermediate CU is required to stay within .NET FX support boundaries, you will not be able to download the update that you need.
That upgrade path is made even more challenging because Microsoft has removed the .NET support information from TechNet for older, unsupported versions of Exchange Server. So charting an upgrade path for every possible scenario is not possible using Microsoft’s documentation.
Fortunately, Michel has captured the older information in his blog post for us all to reference when needed.
As a helping hand to customers who are stuck in a situation like the hypothetical one we’ve just seen, Microsoft has issued new guidance on the Exchange Supportability Matrix.
When upgrading Exchange from an unsupported CU to the current CU and no intermediate CUs are available, you should upgrade to the latest version of .NET that’s supported by Exchange first and then immediately upgrade to the current CU. This method doesn’t replace the need to keep your Exchange servers up to date and on the latest, supported, CU.
Microsoft makes no claim that an upgrade failure will not occur using this method, which may result in the need to contact Microsoft Support Services.
That solves the main technical problem, though it doesn’t entirely remove all the risks.
You can avoid getting yourself into such an upgrade hole by following these recommendations:
- Maintain your Exchange servers by upgrading to supported builds when they are released, or within the support period for that CU release.
- Download all CU releases for your version of Exchange, whether you plan to deploy them or not. This is especially important for consultants, as I know many of you encounter very outdated Exchange versions when you take on new customers. I store the CUs on a NAS. It isn’t very expensive to do so. And you never know when you or a customer will need a specific CU for upgrades or for a server recovery.
- Always check the CU release notes and the Exchange Supportability Matrix so that you can update .NET Framework when you are installing a new CU. This will keep you within the supported versions, and handle the updates in a single maintenance window.
