4/22/2022: Updated for September CU updates.
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 is not supported for any product level.
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
- Upgrade .NET Framework to 4.7.1 (Optional)
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 recovery 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.
Update: Per February 13th, Microsoft updated upgrade guidance on the Exchange Supportability Matrix page, stating:
“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”.
This means you will be supported when upgrading in the revised upgrade path, but the risk is still there. In the example above, when going from Exchange 2013 CU6 with .NET 4.5.1 to CU19, the support statement indicates you can upgrade to .NET Framework 4.7.1, when install CU19. However, things might break and you may need to contact support to get back in a supported, working situation. Therefor, I repeat my recommendation to download and archive CU’s and .NET Framework files, even when you are not planning on installing them (yet).
Pingback: December 2017 Updates Released for Exchange Server
Hey Michal. Its gr8 article as always. Lokijg forward same recommendation for Exchange 2010 SP.X.X
There will be no upgrade matrix, because Exchange 2010 uses ancient .net 3.5 only.
Pingback: Лабиринт обновлений Exchange Server | ILYA Sazonov: ITPro
thnx for the update! good article.
Pingback: Exchange December 2017 Updates - SuperTekBoy
thanks for this great post. I have used a screenshot of your table at my blog:
My post is in german language (People with old Exchange versions can’t find a download for CU15). Please let me know if I should remove your Image from my site.
With proper reference, sure be my guest. Note Frank Carius also did a write-up at https://www.msxfaq.de/exchange/admin/servicepack2013.htm
Well Done, nice tables, clear direction for Exchange 2013. Something i expected from the exchange Team blog. Anyway: they will find it here. At least the german Exchange admins should be able to find it via the link at https://www.msxfaq.de/exchange/admin/servicepack2013.htm and 2016.
Thanks for the link, Frank.
Pingback: Quick method to determine installed version of .NET Framework | Troubleshooting Exchange
Pingback: Download that new Cumulative Update for Exchange…While you can. – No One Uses Email Anymore
thx! very helpful!
Pingback: Monthly IT Newsletter – November 2017–January 2018 – Guy UC World
Any idea where to still get CU4? MS has pulled it and it is no longer available even though I must update to CU4 and then .net to get to CU8.
If it’s blocking your current upgrade path, a support call might help to get you back in a supported state.
Hey Michael, did you find a cu4? I m trying to find a customer where I stored one but no luck so far.
I followed MS advise and jumped to .net 4.7.1 and then did the CU8 update. All well so far.
The support statement has been changed; see update note at bottom of the article. However, the risk is still yours.
Pingback: Guidance for Solving Outdated Exchange CU and .NET FX Versions
Pingback: You should upgrade to the latest version of .NET that’s supported by Exchange first and then immediately upgrade to the current CU | DigitalBamboo's Blog
Why is CU14 missing from the tables?
My bad – added; identical situation as CU13.
Pingback: Yes, Virginia. You can upgrade to the latest Exchange Cumulative Update – even if you aren’t keeping up on those .Net versions! – No One Uses Email Anymore
Pingback: Exchange March 2018 Updates - SuperTekBoy
Pingback: Exchange Updates – March 2018 | EighTwOne (821)
Pingback: Exchange 2016 CU9 and Exchange 2013 CU20 released | Jaap Wesselius
Thanks Michael, great article. I wish I had found it sooner though!
Pingback: .NET Framework 4.7.2 | EighTwOne (821)
Pingback: Exchange June 2018 Updates - 2016 CU10 & 2013 CU21
Pingback: Exchange Updates – June 2018 | EighTwOne (821)
Thank you very much for a great article. This is very helpful, but I have an additional parameter I would like ask about. I have Exchange 2016 CU4 with .NET 4.6.2. My latest Windows update (Windows 2016) was quite a while ago, and I see that the latest Windows update installs .NET 4.7.1. Should I update Exchange to either CU 8 or CU9, install .NET 4.7.1, then update Windows 2016; or should I update Windows using the registry key to prevent automatic installation of .NET 4.7.1 then update Exchange to CU8 or 9, then install .NET 4.7.1?
Per latest policy, you can update to the latest .NET first, then install the latest CU supported for that .NET version (eg 471 and CU10). However, there is still a risk walking an untested path, also when 3rd party software is involved. A safe alternative could indeed be CU8 or 9, NET 471 then CU10. OS updates shouldn’t install NET Framework updates, but there were incidents in the past with Windows Update – hence the reg. key blockers
Hi Michel, such a great article!! many thanks, very helpful.
I got a new client with the below scenario:
CU3 currently installed
planning upgrated to CU10
(Get-ItemProperty ‘HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full’ -Name Release).Release
retrieves 461310 =4.7.1
Can i proceed with the CU10? is there any risk?
Microsoft revised its support statement, you are now OK to install NET4.7.1 first on CU3 (which you already did), then apply CU10. However, Microsoft makes no warranties in those untested upgrade paths, but you are on a supported path. Note that ‘risk’ does not always come from Exchange itself but may also involve installed 3rd party software.
Exchange servers in my organization are running CU 13 With .net version 4.5.2 and I am planning to upgrade to the latest CU 20. But in order to reach CU 20 I need to go to CU 15 upgrade .net to 4.6.2 and then upgrade to CU 20. The problem in this case I can’t get the CU 15 upgrade download any where. Can you help me on how to move ahead!
As indicated, MS supports directly upgrading to the.last supported .NET then immediately applying the latest CU. It might be an untested path though, and you be might have to contact support when running inro issues. When you require an intermediate CU for a safer path, you could try contacting support.
Good afternoon Michel
I have a similar this scenario with a new customer, he is still using the RTM version and wants to move to CU10 on his Exchange 2016. I was planning on going the route CU4, Cu8 and Cu10. However if you are saying the direct way could be approached I would be interessted on reading up on that.
Do you have a link where MS is confirming that.
Read the “Note” here
We have been running Exchange 2013 CU12 for years and I finally got around to updating to CU21. Came across this article and found our server already had .NET 4.7.2 installed (release 461814) and has been working fine with this combination. According to your matrix this is not at all supported, am I missing something? Are there only certain features of Exchange which rely on .NET that we perhaps don’t use?
Going outside support boundaries you will be on your own- Might work, might result in issues. As an enterprise, I would not even consider it, and try to be in a supported state for my applications..
Installed CU21 right on top of existing CU12 and no issues so far, all is working normally. No idea when .NET 4.7.2 got installed but seems the server had been running it for some time even with only with CU12. One would think that Windows Update would not automatically roll out an incompatible .NET update if it detects and older version of Exchange installed if there really is an incompatibility?
There have been incidents in the past where .NET Framework upgrades got published as recommended updates which lead to unwanted automatic deployments (in those cases the blockade registry keys are a valuable precaution).
Pingback: Exchange Updates–October 2018 | EighTwOne (821)
Pingback: Exchange June 2018 Updates - 2016 CU11 (but no 2013?)
Pingback: Exchange Updates – February 2019 | EighTwOne (821)
According to your matrix I am not able to see our current combination:
Exchange 2013 CU 11 & .Net 4.7.0
Not sure when .Net is upgraded to 4.7.0
Our aim is to upgrade Exchange 2013 to CU22
Do you have any suggestion on possible upgrade path?
.NET 4.7 is not supported for any Exchange release; I’ll make an empty row to make that clear.
I don’t know how we ended with .Net 4.7.0 but it is our current situation.
Would it be appropriate solution to upgrade 4.7.0 to 4.7.1 and then upgrade of Exchange 2013 CU11 to CU22?
4.7 ended in the Windows Update channels, and that’s when sometimes accidents happen. It might work though, yet not supported. To get in a supported state, your path seems ok, that is upgrade .NET to 4.7.1 followed by Ex2013 CU22.
Due to some unknown reason one of my CAS and one mail Mailbox server are now with dot net 4.7.2, reset are on dot net frame work 4.7.1,.
Currently we are on CU 20, and want to move to CU22
So which will be the best and safest approach,
update rest of servers to dot net 4.7.2 and then upgrade to CU22
upgrade to CU 22 and then update dot-net frame work 4.7.2 on rest of servers.
I’d install CU22 over CU20, then upgrade .NET Framework from 4.7.1 to 4.7.2 – which is a tested path.
Pingback: Exchange Updates – June 2019 | EighTwOne (821)
Pingback: .NET Versions and Exchange | Just A UC Guy
FYI… looks like E2016 CU13 and E2019 CU2 adds support for .NET FW 4.8
Updated info pending
I’m a big fan of your article and use it regularly for reference…
one small typo in Exch2019 table (.net 4.8.2 does not seem to exist… yet).
Also it looks like Exch2019 CU2 is supported with both .net 4.7.2 and 4.8
Thanks for the heads-up
Pingback: Exchange Updates – Sep. 2019 | EighTwOne (821)
thank you indeed, you saved me hours of research!
I need to update Exchange 2013 CU9 to CU23 and already have 4.7.2 installed. In wonder why we don´t have any issues with that constellation!?
Not supported just means that; it doesn’t mean it works/could work, but YMMV.
Pingback: Exchange Updates – December 2019 | EighTwOne (821)
Pingback: Exchange 2016 CU14 and Exchange 2019 CU4 released | Jaap Wesselius
Pingback: Exchange 2016 CU15 and Exchange 2019 CU4 released | Jaap Wesselius
Pingback: Exchange Updates – March 2020 | EighTwOne (821)
My customer has Exchange 2016 CU5 and along the way someone has updated the server to .Net Framework 4.7.0. What can I do about updating .Net Framework and getting Exchange to CU14 supported by .net 4.7.2 or CU 16 supported by 4.8?
Is it fine to follow Josh’s advice and put the server in maintenance mode and then update to 4.7.2 or 4.8 and then install the respective CU14 / CU16.
4.7.0 is not supported by any CU so I don’t have a safe upgrade path.
I’d put server in maintenance, update to 4.7.2 and CU14, followed by 4.8 and CU16 ending with taking it out of maintenance. This is where testing environments come in handy, especially if 3rd party software is involved.
Pingback: Exchange Updates – June 2020 | EighTwOne (821)
Can you update the information for the latest CU’s?
Consider it done.
Hi, sorry but I want to be sure about that,
so if I have Exchange 2019 CU 2 and .Net 4.7.03190 I need to install .Net 4.8 before install Exchange 2019 CU 6 or not?
Thank you very much.
Pingback: ИТ Вестник №12.2017 - Блог IT-KB
Pingback: Exchange Updates – September 2020 | EighTwOne (821)
Pingback: Exchange Updates – December 2020 | EighTwOne (821)
Pingback: Annual Report 2020 | EighTwOne (821)
Pingback: Zero Day Vulnerabilities Discovered in all Versions of Microsoft Exchange Server | Jaap Wesselius
I will plan to update Exchange 2013 CU7 to CU23 with .Net 4.8.0 installed at first,then need to update KB5000871 for these CVEs 😦
Pingback: Security Update Exchange 2010-2019 (Mar2021) | EighTwOne (821)
It would be wonderful if Microsoft made available some of the older CU’s instead of having to call support to get them in the midst of a bunch of zero day attacks. I guess the choice is either risk getting compromised or risk blowing up a server and in either case, don’t call Micro$oft for at least a week. What a joke.
Why you need older CU’s in the first place? What is the business justification for trailing so much?
Some admins have more to worry about than just exchange. I had assumed installing regular updates meant the exchange server was updated. Stupid probably, but again, exchange is one of many applications in my environment. From what I understand, having the latest CU with all the security updates would have meant being completely vulnerable up until Wednesday of this week anyway.
Vulnerable for HAFNIUM; you’re forgetting all the exploits fixed between CUx and current ones. For this reason I always recommend business to archive those CU’s, whether they install them directly, skip them or not. You also don’t want to encounter unexpected challenges during recovery scenarios.
Pingback: URGENT: Zero Day Vulnerabilities for Exchange Server – Dine.ga
Michel, we have a client on 2016 RTM running 4.6.2 (unsupported however functional). We need to take them to CU19 urgently. What would you propose? Straight upgrade to CU19 and then install .NET 4.8? Or try to obtain ISOs and move to the supported CU for 4.6.2 first?
Hi Michel. I run exchange 2013 DAG with two mailbox servers and a CAS. currently on CU5 installed on .net 4.6.1. whats the best upgarde path to CU23?
Tested upgrade path should be through: Ex2013CU5/NET461 -> Ex2013CU15/NET461 -> Ex2013CU15/NET462 -> Ex2013CU20/NET462 -> Ex2013CU20/NET471 -> Ex2013CU22/NET472 -> Ex2013CU23/NET472 -> Ex2013CU23/NET48.
However, obtaining intermediate CUs would be a challenge as out of support CUs are not available through regular download channels without contacting support.
Supported upgrade path would therefor be: Ex2013CU5/NET461->Ex2013CU23/NET48, where you upgrade NET first immediately followed by installing the CU, per MS support statement (pls read): “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. 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”.
Pingback: EighTwOne (821)
Pingback: Exchange Updates – March 2021 | EighTwOne (821)
Hi Michel, have an exchange 2016 CU5 (.net 4.6.2) that I want to take to CU20 (.Net 4.8). According to your tables I would need to update to CU8 or CU9 then update .Net to 4.7.1 at this point i could update to CU11 or CU12. I would then update >net to 4.7.2 and CU14. At my final stage i would need to update .Net to 4.8 and CU20. Just asking for a confirmation I am following the chart correctly. Thanks.
This would indeed be the validated path: Ex2016CU5+NET462 -> CU8/9 -> NET4.7.1 -> CU11/12 -> NET472 -> CU13/14 -> NET 4.8 -> CU20
However, MS now supports upgrading from an unsupported CU to current CU by upgrading to latest .NET version supported by Exchange first, then immediately upgrade to the current CU. These paths are not only to cut installation short, but also because interim CUs become unavailable over time. Do note these paths are not tested and “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”.
So I could go to .Net 4.8 and CU20 from CU5 on Exchange 2016…But if i have issues i would need to contact MS support?
Correct (statement at https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/supportability-matrix?redirectedfrom=MSDN&view=exchserver-2019#microsoft-net-framework). Also, be prepared for the worst (e.g. reinstall)
Pingback: Exchange Updates – June 2021 | EighTwOne (821)
Can you update the information for the latest CU’s and requirements?
Pingback: Exchange Updates – September 2021 | EighTwOne (821)
Pingback: Exchange Updates (and more) – H1 2022 | EighTwOne (821)
Pingback: Exchange 2016, CU Updatepath / .NET kompatibilität | Gumpert IT Wiki
Pingback: Exchange Updates (and more) – H1 2023 | EighTwOne (821)