Blog Post

Exchange Team Blog
3 MIN READ

Exchange Online PowerShell v2 Module Preview – Now More Secure

The_Exchange_Team's avatar
The_Exchange_Team
Platinum Contributor
Nov 03, 2021

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.

We’re excited to let you know that we are working on a new version of the Exchange Online PowerShell v2 module, built to provide a more secure experience for Exchange Online management. This module (available now in preview as Module 2.0.6-Preview3) enables IT admins to use their Windows client machines for day-to-day management of Exchange Online in their organization without enabling WinRM basic auth!

What’s new in this Preview?

The new module allows admins to connect to Exchange Online using Connect-ExchangeOnline, which now invokes a REST API in the background, making the cmdlets more reliable. Because a Remote PowerShell connection is not established in new version, this version doesn’t require WinRM basic auth to be enabled. You can disable WinRM basic auth by running the command below:

winrm set winrm/config/client/auth '@{Basic="false"}'

Read more about WinRM basic auth here.

A few things to note:

  • This is important to understand: not all cmdlets have been converted to use REST at this time. This is a preview module that supports only a portion of all cmdlets.
  • This version allows you to use all cmdlets via a Remote PowerShell connection as well. For that, you need to pass the -UseRPSSession parameter while running Connect-ExchangeOnline.
  • If you disable WinRM basic auth, the only cmdlets that will work with this module are the ones in the attached list; other RPS cmdlets will not work without WinRM basic auth at this time.
  • Please note that the work to enable cmdlets to run without WinRM basic auth is not the same as what we did to release specific REST-based cmdlets (see Get-ExchangeOnline* cmdlets listed here). This new work (enabling cmdlets to run without WinRM basic auth on a local client machine) is simply enabling regular cmdlets to run without WinRM basic auth. Therefore, you should not expect significant performance increases based on this work, as the goal is to not change any cmdlet names or change parameters, but to begin enabling all cmdlets to run without WinRM basic auth.

Installing the Preview Module

You can use the following command to install the preview module in PowerShell Core:

Install-Module -Name ExchangeOnlineManagement -RequiredVersion 2.0.6-Preview6 -AllowPrerelease

To Install on native PowerShell you will need to install the latest Package Manager and the latest version of PowerShellGet. To do this, close all PowerShell Windows and from an elevated PowerShell session, run the following command.

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Install-PackageProvider -Name NuGet -Force
Install-Module -Name PowerShellGet -Force -AllowClobber

Restart PowerShell and then you can install the module.

If you still have issues, you can download the latest version manually and copy it into the module folder by running:

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Save-Module -Name PowerShellGet -Path C:\LocalFolder -Repository PSGallery

Then copy all contents from under C:\LocalFolder into C:\Program Files\WindowsPowerShell\Modules. Restart PowerShell and then you can install the module.

Viewing the list of updated cmdlets

To generate the list of cmdlets that we have updated, please do the following:

Connect-ExchangeOnline
Get-Command -Module tmpEXO*

This will create a list of all currently available updated cmdlets. Please note that due to preview status of this module (and related cmdlets) there might be situations that a specific cmdlet might be available one day and then becomes unavailable (if an issue is found, we would make it unavailable until the issue is resolved). That is why we suggest generating the cmdlet list by yourself when needed.

Let us know what you think! Send your product improvement suggestions and feedback to exocmdletpreview(AT)service.microsoft.com. Remember this is a preview and we plan to continue adding more cmdlets to the list of those able to run without WinRM basic auth. As we make progress, we will make more announcements!

The Exchange Team

Updated May 24, 2022
Version 12.0

