Microsoft Speeds Up Deprecation of Exchange Remote PowerShell

In December 2022, Microsoft announced the deprecation of Exchange Online remote PowerShell.

The retirement date was listed as June 1st, 2023. This still holds, except a new update has now come out:

Starting on April 1st, 2023, Microsoft will block Exchange Online remote PowerShell on any tenant created after April 1st, 2023:

https://techcommunity.microsoft.com/t5/exchange-team-blog/deprecation-of-remote-powershell-rps-for-new-exchange-online/ba-p/3761567

This doesn’t make a big difference to companies just entering a new tenant and building their scripting from scratch.

But for consultants and application developers using legacy scripts and code, this is a warning of 24 days before breaking stuff.

Endless String of Rushed Changes

Don’t get us wrong: We’re big fans of REST.

Exchange Online remote sessions have several drawbacks, e.g., the constant downloading of modules, and the session throttling, which many admins have seen from time to time:

Processing data from remote server outlook.office365.com failed
with the following error message:
[AuthZRequestId=a9e46cb3-2854-44b2-a339-4220be01fc79]
[FailureCategory=AuthZ-AuthorizationException] Fail to create a
runspace because you have exceeded the maximum number of
connections allowed : 3 for the policy party : MaxConcurrency.
Please close existing runspace and try again.

It is, however, a big problem to rush release REST-backed Exchange Online PowerShell when the REST API itself is still in beta, as we documented in the following article.

Nothing has changed in that respect, as the new EXO V3 PowerShell module still relies on a beta REST API:

PS C:\> Get-Mailbox lene.hau -Verbose
VERBOSE: Computed version info: 3.1.0
VERBOSE: POST https://outlook.office365.com/adminapi/beta/8a35f394-855d-4d13-9f6f-86d8eb24dc6b/InvokeCommand with -1-byte payload
VERBOSE: received 4962-byte response of content type application/json;charset=utf-8

Also, there still seems to be no publicly available tracking of the Exchange Online REST API development.

This contrasts with the Microsoft Graph API, which has been thoroughly documented and tracked for several years.

Another rushed change from the Exchange Online team has recently taken a tremendous amount of heat:

https://techcommunity.microsoft.com/t5/exchange-team-blog/change-in-naming-convention-of-user-s-name-parameter/ba-p/3284733

The 132 (and counting) comments are a ruthless testimonial of the public response to how the Exchange Online team handles change management.