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
Copper Contributor

What error do you get on FB query? @Sascha_Z 

Copper Contributor

For the F/B issue we only get error 400 "bad content", even when errortracing on other forest we didn't get anything more to go on.Haven't tried the TLS regkeys yet but I was making a status and thought of something.

error 400 "bad content" doesn't really say anything but
https://docs.microsoft.com/en-us/exchange/troubleshoot/client-connectivity/exchange-security-update-...  + "Cannot serialize context" in event viewer 4001 events  + this part of the tracelog

               userName="domain\servername$"
               tokenUserName="domain\servername$"
               authenticationType="Negotiate"
               activityId="{80003616-0007-EF00-B63F-84710C7967BB}"
               failureReason="STATUS_CODE"
               statusCode="400"

makes me think they might be related. Because there are people having issues authenticating with account names with $ in, and because it would fit the 'bad content' reply. Not sure how I can test this hypothesis though but thought I'd share

Copper Contributor

@Katrien Cornelis  waiting for your updates. 

 

Copper Contributor

@Shaike @Katrien Cornelis 

I experience pretty much the same error as Katrien and I'm also of the opinion that the dollar sign at the end of the username is the culprit. In one of our tests we changed the user to a new one without "$" and we saw different kind of problems but the error 400 was gone.

Copper Contributor

@Sascha_Z @I am curious, why do you have dollar sign in the user

Copper Contributor

@Shaike 

It's the computer account: CROSS_DOMAIN\exchangeserverA$

Copper Contributor

Did you check “ms-exch-epi-token-serialization” permission to the Source Exchange Servers over the Target Forest?

Copper Contributor

@Sascha_Z 

I'm also of the opinion that the dollar sign at the end of the username is the culprit.

If you read through the replies here you would have noticed this is a confirmed issue.

Copper Contributor

@Sascha_Z @Shaike 

Sascha I'm curious, what issues did you experience after changing to a non-dollar account and further more , how did you do that? It's not something we've chosen, it just presents itself like this.Probably related to machine acc or managed acc /impersonation.
Wondering if you tried logging on to ecp or owa with a $ account , and if it also gave issues? That would be easier to verify but I don't know if it would be reflecting the same issue or not. I'll try anyway.

 

Shaike not sure to whom it was addressed but epi-token was checked here, as were addressspaces.Might re-export autodiscover info but that part 'pur sang' seems to be working in that for example the outlook-test autodiscover succeeds for the people from the other forest on first hit. However, the messages in E.V are about F/B but also Mailtips, Photos,.. and I think they all use autodiscover.

Copper Contributor

Nino Bilic  any update? please let me know as its already 15 days we did not apply the patch

 

Copper Contributor

unfortanetly cross forest free busy still gives 401 unauthorized, the intresting part is that using microsoft test connectivity tool i can see that availability is working.

I have found in a site mentioned that setting registry key DisableLoopbackCheck to 1.

https://server-essentials.com/support/autodiscover-outlook-and-soap-provider-failure-the-remote-serv...

is any of you fixed the free busy cross forest ?

@Sascha_Z @The_Exchange_Team 

Copper Contributor

@Katrien Cornelis  i have just noticed that you mentioned that you fix cross forest

can you explained what exactly did you exported as the following

Export-AutodiscoverConfig -TargetForestDomainController "dc.contoso.com" -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true

 

i had mailtips issue as well but once i restarted the application pool of autodiscover, is that what you did on your side?

 

 

Copper Contributor

@Nino Bilic @The_Exchange_Team : Please let us know in advance in case Microsoft is planning to stop Addscript(..) support from Skype and Lync too.

 

Copper Contributor

Update:

 

So I was apparently under the misconception we also installed the patch (it was planned but didn’t go through because of scheduling issues,apologies for the confusion).
This does explain some things, like the fact that OUR f/b is still visible to the other forests, whereas the other forests did do the patch and THEIR f/b is not working for us.

I created two test users, identical aside from one having a $ as last character in his samaccountname.

Testexfb              to A and B Autodiscover link = Status 200 after auth

Testexfb$            to A and B Autodiscover link = Status 400 after auth

 

logging on to our owa with the testexfb$ account doesn't pose any issue, I'm going to ask the other forests to try this to see if they get an error or not.

 

So despite status 400 pointing to the client (us in this case) it’s imho not a matter of sending different data but rather of the domains (A and B) no longer being able to read /accept the data.

400

Bad request

The Hypertext Transfer Protocol Stack (Http.sys) file blocks IIS 7.0 and later versions from processing the request because of a problem in the request. Typically, this HTTP status code means that the request contains characters or sequences that are not valid or that the request contradicts the security settings in the Http.sys file.

 

