Exchange & .NET Framework 4.7.2

Posted on May 9, 2018 by Michel de Rooij

A quick blog on the recent release of .NET Framework 4.7.2. In the past I blogged about the tight relationship between Exchange versions and the .NET Framework, and the supported combinations of those two to deploy and run Exchange. Shortly after publishing that article, Microsoft revised its support statement:

“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”.

Now while 4.7.2 is a minor release, it is not mentioned in the Exchange supportability matrix at this moment. As such, it is not a validated combination, and you will be in uncharted territory with an unsupported configuration. The revised support statement only mentions upgrading Cumulative Update directly to a recent release as many customers were faced with a two-step upgrade process coming from old Cumulative Updates, basically ignore the supportability matrix. However, it does not mention anything about upgrading to the latest .NET Framework version at this moment. So don’t.

To block (accidental) installation of .NET Framework 4.7.2, you can configure the following registry key on your current Exchange servers to block its installation:

HKLM\Software\Microsoft\NET Framework Setup\NDP\WU\BlockNetFramework472= 1 (REG_DWORD)

or using PowerShell code:

$Version='472'
$RegKey= 'HKLM:\Software\Microsoft\NET Framework Setup\NDP\WU'
$RegName= ('BlockNetFramework{0}' -f $Version)
If( -not (Test-Path $RegKey -ErrorAction SilentlyContinue)) {
    New-Item -Path (Split-Path $RegKey -Parent) -Name (Split-Path $RegKey -Leaf) -ErrorAction SilentlyContinue | out-null
}
New-ItemProperty -Path $RegKey -Name $RegName -Value 1 -ErrorAction SilentlyContinue| out-null
If( ( Get-ItemProperty -Path $RegKey -Name $RegName -ErrorAction SilentlyContinue)) {
    Write-Output ('Installation blockade for .NET Framework {0} set' -f $Version)
}
Else {
    Write-Error ('Unable to set registry entry {0}\{1}' -f $RegKey, $RegName)
}

Exchange Updates – December 2017

Posted on December 19, 2017 by Michel de Rooij

The Exchange Team released the December updates for Exchange Server 2013 and 2016. Apart from the usual set of fixes, these Cumulative Updates also have the following enhancements:

Like announced earlier, these quartely updates introduce support for .NET Framework 4.7.1. Be advised that .NET Framework 4.7.1 will be required for the quarterly updates to be released in June 2018.
Upgrading an existing Exchange deployment with these Cumulative Updates will preserve TLS cryptography settings.
Support for Hybrid Modern Authentication (Info).

Version	Build	KB Article	Download	UMLP	Schema Changes
Exchange 2016 CU8	15.1.1415.2	KB4035145	Download	UMLP	Yes
Exchange 2013 CU19	15.0.1365.1	KB4037224	Download	UMLP	No

Exchange 2016 CU8 fixes:

4056329 Can’t access EWS from Outlook/OWA add-ins via makeEwsRequestAsync in Exchange Server 2016 and Exchange Server 2013
4054516 “Your request can’t” error when accessing an archive mailbox via OWA in Exchange Server 2016
4055953 The recipient scope setting doesn’t work for sibling domains in Exchange Server 2016
4055435 No MAPI network interface is found after you install Exchange Server 2016 CU7
4056609 Event ID 4999 and mailbox transport delivery service does not start after you install Exchange Server 2016 CU7
4045655 Description of the security update for Microsoft Exchange: December 12, 2017
4057248 Many Watson reports for StoragePermanentException in Exchange Server 2016

Exchange 2013 CU19 fixes:

4046316 MAPI over HTTP can’t remove client sessions timely if using OAuth and the resource has a master account in Exchange Server 2013
4046205 W3wp high CPU usage in Exchange Server 2013
4046182 Event ID 4999 or 1007 if diagnostics service crashes repeatedly in Exchange Server 2013
4056329 Can’t access EWS from Outlook/OWA add-ins via makeEwsRequestAsync in Exchange Server 2016 and Exchange Server 2013
4045655 Description of the security update for Microsoft Exchange: December 12, 2017

Exchange 2010
In addition the Cumulative Updates, Exchange Server 2010 SP3 also received an important update, which fixes the issue described in KB4054456. You can download Rollup 19 here, which will raise the version number to 14.3.382.0. The related KB article is KB4035162.

Notes:

Exchange 2016 CU7 and later requires Forest Functionality Level 2008R2 or later.
Exchange 2016 CU8 and Exchange 2013 CU18 do not contain schema changes compared to their previous Cumulative Update. However, they may introduce RBAC changes in your environment. Use setup /PrepareSchema to manually update the schema, or use /PrepareAD to apply RBAC changes, before deploying or updating Exchange servers. To see if you need to update the schema compared to your version or verify the update has been performed, consult the Exchange schema overview.
When upgrading your Exchange 2013 or 2016 installation, don’t forget to put the server in maintenance mode when required. Regardless, setup will put the server in server-wide offline mode post-analysis, before making actual changes.
Using Windows Management Framework (WMF)/PowerShell version 5 or later on anything earlier than Windows Server 2016 is not supported. Don’t install WMF5 on your Exchange servers running on Windows Server 2012 R2 or earlier.
When using Exchange hybrid deployments or Exchange Online Archiving (EOA), you are required to stay at most one version behind (n-1).
If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
Cumulative Updates can be installed directly, i.e. no need to install RTM prior to installing Cumulative Updates.
Once installed, you can’t uninstall a Cumulative Update nor any of the installed Exchange server roles.
The order in which you upgrade servers with Cumulative Updates is irrelevant.

Caution: As for any update, I recommend to thoroughly test updates in a test environment prior to implementing them in production. When you lack such facilities, hold out a few days and monitor the comments on the original publication or forums for any issues.

Exchange and .NET Framework 4.7

Posted on June 13, 2017 by Michel de Rooij

A quick heads-up on that .NET Framework 4.7 has recently been released and will be made available through Windows Update channels. The current versions of Exchange Server are not supported with this version of the .NET Framework, and you should not install or update to this version.

Similar to the situation with .NET Framework 4.61 around a year ago, you can prevent (accidental) upgrades of the .NET Framework by creating the following registry key on your Exchange servers:

HKLM:\Software\Microsoft\NET Framework Setup\NDP\WU\BlockNetFramework47 = 1 (REG_DWORD)

To report on the currently installed .NET Framework version on one or more computers, you can use this PowerShell script, Get-DotNetVersion.ps1. It will not only report the .NET Framework version information, but also if those registry entries to block .NET Framework 4.6.1 or .NET Framework 4.7 upgrades are present.

[PS] C:\> .\get-DotNetVersion.ps1 -ComputerName ex1,ex2 | ft -a

Computer Release NetFramework Net461Block Net47Block
-------- ------- ------------ ----------- ----------
ex1      461268  4.7          False       True
ex2      461268  4.7          False       False

The related article by the Exchange Team on this topic contains steps on how to recover the situation, in case you did upgrade. Of course, with all the dependencies on the .NET Framework by Exchange Server, you may prefer migrating contents to a new Exchange servers with a supported .NET Framework, and decommission servers where you had to remove the unsupported .NET Framework from.

More information can be found in KB4024204.

PS: The updated Unattended Exchange 2013 & 2016 Installation script will now also set the .NET Framework 4.7 blockade registry key.

Exchange 2013 and .NET Framework 4.6

Posted on September 16, 2015 by Michel de Rooij

A quick heads-up that when you are running Exchange Server 2013, you should not install or update to .NET Framework 4.6. This version of the .NET framework is not only not supported, it may also cause your Exchange 2013 server to stop functioning correctly.

When you have updated from a previous version, a suggested workaround is to uninstall .NET Framework 4.6. However, with all the dependencies on the .NET Framework by Exchange Server, it maybe preferred, when you did install version .NET Framework 4.6, to migrate contents, i.e. mailboxes etc., to a new Exchange 2013 server, and decommission the one you installed .NET 4.6.

More information can be found in KB3095369.

Exchange 2013 and .NET 4.5 fixes KB2803754 & KB2803755

Posted on September 5, 2013 by Michel de Rooij

Microsoft published an important hotfix for .NET 4.5 earlier this year. It wasn’t picked up on by many, therefor a quick write up on the matter.

Since Exchange 2013 is built on top of .NET 4.5, it is recommended to install the hotfix on all Exchange 2013 Mailbox and Multi-Role servers. The hotfix will reduce the memory consumption of the store worker processes.

If you’re using Windows Server 2008 R2, the hotfix is KB2803754 and can be requested here ; when using Windows Server 2012 the hotfix is KB2803755 which can be requested here.

After installing the hotfix, you need to do one of the following things:

Set the following registry key:
HKLM\Software\Microsoft\.NETFramework\DisableRetStructPinning=1 (REG_DWORD)
Set the COMPLUS_DisableRetStructPinning environment variable to 1

I’d prefer the first option. Note that you need to restart the server for the change to become effective.

Thanks to Tony Redmond for the heads up.