Released: April 2021 Exchange Server Security Updates
Published Apr 13 2021 10:01 AM 436K Views

Microsoft has released security updates for vulnerabilities found in:

  • Exchange Server 2013
  • Exchange Server 2016
  • Exchange Server 2019

These updates are available for the following specific builds of Exchange Server:

IMPORTANT: If manually installing security updates, you must install .msp from elevated command prompt (see Known Issues in update KB article).

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU19 and CU20
  • Exchange Server 2019 CU8 and CU9

Vulnerabilities addressed in the April 2021 security updates were responsibly reported to Microsoft by a security partner. Although we are not aware of any active exploits in the wild, our recommendation is to install these updates immediately to protect your environment.

These vulnerabilities affect Microsoft Exchange Server. Exchange Online customers are already protected and do not need to take any action.

For additional information, please see the Microsoft Security Response Center (MSRC) blog. More details about specific CVEs can be found in Security Update Guide (filter on Exchange Server under Product Family).

Two update paths are:

ExApril21SU01_1.jpg

Inventory your Exchange Servers

Use the Exchange Server Health Checker script, which can be downloaded from GitHub (use the latest release), to inventory your servers. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs and SUs).

Update to the latest Cumulative Update

Go to https://aka.ms/ExchangeUpdateWizard and choose your currently running CU and your target CU. Then click the “Tell me the steps” button, to get directions for your environment.

ExApril21SU02.jpg

If you encounter errors during or after installation of Exchange Server updates

Make sure to follow the ExchangeUpdateWizard instructions and best practices for installation of updates carefully, including when to install using elevated command prompt. If you encounter errors during or after installation, see Repair failed installations of Exchange Cumulative and Security updates.

FAQs

My organization is in Hybrid mode with Exchange Online. Do I need to do anything?
While Exchange Online customers are already protected, the April 2021 security updates do need to be applied to your on-premises Exchange Server, even if it is used only for management purposes. You do not need to re-run the Hybrid Configuration Wizard (HCW) after applying updates.

Do the April 2021 security updates contain the March 2021 security updates for Exchange Server?
Yes, our security updates are cumulative. Customers who installed the March 2021 security updates for supported CUs can install the April 2021 security updates and be protected against the vulnerabilities that were disclosed during both months. If you are installing an update manually, do not double-click on the .msp file, but instead run the install from an elevated CMD prompt.

Is Microsoft planning to release April 2021 security updates for older (unsupported) versions of Exchange CUs?
No, we have no plans to release the April 2021 security updates for older or unsupported CUs. In March, we took unprecedented steps and released SUs for unsupported CUs because there were active exploits in the wild. You should update your Exchange Servers to supported CUs and then install the SUs. There are 47 unsupported CUs for the affected versions of Exchange Server, and it is not sustainable to release updates for all of them. We strongly recommend that you keep your environments current.

Can we use March 2021 mitigation scripts (like EOMT) as a temporary solution?
The vulnerabilities fixed in the April 2021 updates are different from those we fixed before. Therefore, running March 2021 security tools and scripts will not mitigate the vulnerabilities fixed in April 2021. You should update your servers as soon as possible. Please note that if March EOMT is ran after April updates are installed, it will mistakenly mention that systems are possibly vulnerable (As EOMT is not aware of April updates).

Do I need to install the updates on ‘Exchange Management Tools only’ workstations?
Servers or workstations running only Microsoft Exchange Management Tools (no Exchange services) do not need to apply these updates.

Why are there security updates two months in a row?
Microsoft regularly releases Exchange Server security updates on ‘patch Tuesday’. We are always looking for ways to make Exchange Server more secure. You should expect us to continue releasing updates for Exchange Server in the future. The best way to be prepared for new updates is to keep your environment current.

Is there no update for Exchange Server 2010?
No, Exchange 2010 is not affected by the vulnerabilities fixed in the April 2021 security updates.

Is there a specific order of installation for the April 2021 security updates?
We recommend that you update all on-premises Exchange Servers with the April 2021 security updates using your usual update process.