@ShaikeI think there was/is a misunderstanding. If I do test-autoconfig via outlook i get Status 200 on first try or second.
I can obvi be mistaken but I have the idea that autodiscover as a service is working and was always working, it's only when the impersonation comes in play that stuff stops working. Which again, would support the hypothesis of the servername$ problem.

 

 
 
Copper Contributor

@Katrien Cornelis we dont have users with $ ,honestly i dont understand for what purpose but following the case test-webservicesconnectivity gives your what?

Copper Contributor

2021-04-29 17_56_55.png

 

As already said, we do not use users with $ in the name. I only created a test user like that to see if this was causing issues on the other forests side because the samaccountname of the computerobjects have a $ at the end. Which is the account being used when using epi-serial... access you configure for the f/b.

Copper Contributor

@Katrien Cornelis yes i understand that but for epi serializarion you give access just to exchange servers$ and not end users becsuse the crossforest request is coming in behalf of the server. 

Copper Contributor

@MIJ2021 

Can you elaboratw which permissions needs ti be fixed?

 

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.

Copper Contributor

@The_Exchange_Team  @Nino Bilic people here were complaining that once an account with $ sign cannot get free busy or reach owa.

When a crossforest free busy is done the request comes from domain\exchange server$

Isnt it the same behavior?

Copper Contributor

Just had a call with microsoft support yesterday and wanted to share my info with you.

-----------------------------------------------------------------------------------------------------------------------------

Issue description

 

Per-User Free busy information in a trusted cross-forest topology not visible after security update KB5001779.

 

Free/Busy lookups based on the PerUser Availability Address Space mechanism do not work between trusted organizations (cross-forest) - Exchange 2013 On-premises organizations.

 

As we discussed, we are aware of issues with cross-forest Free/Busy requests appearing in some configurations after installation of the KB5001779 Security Update, released: April 2021 

 

Description of the security update for Microsoft Exchange Server 2019, 2016, and 2013: April 13, 2021 (KB5001779)

https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-...

 

The issue appears in configurations using the “per-user free/busy information in a trusted cross-forest topology:

https://docs.microsoft.com/en-us/exchange/architecture/client-access/availability-service-for-cross-...

 

The issue has already been reported to Our Product Group (developers of Exchange).

The problem is still under investigation.

 

Action plan (Workaround):

 

*Use the “organization-wide free/busy information in an untrusted cross-forest topology”:

 

*Use the Exchange Management Shell to configure organization-wide free/busy information in an untrusted cross-forest topology

https://docs.microsoft.com/en-us/exchange/architecture/client-access/availability-service-for-cross-...

 

*Instead of using the Availability Address Space mechanism, configure federation trusts in both the Exchange organizations and then configure organization relationships between the organizations:

 

 *Configure a federation trust

https://docs.microsoft.com/en-us/exchange/configure-a-federation-trust-exchange-2013-help

 

*Create an organization relationship

https://docs.microsoft.com/en-us/exchange/create-an-organization-relationship-exchange-2013-help

 

*Managing Federated Sharing with the EAC

https://techcommunity.microsoft.com/t5/exchange-team-blog/managing-federated-sharing-with-the-eac/ba...

 

------------------------------------------------------------------------------------------------------------------------------------------------------

 

I did not test the workaround yet so i cannot tell if it is working.

Maybe this will help some of you.

Microsoft

@Katrien Cornelis @Shaike @HeinrichsSven @Amair1608 @Sascha_Z @lewis_holyfield 

We have just published a KB article on the Free/Busy issue, talking about two ways that this can be worked around at this time; please see here:

"(400) Bad Request" error during Autodiscover for per-user free/busy in a trusted cross-forest topol...

Copper Contributor

@Nino Bilic thanks

I was suspecting that once the account that being authenticate in cross forest is the exchange server computer name$ and thats the reason we get the 401 unauthorized. Once i changed to UseServiceAccount $false  instead to $true it WORKS!

 

Now microsoft needs to update the document on:

https://docs.microsoft.com/en-us/exchange/architecture/client-access/availability-service-for-cross-...

 

Thank you!

 

Copper Contributor

@The_Exchange_Team @Nino Bilic 

The linked workaround solved our issue.

 

Thank you very much!

Sascha 

Copper Contributor

Workaround fixed it for us as well, great. Because federation wasn't an option.Thx

Copper Contributor

Has there been a fix to administrating Exchange using an account with $ at the end of the username?

Copper Contributor

@The_Exchange_Team@Nino Bilic 

 

How does one access Microsoft Exchange Developer Support?  I tried opening a developer case using all of our MS Silver Partner avenues and could not get the right answer.

