History of Exchange Online PowerShell module releases
We’ve released several versions of Exchange Online PowerShell modules:
Exchange v1 – this is the original way to connect to Exchange Online PowerShell and it has been used for years. You don’t need to install anything to use it because it is included with PowerShell. This module does not support Modern auth. Once Basic auth is disabled in Exchange Online, this module will permanently stop working.
Exchange v3 module – fully released version (used to be preview v2 module) that supports Modern auth and enables using Exchange Online cmdlets via REST API calls.
Different types of cmdlets
There are 3 different versions of cmdlets:
Remote PowerShell (RPS) – any of the 1000+ cmdlets you get when using any Exchange Online PowerShell module.
REST-based – any of the 9 cmdlets listed here. These were created from scratch and introduced in the v2 PowerShell module to help customers do very large bulk read operations in their tenants.
REST-backed – this is new and currently included only in the v3 module. These are basically RPS cmdlets that have been modified to use REST instead of RPS when working with Exchange Online. With this module, you are able to disable WinRM Basic authentication on your client machines. REST-backed cmdlets are more performant and reliable.
Update 5/24/2022: We have now enabled all of the cmdlets to be REST-backed if you are using the v3 module. On this note, there is no functional difference between a RPS cmdlet and its REST-backed equivalent. You should expect that all the parameters will work the same between the two versions.
Basic authentication with Exchange Online vs. on the client (WinRM)
When talking about PowerShell, there are two places where Basic auth is used:
First is the PowerShell module authenticating to Exchange Online using Basic auth; and
Second is the requirement to have WinRM Basic authentication enabled on client machine, which is a prerequisite for RPS cmdlets.
The deprecation of Basic auth in Exchange Online is not related to the requirement to have Basic auth enabled on the local client machine (WinRM) where the module is running. We know that customers want to be able to disable Basic auth on WinRM and that’s what the v3 module is about. But that work is not related to the deprecation of Basic auth for the module to connect to Exchange Online.
Further, the fact that WinRM Basic auth is enabled does not mean the PowerShell module is using Basic auth to connect to Exchange Online.
The WinRM Basic auth pipeline is essentially used for transporting Modern auth tokens when the v2 module is used. If WinRM Basic auth is disabled, the new cmdlets (both REST-based and REST-backed) will continue to work, but the older RPS cmdlets will not. It is those RPS cmdlets that today require WinRM Basic auth to be enabled on the client machine.
Putting it all together
Here’s a table that describes the above modules and their use of Basic auth:
Exchange Online PS module version
Requires Basic auth on client WinRM
Uses Basic auth for Exchange Online
New-PSSession and Import-PSSession
Yes, only basic (until October 2022)
v1 Module with MFA
v2 Module (current version: 2.0.5)
Yes for RPS cmdlets (UseRPSSession) No for REST-based cmdlets
Yes for RPS cmdlets (UseRPSSession) No for any REST cmdlets
Here’s a quick recap of what you need to know:
The use of WinRM Basic auth on a client machine is not related to deprecation of Basic auth in Exchange Online. Even after Basic auth is disabled in Exchange Online, you can still use the v2 PowerShell module with WinRM Basic auth on your client machine, which you’ll need to do if you need access to RPS cmdlets.
If you are still using the v1 version of the PowerShell module (New-PSSession and Import-PSSsession), it will stop working when Basic auth is turned off for Exchange Online (starting October 1, 2022.)
There is 100% of parity for the RPS cmdlets between the v1, v2 and v3 modules. If, however, you disable WinRM Basic auth, you will be able to use only REST-based or REST-backed cmdlets. All of the cmdlets are enabled as REST-backed if you are using the v3 module.
If you are using only the RPS cmdlets, move to the v2 or v3 module today and start using Modern auth to connect to Exchange Online, with no loss of functionality (use the UseRPSSession parameter when connecting to use RPS cmdlets).
We hope this clears up any confusion you may have had. Let us know if you have any feedback!