Known Issues

  1. After application of the Exchange Server April security update CMDlets executed against the Exchange Management Console using an invoked runspace might fail with the following error message: The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode. Please see the following KB article: “The syntax is not supported by this runspace” error after installing April 2021 Exchange security u...
  2. Requesting free/busy information for a user in a different forest in a trusted cross-forest topology might fail with the following Autodiscover error: The remote server returned an error: (400) Bad Request. Please see the following KB article: "(400) Bad Request" error during Autodiscover for per-user free/busy in a trusted cross-forest topol...
  3. Administrator or Service accounts ending in symbol '$' might fail connecting to Exchange Management Shell or ECP. The only workaround at this time is to use accounts without the symbol '$' at the end of the name.

Major updates to this post:

  • 5/4: Edits to Known Issues section
  • 4/16: Added a Known Issues section
  • 4/14: Added info to March EOMT note and behavior after April updates are installed
  • 4/13: Changed download links to the KB article (has additional download information)
  • 4/13: Fixed a typo in the upgrade path graphics (to reflect correct CUs for Exchange Server 2019)

The Exchange Team

231 Comments
Brass Contributor

Anyone seen an issue after installing April's KB5000871 security update & Exch2016 CU20?  First of all if you do it in that order, then you have to install KB50000871 a second time.  After that, half of my Exchange services would not auto-start after a server restart.  They did manually start thank goodness.

Iron Contributor

@Amair1608 re hotfix via Windows Update

No, the hotfix did not show up via Windows Update for me on Windows Server 2019 Core either.   It did show up on Windows Server 2016.  Inconsistencies and quirks in Exchange have been going on for years and have come to be expected with every new CU and update.  If you contact Microsoft they will likely have some excuse why it doesn't show up or they will put the onus on you to deal with it or workaround their problem somehow.  Very disappointing.

 

Copper Contributor

@The_Exchange_Team 

Having installed this update on Exchange 2016 CU19; will we need to reinstall after upgrading to E2016 CU20?

Copper Contributor

@steveallen1977 yes.

 

Copper Contributor

Hello @Nino Bilic,

We are running two Exchange 2013 CU23 installations on 2012 R2 with a cross forest configuration.

Update KB5001779 broke the ability to see the free/busy information of the other organization in both ways.

The only hints in the logs are:

 

Autodiscover,autodiscoverxxxxxxxxxx,/autodiscover/autodiscover.svc,,,false,,,,ASAutoDiscover/CrossForest/EmailDomain//15.00.1497.015,10.20.30.138,SERVERNAME,401,,UnauthenticatedRequest,POST,,,,,,,,,1338,,,,1,,,0,,0,,0,0,,0,9,0,,,,,,,,,0,8,0,,8,,9,9,,,,BeginRequest=2021-04-19T07:20:03.518Z;CorrelationID=<empty>;ProxyState-Run=None;ProxyState-Complete=CalculateBackEnd;EndRequest=2021-04-19T07:20:03.533Z;,
Autodiscover,autodiscovexxxxxxxxxx,/autodiscover/autodiscover.svc,,Negotiate,false,,,,ASAutoDiscover/CrossForest/EmailDomain//15.00.1497.015,10.20.30.138,SERVERNAME,401,,,POST,,,,,,,,,0,,,,,,,,,,,,,,,0,,,,,,,,,,,,,,0,,0,0,,,,BeginRequest=2021-04-19T07:20:03.549Z;CorrelationID=<empty>;EndRequest=2021-04-19T07:20:03.549Z;,

 

Is anyone experiencing similar/same issues?

Copper Contributor

@Nino Bilic
@Lyle Epstein


We have now solved the problem. I think it was a follow-up error or several different errors at the same time from the last CU and Sec patch in March.

The permission structure was no longer intact under
C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess
as a result the CU20 installation was not clean.

Permissions restored.
CU20 installed again
UpdateConfigFiles.ps1
UpdateCas.ps1
KB5001779

