Blog Post

Exchange Team Blog
2 MIN READ

Modern Auth and Unattended Scripts in Exchange Online PowerShell V2

The_Exchange_Team's avatar
The_Exchange_Team
Platinum Contributor
Jun 30, 2020

Today, we are happy to announce the Public Preview of a Modern Auth unattended scripting option for use with Exchange Online PowerShell V2. This feature provides customers the ability to run non-interactive scripts using Modern Authentication. This feature requires version 2.0.3-Preview or later of the EXO PowerShell V2 module, available via PowerShellGallery.

Check out the detailed guide on how to install/update the new EXO PowerShell V2 Module here.

As previously announced, Basic Authentication for Exchange Online Remote PowerShell will be retired in the second half of 2021. Customers who currently use Exchange Online PowerShell cmdlets in unattended scripts should switch to adopt this new feature. This new approach uses AzureAD applications, certificates and Modern Authentication. You can find detailed step-by-step instructions available here.

It’s simple to create and use sessions using this new feature. For example, if you are currently using Basic Authentication for unattended scripting, you are probably using something like this in your scripts;

 

New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

 

Once you have changed to Certificate Based Authentication, the above cmdlet pattern will need to be changed to use Connect-ExchangeOnline along with other necessary parameters. For example:

 

Connect-ExchangeOnline -CertificateFilePath "C:\Users\johndoe\Desktop\automation-cert.pfx" -CertificatePassword (ConvertTo-SecureString -String "<My Password>" -AsPlainText -Force) -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"

 

Please note the feature does not support delegation. Unattended scripting in delegation scenarios is supported with the Secure App Model which is documented here.

We hope this new feature makes it possible for you to move away from using Basic Authentication for your unattended scripting needs and appreciate the increased security this new option provides. Please do give us feedback, we really do want to hear what you think.

The Exchange Team

Updated Jul 30, 2020
Version 6.0

148 Comments

  • JGrote's avatar
    JGrote
    Iron Contributor

    YOU MUST NOT USE CNG CERTIFICATES, for some bizarre reason there's no support for it in this module, and that is the default type of certificate created/imported by Windows 10

     

    When generating your cert use New-SelfSignedCertificate -KeySpec KeyExchange to force a csp provider.


    if you see

    New-EXOPSSession : Invalid Provider Type Specified

    as an error, this is your problem. I wasted several hours, would have been nice to know...

     

    Also, it doesn't work in Azure Automation, which is where a lot of Exchange Tests run, throws a network dll error, you would think it would have been tested...

     

     

  • GautamSharma's avatar
    GautamSharma
    Copper Contributor

    This is great Addition and will help to run auto script scheduler... hope it works with Azure Automation...

  • victorguo If you install the module with -Scope CurrentUser, it will go into %UserProfile%, while if you don't do it that way, it will install system-wide into Program Files.  It's a PowerShell / modules thing, but not anything exclusive to this module.

     

    So happy to see this preview go live.

  • victorguo's avatar
    victorguo
    Brass Contributor

    The installation path for 2.0.3-preview has been changed to %UserProfile%\Documents\WindowsPowerShell\Modules\ExchangeOnlineManagement. Compared to the GA version, it is C:\Program Files\WindowsPowerShell\Modules\ExchangeOnlineManagement.

    Is this a permanent change or just for the preview version?

  • navgupta's avatar
    navgupta
    Former Employee

    JamesIII - We are only supporting Exchange Built-in roles which are available in AAD as those are the ones which can be assigned to an AAD App.

     

    DevOpsMaverick - Thanks for the note. This has been corrected and docs changes should reflect in few hours.

     

    Paul Westlake You are right and that's what we intend to tell with the parameter name. Name is generally not considered as unique and hence GUID will be the one to use. We will call it out explicitly in example.

  • Paul Westlake's avatar
    Paul Westlake
    Copper Contributor

    This is great with one slight amendment on the command... The AppID needs to be the Registered Apps AppID GUID not its displayname... Otherwise it does not locate the registered app in the target tenant... 

  • Great News. A Welcome Addition !

     

    But I was reading the https://docs.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps article Friday which made no suggestion this is a public preview ... maybe worth flagging on there in case folks come across that link without reading this blog post.

  • JamesIII's avatar
    JamesIII
    Copper Contributor

    Great News!

     

    Will this work with Exchange RBAC roles (custom roles) or only with Azure default service roles?