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

i can also confirm rewriting the code from 

 

 powershell.AddScript("Get-Mailbox " + SelectedUsername + "*");
                            runspace.Open();
                            powershell.Runspace = runspace;

to

 

                            powershell.AddCommand("Get-Mailbox");
                            powershell.AddParameter("Identity", SelectedUsername);

                          
                            runspace.Open();

it works just fine, but we use the addscript function a lot of place in the code, so its a big tast to re write everything. 

Copper Contributor
Copper Contributor

As a best practice, should I install windows hotfix and Exchange CU security update separately? For example, Microsoft update finds 2 Windows server April hotfix and Exchange update 5001779, should I install windows hotfix at first ,then restart server, install Exchange update and restart server?  Or just select all hotfix let Microsoft update do its job? Thanks.

Steel Contributor

I suspect I'm also having problems after the patch. I used to re-link Linked Mailboxes multiple times a week but today, suddenly today (after installing the patch yesterday) the same command does not work and I get the following error and it says there an errors Proxy method RPS and I assume RPS means Remote PowerShell?

 

Error on proxy command 'Set-Mailbox -Identity:'Test.User@domain.com' -LinkedDomainController:'dc.accountforest.net' -LinkedMasterAccount:'AF\testuser'
-LinkedCredential:'System.Management.Automation.PSCredential' -Confirm:$False -Force:$True' to server DC.resourceforest.net: Server version 15.02.0792.0000, Proxy method RPS:
Cannot process argument transformation on parameter 'LinkedCredential'. A command that prompts the user failed because the host program or the command type does not support user interaction. The
host was attempting to request confirmation with the following message: Enter your credentials..
    + CategoryInfo          : NotSpecified: (:) [Set-Mailbox], CmdletProxyException
    + FullyQualifiedErrorId : Microsoft.Exchange.Configuration.CmdletProxyException,Microsoft.Exchange.Management.RecipientTasks.SetMailbox
    + PSComputerName        : exchange.resourceforest.net
Copper Contributor

Hello, after 2016 Installation  from CU 18 to CU20 that we can install KB5001779 completely  broken all services. 

 

We have no idea to fix this tried many nothing works. :(

 

 

We get following error on powershell. (see blow)  

Also in eventvwr:

many ASP.NET  eventID 1310  for all different virtuall directories (ECP, EWS,OAB, ........)  e.g.

Spoiler
 

Application information:
Application domain: /LM/W3SVC/1/ROOT/EWS-82-132630328195781290
Trust level: Full
Application Virtual Path: /EWS
Application Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\EWS\
Machine name: MS108

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

Exception information:
Exception type: ConfigurationErrorsException
Exception message: Could not load file or assembly 'Microsoft.Exchange.Data.Directory, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. (C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\EWS\web.config line 65)

 

 

 

 

 

New-PSSession : [ms108.xxxxx] Connecting to remote server ms108.xxxxxx failed with the following error
message : The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from
the destination computer. The content type is absent or invalid. For more information, see the
about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed

Copper Contributor

Hello, after 2016 Installation  from CU 18 to CU20 that we can install KB500 completely  broken all services. 

 

We get following error on powershell. (see blow)  

Also in eventvwr:

many ASP.NET  eventID 1310  for all different virtuall directories (ECP, EWS,OAB, ........)  e.g.

Spoiler
 

Application information:
Application domain: /LM/W3SVC/1/ROOT/EWS-82-132630328195781290
Trust level: Full
Application Virtual Path: /EWS
Application Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\EWS\
Machine name: MS108

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

Exception information:
Exception type: ConfigurationErrorsException
Exception message: Could not load file or assembly 'Microsoft.Exchange.Data.Directory, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. (C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\EWS\web.config line 65)

 

 

 

 

 

New-PSSession : [ms108.xxxxx] Connecting to remote server ms108.xxxxxx failed with the following error
message : The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from
the destination computer. The content type is absent or invalid. For more information, see the
about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed

Copper Contributor

Hello All,

Does anyone know if we nee to re-apply the update if we go from Exchange 2016 CU19 to CU20? 

Copper Contributor

@MIJ2021 We had the exact same issue. Same Update-Procedure and the Sec Update broke stuff with the same errors within event log as you stated.

 

We just solved it by reinstalling the CU20 from an elevated command line and leaving the Security Update out this time after installing the CU20. Took a while, but worked. 

 

Maybe that works for you, too! :)