Healthcheck => all OK All functions restored.

And no Recovery Setup needed :) yeepy

 

 

Copper Contributor

 

Hi @Sascha_Z,

 

We also run a cross forest deployment and after deploying the April 2021 update it has broken our free\busy as well. We have an urgent ticket open with Microsoft and will soon escalate it to critical as our institution relies heavily on seeing each others availability. 

 

Copper Contributor

@Nino Bilic

 

When attempting to use PSRemoting to remotely manage Exchange we now get the aforementioned "The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode." error.

 

You mentioned in your post that we should use the "AddCommand" method as a workaround, but that's only helpful for those using C#. What about us admins that are trying to use PowerShell to automate things via Invoke-Command?

Copper Contributor

It was an issue after security update on the exchange 2016 server, after the update (security update release Apr 13, 2021) when system rebooted there was BSOD .

Stop code: BAD POOL CALLER

Anyone face the same thing or anyone have any information why it happen. Exchange 2016 restart after BSOD and working fine but I want to know why it's happen.

Thanks

Copper Contributor

Hi @lewis_holyfield ,

 

 

I'm glad that we are not the only ones facing this issue. Once your problem has been solved could you share some information about the troubleshooting steps?

Copper Contributor

@lewis_holyfield @Sascha_Z 

Long shot, but I've seen free/busy break between servers after disabling TLS 1.0/1.1 (and thus only supporting 1.2 and higher).

Doubt that's the case here, but trying doesn't hurt I presume.

Below registry keys will configure .NET to use higher TLS levels. Apparently it doesn't default to TLS 1.2 if it's available and not even when it's the only stack enabled.

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:00000001

for .net this looks solid. you need to adjust winhttp, powershell 5.1 and schannel (including ciphers)

Copper Contributor

@FreakyNL 

 

We do have Exchange 2013/2016/2019 so we had to configure TLS 1.2 in order for things to work. But after applying the patch things stopped working, so at this point it is worth a shot, the only reg keys we didnt have were the DWord - SchUseStrongCrypto entries and v2.0.50727 keys. I will give it a shot and let you all know.

Copper Contributor

 

I'm a team player...

