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
Iron Contributor
@Nino Bilic @The_Exchange_Team Thank you for the nice information. We just wanted to make you aware that we are also having issues with the security update and remote powershell. This is the error that we are getting:

System.Management.Automation.RemoteException: The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
It seems we are still waiting for an official response.
Copper Contributor

We are using PRTG to monitor our Exchange Servers 2013 C23 and it can't do remote powershell with remote exchange management shell with the Exchange server after I installed the April Security update.

 

 

Microsoft

@niels haaijer - Yes, apply to Edge servers too

@Alex Sanin - There is a specifici FAQ about Hybrid in the post; but if you are running hybrid, you are running Exchange on-premises. If you are on CU23 for Exchange 2013, you simply need to either install the April update from Microsoft Update or if you are downloading it, you MUST install the update from the elevated CMD prompt. The KB article tells you what to do (in known issues) and download instructions tell you also. It should be ~30 minutes.

@Vinch_BE - yes, best is to reboot after done!

@FreakyNL - unknown at this time; we do have a repro of this and engineering is looking into it. Sorry, no better answer right now!

@Michael Hincapie @anthonytenherkel @JazDotKiwi650 @Googol @GregS410 - at this time, I do not have an answer for you; I think based on error samples you have provided (thank you!), we have a good idea where to look; engineering has been engaged on this. 3rd party monitoring is something that we cannot test for in our test passes but still - if we have deliberately changed something here, we need to document it for sure. Consider this under investigation.

Copper Contributor

@Nino Bilic Do you know if we apply the April update and then update from Exchange CU19 to CU20, do we have to reapply the patch?

Copper Contributor

@Nino Bilic  @The_Exchange_Team 

I installed correct security patch on my Exchange and it messed ECP.  Not sure why it happened. 

Finally i could recover it using following link.

 

https://docs.microsoft.com/en-us/answers/questions/116565/event-id-1310-aspnet-40-exchange-2016.html

Microsoft

@nick_ap If you update the CU, you will need to install the April SU post CU20.

@Prashant_A-Rookie This can happen if the update was downloaded for manual installation and then .msp was double-clicked on (vs. installed from elevated CMD prompt). We are working on long term solution for this but until then, .msp MUST be installed from elevated CMD prompt!

Copper Contributor
Senior Member

Is the patch applicable to Exchange Edge Servers as well?

@niels haaijer 

Yes. Tested on W2019 & Ex2019 CU9

Copper Contributor

Hey,

 

Since many of our customers reported the issues here. We wanted to communicate some more information to get this sorted faster.

 

@Nino Bilic 

PRTG is using Remote Powershell and accessing the Exchange Management Shell, which was reported as broken already. 

var credential = new PSCredential(user,pw);
var connectionInfo = new WSManConnectionInfo(false, server, port, "/Powershell", "http://schemas.microsoft.com/powershell/Microsoft.Exchange",                                                      credential)
System.Management.Automation.Runspace.Runspace = RunspaceFactory.CreateRunspace(connectionInfo);
Runspace.Open()

While the errormessage said something about Language Mode, we tried to adapt that. Sadly the System.Management.Automation.Runspaces.RunspaceFactory does not have a overload, which takes the arguments for a System.Management.Automation.Runspaces.InitialSessionState object, where you can adjust the Language Mode and a RunspaceConnectionInfo(specifically WSManConnectionInfo) object.

Once the Runspace is created, the Language Mode cannot be changed anymore.

 

Thanks,

Eugen Wilhelm (Paessler AG)

Copper Contributor

When we had the issues I had removed the powershell virtual directories through powershell on both our servers and recreated them.

They oddly also showed powershell virtual directories on the back-end. Had removed those too.

Make new powershell virtual directories, but on the back-end the 'PowerShell' didn't show up as an application but just a regular folder. Recreated it, and it's application pool, based on working server.

 

PowerShell works now, but only as user w/o $ in account.

Copper Contributor
Copper Contributor

Sorry for such a basic question but can someone please verify for me to update procedure?  I am on Exchange 2013 CU23.

 

Step 1 - Do monthly security updates from Windows update. 

Step 2 - Manually download the MSP file and install from an elevated command prompt.

 

The point being there is a manual download and install for Exchange.  Simply running Windows Update is not enough.

 

Thanks!

Copper Contributor

@FreakyNL , @The_Exchange_Team 

I have both exchange 2016 and 2019 servers.

Edge server is 2016, the edge server's exchange tool box works just fine with $ account. (The user's name and display name does not have $, the server is in DMZ, a separate domain)

