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

!!!The upgrade patch cannot be installed by Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update q different version of the program. !!!

What are prerequisites for thew patch?

Win Srv 2019, Exchange 2019 CU9

Thank you for keeping up the update history for the OP.

Also Kudos for the very comprehensive guidance and references how to check and apply patches correctly.

@The_Exchange_Team 

Copper Contributor

Last patch messed up the environment. Now this one does too.

If I log on with a regular user account to /owa it seems to work fine.

Admin account (only have one w/o a mailbox here I'm afraid) on either /owa or /ecp throws 'Cannot serialize context'

Powershell seems to have moved the DAG to the other server however. Now that the second one is patching I can't use the webinterface anymore though.

Microsoft

@vmilanov - are you 100% sure that you got the update for the right CU? See Repair failed installations of Exchange Cumulative and Security updates - Exchange | Microsoft Docs (this links directly to that specific error).

@FreakyNL - can you elaborate? Do you mean access /ecp is permanently broken for admin account without a mailbox only, after the installation of March and April SUs? Or did this start happening after specific CU? What version of Exchange? I would not expect /owa to work, BTW (because the account does not have a mailbox)...

Iron Contributor

Thank you for the great information. Here we go again!

Copper Contributor

Hi,

don't know. Don't have an admin account with a mailbox. Second server is running CU20 update and KB after it. Will take a while.

Start exchange management shell doesn't work, throws errors. Will connect to 2010 after attempting both 2016's.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

seems to work though.

Copper Contributor

After Exchange 2016 CU20 on the other server /ecp and Exchange Management Shell still worked on the second server.

After installing the patch it broke on that server too.

/owa and /ecp state 'Cannot serialize context' whilst PowerShell throws:

 

New-PSSession : [SERVER2.domain.local] Connecting to remote server SERVER2 failed with the following error
message : For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Micr ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed

For both the 2016 servers. It connects to the Exchange 2010 that's still alive after that.

Back-end certificates look fine on both servers.

Copper Contributor

Hi @The_Exchange_Team the link to kb5001779 appears to be dead. Can you please provide and updated link?

Microsoft

@FreakyNL Can you check the bindings on default web site and Exchange Back End? This will take you to this specific section of the troubleshooting doc: Repair failed installations of Exchange Cumulative and Security updates - Exchange | Microsoft Docs

Copper Contributor

The CU URLs are broken.  404 page comes up.  As of 7:36 EST April 13th

Copper Contributor

Link to the catalog:

Microsoft Update Catalog

Microsoft

@MrOCanada - OMG I have no idea what happened there; The KB is down? Sigh. I just changed all the links to point directly to the download pages again. Will look into KB next.

Copper Contributor

Thanks @Keith-Work-711 the Cab files are available through Windows Catalog :)

Copper Contributor

@Nino Bilic The back-end seems fine to me. /owa works for a regular user with mailbox. Neither /owa nor /ecp works for my admin account but it doesn't have a mailbox.

 

As stated Microsoft Exchange Shell fails with the errors in my previous post for both the Exchange 2016 servers after installing the patch.

 

Whilst that seems to imply there are issues with new-pssession, neither that nor enter-pssession throws errors when ran with -computername against either of them.

'Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn' seems to load fine on both of them as well and was able to run the StopDagServerMaintenance.ps1 script with that after loading Microsoft.Exchange.Management.PowerShell.SnapIn just fine.

 

Have compared output of Get-PowerShellVirtualDirectory with another customer's 2016 (patched too) and didn't really notice any differences with regards to authentication settings etc.

Did note some additional output on the customer with issues and both the default website and the back-end listed powershell virtual directories on it. The Get-PowerShellVirtualDirectory command returns a 'SerializationData' line on the 2016's powershell virtual directories. This doesn't happen at 2 other customers.

 

Copper Contributor

we are also having the same issue after the patch update on Exchange 2016 CU 19, Exchange management won't load Queue viewer not loading, after uninstalling the patch from the server everything works fine, is there any solution for this issue.

Copper Contributor
Copper Contributor

We’re running Exchange 2016 CU19 and are planning to upgrade to CU20 in several weeks. Do we need to reapply this patch after installing CU20 if we patch CU19?

Copper Contributor

@The_Exchange_Team can anyone help with this issue, I am trying to call support and waiting for the last 30 mins for the call to answer.

Copper Contributor

@alabkrishnan do you get the same error as I do?

What do you get if you start normal powershell as admin on one of the 2016 boxes and run:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Get-PowerShellVirtualDirectory | fl
Copper Contributor

@The_Exchange_Team @Nino Bilic if I start Exchange Toolbox it throws this, might be the root cause

Deserialization fails: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Exchange.Data.Directory, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Microsoft.Exchange.Data.Directory, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
   at System.Reflection.Assembly.Load(String assemblyString)
   at System.UnitySerializationHolder.GetRealObject(StreamingContext context)
   at System.Runtime.Serialization.ObjectManager.ResolveObjectReference(ObjectHolder holder)
   at System.Runtime.Serialization.ObjectManager.DoFixups()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at Microsoft.Exchange.Data.SerializationTypeConverter.DeserializeObject(Object sourceValue, Type destinationType)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog]
Copper Contributor

@vmilanov  - Make sure you have the correct download for CU19.  The CU20 and CU19 patches are different files, though the sizes are very similar.

Microsoft

@alabkrishnan - it is SUPER important that you install from elevated CMD prompt; I really want to make sure that this was done (it is unclear what the error was) - I just helped someone on Reddit with the same problem. This is exactly the symptom and resolution: Repair failed installations of Exchange Cumulative and Security updates - Exchange | Microsoft Docs

Copper Contributor

@Nino Bilic he seems to be having the same issue as I do on 2 servers and I use elevated cmd prompt with 'start Exchange2016-KB5001779-x64-en.msp'

Copper Contributor

Can someone on the Exchange team PLEASE tell us why the "run from admin" hasn't either been corrected or coded to be detected yet?  Absurd. . .

Microsoft

@FreakyNL - I am thinking that something might be going on with the Arbitration mailbox (because your Admin account does not have a mailbox). What you see is probably because of the mailbox anchoring behavior change in Exchange 2013. See this (I am pretty sure we had a KB on this, looking...)

Copper Contributor

@Nino Bilic I'm quite convinced it's something with the .net assemblies causing issues. The toolbox error seems to indicate that and considering the other parts are throwing serialization errors seems highly likely.

 

Running:

msiexec /p Exchange2016-KB5001779-x64-en.msp /l* c:\tt\KB5001779.log

But it's slow. As in 10 mins to detect space requirements and hanging in stopping services for almost 20 mins.

Microsoft

@alabkrishnan Are you also running Exchange 2013? Does your admin account also not have a mailbox? If so - can you verify that the database that hosts the SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c) mailbox is online and accessible?

@FreakyNL Did you check the location of SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c) and if the database is online?

If that mailbox is gone for whatever reason, this article explains how to get it back: Recreating arbitration mailboxes: Exchange 2013 Help | Microsoft Docs

Copper Contributor

@Nino Bilic 

PS D:\Program Files\Microsoft\Exchange Server\V15\bin> get-mailbox -arbitration | ft Name, Database

Name                                                Database
----                                                --------
SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} UserMailboxDB_1
SystemMailbox{1f05a927-8901-4be2-a0cc-0b072049efb5} UserMailboxDB_1
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 UserMailboxDB_1
SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA} UserMailboxDB_1
SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201} UserMailboxDB_1
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} UserMailboxDB_1
Migration.8f3e7716-2011-43e4-96b1-aba62d229136      UserMailboxDB_1

And yes, the database is online (DAG too).

Copper Contributor

@alabkrishnan hey, you got a $ or other special chars in your username?

Copied my admin account to one without $ in the names - problems be gone.

Copper Contributor

Hmm problems only disappeared on /ecp. Exchange Management Shell and the Exchange Toolbox still don't work.

Copper Contributor

We use Quest Unified Communications Command Suite Diagnostics to monitor our Exchange 2016CU20 servers

 

Install KB5001779 - most of the tests fail to run.  remove it, all works well.   something is up with the ability to remotely monitor Exchange 2016 with KB5001779 installed -   my testing is just in lab so far, hoping MS pulls and re-issues this one, something isn't right

Copper Contributor

@FreakyNL yes we do have $ in the admin account, as suggested after removing all issues are resolved for us.

Microsoft

@FreakyNL and @alabkrishnan - thanks, we are trying to figure out what is going on here; good to know!!

Copper Contributor

Anyone else besides @FreakyNL and @alabkrishnan had successful installation?  I am wondering if I should wait until weekend before doing the install.

 

Thanks for your response.

Copper Contributor

Please release this for older CUs like the March vulnerability, I am unable to upgrade to CU 18, 19 or 20 because the Exchange 2016 I have inherited is only installed as part of Hybrid and is just setup as a management console (Exchange express if you will). The March security update was released for customers who are unable to upgrade for one reason or another, and I know of at least one other who ran into the issues I ran into whilst attempting to upgrade.

Microsoft

@itsupport-bhms Just to give you an idea - this post has >55,000 views right now, in just under 12 hours. I guarantee you there are a ton of people who have done installations by now (I have seen multiple threads on Reddit also). Things come up sometimes, yes, but - I'd say do it.

Microsoft

@luke_q7 - the installation that you have should be a 'regular' Exchange installation; it is simply an on-premises install and you should update it. At this point, we do not have any plans to release fixes for older CUs.

March was the ONLY time that we have done such a thing (and we release security updates often, not every single month but often) - and it was because of active exploits by a particular actor (it was a very unique situation). Released updates for older CUs were not full updates either; those updates only addressed 4 March vulnerabilities. They were not 'cumulative' security updates like we release usually. Please update... Exchange Update Wizard will give you the steps that you need to follow.

Copper Contributor

@FreakyNL

 

Same here, I have exchange admin account with $ at the end, I got HTTP 400 error and/or serialization error.

Accessed ECP with an account w/o $, now I can access the ECP.

 

Thank you 

Brass Contributor

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

 

I upgraded from CU18 to CU20 successfully (cmd prompt elevated as administrator), monitoring was still fine at that point. Like I have done numerous times for both CUs and security updates. Then when I applied April security update for CU20 (cmd prompt elevated as admin), powershell is failing with this message below:

 

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.

 

It has the appropriate permissions, nothing has changed there, confirmed its still good. It was working fine before the security update. I got this same behavior on both my DR exchange servers, so not proceeding with my production ones until I know what's going on or hear from someone at Microsoft. Did the security update change something with remote exchange management shell and that was the vulnerability fix? Perhaps PRTG vendor needs to supply and update and adjust their sensor accordingly if by Microsoft design this was changed?

 

I've validated all the services automatic are running, test-servicehealth, test-replicationhealth, virtual powershell directory, exchange management shell works fine on server, get-mailboxdatabasecopystatus, reviewed application logs and no issues.

 

Hope you can help @Nino Bilic @The_Exchange_Team or someone?

 

 

Copper Contributor

Is the patch applicable to Exchange Edge Servers as well?

Copper Contributor

First 3 steps to install april security update:

1. Put the server in maintenance mode.
2. Reboot the server.
3. Install security update

 

Is it required to reboot the server after placing the server in maintenance mode? And if so, why is it required to first reboot?

 

Manage database availability groups | Microsoft Docs states:

 

Installing updates on DAG members

1. Use the steps described above to put the DAG member in maintenance mode.
2. Install the update.
3. Use the steps described above to take the DAG member out of maintenance mode and put it back into production.
4. Optionally, use the RedistributeActiveDatabases.ps1 script to rebalance the active database copies across the DAG.

Copper Contributor

Hi MS Moderator or Premier MS Engineer 

 

Exchnage 2016 CU19 Since the Security update is compatible with it after i install it, When i Upgrade to CU20 Do i need to reinstall this Update again 

since CU20 was relased on March 15 and dont include this update,

 

 

Copper Contributor

If you cannot login after applying latest CUs most likely cause is broken Certificate bindings for HTTP.

Use NETSH as detailed in this excellent article for a relatively easy fix. http://www.stormbreaker.tech/?p=173

 

RayC

Iron Contributor

Hi @The_Exchange_Team 
Following FAQ statement "While Exchange Online customers are already protected, the April 2021 security updates do need to be applied to your on-premises Exchange Server"

I kind a bit confused. Do I need to patch my "Hybrid" EXC 2013 CU23 or follow FAQ statement?
Is there any detail how Hybrid is protected ? 

Regards,
Alex 

Copper Contributor

Hello,

Do we need to reboot Exchange after applying the update only ( not the CU) ?

Thanks

Copper Contributor

@alex kim @alabkrishnan did it also resolve the issues with the Exchange Management Shell and Exchange Toolbox for you? Those seem to persist here, but maybe we should try re-applying the update with an account without a $ in the name.

 

@itsupport-bhms I presume you mean unsuccessful, technical the installation succeeded and other than some management tooling everything works. Have no issues whatsoever at 2 other customers where I applied it. This specific customer we only obtained recently and has had many people messing around in settings. They somewhat regularly have odd issues.

Copper Contributor

Hi I've installed the patch to an Exchange 2016 server, the installation seemed to go fine and Exchange appears to is operating normally post reboot, however i've got an issue with a couple of 3rd party applications that connect to exchange via remote powershell and they are both broken.

 

One is our monitoring application called PRTG, and appears to be the same issue as mentioned by @Googol.

I've enabled sensor debug logging and can see the following error message in the PRTG sensor logs.

 

2021-04-14 20:03:32,457 [DEBUG] - Running script: 'Get-ExchangeServer'
2021-04-14 20:03:32,490 [ERROR] - Error in RunRequest Get-ExchangeServer
2021-04-14 20:03:32,490 [ERROR] - Exception occured
System.Management.Automation.RemoteException: The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.PowerShell.CoreInvokeRemoteHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.CoreInvoke[TOutput](IEnumerable input, PSDataCollection`1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
at System.Management.Automation.RemotePipeline.Invoke(IEnumerable input)
at ExchangeSensorPS.ExchangeSensorProgram.RunRequest(String script)
at ExchangeSensorPS.ExchangeSensorProgram.GetExchangeProductVersion(Collection`1 result)
at ExchangeSensorPS.ExchangeSensorProgram.Main(String[] args)

 

 

Our other application that is also broken is an in house tool we use for Exchange admin tasks is producing a similar error message, the keywords are "System.Management.Automation.RemoteException: The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode."

 

Any ideas?

 

Copper Contributor

@The_Exchange_Team @Nino Bilic any chance for a fix on the $ in  user account name issue? Customer has quite a few admin accounts spread amongst several parties. They all end in $, it being one of their policies.

Brass Contributor

@JazDotKiwi650 I reached out to PRTG support and they said several customers have already reported this remote powershell issue. Their dev team is working on a hotfix/update to remediate due to the changes in Microsoft code. Hopefully its a quick turnaround and fixed soon and not have to wait for a Microsoft update. Looking like they changed it to fix the vulnerability, unless they accidentally broke it, which then we'll have to wait for an update or some combination.

 

Good luck with your other app.

Copper Contributor

Ok great thanks for letting me know @Googol .

Glad to know its not just us, I'm logging a case with PRTG support aswell.

 

Ah so if code changes are needed for PRTG then I'll also need to find out the details of that so I can update our other inhouse tool.

 

 @Nino Bilic @The_Exchange_Team Is there any guidance for developers on what changes are needed when programmatically connecting to Exchange power shell using C# ?

 

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