Expediting NET Framework Install For Exchange

Managing and maintaining an Exchange server requires multiple actions.  Not only do the Exchange CU and security updates need to be installed along with the Windows OS updates, it is also required to update and maintain the .NET Framework.  This is not a new requirement, and has been a required task for many years now.  With that being said, there is now a tighter requirement and is enforced by Exchange setup.

There have been some challenges if .NET is not maintained and it is updated immediately prior to installing the Exchange CU.  The process to complete the .NET Framework installation will prevent Exchange setup from executing until it has completed. This can take an extended amount of time and exceed the allotted change window schedule.

 

Exchange Cumulative Updates & .NET Framework

The Exchange support matrix outlines the support requirements for a given version of Exchange, and we will specifically focus on the .NET Framework support requirements.  In the release posts for Exchange CUs the changes to .NET requirements are announced.  What typically happens is that a given CU will introduce support for version X of .NET.  That is optional for a couple of CUs, and then becomes mandatory after that.  This was done so that customers can gradually plan and adopt these changes in a controlled fashion.

For example:

Exchange 2019 RTM & CU1 supported .NET Framework 4.7.2

Exchange 2019 CU2 added support for .NET Framework 4.8  in addition to 4.7.2

Exchange 2019 Cu3 supported 4.8 and 4.7.2

Exchange 2019 CU4 Requires 4.8

 

Exchange Support Stance For .NET

Note that versions of .NET that are not listed in the support matrix for a given version of Exchange is not supported.  The below is taken from the current version of the matrix.

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.

This means that to maintain support you have to ensure that the correct version of .NET is installed.  You can refer to this post where these issues were previously discussed.

 

The intent is that customers should install the CU which adds support for the new .NET framework, then test and evaluate the new .NET Framework in their lab.  In a separate subsequent change window, .NET Framework can be updated in production in preparation of the Exchange CU which requires it.  If this approach is followed, then you probably have not seen the issue which sparked this post.

 

Installing .NET Framework and Exchange CU in The Same Maintenance Window

If .NET was not installed/updated in a previous maintenance activity, it is more than likely you will encounter a blocking issue when installing .NET and the Exchange CU in the same maintenance window.

After installing .NET and restarting the server, not that a process called mscorsvw.exe will consume a certain percentage of CPU.  In the lab environment below, this is a 4 vCPU system and the process is intended to be low impact so that it does not consume resources.  It is running on a single core in effect and will not go about the 25% in this example.

But while this is running, you cannot start Exchange setup.  It must complete.

 

While it is good that the server resources are not consumed, the clock is ticking in the maintenance window and the service is idling as it was placed in maintenance mode.

Wouldn't it be good to expedite this and move on with the other tasks in our maintenance window so we can get back to bed?

 

Accelerating .NET Generation

It is possible to make the process complete faster by using more server resources. This needs to be done manually by running the below command in an elevated cmd prompt.

Ngen.exe is the CLR Native Image Generator.  Depending on the .NET Framework the path may be different.

A couple of examples:

C:\Windows\Microsoft.NET\Framework\v4.0.30319.1\Ngen.exe ExecuteQueuedItems

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Ngen.exe ExecuteQueuedItems

 

Note that after running the command, the CPU usage dramatically increases.

 

This allowed the required compilation jobs to complete quickly, and we can then move to the matter in hand - installing the Exchange CU.

 

 

Cheers,

Rhoderick