Understanding the Different Versions of Exchange Online PowerShell Modules and Basic Auth

Published May 18 2022 08:28 AM 8,748 Views

Update 5/24/2022: We have now enabled all of the cmdlets to be REST-backed if you are using the 2.0.6-Preview6 module.

Exchange Online PowerShell is deprecating support for Basic Authentication starting in October 2022. So, we wanted to clarify which versions of Exchange Online PowerShell modules are affected by this deprecation. We do realize that over time, things may have become a bit difficult to understand.

Let’s see if we can make this better!

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 v1 with MFA – this is a version of v1 that does support Modern auth.
  • Exchange v2 module (current version 2.0.5) – this module supports Modern auth and MFA and gives you the ability to use 9 very performant cmdlets and all the cmdlets available in v1 modules.
  • Pre-release (Preview) Exchange v2 module (current version 2.0.6-Preview6) – preview version of the 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 Preview v2 module. These are basically RPS cmdlets that have been modified to use REST instead of RPS when working with Exchange Online. When we’ve completed this work, you will be able to disable WinRM Basic authentication on your client machines (you can do this today if you use the Preview module). 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 2.0.6-Preview6 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:

  1. First is the PowerShell module authenticating to Exchange Online using Basic auth; and
  2. 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 we are working on that, as well (that’s what the Preview 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 v2 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

Connection command

Requires Basic auth on client WinRM

Uses Basic auth for Exchange Online

v1 Module

New-PSSession and Import-PSSession

Yes

Yes, only basic
(until October 2022)

v1 Module with MFA

Connect-EXOPSSession

Yes

No

v2 Module (current version: 2.0.5)

Connect-ExchangeOnline

Yes for RPS cmdlets (UseRPSSession)
No for REST-based cmdlets

No

v2 Module preview
(current version: 2.0.6)

Connect-ExchangeOnline

Yes for RPS cmdlets (UseRPSSession)
No for any REST cmdlets

No

Summary

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 and v2 modules. If, however, you disable WinRM Basic auth, you will be able to use only REST-based or REST-backed cmdlets. Update 5/24/2022: We have now enabled all of the cmdlets to be REST-backed if you are using the 2.0.6-Preview6 module.
  • If you are using only the RPS cmdlets, move to the v2 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!

Exchange Online Manageability Team

11 Comments
Co-Authors
Version history
Last update:
‎May 24 2022 06:09 AM
Updated by:
www.000webhost.com