Copper Contributor

@Corbett Endersnot afaik, the suggested solution is 'don't use a $' atm I think. Because that's in part what was causing the free busy problem and the workaround/fix is federation OR use dedicated svc account instead of computernames with $ at the end

Copper Contributor

Hello Nino Bilic


after not hearing from you for so long I finally applied security path of April 13th  on my staging and production Exchange 2019 CU9 this Thursday and everything works fine.

One common event warning I noticed before and after applying the patch is this. If you anyone experienced the same then please update.

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 5/22/2021 7:46:56 AM
Event time (UTC): 5/22/2021 3:46:56 AM
Event ID: c2abd3c344584b7599413857078a5301
Event sequence: 6
Event occurrence: 5
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1/ROOT/owa-1-132659982733500338
Trust level: Full
Application Virtual Path: /owa
Application Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\
Machine name: EXMAILSVR

Process information:
Process ID: 812
Process name: w3wp.exe
Account name: NT AUTHORITY\SYSTEM

Exception information:
Exception type: ArgumentException
Exception message: Invalid input value
Parameter name: input
at Microsoft.Exchange.Data.ApplicationLogic.Cafe.BackEndServer.FromString(String input)
at Microsoft.Exchange.HttpProxy.OwaResourceProxyRequestHandler.ResolveAnchorMailbox()
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalBeginCalculateTargetBackEnd(AnchorMailbox& anchorMailbox)
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<BeginCalculateTargetBackEnd>b__278_0()
at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(Action method)



Request information:
Request URL: https://85.68.45.35:443/owa/auth/x.js
Request path: /owa/auth/x.js
User host address: 192.168.1.1
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\SYSTEM

Thread information:
Thread ID: 121
Thread account name: NT AUTHORITY\SYSTEM
Is impersonating: False
Stack trace: at Microsoft.Exchange.Data.ApplicationLogic.Cafe.BackEndServer.FromString(String input)
at Microsoft.Exchange.HttpProxy.OwaResourceProxyRequestHandler.ResolveAnchorMailbox()
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalBeginCalculateTargetBackEnd(AnchorMailbox& anchorMailbox)
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<BeginCalculateTargetBackEnd>b__278_0()
at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(Action method)


Custom event details:

Copper Contributor

Has anyone running Exchange 2013 noticed their eDiscovery is broken after the April update? We've been running on the April update since right after it was released but just today I went to run a new eDiscovery and I am now getting an Error 400 Bad Request error for just those functions. The last time I ran one of these searches was just before the update so it seems to be related to the patch. Any thoughts?

Copper Contributor

Just for confirmation, do I need to install Microsoft Exchange 2016 CU21 Security Update 1 on our Edge Transport Servers in the DMZ?

Regards,

Keith

Copper Contributor

Dear All,

 

I am getting below error on in-house Exchange 2019 CU9, any idea what it is? apricate your help "Request path: /ecp/pentest.js"

 

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 12/21/2021 5:17:05 PM
Event time (UTC): 12/21/2021 1:17:05 PM
Event ID: cbd87ddb5f5446e4b2639983ee53ae54
Event sequence: 30
Event occurrence: 29
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1/ROOT/ecp-1-132835533899877201
Trust level: Full
Application Virtual Path: /ecp
Application Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp\
Machine name: MachineName

Process information:
Process ID: 6568
Process name: w3wp.exe
Account name: NT AUTHORITY\SYSTEM

Exception information:
Exception type: ArgumentException
Exception message: Invalid input value
Parameter name: input
at Microsoft.Exchange.Data.ApplicationLogic.Cafe.BackEndServer.FromString(String input)
at Microsoft.Exchange.HttpProxy.BEResourceRequestHandler.ResolveAnchorMailbox()
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalBeginCalculateTargetBackEnd(AnchorMailbox& anchorMailbox)
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<BeginCalculateTargetBackEnd>b__278_0()
at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(Action method)



Request information:
Request URL: https://publicip/ecp/pentest.js
Request path: /ecp/pentest.js
User host address: 
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\SYSTEM

Thread information:
Thread ID: 8
Thread account name: NT AUTHORITY\SYSTEM
Is impersonating: False
Stack trace: at Microsoft.Exchange.Data.ApplicationLogic.Cafe.BackEndServer.FromString(String input)
at Microsoft.Exchange.HttpProxy.BEResourceRequestHandler.ResolveAnchorMailbox()
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalBeginCalculateTargetBackEnd(AnchorMailbox& anchorMailbox)
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<BeginCalculateTargetBackEnd>b__278_0()
at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(Action method)


Custom event details:

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