Copper Contributor

We also have No Language support when we try to connect via Remote PowerShell using Script Blocker. Anyone has solution yet for this problem?

 

Copper Contributor

@kbegg00 yes, you need to reapply everytime you upgrade the latest CU

 

Copper Contributor

@liujun 

 

此修补程序仅适用于Exchange服务器。

 

如果您不使用Exchange,则无需修补。

 

If you are not using Exchange server, then no need to update.

Copper Contributor

The April 2021 patch has broken our cross forest free\busy, is anyone else experiencing the same issue? We are now seeing 400 Bad request errors in the MSExchange Availability logs.

Microsoft

@fw888888 (for some reason I can't tag you) - Windows and Exchange fixes are totally separate so I do not know that it matters. I think just letting MU do it's thing is OK in this case.

@MIJ2021 - also check this (linking to specific scenario): https://docs.microsoft.com/en-us/exchange/troubleshoot/client-connectivity/exchange-security-update-...

@kbegg00 - As already mentioned - yes, you need to install if you move up a CU. That is because currently there is no CU that has April fixes 'built in natively' (that can be expected in June CU)

@Prasad3435 - Have you seen a reply from madsholme1165 just few comments back? Basically update from .AddScript() to .AddCommand() will unblock you.

Copper Contributor

After install KB5001779 on Exchange 2016 CU20, NetApp SnapManager for Exchange (7.2.1) is stopped working.

I see the following error:

 

[04/15 22:42:16 028] Getting dash board info...
[04/15 22:42:16 028] Calling PowerShell to get current exchange server...
[22:42:16.028]  [PowerShell Cmdlet]: get-exchangeserver -status -identity HQ-EX1
[04/15 22:42:16 028] [PowerShell Cmdlet]: get-exchangeserver -status -identity HQ-EX1
[22:42:16.075]  [Remote PowerShell Cmdlet Error]:The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
[04/15 22:42:16 075] [Remote PowerShell Cmdlet Error]:The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
[22:42:16.075]  [PowerShell Cmdlet]: get-exchangeserver -status -identity HQ-EX1
[04/15 22:42:16 075] [PowerShell Cmdlet]: get-exchangeserver -status -identity HQ-EX1
[22:42:16.106]  [Remote PowerShell Cmdlet Error]:The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
[04/15 22:42:16 106] [Remote PowerShell Cmdlet Error]:The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
[22:42:16.106]  [PowerShell Cmdlet]: Get-DatabaseAvailabilityGroup -Identity HQ-EX1
[04/15 22:42:16 106] [PowerShell Cmdlet]: Get-DatabaseAvailabilityGroup -Identity HQ-EX1
[22:42:16.169]  [Remote PowerShell Cmdlet Error]:The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
[04/15 22:42:16 169] [Remote PowerShell Cmdlet Error]:The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.

 

How to fix that ?

 

 

Microsoft

@Alternator - Please contact the vendor; they will need to modify how PS code is called in this particular case - change from .AddScript() to .AddCommand() and then it will work.

Copper Contributor

Nino Bilic

Thank you for answer.

We and a lot of sysadmins are HAPPY to see these changes.

We double happy, because this product is outdated and EOL.

Now we don't have working backup by Netapp.

Thank you guys for your hard work!

 

;-(

 

 

 

Copper Contributor

@Nino Bilic 

should this be read as ms is not gonna change it back to ps.AddScript() will work again?
our support tools is using AddScript to run big scripts, and its a bit easyer to handle than having to mess with addcommand on all those diffrent commands. 

Copper Contributor

@Nino Bilic Any update on multiple 3rd party monitoring tools now broken by this update?     Modifying powershell script on a 3rd party monitoring platform is hidden inside of code and likely signed so not easy to modify.

 

This puts us in a very hard place - do we proceed with a security update that looks very important and break all of our message flow and database monitors, or go with monitoring and no security update.  Neither answer is satisfactory for 2 platforms that worked well together when we started this week.

 

Thanks

 

Greg

Copper Contributor

Anyone have any system running outlook 2013 or 2016 on windows 7?  After this update was applied to our Exchange server, now systems running Outlook with Windows 7 can not connect to our exchange server.  They all get "The Server is not available".  It's for sure related to Windows 7, as I just upgraded a system to Windows 10, and now no issues with outlook connecting to our exchange server.

 

Anyone have any ideas, yes I know Windows 7 no longer supported. :(  But we still have a few stragglers waiting to be updated.

Copper Contributor

Any special instructions for rolling back the patch?

Copper Contributor

@Nino Bilic Any update or workarounds for the accounts with "$"? Is it known if issues caused when patching is performed using account with $ or after the upgrade all accounts with $ will experience issues?

Copper Contributor

At this point, I'm leaving one patched server facing the Internet.  The rest will only be CU20 so that we can perform admin tasks with $ accounts.

Microsoft

@GregS410  - we can now confirm that the change that broke several 3rd party products as well as some home-grown code calling .AddScript() is not going to be rolled back and .AddCommand() is a way forward. I have just added the Known Issues section to the blog post to reflect this (a KB article will follow next week)

@jsab5 - uninstallation should be simple via the add/remove; why would you?

@ddovnar - At this time, the $ issue is still under investigation; we know what the work around is (rename accounts) but we do realize it is a workaround. It is unclear where this will go, sorry to be vague but that is how it is right now.

@Corbett Enders - we definitely recommend that you update all of your servers; you have made some assumptions but they might not be correct. It is understandable that it is really bad that we do not have a full answer on the $ situation at this time (still under investigation) but protecting the environment should be the primary concern.

Copper Contributor

@Nino Bilic  the assumption that the other unpatched servers are not at risk if they are not accessible from the Internet?  Are you saying they are still at risk?

 

We only have $ admin accounts, if I patch them all, how do I manage my environment?

Copper Contributor

@Nino Bilic Can you confirm if you will fix it so AddScript will work again, or areyou saying we should reformat all our tools and code to use AddCommand, even though not every script fits inside the AddCommand.. (multi lines scripts are gonna be a pain like this)..

Copper Contributor

@Nino Bilic This is really ridiculous.    A hotfix changes functionality that has been in use for years with no advance notice breaking monitoring tools that enterprises use to keep our servers healthy and find issues and fix them proactively.    So now I lose all of this with no notice.    How can you justify doing this to your customers?   The exchange team needs to reconsider restoring the broken functionality ASAP.   This is not a way to treat the customers who administer your products.   A change like this should have been included in a cumulative update with advance notice so that 3rd party vendors have time to fix it and Exchange administrators can make better decisions.

Copper Contributor

Thanks @Nino Bilic and the @The_Exchange_Team for jumping on getting these patches out to us as fast as you can and supporting the remainder of on prem servers. Looking forward to Exchange 2021.

Iron Contributor

Thank you @madsholme1165 and @Nino Bilic for the information you have provided.

We have been able to make the changes to our custom application to start using:

powershell.AddCommand

Instead of:

powershell.AddScript

This has fixed the original issue we had:

 

System.Management.Automation.RemoteException: The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.

 


Hope this is helpful to others having similar issues.  This AddScript seems related to the vulnerability that we are patching.

Copper Contributor

AddCommand mabye be a work around, but i dont see how its more secure than addscript. You need to add that back, running bigger scripts remote with addcommand is gonna be a mess! Admit you messed up, and fix it, rater than just saying "recode youre stuff".. after all is it not the reason we pay microsoft these expensive licensce fees? so that we can trust oure stuff keeps running ? COuld we please get a statement if you are looking into to readding the addscript function? or is it gone forever?

Copper Contributor

I Completely agree with @madsholme  this needs to be fixed, and not through your system admins and 3rd party software vendors under the bus like this

Copper Contributor

We have Win 2012 R2 w/ Exchange 2016 CU20 with March updates installed and was working. Just used Windows updates to download new patch and installed. Rebooted and now Exchange Management Shell on server is broken. We get

VERBOSE: Connecting to MBX1.host.local.
New-PSSession : [mbx1.host.local] Connecting to remote server mbx1.host.local failed with the following error message
: [ClientAccessServer=MBX1,BackEndServer=mbx1.host.local,RequestId=8d98dcd9-de12-4964-8813-d7f731557639,TimeStamp=4/16/
2021 8:54:24 PM] [FailureCategory=Cafe-SendFailure] For more information, see the about_Remote_Troubleshooting Help
topic.
At line:1 char:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed
Failed to connect to an Exchange server in the current site.
Enter the server FQDN where you want to connect.:

 

Copper Contributor

Snap Manager for Exchange broke.  Had to backout.  No backups.....

Microsoft

@GregS410:

We totally understand the frustration. Unfortunately, this was a security related change and therefore we were not able to go through the normal notification period of a "feature" change.
As long as the code in question uses .invoke() to run the command on the server and not on the client then yes .AddScript() will no longer work. The fact .AddScript() was working with .Invoke() at all was actually a problem that was corrected by the April update.
If script still needs to be run import the session instead of invoking the runspace and the scripts will run without issues.
Please contact Microsoft Exchange Developer Support and they will be more than happy to directly assist in converting from a direct invoke() to a session import and invoke.
Copper Contributor

@Nino Bilic thanks for the link and the explanation. i will look into it.

Copper Contributor

After installing this patch on Windows Server 2012R2 with Exchange 2016 CU20 with March update, OWA, ECP I do get the login prompt, but after entering admin creds I get HTTP ERROR 503, along with Exchange Management Shell Powershell being broken, mail flow is now effected.  All services seem to be up and running.  Any thoughts on how to fix?

Copper Contributor

Sorry for the repeat post, I was on Exchange 15.1.2176.2 (CU19) which then broke. I downloaded Exchange CU20 and installed.  This still did not resolve. Digging through the event log, I found repeatedly

 

event ID 15021 HttpEvent, An error occurred while using SSL configuration for endpoint 0.0.0.0:444. The error status code is contained within the returned data.

 

Doing some digging I found this article. https://www.vcloudnine.de/microsoft-exchange-2013-shows-blank-ecp-owa-after-changes-to-ssl-certifica... 

 

I followed those instructions and got my server back! PowerShell, OWA and ECP and mailflow are working now.  I had never changed SSL certificates in the last year and I know OWA, ECP, PowerShell and mailflow all were working before I did this update.

 

I think I should hold off on this update till we get some more information on what is going on.

 

Microsoft

@Lyle Epstein - great that you were able to solve this problem! Can you share how you installed the update? Was it installed via Microsoft Update (MU) or a manual install and if manually, di you just double-click on the .msp file after download or did you run it from the elevated CMD prompt?

Copper Contributor

Hi @Nino Bilic . I installed the update via Windows Updates. Looking through the logs now, I had the following 3 updates to be installed. KB5001382, KB890830 and KB5001779 . All 3 were installed successfully, but when I rebooted and logged back in, the troubles began.  Looking back in Exchange logs is where I figured out I was on CU19 (sorry for the confusion). 

 

I'll monitor this blog to see when update progress is made for all.

 

Thanks,

Lyle Epstein

Iron Contributor

@Nino Bilic Hello Nino. KB5001779, just like KB5000871 is not visible by running get-hotfix or by looking for updates in WAC when installed on a Windows 2019 Core server.   This is not a problem with other Windows Server security hotfixes - only with Exchange hotfixes.   This is an issue for administrators, installers, etc.  When will this be addressed?   Do you see the same thing on your Windows 2019 Core servers?

Copper Contributor

Hi @Nino Bilic . Could you please confirm if the following code with "isScript = true" would work or not?

powershell.AddCommand(new Command("commandText", isScript));

 

Copper Contributor

@Jesper_Lerch yes cu re installation

don’t work my case :frowning_face:

@Nino Bilic

 

We have tried all the steps. I think we have a "multi - problem" here. Also reinstalled the CU20 several times without Sec. patch. Exchange services are all running. Fortunately it is only for the Hybird scenario and internal relay. Smtp even works but no powershell no single web service. What sequence in the individual steps would you suggest here 1 CU20 new without sec patch. 2. try to fix 2012

HTTP 500. does this also apply to the powershell not working. hmmmm I have also patched 10 exchange environments not a single problem. Have a nice weekend. Hope i get this server running again don't want a recovery installation or new one.

Copper Contributor

@MIJ2021 That sounds similar to the issue I ran into with powershell and http error. Did you check the certificate binding on 0.0.0.0:444 ? See this article I followed that fixed mine: https://www.vcloudnine.de/microsoft-exchange-2013-shows-blank-ecp-owa-after-changes-to-ssl-certifica... 

 

Lyle Epstein

Copper Contributor

Hi @Lyle Epstein yes try this also and much more things but nothing helps. Think re install cu20 again. befor i deinstall latest sec patch and run all known fixes again. When this not help i must run a recovery installation or new one br Johannes

Copper Contributor

Hello Everyone,

 

Did anyone of you received April 2021 Exchange Server Security Updates via windows update as said by Microsoft? I am using Win 2019/Exch 2019 with CU9. I do not see anything related to Exchange yet WU.

 

"Method 1: Microsoft Update

This update is available through Windows Update. When you turn on automatic updating, this update will be downloaded and installed automatically. For more information about how to turn on automatic updating, see Windows Update: FAQ.?|"

Copper Contributor

@The_Exchange_Team I've asked my vendor to correct the code, possibly I hope to get positive response. With this, should I consider there is no further update or a fix to work with existing code?

 

Copper Contributor

I'm trying to update from CU19 to CU20 on server 2016 but the CU20 setup fails:

Error:
Access to the path 'C:\Program Files\Microsoft\Exchange Server\V15\Bin\perf\amd64\dscperf.ini.tmp' is denied.

Warning:
An unexpected error has occurred and a Watson dump is being generated: Access to the path 'C:\Program Files\Microsoft\Exchange Server\V15\Bin\perf\amd64\dscperf.ini.tmp' is denied.

This file doesn't exist.

update source: ExchangeServer2016-x64-CU20.ISO

Microsoft

@Prasad3435 - That is correct; the new behavior is expected after April update

@blazegw - have you rebooted the machine before the installation? It could be that something has the file locked; could you try to temporarily pause a file-level AV protection if it is running on the machine? Alternatively, you can run the SetupAssist script which will help you validate that the permissions are all in order when trying to run setup: CSS-Exchange/Setup at main · microsoft/CSS-Exchange (github.com) (links directly to that script description)

Copper Contributor

Mailbox databases were not enumerated by the backup job in HP Data Protector backup software, similar to the Netapp Snapmanager backup software causing Exchange backup jobs to fail.
After removing  (KB5001779)  , exchange backups began working again.

Copper Contributor

Tried to install KB5001779 on Exchange 2013 Windows Server 2012 today, it failed and now all Exchange services are now unable to start

 

Did anyone experience the same?

Copper Contributor

G'day! Was this change to a basic function (used by authorised 3rd party products) advised to the 3rd party vendors before release to ensure that stuff didn't break?

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