Released: June 2020 Quarterly Exchange Updates

[The_Exchange_Team]

Today we are announcing the availability of quarterly servicing cumulative updates for Exchange Server 2016 and 2019. These updates include fixes for customer reported issues as well as all previously released security updates. 

Changes to OWA’s Blocked File Extensions

This quarterly update adds additional file types to the default OWA Mailbox Policy BlockedFileTypes list. The new extensions added to this list are listed in KB4559446. This change was made to increase security by preventing users from being able to download these attachment types.

Addition of Pipelining Support to Restore-RecoverableItems

This update also addresses a customer reported issue whereupon the Restore-RecoverableItems didn’t support pipelining which made its use more difficult. This update adds pipelining support to this cmdlet. You can find more details in KB4547707.

Release Details

The KB articles that describe the fixes in each release and product downloads are available as follows:

• Exchange Server 2019 Cumulative Update 6 (KB4556415), VLSC Download
• Exchange Server 2016 Cumulative Update 17 (KB4556414), Download, UM Lang Packs

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps here to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the currently supported cumulative update for the product version in use, e.g., 2013 Cumulative Update 23; 2016 Cumulative Update 17 or 16; 2019 Cumulative Update 6 or 5.

For the latest information on Exchange Server and product announcements please see What's New in Exchange Server and Exchange Server Release Notes.

Note: Documentation may not be fully available at the time this post is published.

The Exchange Team

[RAJASEKHAR GOLLAPALLI]

Good to have additional file extensions in OWA, Pipeline support in Restore-Recoverable items. 

[Davyd_]

what about the complete disabling of TLS 1.0/1.1?
has it become a fully supported configuration or need to wait for additional announcements?

[Lukas Sassl]

@Davyd_ Do you know this three-part series?

https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-tls-guidance-part-1-gettin...

https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-tls-guidance-part-2-enabli...

https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-tls-guidance-part-3-turnin...

Part 3 is about turning off TLS 1.0/1.1

[Davyd_]

of course! I even have it in my bookmarks.

The preparatory steps have been completed for a long time, but as far as I understand it was recommended to wait - from other articles, I concluded that Microsoft planned to release the final recommendations and patches (and disable tls 1/0/1.1 in Office 365) just at this time.

Running ahead of the Microsoft is not the best idea.

[Lukas Sassl]

It's possible to disable TLS 1.0/1.1 with Exchange 2016 CU9+ and the latest .NET which is supported by CU in use. Disabling TLS 1.0/1.1 was a frequently asked feature. I've seen many customers who fulfil the requirements, running TLS 1.2 only. Are you referring to other articles published by Microsoft?

[Davyd_]

Hi Lukas, 

we were confused by this piece from 3-d part of this article:

"It is our intention in the near future to provide additional guidance to customers on the cipher and hashing algorithms that we recommend be used to best secure Exchange Server communications."

from it we concluded that we need to do all the preparatory work but do not rush.

it is also embarrassing that Microsoft has not yet made this step for its own cloud:

https://docs.microsoft.com/en-us/office365/troubleshoot/o365-security/prepare-tls-1.2-in-office-365

https://docs.microsoft.com/en-us/office365/troubleshoot/o365-security/tls-1-2-in-office-365-gcc

we have more than 10,000 employees and they also stay at home so discretion in the current situation is justified in my opinion

[Lukas Sassl]

Exchange 2019 use TLS 1.2 only with a customized set of cipher suites and hashing algorithms by default (https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-2019-now-available/ba-p/60...). We have removed legacy ciphers and hashing algorithms by default. This is not the case when it comes to Exchange 2016. It's possible and recommended to disable weak ciphers and hashing algorithms. There is an EHLO blog post from 2015 talking about this: https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-tls-038-ssl-best-practices/ba-p/6...

Deprecation enforcement of TLS 1.0 and 1.1 is currently paused due to SARS-CoV-2 (COVID-19). There are millions of users using Microsoft 365 services and we need to make sure, that everybody have enough time to prepare for the deprecation of TLS 1.0/1.1 . 

Getting rid of TLS 1.0/1.1 is a process that requires time and careful planning. If there are for example Windows 7 / Server 2008 R2 OS in place (hopefully not ;)), you need to make sure that TLS 1.2 is enabled as default for WinHTTP (https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-sec...). 

Failure to plan carefully means that some users may no longer be able to access the service.

[Davyd_]

Thank you Lukas!

this is the article on which my doubt is based:  "For now) Wait to disable TLS 1.0 on the Exchange server"! 

we have the same doubts - some users from personal devices still connect using outdated protocols and this is a large amount of organizational work 

[Lukas Sassl]

Okay, but this article is from 2015, outdated and replaced by the newer guidance (3 part series listed above) since we added support to completely disable TLS 1.0/1.1 with Exchange 2016 CU9 

[null null]

Hello

Do you know if running Get-ADServerSettings command on the Exchange 2016 Edge server role crashes with following error has been fixed? thanks

WARNING: An unexpected error has occurred and a Watson dump is being generated: Unable to cast object of type
'Microsoft.Exchange.Data.Directory.SimpleServerSettings' to type 'Microsoft.Exchange.Data.Directory.RunspaceServerSettings'.
Get-ADServerSettings : Unable to cast object of type 'Microsoft.Exchange.Data.Directory.SimpleServerSettings' to type
'Microsoft.Exchange.Data.Directory.RunspaceServerSettings'.
At line:1 char:1
+ Get-ADServerSettings
+ ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-ADServerSettings], InvalidCastException
+ FullyQualifiedErrorId : System.InvalidCastException,Microsoft.Exchange.Management.ADServerSettings.GetAdServerSettings

[itops2020]

Hi All

Does any one apply it

is there any issue found after deployment ?

[Davyd_]

already in the process of deployment in production - so far nothing interesting, 

except that the installation on the VM took too long (I'm not sure that this is the root cause, but on physical servers everything is as usual).

[DrmTheater]

Davyd_ what virtual technology are you using and how long did it take to upgrade Exchange?  I'm planning to running the CU17 update next week and we are running Exchange on VMware 6.5. Thanks. 

[Davyd_]

Hyperv - it took about 2 hours (even if the virtual disks were on the SSD),

although the update of the physical server took about 30 minutes (not counting reboots and so on)

[mstoffa]

I have a question and trying to find the best place to post this because it is related with SameSite Cookies and trying to see if CU17 may address this issue.  I am currently running two Exchange 2016 Servers CU16 behind a Big IP Load Balancer.  I was aware of the change that was stated back in February on the Exchange Team Blog site about SameSite Cookies and needing to have CU16 applied which came out in March.  Both of my servers are running CU16 and we are on premises only (no hybrid setup). I just started having issues a few weeks ago with users trying to login to Exchange Web Access from Google Chrome (no issues with Firefox, Microsoft Edge, Microsoft Edge Chromium, Etc).  I get a login screen and am able to login and just get redirected back to the login screen.   To test this in Chrome I changed the "SameSite by Default Cookies" from "Default" to "Disabled"  I was able to login to Web Access with no problem.  If I changed it back I had the same behavior.  To temporary fix the problem with our Domain devices I was able to modify our Google Chrome ADMX policy to set "Revert to legacy for SameSite Cookies on these sites" for our site for Exchange Web Access. 

From the article that was written on the Exchange Team Blog back in February 2020 and other things I have read it was recommended to install the Beta version of Google Chrome and test sites.  I ran this for some time and never ran into any issues with Exchange.  I also used the Developer Tools in Google Chrome and can see that this appears to be a SameSite Cookie issue being blocked by Google Chrome.  

I have found very little about other users having any problems and I wanted to try and find a place to post this to get some suggestions or see if anyone else is having a similar problem.  I was going to look at applying CU17 because it does appear to address an issue I have been experiencing for awhile now with exporting E-Discovery Search PSTs.  However I have been able to use the workaround for this with the old DLL file. 

So my question is has anyone else experienced this issue and do you know if CU17 addresses it?  It was my understanding that CU16 was to address the problem with SameSite Cookies and Google Chrome.   

[mstoffa]

Just an FYI, I believe I have fixed the issue I was having with Exchange and SameSiteCookies.  The issue appears to be related with the Big IP Load Balancer we are using.  I found an iRule on F5 DevCentral for SameSiteCookies that has been updated several times to version 1.4.  I tested using this iRule and the Cookie appears to be getting written correctly and I am no longer getting a SameSiteCookie being blocked by Chrome with Default Settings for Chrome.  I know this is not exactly related with CU17 as I posted above but I wanted to put a solution with this if anyone else runs into a issue like this. 

[jordanl17]

We're on Exchange 2016 CU14 and would like to go straight to CU17.  We are on .NET 4.7.2, so I'll need to install .NET 4.8 first.  reboot, run all Windows Updates, reboot, then run CU17 installer from elevated command prompt, wait a lot of time because I'm on a VM, and then done???? (and then reinstall DUO mfa for OWA).  anyone forsee any issue?  (I don't see where only jumping 2 CUs is recommended, but I remember hearing that.)

[T_East]

Really simple question here to help with a bit of confusion over Prepare/AD.

Environment is Exchange 2016 CU5 looking to go straight to CU17. Single domain, meet all the other requirements (C++, .NET).  Confused about the Prepare/AD steps in CU12.

Can I just run the Setup.exe in the CU17 ISO (as a Domain Admin with all the appropriate group memberships) Wizard and let it take care of everything for me?