There may be a change in the way that Microsoft will support upgrades from older CU’s to the latest CU of Exchange 2013 or 2016. If we review the Exchange Server Supportability Matrix we see that in the .NET section, there is this note:
- “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. “
Reading this it tells me that while an upgrade from an old, unsupported CU to a newer supporter is allowed, there is no guarantee it will work. If it fails, a call to Microsoft support is needed. This clarification seems to eliminate the need for the Bridge CU (CU4) and may allow for a direct path for an upgrade. I would take this note with a grain of salt as there is no guarantee it would work. This upgrade path is a hard one for Microsoft to predict as there are quite a few CUs for Exchange 2013 now and there are endless possibilities for this to fail when upgrading .NET and then upgrading to the latest CU. Proceed with caution.
Recently I had a customer who fell behind on their upgrades for Exchange 2013. The servers were running Exchange 2013 CU, which was released in May of 2014. The newest update was CU18 and required some work due to changes in .NET requirements over the past three years. With this upgrade scenario CU15 could be used as a bridge update, allowing us to traverse the gap for .NET versions, while still being supported.
At first I thought that this was a problem unique to Exchange 2013. Then a fellow MVP pointed out a change to the .NET support listed on Microsoft’s Exchange compatibility matrix. This led to research to find a more complete view of .NET requirements for all versions of Exchange. I was about to find this chart – HERE The chart looks like this:
Not the changes in .NET over time as well as support levels for different CU’s. Upon seeing this, it appears that Exchange 2016 CU4 will become the ‘new’ bridge update for older versions of Exchange Server 2016. Why is CU4 the bridge? Well, let’s look how a supported upgrade path would look like:
(1) On your Exchange 2016 RTM to CU3 server – upgrade to Exchange Server 2016 CU4
(2) Now upgrade .NET 4.5.2 to .NET 4.6.2
(3) Upgrade Exchange 2016 CU4 to CU8
(4) and finally upgrade .NET from 4.6.2 to 4.7.1
Now it is plausible that you won’t have to perform all 4 steps, but it is currently within the realm of possibility from what I have seen my clients do upgrade wise. Remember that Microsoft would like you to be within an update or two of the latest and greatest.
If you are running a version previous to CU4 and are looking to go to CU8, you may be out of luck as CU4 is now gone as well:
If you find yourself in this situation, I believe you can call Microsoft Support for the update, but I have not verified this update is available at all.
Performing a search for available CU’s here is what I found:
Exchange 2016 CU 6, 7 and 8: Available
Exchange 2016 RTM to CU5: Not available
So again, we find ourselves in a possible bridge too far scenario. Let’s hope that you are running at least Exchange 2016 CU4. If you are, congrats, all updates (.NET and Exchange) are currently available to upgrade Exchange 2016 to CU8 and .NET 4.7.1.
nice summary of the .NET requirements.. but 🙂
if a customer ignores any CU releases for more than a year, it is maybe the better idea to just stand up a complete new (and updated) exchange server and add it to the DAG and just throw away the old ones.. or did they installed any windows updates or are they still waiting for R2 before the install server 16?