Table of Contents
Part of the Effort to Move Exchange Online to Modern Authentication
Updated March 27, 2023
Microsoft’s December 15 announcement of the deprecation of Remote PowerShell (RPS) for Exchange Online was predictable but regrettable. Not that I want to keep RPS. Microsoft built RPS to allow administrators to manage Exchange 2010 on-premises servers from local workstations. But time moves on and RPS started down the slippery slope to oblivion when Microsoft began to modernize Exchange Online PowerShell with the introduction of the REST-based cmdlets in 2019. That process came to a head with the launch of V3.0 of the Exchange Online management module in September 2022.
Update: Microsoft issued message center notification MC488586 (20 Dec 2022) for this change.
Update 2: Microsoft has stretched things out to allow customers some extra time to prepare for the change. Remote PowerShell will work in tenants where it’s used today until the end of September, 2023. After that, no more Remote PowerShell. An opt-out tool is available for tenants to request the extra time.
Heading to the V3 Module
What’s happening is part of a phased approach to force Exchange Online tenants to use the V3 module.
- Usage of the V1 module will cease when Microsoft finally blocks basic authentication for connectivity protocols on January 1, 2023. This is a good thing because all clients, including PowerShell, should use modern authentication.
- Usage of the V2 module (the version that originally launched the REST cmdlets) will stop with the deprecation of this module on July 1, 2023. Although the V2 module supports modern authentication, many of its cmdlets are not modernized and therefore still have some dependencies on components like basic authentication via WinRM.
- Microsoft will stop all RPS connections from October 1, 2023. This means that any script that connects to Exchange Online using the New-PSSession cmdlet or by specifying the –UseRPSSession parameter with the Connect-ExchangeOnline cmdlet will fail and you’ll see errors like that shown in Figure 1.
With the Exchange Online management V3 module available for over two months and a deprecation date set six months away (June 30, 2023), why would anyone be upset that Microsoft has chosen to proceed to retire RPS?
Easy Change to Remove Remote PowerShell
Making the change to modern authentication without Remote PowerShell for Exchange Online is easy. First, make sure that all workstations run V3 of the Exchange Online management module. If you use Azure Automation to run Exchange Online scripts, make sure to update the Azure accounts with the Exchange Online V3 module. I use script to periodically check and update modules on local workstations and Azure Automation.
Next, find all the scripts that connect to Exchange Online and look for instances of:
New-PSSession -ConfigurationName Microsoft-Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid
Editorial note: There are many internet articles that inform readers that this is the way to connect to Exchange Online PowerShell. Many of the blogs are quite old, but I found some published in 2022 (here’s an example).
Other scripts might use the Connect-ExchangeOnline cmdlet with the –UseRPSSession parameter. I think these scripts will be less common. My concern is with old scripts that no one has looked at in a while.
Once you find the scripts, you can modify their code to use Connect-ExchangeOnline. Be sure to test the scripts afterward. Apart from the connection, no changes are necessary to cmdlets.
The compliances cmdlets contained in the Exchange Online management module continue to have a dependency on remote PowerShell. Microsoft plans to remove that dependency in the future but hasn’t provided a firm date for the change.
The Azure AD Conundrum
Microsoft wants to eliminate RPS by the end of June 2023, which is the same deadline chosen for the deprecation of the Azure AD and Microsoft Online Services (MSOL) PowerShell modules (license management cmdlets stop working after March 31, 2023). The deprecation of these modules has been delayed multiple times, but as the date approaches tenant administrators know that they must upgrade scripts to use cmdlets from the Microsoft Graph PowerShell SDK or Graph API requests. No automatic tool is available to upgrade scripts. It’s a manual process to review code, decide what SDK cmdlet might be an appropriate alternative, make the change, and then test. This is time consuming work.
For the Exchange development group to choose the same date to deprecate RPS shows an unfortunate and unhappy lack of awareness of what’s happening in the Microsoft 365 ecosystem. It’s possible that an assumption exists that different developers deal with Azure AD and Exchange Online. That assumption might be correct on-premises where the lines between Active Directory and Exchange Server are more distinct. Inside Office 365, the need for close interconnection between Azure AD and Exchange Online is obvious. Even Microsoft acknowledged this when they introduced the dual-write mechanism to update Azure AD and the Exchange Online directory some years ago.
Overall, it would be better if Microsoft pushed the date out a little to give tenant administrators and developers time to finish the Azure AD transition before needing to deal with RPS.
New Year Might Bring Relief
No doubt the Exchange developers will let us know more details about the strategy they’re pursuing to eliminate RPS over time. For now, it seems like we’re heading for an unfortunate and avoidable clash of PowerShell update exercises. That’s bad news. Let’s hope that something changes to ease the problem in 2023.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.