In this blog, I will review a common situation in which Exchange servers are installed in an outdated Cumulative Update (CU) version and needs to be upgraded.
Basically, this process shouldn’t be so complex unless .NET compatibility was an issue that can affect the whole upgrade process.
Exchange’s CU supportability policy
According to the Exchange serving model since Exchange 2013 and for all the On-Premises versions ahead, only the latest 2 CUs versions are supported:
“A CU will be supported for a period of three (3) months after the release date of the next CU. For example, if CU1 is released on 3/1 and CU2 is released on 6/1, CU1 support will end on 9/1.”
As you probably know, Exchange must have .Net Framework, which has to be supported by the Cumulative Update (CU) version you are running.
For more information please visit the Exchange supportability matrix:
When do I have an issue?
Think about a customer that runs Exchange 2016 CU12 and having .NET 4.72 installed on the servers.
This customer would like to upgrade his servers to Exchange 2016 CU16 (currently the latest).
According to the Exchange supportability matrix, the only .Net Framework supported by Exchange 2016 CU16 is .Net Framework 4.8:
Now this customer has 2 options:
- In order to be “on the safe side”, he needs to install Exchange 2016 CU13/CU14 which supports .Net 4.72 as well, install .Net 4.8 (which supports Exchange 2016 CU13-CU16) and then upgrade to Exchange 2016 CU16.
The advantage of this process is that all along the way, the environment is in a supported state.
The disadvantages of this process are, that you might not have the previous CU (CU14 in this example) since only the latest CUs are publicly available.
The other disadvantage is, of course, a long installation process especially if you are having a large Exchange environment with many servers.
- The other option to install .Net 4.8, which is an unsupported state according to the Exchange supportability matrix and then upgrade to Exchange 2016 CU16.
So how to upgrade in the safest way?
Please consider the next important statement at the Exchange supportability matrix article:
“When upgrading Exchange from an unsupported CU to the current CU and no intermediate CUs are available, you should first upgrade to the latest version of .NET that’s supported by Exchange 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.”
Having said that, since we must upgrade our Exchange to a newer CU, the next steps should take place, in order to complete this process successfully:
1. Put the Server into Maintenance Mode.
2. Stop all of the Exchange Services.
3. Download and install the correct new .Net Version according to the supportability table.
Keep in mind that this step can take up to 20 minutes and even 2 hours (had cases like this), therefore do not stop the installation and keep waiting until it ends successfully.
4. After the installation was completed, reboot the server.
5. Update to the newest Cumulative Update for Exchange 2013/2016/2019.
6. Make sure to reboot the server after the CU is installed.
7. Ensure all Exchange services are in their normal start Mode and started
8. Take the server out of Maintenance Mode.
Recommendations before installing a new CU
There are a few recommendations which are very important to implement before installing new CU:
- Reboot the server beforehand.
- Test the new CU in a lab/test environment before running it in your production environment.
- Check with any 3rd party products installed on the Exchange servers, that they are supporting the CU version that you are about to install.
- Verify that you are having spare hardware (or enough resources in Virtual environment) for the RecoverServer process in case that the installation will not complete successfully.
- Check the Hash file of the CU’s ISO before the installation in order to verify that the installation is not corrupted.
You can use the Get-FileHash to verify that the “SHA256” number from VLSC is the same as the file that you have
- Stop any AntiVirus software installed on the server.
- Run the CU installation using elevated permissions (Run As Administrator).
- Run the installation on an Exchange server in the same AD site where the Domain Naming Master (AD role) is located.
- According to CU installation process in Microsoft’s web site:
“Any customized Exchange or Internet Information Server (IIS) settings that you made in Exchange XML application configuration files on the Exchange server (for example, web.config files or the EdgeTransport.exe.config file) will be overwritten when you install an Exchange CU.”
Therefore, backup any changes that you have made (in case you did).
Those changes include of course any Theme changes like changing the login screen to OWA for example.
Good Luck :-)