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)
}
One of the longest standing requests of the community regarding Exchange features is the request to have the ability to share e-mail signatures between Outlook for desktop, Outlook Web Access (OWA) and mobile clients like Outlook for iOS. Several 3rd party vendors have been filling this gap with solutions with the possibility of adding standardized signatures on the transport layer or through application add-ins for the 
With the speed of development in Office 365, it is sometimes hard to track which changes have been made to your tenant. Of course, there is the roadmap and message board which you can use to keep up to date, but those are in general high level descriptions. Sometimes you may want to see what are the changes at the cmdlet level in your tenant, between tenants, or Azure Active Directory module. And there is also the occasional gem in the form of a yet undocumented cmdlet or parameter which could hint at upcoming features.
Mid-2017, I had a 
EighTwOne (821) 