Blog Post

Exchange Team Blog
4 MIN READ

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

The_Exchange_Team's avatar
May 18, 2022

Update 10/2022: PowerShell module v3 is now released. References to the 2.0.6-Preview6 module in this blog post have been replaced with v3.

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.
  • 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:

  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 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

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

v3 Module

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, 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!

Exchange Online Manageability Team

Updated Oct 07, 2022
Version 5.0
  • How do we suppress the warning that's generated for the first command run when using 2.0.5?

     

    New update available!
    You are using an older version of Exchange PowerShell...

    This output is appearing on lots of internal tools made that call PowerShell in the background and causing concern/support cases.

     

    It's also not really acceptable to warn users that the current production version of the module is "old" and that we need to migrate production systems to a preview.

  • Satyajit321's avatar
    Satyajit321
    Brass Contributor

    Good work in putting it together in a straight forward article.

     

    I would like to call something out though.

    "On this note, there is no functional difference between a RPS cmdlet and its REST-backed equivalent." - Not quite, we lose the fairly useful automatic formatting data (ft). As an administrator and years of practice, its a significant difference. More on general PS behavior when compared to basic PS cmdlets.

     

    Any plans to move towards Mg cmdlets, AzureAD has already made the move. Changing the endpoint to graph.microsoft.com should bring in higher throttling benefits, which is 20 on max concurrent sessions.

     

    The new module is missing below ones for me.

    WindowsPowerShell
    FunctionConvertFrom-ExoJobData.ps1
    FunctionNew-ApplicationAccessPolicy

     

    #2.0.5

     gcm new-app*

     

    CommandType Name Version Source
    ----------- ---- ------- ------
    Function New-App 1.0 tmp_zjv1yi2a.zm1
    Function New-ApplicationAccessPolicy 1.0 tmp_zjv1yi2a.zm1
    Cmdlet New-AppLockerPolicy 2.0.0.0 AppLocker

     

    #2.0.6

    gcm new-app*

    CommandType Name Version Source
    ----------- ---- ------- ------
    Function New-App 1.0 tmpEXO_h234vekq.caz
    Cmdlet New-AppLockerPolicy 2.0.0.0 AppLocker

     

    Normal cmdlet count for non REST (-UseRPSSession) : Count : 795

    New Preview6 : Count : 793

  • RyanM's avatar
    RyanM
    Copper Contributor

    Now that all of the cmdlets are REST-backed, is there any timeframe for 2.0.6 to move from preview to be the current version of the v2 Module?

  • ians-uleth That is correct; with the Preview module, you can now use all cmdlets as REST-backed cmdlets with no WinRM basic auth. I don't see where the conflicting information is? RPS cmdlets still require WinRM Basic Auth, but now that all of cmdlets are REST-backed, it does not matter anymore what RPC cmdlets need, because you don't need RPS cmdlets anymore. If you can run Preview, of course.

  • ians-uleth's avatar
    ians-uleth
    Iron Contributor

    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.

    Could you clarify this? Does this mean that—since all cmdlets will be either REST-based or REST-backed—that we will no longer require WinRM basic auth?

     

    Because this seems to contradict that:

    v2 module preview -- requires basic auth on client WinRM -- Yes for RPS cmdlets (UseRPSSession) No for any REST cmdlets

  • Andres-Bohren's avatar
    Andres-Bohren
    Steel Contributor

    I was wondering how you can detect if your connected to Exchange Online with the REST Based commands as there is no PSSession to check for.

    Any Ideas?

  • proed's avatar
    proed
    Copper Contributor

    I recently had to connect to EXS (Exchange onpremises) and simultaneously to EXO. I did that with the -Prefix parameter from the connec-exchangeonline command. I noticed that the new rest commands do not follow the -Prefix instructions 😢 bug or feature? 😀

     

     

    edit: hops didn't saw the comment from Morgi also mentioned it

  • techienick's avatar
    techienick
    Copper Contributor

    Will the rest api's make there way onto the Graph so they can be called programmatically?

  • Morgi's avatar
    Morgi
    Copper Contributor

    I was wondering if there is a plan to make the 9 REST-based comdlets work with the -prefix setting?

    As right now those do not honor that connection configuration.