As part of our continued commitment to strengthening security across Exchange Online, we want to inform our customers about an important change coming to the Exchange Online PowerShell module.
What...
Updated Mar 18, 2026
Version 3.0
Blog Post
So, just to clarify, is this a client-side change then? Will older versions of the module still work with -Credentials, or are you going to block ROPC service-side at some point?
WRT to supported scenarios, there are few cmdlets that do not work with application context/MSI. What will be the alternative to manage those?
Also, what about the SCC cmdlets/connectivity method?
- Nino_Bilic
Microsoft
I'll answer the first part of your question, Vasil (other parts someone else will). The changes made here are both client and service side:
- Yes, PowerShell modules starting with the version specified will not have that parameter, and you could after that day still use the older PS version with the Credential parameter. So yes, this is a client-side change.
- Also yes, there will be a service side change which will eventually break this no matter which client (PS version) you use on client side. And that change is the overall deprecation of ROPC flow. Once that goes, it's gone. Once that service change is made, no matter which version you have client side, the parameter will not work.
VivekHi Vasil, For the first part of the question, as mentioned by Nino, to start with it will be client-side change post June 2026. And eventually in the long term, the changes would be made server side that would break all the older versions as well. The timelines for this are not yet decided.
The deprecation would impact both Connect-ExchangeOnline as well as Connect-IppsSession. The SCC cmdlets that do not work in App only modes, will not be supported as these cmdlets are not intended to be used in automation scripts. In case you believe these are required for your specific scenarios, we can discuss to get your requirements.
We are facing an issue where the Export-ActivityExplorerData cmdlet has recently stopped functioning when using app‑only authentication (CBA).
Our application is correctly configured with the Exchange.ManageAsApp and Security Reader roles and permissions.|
However, we are now encountering the following error both in local PowerShell sessions and within Azure Automation. Since the alternative method using the ‑Credential parameter is also being deprecated, we would like to understand whether Microsoft has recently enforced any change that blocks the use of Export-ActivityExplorerData with app‑only authentication.
$res = Export-ActivityExplorerData -StartTime $start -EndTime $end -Filter1 $flt1 -PageSize 100 -OutputFormat json
Write-ErrorMessage : |System.AggregateException|One or more errors occurred.
At C:\Users\kusanj\AppData\Local\Temp\tmpEXO_myjaxxmt.skb\tmpEXO_myjaxxmt.skb.psm1:1191 char:13
+ Write-ErrorMessage $ErrorObject
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidResult: (:) [Export-ActivityExplorerData], AggregateException
+ FullyQualifiedErrorId : [RequestId=cd1a2cda-9c20-e221-e8f4-f655863f6f68,TimeStamp=Wed, 11 Mar 2026 05:21:22 GMT],Write-ErrorMessage
Could you please clarify if this is an intentional restriction by Microsoft and guide us on how to proceed for this specific scenario?