Both exchange mailbox server 2016 and 2019's  exchange toolbox does not work when used with $ account (this account's name and display name has $, it still does not work even after I changed name and display name)

Both exchange mailbox server 2016 and 2019's  exchange toolbox works when used an account with $.

I re-installed the patch to one of exchange 2016 and 2019 each, and tested, the behavior is the same.

 

Because our organization does not allow PowerShell to be executed remotely, I can't test the PowerShell remote-ability.

All exchange mailbox server 2016 and 2019's local powershell works even if I used $ account.

 

 

 

 

Copper Contributor

I don't know why I can't edit my post but the previous one has misinformation/typo, so here we go again.

 

@FreakyNL , @The_Exchange_Team 

I have both exchange 2016 and 2019 servers.

Edge server is 2016, the edge server's exchange tool box works just fine with $ account. (The user's name and display name does not have $, the server is in DMZ, a separate domain)

Both exchange mailbox server 2016 and 2019's  exchange toolbox does not work when used with $ account (this account's name and display name has $, it still does not work even after I changed name and display name)

Both exchange mailbox server 2016 and 2019's  exchange toolbox works when used an account w/o $.

I re-installed the patch to one of exchange 2016 and 2019 each, and tested, the behavior is the same.

 

Because our organization does not allow PowerShell to be executed remotely, I can't test the PowerShell remote-ability.

All exchange mailbox server 2016 and 2019's local powershell works even if I used $ account.

Copper Contributor

@The_Exchange_Team @FreakyNL 

 

The problem got fixed after simply changing the $ account ID. For example changing johnd$ to john.doe fixed the issue.

 

 

Copper Contributor

Hello,

 

I tried this update on Exchange Server 2019 with the latest CU and it worked just fine, but unfortunately..

 

I applied the patch for Exchanger Server 2016 with CU19 installed on a Windows Server 2012 R2, but the server broke:

 

- All Exchange sevices seem to be running, but no one can connect to the Exchange server with their Outlook clients

- The ECP/OWA logins are "successful but show only a blank page

- Starting the Exchange Management Shell gives a lot of error messages and can not find any exchange server(s) on any site. Parts of the error messages:

 

VERBOSE: Connecting to bla.blaaa.net.
New-PSSession : [bla.blaaa.net] Connecting to remote server bla.blaaa.net failed with the follo
wing error message : [ClientAccessServer=BLA,BackEndServer=ebla.blaaa.net,RequestId=aff1b744-4ccd
-434c-ba90-29bec457cc17,TimeStamp=2021-04-14 16:25:16] [FailureCategory=Cafe-SendFailure] For more information, see th
e 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
WARNING: No Exchange servers are available in the Active Directory site my-site. Connecting to an Exchange server in
another Active Directory site.

VERBOSE: Connecting to bla.blaaa.net.
New-PSSession : [bla.blaaa.net] Connecting to remote server bla.blaaa.net failed with the follo
wing error message : [ClientAccessServer=BLA,BackEndServer=bla.blaaa.net,RequestId=33fd0e97-f88e
-4a91-a6d6-e7bcaae62ee5,TimeStamp=2021-04-14 16:25:26] [FailureCategory=Cafe-SendFailure] For more information, see th
e 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.

 

The installation did not encounter any problems at all and went "fine".

 

Any clues?

Copper Contributor

@John_Smirnoff 

Did you manually download the MSP file and installed from an elevated command prompt?

 

Copper Contributor
Copper Contributor

    Anyone actually have a success, without these issues or are they constant? Can anyone note what they may have done differently in this post to install and make the install success without these issues? We are planning on upgrading to CU19 over the next couple of days on our 4 node cluster. Then we will install the security patch pending any workarounds for ALL the issues found in this blog.

 

MICROSOFT: Your assistance would be appreciated here. You have many Exchange admin's frustrated and worried about the install of the patch. 

 

NOTES:
-Related to CU19 vs CU 20, doesn;t seem to matter. These issues occur on each.
-I think we all know now to install via Elevated cmd
-Edge servers need the patch as well
-If on CU19 and you install the patch, and updating to CU20, the CU20 paytch will need to be installed. = Nino Bilic

 

Seems pretty consistent, this patch created problems in the following areas

1. FreakyNL = If $ is in the Username = "Copied my admin account to one without $ in the names - problems be gone"
2. FreakyNL = "Admin account (only have one w/o a mailbox here I'm afraid) on either /owa or /ecp throws 'Cannot serialize context'" Seems to be if the Admin account doesn't have a mailbox. Arbitration mailbox has been mentioned as a potential.
3. FreakyNL = "Start exchange management shell doesn't work" Not sure if this is specificly because the admin account has a mailbox
4. Multiple people with Exchange Toolbox issues as well. .NET assembelies have been mentioned = FreakyNL
5. GregS410 = "something is up with the ability to remotely monitor Exchange 2016" Seems to affect many monitoring products such as PRTG
6. Prashant_A-Rookie = ECP issue may be resolved by https://docs.microsoft.com/en-us/answers/questions/116565/event-id-1310-aspnet-40-exchange-2016.html. Anyone else try this?

Copper Contributor

Is this a patch that can be installed like a regular windows update patch or is it more like a CU where the server will need downtime while the patch installs?

Copper Contributor

@Nino Bilic @The_Exchange_Team Looks like a few different problems at once

 

I see advice to remove and re-add Powershell virtual directory - does this fix the remote powershell/third party monitoring tool issue that affects us, or just the ECP issue which is not what I am seeing.

 

Also, recreating Powershell virtual directory looks more complicated on a single server lab node because its a single server.

 

I had initially installed via Windows Update powershell run from a powershell admin window.   I tried the uninstall and reinstall by downloading the .msp and installing from command prompt admin window.   no difference.

 

Hopefully this will be resolved soon, it looks like a high risk update, but breaking monitoring will cause its own problems.

 

Thanks for everyones help with this

 

Greg

 

 

Copper Contributor

@John_Smirnoff 

If outlook can't connect, if I were you, I would delete the C: and reinstall the OS, fully patch it, give the same computer name, reconnect exchange data and log disks and assign original drive letters, and install exchange in recovery mode using the latest CU. It can be done in a few hours.

Making sure users can use email is top priority in my mind, other than waiting for M$ to fix the issue as it seems they don't have a QA department anymore.

 

Copper Contributor

@RWhitmire 

It requires a downtime.

In my case,

Exchange 2016 edge took 10 min.

Exchange 2016 mailbox took 45 min

Exchange 2019 mailbox took 1 hour to apply the patch.

While it is applied yes exchange was down, and once it is done. you have to reboot the server.

 

 

Copper Contributor

@ewilhelm_paessler 

Hi there, In case this helps you I've been able to make our inhouse Exchange admin tool work with remote powershell.

I did nothing to change the setup of the runspace but changed the way powershell commands are executed and it appears to be working.

Using AddCommand() instead of AddScript()

 

Example code that is not working:

Powershell ps = GetPowerShellInstance();

ps.AddScript("Get-Mailbox -identity 'testuser@contoso.com'");

Collection<PSObject> collection = ps.Invoke();

 

Example code that is working:

Powershell ps = GetPowerShellInstance();

ps.AddCommand("Get-Mailbox");

ps.AddParameter("Identity","testuser@contoso.com");

Collection<PSObject> collection = ps.Invoke();

 

I hope this is helpful for others.

 

 

 

Copper Contributor

Thank you for the suggestions, but another problem is the hybrid environment which is a H*** to set up. We are considering different options, but we would appreciate a reply/a solution from MS very VERY much.

Copper Contributor

Thanks @Nino Bilic I installed patches on 3 node cluster Exchange 2013 last night and so far so good.

 

@jeffc1670 go to https://aka.ms/ExchangeUpdateWizard and it will tell you the steps to update Exchange 2013 CU23

 

if you have applied March security patch then you may have installed net framework 4.8 so you can skip that.

 

Don't get download from windows update.  Download the patch, use elevated command prompt to run patch .MSP.

 

Additional step that I did before installing patch is to stop ALL Exchange services manually.  during the patch install, I also keep checking the service to make sure the service doesn't restart automatically.

 

It took me about 1 hour per server.

Copper Contributor

Another frustrated engineer here.

Microsoft Exchange update KB5001779 broke the PRTG DAG sensor.....

 

The sensor was able to connect to the device using Remote PowerShell but could not retrieve access to Remote Exchange Management Shell. Ensure that remote management is enabled on the Exchange Server and the user has sufficient rights. See https://kb.paessler.com/en/topic/54353 for details. The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.

Microsoft

@-MeandExchange (for some reason I can't tag you?) - there have been tons of people who applied updates by now. Every time we release any kind of update (Su or CU) there is discussion here in blog comments about issues that come up. Every time.

@GregS410 and @Caspian - I got no updates as of now about 3rd party monitoring solutions that might be broken; we understand that this is important to folks. We have a few support tickets in play on this now, and they are sitting with someone who will be able to debug this problem. We'd call this 'under investigation' then. No workarounds or other ideas as of yet.

Copper Contributor

Thanks @Nino Bilic 

 

I just submitted a PSS case as well - hopefully this will get linked to the others.

Copper Contributor

After installing this update ems stops working for managed service accounts, so we have to switch back to regular users that have no automatic password management, which is bad. You cannot remove $ from managed account username, since install-adserviceaccount cannot find it after such change. This affects exchange 2013|2016|2019. Is there a fix for it?

Copper Contributor

Do i need to put exchange server into maintenance before installing the SU for CU23? 

any ideas?

Copper Contributor

@Nino Bilic  Probably because the "-" in the name. 

 

Discussion, yes.. But these types of issue among this many Exchange admin's no. I'm concerned to have these same issues even when following the proper procedure. Looking for additional ways to mitigate risk. Your attention is appreciated.  

Copper Contributor

@Tbrian5  put in maintenance mode will be safer.  putting the Exchange Server into the maintenance mode avoid any disconnectivity issues from the clients perspective and a seamless upgrade/update.

Copper Contributor

After many hours of troubleshooting and finding tons of errors (maybe because of our setup nad the patch??) we managed to "solve"the problem somehow, so forget about my issues. Time to hit the bed.

Microsoft

@Vgubin - as of now, we do not have workaround for either the accounts with "$" in the name or certain 3rd party monitoring solutions that cannot connect to Exchange PS/ECP after April updates.

Copper Contributor

@Nino Bilic 

 

This from the FAQ seems conflicting to me:

 

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.

 

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.

 

As I said before, I have an Exchange lite (Exchange Express) install because it's hybrid, literally it's just got management tools on it (no exchange services)

Copper Contributor

Bricked Exchange 2016. Rebooted, updates removed, all Exchange services disabled. All were re enabled and

Currently trying to fix the transport service.

Microsoft

@luke_q7 Thing is - there is no such thing as "Exchange express". If your organization is in fact in Hybrid, then you have an Exchange Server on-premises. I take it you use it for management, right? Which means that EAC, or Exchange PowerShell have to connect somewhere on-premises. So Exchange services and IIS virtual directories are running somewhere. Now, you could also have a "Management tools only" machine which only has Exchange Management Tools installed, but in that case, those management tools still need somewhere on-premises to connect to.

I am making an assumption here that you run Exchange Admin Center and/or PowerShell on-premises? If yes - there is Exchange Server somewhere. That is the machine that needs updating if you are in hybrid.

Copper Contributor

@Nino Bilic

Thanks, I guess when I say Exchange express, I meant there is no mailboxes, no DAGs etc, literally just for management purposes but yes, it is running IIS etc.

When I tried to update the CU in March from 16 to 19 (20 just arrived - I tired that too), it went on and on about no mailboxes (correct)- mailbox server role not installed, that's because everything is O365, and also issues around not being able to talk to AD (doesn't exist or can't be contacted) - probably because AD hadn't been extended.

Copper Contributor

Also issue with management shell and account using $ in the username.  I don't want to rename my account, so I guess we wait for a fix.

Iron Contributor

@Nino BilicThank you for all the information provided and for being proactive.  Just wanted to clarify that our issue with the following error is not related to the 3rd Party Monitoring Tools but with our custom tool we have. So it seems something change in the process of remote management. hope this helps. Please let us know if you need more information.

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



Iron Contributor

To give positive comments I can say, that I have pathed Exchange Server 2016 CU19 with the latest security update and it was a success. No issues found afterwards. .MSP ran from elevated command prompt.

Copper Contributor

@John_Smirnoff 

Perhaps something went wrong with the web part.

Did you run from evelated prompt like alex kim said? Otherwise run it again from elevated prompt and if it doesn't work then there's a UpdateCAS.ps1 in the bin folder of the exchange installation. Try running that and see if things improve. You can run it from regular (admin) powershell.

 

@-MeandExchange 

Yes, multiple environments without issues, all of them after renaming accounts with $ in them and fixing powershell I broke whilst troubleshooting. The environment with issues I removed and recreated powershell VDs, oddly those servers showed a VD for powershell on both the front-end and the back-end. Removing the back-end one broke some things in IIS I presume (application pool was gone and the 'powershell' on back-end showed up as a folder instead of an application). Threw the same error code in Management Shell as with $ accounts. After recreating the IIS config manually it started working (w/o $ in account then, still doesn't with $). It's not related to the account not having a mailbox.

 

@GregS410 I thought issue might stem from some non-default config on the powershell VDs (mostly them appearing on back-end too - someone might have created them by accident). If it comes from me, I'd let it be, our issues came solely from $ in account.

Copper Contributor

There’s any workaground or mitigation for those cve ? i’m using F5 for load balancer and trendmicro for endpoint (IPS included). I cannot update security right away for reason. Please advice.

Copper Contributor

Is the exchange 2019 version number supposed to bump up after the patch installation?

Mine is still CU9 version number (I think)

AdminDisplayVersion : Version 15.2 (Build 858.5)
ExchangeVersion : 0.1 (8.0.535.0)

 

Copper Contributor

@Nino Bilic, we had an issue after installing the patch on our Windows Server 2012r2 box with Exchange 2013 where %ExchangeInstallDir% wasn't expanded to the full path in any of the web.config files, with the result that assemblies wasn't loading.

We fixed this by running a find/replace to manually change to full paths in the config files.

Microsoft

@ngtlam1806 - we have not released any mitigations for those particular CVEs, no.

@boredoutofmyskull - no, the version change will not be different after SU; you can either check add/remove (the update will show there under update to the current CU) or the Health Checker script.

Copper Contributor

All of my mailboxes are in the cloud, when can we (officially) get rid of this on prem server permanently? Skype/Teams did not require us to KEEP an on prem server to manage AD objects once moved to the cloud in hybrid AD mode, why does exchange?

 

FYI: I am aware that we can technically get rid of it and edit AD objects directly but it is not a supported config.

Copper Contributor

Can you clarify a point on EX 2013 CU23. Your wizard says installs .Net 4.8 yet the Comparability Matrix says both 4.7.2 and 4.8 are support.  

Any issues with installing .Net 4.8 on top of CU 23? , is it REQUIRED for this April patch?  No issues in previous months with .Net 4.7.2 (I know, I know easy upgrade just reviewing options)

 

If it is required, can you update the KB to reflect the system requirement 

Microsoft

@David__G - Yeah, we hear you. No immediate news or announcements but we heard this loud and clear.

@KrisHappe - Unclear what you mean; I mean the ExchangeUpdateWizard will suggest to install the 'latest' if you are going from older version to CU23; it would not really make sense to suggest installation of older version? You are correct that both are supported in this scenario. And no, upgrade of .NET is NOT needed to install the April update. The wizard is really geared to be the "steps to update from older unsupported CU to latest supported CU" because once you are on latest CU, you can simply install the update (via MU or manually, from elevated CMD prompt).

Copper Contributor

After this update our support tool does not work any more. We run a exchange 2016 server, and the tool does a simple:

 

 

        public void SearchExchangeMailBox()
        {
           
            PSCredential cred = new PSCredential(ADtoolUserName, ADtoolUserPassword);
            WSManConnectionInfo connectionInfo = new WSManConnectionInfo(new Uri("http://exch01/powershell?serializationLevel=Full"), "http://schemas.microsoft.com/powershell/Microsoft.Exchange", cred);
            connectionInfo.AuthenticationMechanism = AuthenticationMechanism.Kerberos;




                using (Runspace runspace = RunspaceFactory.CreateRunspace(connectionInfo))
                {

                        using (PowerShell powershell = PowerShell.Create())
                        {

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

                            Collection<PSObject> results = powershell.Invoke();
                            foreach (ErrorRecord err in powershell.Streams.Error)
                            {
                                MessageBox.Show("Error");
                                MessageBox.Show(err.ToString());
                            }

 

 

But that now throws a error now. Nothing has change on our part. 

System.Management.Automation.RemoteException: The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
   ved System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
   ved System.Management.Automation.PowerShell.CoreInvokeRemoteHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
   ved System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
   ved System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
   ved ADTool.MainForm.SearchExchangeMailBox()
   ved ADTool.MainForm.searchBtn_Click(Object sender, EventArgs e)
   ved System.Windows.Forms.Control.OnClick(EventArgs e)
   ved System.Windows.Forms.Button.OnClick(EventArgs e)
   ved System.Windows.Forms.Button.PerformClick()
   ved ADTool.MainForm.searchBox_KeyUp(Object sender, KeyEventArgs e)
   ved System.Windows.Forms.Control.OnKeyUp(KeyEventArgs e)
   ved System.Windows.Forms.Control.ProcessKeyEventArgs(Message& m)
   ved System.Windows.Forms.Control.WmKeyChar(Message& m)
   ved System.Windows.Forms.Control.WndProc(Message& m)
   ved System.Windows.Forms.TextBox.WndProc(Message& m)
   ved System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Co-Authors
Version history
Last update:
‎May 04 2021 05:18 PM
Updated by: