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 next CU. 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.
Photo by Anastasia Petrova on Unsplash
Hello All
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.
Thank you
My Exchange Analyzer indicate that i may be running unsupported combination of Exchange and .NET framework. I am on Exchange 2016 CU12 and running .NET framework 4.7.1. How do I clear/Fix the error?
I urgently need the Exchange 2016 CU6 to restore a server after ransomware attack.
Can anybody help me?
Thanks for these many articles about Exchange Server. I have been turning to them often.
I have an Exchange 2016 mailbox server running RTM. The current CU is CU11. Would you suggest risking the Exchange 2016 RTM to CU11 upgrade or simply upgrading to Exchange 2019? If the former, do you know of a document describing steps of a similar successful upgrade? If the later, I would want to use the Desktop Experience on Server 2019. Thanks.
Pingback: June 2018 Updates Released for Exchange Server – SimpleITPro
Pingback: March 2018 Updates Released for Exchange Server – SimpleITPro
Pingback: FAQ: In What Order Should You Install Service Packs, Update Rollups, and Cumulative Updates? – SimpleITPro
We are currently running Exchange 2010 with the latest rollups to date (as of Sept 18th of this year) on a box with Server 2008. I’m trying to install a new Exchange 2016 VM on a Server 2016 host, but my prerequisites have halted me because my AD forest level must be 2008 R2 or higher. I need to get my hands on an older CU, before they jumped the Forest prerequisite up to 2008 R2. Any advice for me?
Dear Sir,
Please answer my question
I have 4 exchange 2013 server with CU1 and DAG configured
2 mailbox server and 2 CAS
I need to upgrade exch2013 CU21
please let me know what are the server i want to install first, and direct upgrade is possible or not
can i install .net 4.7.1 and CU21 ?
please email me your answer
sajithknr@hotmail.com
sajith
Hello, I have a DAG with 3 nodes with Exchange Server 2016 CU1 and .NET Framework 4.6.1. We want to update directly to CU10.
What would be the procedure if I do not have the other CU?
Dear Paul
I am planning to implement DAG on Exchange 2016.
Currently I have an Server Exchange 2016 CU3 build number 15.01.0544.027 (EX01) running on Windows Server Data2012 R2 Data Center.
Exchange CU3
Currently I am planning to build another Server Exchange 2016 CU9 build number 15.01.1466.003 (EX02) running on Windows Server 2012R2 Standard
My question is whether DAG can be implemented between two servers overhead:
OS: Window server 2012R2 data (EX01) => Windows Server 2012R2 standard or mandatory datacenter (EX02)
Software: Exchange Version 2016 between 2 Exchange 2016 CU 3 (EX01) vs Exchange 2016 CU9 (EX02) has a DAG that is not between these two CUs
Or I have to update Old Server Exchange 2016 CU3 (EX01) to Exchange 2016 CU9 (EX02) then DAG Exchange 2016 CU9
Please help to advice
Many thanks
Hi, we are currently just running one Exchange server to maintain the hybrid setup (and have an inhouse anonymous relay). Would it make sense to offer as little time-out as possible to add a new 2016 Exchange server (running tests while the old is still there), then move over the left mailboxes (I suppose regular and arbitration), then decommission the old? Or is it sell pain to simply upgrade the old 2013 server (in-place). My first thought was that it might be the same work and I get a cleaner setup (I did not install the Exchange 2013). Any comments, recommendations, experiences? Thanks.
Martin
My environment currently running with .net version 4.6.01078 and Exchange Server 2013 CU13, can i update CU19 directly ? or do i need to update any .Net version or CU update which released before to CU13
Hi Paul,
Am I understanding this correctly, that as today we have exchange 2016 CU8.
So Exchange 2016 CU6 is not supported from Microsoft?
I am having a discussion with Veritas Backup Exec, where they claim there is a 12 months support for the latest SP. https://support.microsoft.com/en-us/help/17138/service-pack-lifecycle-policy
So my question is, do you have a link to something from Microsoft saying that Exchange 2016 is only supported by the most current CU and -1?
I cant find int myself. Hope to get your help.
The Real Person!
The Real Person!
That link is for service pack support lifecycles. Exchange does not use service packs any more.
Servicing model explained here:
https://blogs.technet.microsoft.com/exchange/2013/02/08/servicing-exchange-2013/
Exchange 2016 follows the same servicing model, announced here:
https://blogs.technet.microsoft.com/exchange/2015/10/01/exchange-server-2016-forged-in-the-cloud-now-available-on-premises/
They’ve also explained it in detail at Ignite sessions in the past if you want to hear/see more about it.
Thanks for the great article, Paul!
I recently finished upgrading 6 Exchange servers from Exchange 2013 CU5 (Version 15.0 Build 913.22) to the latest Exchange 2013 CU19 successfully. The plan I followed is outlined below.
1. Move databases
2. Disable Certificate Revocation Check in IE
3. Disable Anti-virus
4. Disable backup services
5. Put server in maintenance mode
6. Restart server
7. Install .NET framework 4.6.2
8. Restart server
9. Install Exchange 2013 CU19 with elevated permissions
10. Restart server
11. Verify server health (check services, check event logs, test Exchange server health w/ various PowerShell commands)
12. Take server out of maintenance mode
13. Move databases
14. Test Outlook, OWA, ActiveSync, and send/receive capabilities
Everything went very smooth and it took me about 90 minutes per server.
Your mileage may vary and this outlined plan doesn’t nullify the need to keep our Exchange servers updated.
Thanks for those steps Josh. Man o man do i hope things go ‘very smooth’ for me 🙂
i’ve got Microsoft on speed dial just in case.
So if we are installing the latest CU do we update the CU first or .net 4.7 first?
The Real Person!
The Real Person!
That question is answered in the article my friend.
Hi Paul, After reading this article I went to check if I could find past CU’s for my Exchange 2013 customers. I found the downloads have been removed and I do not have any copies of the retired CU’s.
Do you have a copy of Exchange 2013 CU15 and CU16 that you could share ?
The Real Person!
The Real Person!
I have them because I’ve been stockpiling Exchange installs, SPs, CUs etc since I became a consultant many years ago. But it’s not permitted for me (or anyone) to redistribute them.
I would suggest you get into the habit of stockpiling them yourself starting with what’s available today. Ask your industry friends and colleagues if they happen to have the ones you are missing from the past.
Hi,
Thank you for your article, it helped.
Just to clarify, if .NET 4.7.1 is already installed on the Exchange server, I should be able to go straight to CU19?
My server is: Exchange 2013 CU13 with .NET version 4.7.1 (from the registry: Release 461310 and version 4.7.02558) and in case you need, my AD Schema version from ADSI Edit is rangeUpper 15312
I was told to update to CU15, then to CU19, if I can skip a step, that would be great.
The Real Person!
The Real Person!
CU15 isn’t supported with .NET Framework 4.7.1, so you really gain nothing by upgrading to CU15 first.
Microsoft’s guidance is to update to the latest supported .NET FX, and then update to the latest CU. You’ve basically already done step 1, so that just leaves the CU upgrade.
We are running exchange 2013 with 4.71 (461310)?
So MS is saying just update to cu19?
Sorry we’re also on Cu12
The Real Person!
The Real Person!
Yes.
Also, make sure you’re not accidentally updating .NET through WSUS or Windows Update on those servers. For Exchange servers you need to manage the .NET Framework updates so you stay within those supported configurations.
Hi Paul, so Lets we run Exchange 2013 cu13 and never downloaded cu15. We run Net4.6.1 that is latest supported .Net. We just go install CU19 and then update .Net?
The Real Person!
The Real Person!
No, other way around, if you follow Microsoft’s guidance (quoted in the article above).