Don’t let the wrong .NET Framework break your Exchange server

Exchange and .NET Framework have come a long way together. With each version, you will see in the prerequisites which versions are supported and recommended by Microsoft along with your Exchange version. You will also notice that legacy versions of Exchange won’t support the newer versions of .NET as they are going out of support. Newer versions will support them but only after you apply a specific cumulative update. The biggest challenge with this today is with the newer operating systems. Windows Server 2016 and higher go and download updates — not only Exchange but .NET. The other problem is administrators using a WSUS system or SCCM go and release updates and don’t realize that the .NET version update could potentially bring down a server.

Example of .NET Framework breaking Exchange

.net framework

I have a classic example of this. A customer was running Exchange 2013. At the time, .NET 4.7 was not supported on Exchange 2010, Exchange 2013, and Exchange 2016. (Exchange 2019 was not around yet.) I sent the release notes to them regarding .NET 4.7 and that they shouldn’t install it but I was too late, unfortunately. They had just done the update and rebooted the server. At first, the comments were, “My server is fine,” but soon users started calling in saying that email on their mobile phones was not working and Exchange services kept stopping and starting.

This is as a result of an unsupported version of .NET Framework on Exchange. Right, so the first thing the customer wanted to know is can they do a rollback. At the time, there was a document on Microsoft’s blog site that detailed a rollback of .NET. But some time after the rollback was done, nothing wanted to work.

The server was now completely broken. They attempted to run an upgrade to a newer CU version but it also failed to install and was throwing out some funky errors.

The result after countless hours of troubleshooting was to shut down the server and do a recovery. This was covered in one of my previous posts.

If you were running a database availability group (DAG), you could have moved the databases and possibly kept the company online and the SLA would have been met while you recover the broken one. But many IT staff feel that Hyper-V replication or snapshots are sufficient for Exchange — we not going to dive into this as it is covered in other articles.

Hotfixes and hot messes

.NET Framework Exchange

You can see that just applying Windows updates or hotfixes in a production environment without deploying them in a test environment can bring down your Exchange server or servers. Yes, you shouldn’t try to install something not recommended, but best practice is to test the Windows updates and then advise your change advisory board (CAB) on the outcome.

Now let’s throw a spanner in the works a bit. With later cumulative updates for Exchange 2013 and higher, you will see some requirements that .NET must be updated to be able to install a newer version. But you say, “You just said don’t install it.” OK, so Microsoft won’t make you install something to break it later. You can ignore them but the setup will require it and fail. If Microsoft says install .NET 4.7.2, as an example, and you are on .NET 4.7.1, then it is OK. Follow the guidance and then proceed to your cumulative update after a reboot.

OK, we have hit a brick wall. You are running Exchange 2013 CU6 or Exchange 2016 CU7, as an example, and now you cannot go to CU7 and CU8 respectively but only have the option to go to the latest version or one behind. The same rule applies — install .NET version X recommended by Microsoft, reboot your server, and then proceed to that cumulative update.

The next thing you might notice is that, for example, you have Exchange 2016 CU12. Microsoft says that .NET 4.8 is supported and this is before you update to a newer version, but going forward the list of prerequisites will change to the newer versions. You can safely deploy .NET 4.8, just make sure you check the support matrix to ensure your Exchange 2016 server or 2013 is on the supported list for .NET upgrades.

Follow the guidelines

Failing to adhere to these guidelines will result in a broken Exchange server and many hours of troubleshooting or recovery of servers. Make sure that you also chat with your Windows Update Teams that handle WSUS or System Center Configuration Manager (SCCM) and advise them that this list of .NET updates will work and that list will break Exchange. Have them create a dedicated group for Exchange and have exclusions in place as you can manually update .NET vs having them push it out.

Personally, I prefer updating .NET from an executable that you can download. It is called the offline installer for .NET Framework. (There are installers available for different versions of .NET Framework.) The file is about 110MB to download. If something goes wrong with Windows updates and it installs halfway and at that time you have a surge (it happens) and the machines reboot or you have a host problem the same applies.

So, there you have it. If you are unsure about installing a particular .NET version, always refer to the support matrix on Microsoft’s website. If you are still unsure, then chat with your Microsoft Technical Account Manager or reach out to the TechNet forums for advice.

If you are deploying new servers, install the version of .NET Framework needed for that version of Exchange. This will save you upgrades later on down the line. With operating systems like Windows Server 2016 and higher, they come with a newer version of .NET Framework already, but still follow the best practice and you cannot go wrong.

Featured image: Pixabay

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top