30 Comments

  • Craig Brown's avatar
    Craig Brown
    Brass Contributor

    Agree with the other posters above - turn off the warning until this is GA and fully supported.  "Please note that due to preview status of this module (and related cmdlets) there might be situations that a specific cmdlet might be available one day and then becomes unavailable" - sorry, I have an organization to run that relies on this functionality, I need something reliable and fully supported.

  • Ron Houet's avatar
    Ron Houet
    Brass Contributor

    I also agree, it's out of the question to use preview versions in our production environment. 

    Please remove the warning or make version 2.0.6 GA.

  • FilipNotebaert's avatar
    FilipNotebaert
    Copper Contributor

    I agree with Sascha.

    Even though I am excited to start working with this new version, as long as it's in preview, I will not install it yet for the same reason Sascha listed above.

     

    Cheers,

    Filip

  • SaschaSeipp's avatar
    SaschaSeipp
    Brass Contributor

    The_Exchange_Team : While this certainly is a nice development, in my understanding, "preview" modules are not supported, right? So why does the current, productive ExchangeOnlineManagement module in version 2.0.5 now bug me when calling any cmdlet to update to the newest module, when this newest module (apparently 2.0.6-preview5) is still just a preview?

     

    There are other places in the Azure / PowerShell universe where it is the same: "use the preview module, or this won't work". You would never tell a customer to use the Outlook Beta to do some dedicated productive task, right? So why is this ok for admins? Or is there some basic part I don't understand about this?

     

    Best regards
    Sascha

  • JGrote's avatar
    JGrote
    Iron Contributor

    JeremyTBradshaw what they basically did was rather than do a PSSession directly, made a rest API that calls a "Command" endpoint that issues the command on your behalf and returns CLIXML back that gets re-hydrated. Pretty clever way to maintain compatibility.

     

    It's all just a wrapper around Invoke-WebRequest, which means that it can be parallelized and isn't subject to the 3 connection limit:
    https://twitter.com/JustinWGrote/status/1491537361703895040

  • Can you please clarify what these changes mean for the Verb-EXO*** cmdlets?  Are those still superior in terms of reliability in long-running scripts?  Or are all Verb-EXO*** cmdlets and all REST-API backed original cmdlets now equal?

     

    I'm running into some shortcomings with Get-EXOMailbox / Get-EXORecipient but have things on the go today that I would like to develop unattended scripts for.  This would be for clients, so I want to go with the most 'legit' thing going (that will actually work).

     

    I can do Get-EXOMailbox -ResultSize Unlimited, then Get-EXOMailboxStatistics, then do Get-Mailbox (legacy/ v2.0.5) for just a few mailboxes to get the properties I need, but were missed in the creation of Get-EXOMailbox.  Or, I can just jump to the preview module and use REST-API-backed Get-Mailbox / Get-MailboxStatistics.  But is one more reliable than the other in a 40K+ mailboxes EXO tenant?

     

    *Edited to remove whiny-boo-boo closing.

  • The_Exchange_Team 

    I am a little bit curious. I am using

    - Windows 11 

    - PowerShell 5.1

    - ExchangeOnlineManagement 2.0.5

     

    Basic Auth in WinRM is already set to false and everything works fine as far as i see. Did the Support for Basic=False alredy come with a prior Module?

     

    C:\>winrm get winrm/config/service
    Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 1500
    EnumerationTimeoutms = 240000
    MaxConnections = 300
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = false
    Auth
    Basic = false
    Kerberos = true
    Negotiate = true
    Certificate = false
    CredSSP = false
    CbtHardeningLevel = Relaxed
    DefaultPorts
    HTTP = 5985
    HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = false
    EnableCompatibilityHttpsListener = false
    CertificateThumbprint
    AllowRemoteAccess = true

     

    Regards Andres

  • The_Exchange_Team's avatar
    The_Exchange_Team
    Platinum Contributor

    DevOpsMaverick The focus of this particular work is to move the existing cmdlets to not require WinRM basic auth... but this is not the same thing as making them into "Get-EXO*" cmdlets. It is not planned to move all of the Exchange cmdlets into full-REST "Get-EXO*" model, rather move them all to nor require WinRM basic auth.

  • FlorinCopil's avatar
    FlorinCopil
    Brass Contributor

    Finally, a module that works properly on MacOS as well. 🙂

    Now, that it doesn't use basic auth anymore, the legacy commands are working as well, not only the Verb-EXO* cmdlets. So you can do Get-Mailbox as well as Get-EXOMailbox.

    We can now use PowerShell core on more OSes. (not that I don't like Windows, I do, a lot)

  • Noice !

    Any plans to move the legacy CmdLets like Get-DistributionGroupMember etc. over to Get-ExoDistributionGroupMember (i.e. REST-based CmdLets)? ...

     

    Or is there a plan to add the administration capabilitys to Graph and just have everyone go that way?

     

    Love your work !