Microsoft Exchange and the .NET Framework

Over the past 20 years we’ve seen some dramatic changes in Microsoft Exchange Server. Exchange server 2000 was the first version that was using Active Directory, after switching from its own directory that was in Exchange server version 4.0 until version 5.5.

Exchange server 2007 was the first version that was a 64 bit version of Exchange server, and was therefore capable of using much more resources than for example Exchange 2003.

Exchange server 2010 was the first version of Exchange that was using bits and pieces of the .NET Framework, something that’s not directly visible to the administrator. Subsequent versions of Exchange server were more and more tied to the .NET Framework, something that’s clearly visible in Exchange server 2019. The huge memory requirement of Exchange server 2019 is something that’s coming from settings in the .NET Framework, resulting in dramatic performance improvements.

.NET Framework

Microsoft started the .NET Framework development in the nineties, but the first version of the .NET Framework was released in 2002 and was only included in Windows XP SP1. Important to note is that the .NET Framework is a separate product from Microsoft, just like any other product. Microsoft Exchange server is just a Microsoft internal .NET Framework customer, just like it is an internal customer of Microsoft Windows. When issues arise in Exchange server related to the .NET Framework, these issues must be fixed by the .NET Framework team and not the Exchange server team.

Over the years subsequent versions of the .NET Framework were released, but from an Exchange point of view the first used version was the .NET Framework 3.5 (released in 2007) in Exchange server 2010. The .NET Framework 3.5 and .NET Framework 3.5 SP1 libraries are the only libraries that are used by Exchange server 2010. Newer versions of the .NET Framework are not used by Exchange 2010 and according to Microsoft these can safely be installed on any existing Exchange 2010 server. Personally I’m not a big fan of installing newer versions of the .NET Framework on Exchange server 2010, in the past I’ve seen issues with Exchange server 2010 where newer version of the .NET Framework was installed. However, when running the Hybrid Configuration Server in an Exchange 2010 server environment it needs the .NET Framework 4.7 or higher or the Exchange server 2010 server, otherwise it won’t continue and results in the unsupported version error message as shown in the following screenshot:

Other than the Hybrid Configuration Wizard that needs the .NET Framework 4.6.2 or higher, there are no dependencies on the .NET Framework other than version 3.5 SP1.

Live becomes more complex with Exchange server 2013 and higher. With a quarterly cumulative updates cadence, basically a newer version of Exchange is released. This results in newer hardware and software requirements, especially when it comes to the .NET Framework.

• Exchange server 2013 RTM (released in December 2012) supports the .NET Framework 4.5 but Exchange server 2013 CU12 (released in June 2019) supports the .NET Framework 4.8.
• Exchange server 2016 RTM (released in October 2015) supports the .NET Framework 4.5.2, but Exchange server 2016 CU23 (released in June 2019) supports the .NET Framework 4.8.
• Exchange server 2019 RTM (released October 2018) supports the .NET Framework 4.7.2, but Exchange server 2019 CU2 (released June 2019) supports the .NET Framework 4.8.

For all supported version of Exchange server and the supported versions of the .NET Framework please check the Microsoft Supportability Matrix. 

Besides the version of the .NET Framework that is supported, there’s also a mandatory version of the .NET Framework that needs to be on the server before the Exchange server will actually install. If your Exchange server is running the latest Cumulative Update or maybe one or two Cumulative Updates behind it’s not a big deal, your server is most likely running a recent version of the .NET Framework and you should be good.

However, lots of my customers are running an old version of Exchange server, for example Exchange 2013 CU13 and therefore also running an old version of the .NET Framework like version 4.6.1. Upgrading from Exchange 2013 CU13 to CU23 is not directly possible, because of the .NET Framework dependencies. Upgrading the Exchange 2013 CU13 server to a recent and mandatory build of the .NET Framework won’t work either because of supportability issues. In such scenarios you have to install an interim version like Exchange 2013 CU19, upgrade the .NET version again and then install Exchange 2013 CU23. So, not keeping up-to-date with your Exchange version will backfire on you later when you eventually have to upgrade to the latest version of Exchange.

For upgrade paths you can follow when upgrading (very) old versions of Exchange server you can always check a blog post from fellow MVP en ENow author Michel de Rooij on this specific topic here.

Summary

Exchange server has a dependency on the .NET Framework, for Exchange 2010 it is not that bad but for Exchange 2013 and Exchange 2019 it can truly backfire when running older versions Cumulative Updates. You won’t be the first that run into issues with a required .NET Framework version when upgrading to a recent Cumulative Update of your Exchange server.

Besides Exchange, there are also other (3^rd party) applications that have a dependency on .NET Framework, the Hybrid Configuration Wizard is probably a well know example.

I recommend to keep your Exchange environment up-to-date, the latest or one previous version should be good. Also keep a close eye on the .NET Framework developments and which version of .NET Framework is mandatory. It will save you quite some frustration.