So I applied the DWord entries into the v2.0/3.0 keys even though TLS_1_2 was already applied before the Big (April) Bang, but to no avail... :(

Copper Contributor

@The_Exchange_Team when can we expect april security patch via windows update?

Copper Contributor

Who has any updates how to fix free busy issue? Facing unauthenticated error on availability service and error 401 when looking into HttpProxy autodiscover logs.

On fiddler error 400 is mentioned.

 

Does the TLS 1.2 does anything? What is the impact ?

When mention that its not stable doest it fix it at all?

I saw it mentioned on other issue as a solution 

https://tkolber.medium.com/exchange-2019-free-busy-issue-with-exchange-2013-2016-ca902ca543a8

 

But haven't rediscovered myself.

I ran some scripts like updatecas.ps1 it copied some owa files to current folder but it didnt do nothing to the availability service.

I have spent 8 hours today with microsoft with no progress so far...

 

Copper Contributor

@Shaike 

 

For us, it was confirmed the April 2021 update broke our cross forest free/busy. 

Copper Contributor

Yes i also confirm that ours is broken as well. Also availavility check from microsoft connecitivity tool i get error 401

https://testconnectivity.microsoft.com/tests/EwsTask/input

Steel Contributor

Anyone here any good at refactoring scripts for this latest update? 

We use an azure automation hybrid runbook worker that drops down onto one of our On Premise servers, and invokes commands. Below is our script. Would love some help here if anyone knows what to change. 

 

 

[System.Management.Automation.PSCredential]$Credential1 = Get-AutomationPSCredential -Name 'Redacted'
$SecurePassword = $LogonSecret | ConvertTo-SecureString -AsPlainText -Force
$parameters = @{
  ConfigurationName = 'Microsoft.Exchange'
  ConnectionUri = 'http://redacted/PowerShell'
  Credential = $Credential1
  Authentication = 'Kerberos'
  
}
Invoke-Command @parameters -ScriptBlock {
    New-RemoteMailbox -Name ($Using:FirstName + " " + $Using:LastName) -FirstName $Using:FirstName -LastName $Using:LastName -Password $Using:SecurePassword -UserPrincipalName $Using:LogonName -PrimarySMTP $Using:LogonName -OnPremisesOrganizationalUnit $Using:OU -Archive
    Set-User -Identity $Using:LogonName -StreetAddress $Using:StreetAddress -City $Using:City -StateOrProvince $Using:State -PostalCode $Using:Zip -Office $Using:OfficeLocation -Phone $Using:PhoneNumber -Title $Using:Title -Department $Using:Department -Company $Using:Company -CountryOrRegion "United States"
    Set-RemoteMailbox -Identity $Using:LogonName -EmailAddressPolicyEnabled $true
    }
Steel Contributor

I figured this out. Switched to importing the module as described in the blog below, removed the codeblock and invoke commands, and it worked.

 

https://www.codeisahighway.com/how-to-use-office-365-exchange-powershell-module-in-azure-automation/

 

 

 

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://redacted/powershell -Authentication Kerberos -Credential $Credential1
Import-Module (Import-PSSession -Session $Session -DisableNameChecking -AllowClobber) -Global

    New-RemoteMailbox -Name ($FirstName + " " + $LastName) -FirstName $FirstName -LastName $LastName -Password $SecurePassword -UserPrincipalName $LogonName -PrimarySMTP $LogonName -OnPremisesOrganizationalUnit $OU -Archive
    Set-User -Identity $LogonName -StreetAddress $StreetAddress -City $City -StateOrProvince $State -PostalCode $Zip -Office $OfficeLocation -Phone $PhoneNumber -Title $Title -Department $Department -Company $Company -CountryOrRegion "United States"
    Set-RemoteMailbox -Identity $LogonName -EmailAddressPolicyEnabled $true
Microsoft

@Shaike and @lewis_holyfield - can you confirm? Do you use Federated Sharing (that works) or - if not, do you use OrgWideAccount or PerUserAccount on your Availability config?

Copper Contributor

We use availability address space with PerUserFB

Copper Contributor

@Nino Bilic 

We are using perUserFB as well.

Copper Contributor

@Nino Bilic  

 

Can we expect Security update via windows update? or we have wait till next CU released? 

 

Currently I am using win2019/ Exchange 2019 CU9

 

Copper Contributor

Microsoft recommended me to set TLS 1.2 as default for .NetFramework 4 . I didnt apply yet. I would be happy to hear if someone already did and if it fixed the free busy issue or might make others. @lewis_holyfield 

 

Copper Contributor

@Nino Bilic and @Shaike 

PerUserAccount

Copper Contributor

@lewis_holyfield did the tls fixed the free busy?or impact somehow?

Microsoft

@Amair1608 - The April security update should be on Microsoft Update (MU) already. Are you sure it is not already installed if you are not seeing it show up? It will be listed in add/remove under "Microsoft Exchange Server 2019 Cumulative Update 9 - Software Updates (1)"

Copper Contributor

Has there been a fix released for administrating the environment with accounts that have $ in the username?

Microsoft

@Corbett Enders - Not yet, no. As of now, we have no workarounds other than renaming the accounts to remove the "$" symbol from the end of the account name.

Copper Contributor

@Nino Bilic what's the state of fixing the free busy?

Copper Contributor
Copper Contributor

@Nino Bilic @lewis_holyfield @Shaike @Sascha_Z 
another broken free/busy here

cross-forest with 2 forests,EX 2013 on our end,PerUserFB

Forest 1: They can see our FB but we cannot see theirs. HTTP 400 bad requests popping up.

Forest 2: We cannot see their FB, waiting for feedback if they can see ours.  "Here we have The underlying connection was closed: An unexpected error occurred on a send.."

Copper Contributor

I have no idea how to apply .AddScript() or .AddCommand().  The script I am running (from a remote server) is as follows:

 

Invoke-Command -Session $ExOSessionVariable -ScriptBlock {Get-RemoteMailbox -Identity UserName ; Get-User -Identity UserName}

And I'm getting the following error:

 

The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.

I'm just an amateur Powershell scripter and have no idea how to apply .AddCommand().  Any help is appreciated.

 

Copper Contributor

Free busy works with tls 1.2 as default

Copper Contributor

But tls 1.2 breaks mail flow with exchange 2010.

Copper Contributor

@Shaike 

 

Not applicable as we are on Exchange 2013/2016/2019 and it was working...

 

Copper Contributor

Our Exchange Server (2016) was also pretty much bricked by these April updates, at least no email clients Outlook etc. could connect.  Microsoft spent 18 hours over night on our server getting it back up and working, the problem looks to have been a corrupt self signed certificate.  The server was working fine before hand and had had March's update applied no issues.  Anyone else had similar certificate issues and lost server functionality after applying these updates?

Copper Contributor

Hi @AndyC1969 . I had the same issue, which I documented in this thread. For me, after installing the update PowerShell, OWA, ECP and mail flow all stopped working. The fix I documented in this thread got me back up and running, it was an unknown certificate that I had to remove with netsh.

Copper Contributor

@Lyle Epstein What was the fix? 

And how dif you find the corrupted certificate what was the impact?

Copper Contributor

@Shaike I followed this guide https://www.vcloudnine.de/microsoft-exchange-2013-shows-blank-ecp-owa-after-changes-to-ssl-certifica... which lead me to the bad certificate and removal and repair. Once I did that, PowerShell, ECP, OWA and mailflow all worked again as they were broken after I installed this update. Even re-installing CU20 left it broken until I fixed the broken certificate.

Copper Contributor

Nino Bilic 


I dont see the security updated nor its showing on windows update I have been look since the day its out but until now its not showing up.

 

Amair1608_0-1619247485156.png

 

Copper Contributor

@Lyle Epstein Hi there, thanks for your comments, for us Outlook stopped working, everyone's Outlook showed "Disconnected.", and no matter what we did, it wouldn't connect.  There may have been other parts of the system that also weren't functioning, but mailflow and OWA seemed ok, as that's what we had to use temporarily.  I'm still waiting for the full RFO from our 3rd Party and Microsoft, but looking at the current certificates, this one was replaced, 'Issuer : CN=Microsoft Exchange Server Auth Certificate, NotBefore : 15/04/2021 21:52:13'. Our email didn't start working again until 4:01am on the 16th, so I don't think this was the only work that was carried out to fix it. I'm not looking forward to May's updated! ;o)

Copper Contributor

Dear all,

 

Did anyone make progress in the F/B issue? Switched .NET 4 to TLS1.2. It didn't brake something but F/B still doesn't work.

 

Sascha

Copper Contributor

@Sascha_Z 

when you test availability thorugh - what do you get ?https://testconnectivity.microsoft.com/tests/EwsTask/input

which changes did you apply on TLS ?

 

Copper Contributor

@Shaike 

 

Unfortunately this test isn't applicable for our environment because our cross domain setup works with a separate EWS connector which isn't accessible through public internet.

I've applied all of them mentioned in https://tkolber.medium.com/exchange-2019-free-busy-issue-with-exchange-2013-2016-ca902ca543a8

 

 

Copper Contributor

@Sascha_Z 

Try to change only the following and not as described in the link...

 

Create below registry key for the exchange 2016 servers and reboot the servers 


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]

"SystemDefaultTlsVersions"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]

"SystemDefaultTlsVersions"=dword:00000001



 

Copper Contributor

@Shaike 

 

They are already set to these values :(

Copper Contributor

@Sascha_Z are you sure? They are not set as default 

Co-Authors
Version history
Last update:
‎May 04 2021 05:18 PM
Updated by: