Microsoft keeps track of the current supported combinations of .NET Framework and Exchange Cumulative Updates at the Exchange Server Supportability Matrix. However, as time progresses, support information on older Cumulative Updates might be removed from the information presented, and you may need to resort to cached versions of this page or other sources to find this information.
This might be problematic for organizations that are not current, and need to find out which upgrade path they are required to follow to stay within the boundaries of supported Exchange deployment configurations. For example, you may need to upgrade to a specific Cumulative Update first, that is supported with a newer release of the .NET Framework, in order to be able to upgrade to a later Cumulative Update.
For these situations, the following tables contains the supportability matrix, enhanced with information regarding earlier Cumulative Updates and .NET Framework versions. These will provide you the supported upgrade paths for older versions of Exchange.
- When possible, bypass .NET Framework 4.6.1, as it not only requires updating the CU level prior to updating the .NET Framework, but also requires an additional hotfix: kb3146715 (ws2012r2), kb3146714 (ws2012) or kb3146716 (ws2008r2).
- NET Framework 4.7.1 is recommended but not yet required for the indicated product versions.
Suppose your organization loves procrastinating, and you are running Exchange 2013 CU6. Luckily, you run it on .NET Framework 4.5.1, which was already a supported configuration back in 2014 – yes, it’s been that long. Looking at the table, to get current with a minimal number of updates in mind, you can derive the following path:
The upgrade path to CU19 would therefor be:
- 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
Note that in addition to information being refreshed on Microsoft pages, availability of older Cumulative Updates or .NET Framework updates might also change, so archive those files accordingly, if not for recoverability of existing Exchange servers, then for this exact purpose.
Of course, you should stay current as possible from a support and security perspective, making the above a non-issue. Reality is, there are customers who have reasons, legitimate or not, to be trailing with updates in their environment, and at some point may need guidance on how to proceed in order to get current. I hope this information helps in those situations.
Thoughts and feedback is welcomed in the comments.