Announcing General Availability of the Exchange Online PowerShell v2 Cmdlets
Published Jun 03 2020 10:00 AM 31.4K Views

At Microsoft Ignite 2019, we announced new Exchange Online management cmdlets and showed how they can be used to perform fast and highly reliable data retrieval operations. Today we’re delighted to be able to announce the general availability and full support of these cmdlets in all Exchange Online environments.

The V2 module is now available in the PowerShell Gallery and we recommend all Exchange Online customers start using these new cmdlets right away.

There are many good reasons to start using this module.

Firstly, it’s easy and non-disruptive to you, the admin - The new EXO V2 module contains all the existing Remote PowerShell cmdlets, as well as 9 new V2 cmdlets. So you can use the new module with no impact or change to your day to day tasks or scripts.

So if there’s no impact or change, why use it? There are in fact two great reasons.

Firstly, the new module is entirely Modern Authentication based. If you start using this, you are getting off Basic Authentication for your admin tasks, and as you know, that’s a good thing because Basic Auth is going away in Exchange Online. So just switching to this module means your connection is more secure and you have one less thing to worry about.  

Secondly, and this is the real bonus – there are (currently) 9 new REST based cmdlets for the most commonly executed tasks and they are considerably faster and more reliable than their v1 counterparts.

How much faster and more reliable? Since we made the cmdlet module available in preview last year, we have seen millions of calls into Exchange Online using this module and these new cmdlets. In the month of May 2020 alone, we saw 150 million commands executed against Exchange Online using just the the 9 new cmdlets in the new module. That number is so big we’re going to say it again, and bold it. 150 million. And that’s in just one month.

Over that time, we’ve seen these cmdlets be 4-8x faster than their predecessors and seen them prove to be considerably more reliable (as confirmed by the feedback we’ve had). We are ready for prime time now, as 150 million executions in a month – was just us ‘testing’. (The numbers are quite something aren’t they)

We have plans to continue evolving and improving the module and we’re very open to feedback, either here on the blog or in the Office 365 Admin/Exchange Admin UserVoice forum here.

We can share that we’re considering adding more cmdlets, so we’d like to hear which cmdlets you think are most important. We’re currently working on support for PowerShell Core, and are hard at work on Service Principal and Certificate Based Auth support to provide a solution to those wanting non-interactive scenarios (we will blog about this separately).

We hope that you download and try out the new module today, we really think you’ll enjoy using it and the benefits you get from it. Please also see our previous blog post about this module as it contains some frequently asked questions about it.

The Exchange PowerShell Admin Team

18 Comments

Congrats team, keep up the good work.

Iron Contributor

So you're planning to sunset basic authentication, but the brand new module you made doesn't support Powershell 7. What's your recommended go-forward plan for these users then?

JGrote_1-1591288750703.png

 

Brass Contributor

Whilst this is semi good to see similar to @JGrote I have to say that I am disheartened to see this not have PowerShell v7 support, both on Windows and off of Windows. As I commented in this twitter thread I know that many teams at Microsoft are still living in PowerShell v5.1 (on box in Win10 & Server 2016+) so perhaps see little need for this but as we are seeing HUGE numbers of PowerShell v7 starts on non-windows oses, this "oversight" needs to be prioritised as more and more admins start to use not just PowerShell v7 on Windows but on Mac's and Linux variants as well.

 

@The_Exchange_Team - I am happy to facilitate converstations with you from the wider PowerShell community if that would be of use to help you in planning this to come in a future release.

Copper Contributor

@The_Exchange_Team  Does this include the exchange cmdlets https://docs.microsoft.com/en-us/powershell/module/exchange/set-mailboxmessageconfiguration?view=exc...

 

Specifically referring to "Set-MailboxMessageConfiguration"

 

 

Thanks

Microsoft

@JGrote  @Ryan Yates - Support for PowerShell 7(on Windows & Linux) is under preview testing. It will be announced in coming month. 

 

@Carlos-Authentix - All the Remote PowerShell Cmdlets which were earlier accessible via New-PSSession are available in this V2 module. Depending on the Admin role assigned to the logged-in account, it will be available for use in the session.

Iron Contributor

There is not parity for several commands. For instance, this filter doesn't work in the new exorecipient but works fine in the old one

JGrote_0-1591380112344.png

 

Copper Contributor

@The_Exchange_Team  Does it support running scheduled scripts (non-interactive) ? i am looking for instructions if it does. whenever i try to connect using connect-exchangeonline -userprincipalname <upn> on windows powershell , this pops up a login form for few seconds and go away and connection works fine but for scheduled scripts it fails possibly because of the popup form . i am trying to see how this would work for non-interactive scripts.

Brass Contributor

Excellent work @The_Exchange_Team , the REST based cmdlets are really fast and works well. Specially when you have over 100k and growing environment to manage\report.

I would like to see upcoming faster cmdlets for below, which is slow and errors out for tenant wide extracts currently.

 

#Get DL members

Get-DistributionGroupMember

Get-DistributionGroup

 

This is not Exchange Online, however still has the same issue:

Get-MsolUser

Brass Contributor

Intune Microsoft security baselines do not allow WinRM basic authentication. However, this new module requires basic authentication to login using MFA. How are we supposed to work around that?

Copper Contributor

@The_Exchange_TeamKeep up the good work. 

Where could one report potential bugs?

 

I believe the Get-EXOMailbox command is not properly retrieving the mailitemsaccessed logging attribute

 

When attempting to retrieve which mailboxes have the new MailItemAccessed logging enabled, using the Get-EXOMailBox command does not retrieve expected results

Running the same command using the legacy Get-Mailbox command produces the expected results

85301770-3cf43780-b476-11ea-9723-cb89143dd5f3.png

 

Please see the screenshot below. This shows that the Get-EXOMailbox is not pulling the correct auditing settings when calling an unlimited set of results. All results match between the two commands with the exception of "MailItemsAccessed"85338364-266ad200-b4b0-11ea-9c8a-ba824d04c1fb.png

It does appear when I call a specific identity, I return the expected results

85338443-4e5a3580-b4b0-11ea-957a-01f241e57421.png

 

 

Steel Contributor

Any insight on when the -CerrificateThumbrint and other App-Only auth parameters will be released?

Copper Contributor

Is it possible to load Connect-ExchangeOnline and Connect-IPPSSession with in the same Powershell session?

Seems like they use the same PSSession.

Steel Contributor

@mark3grahams You can do it if you use -Prefix when Connect-ExchangeOnline, like this:

 

Connect-ExchangeOnline -UserPrincipalName <yourUPN> -Prefix EXOv2

Connect-IPPSession -UserPrincipalName <yourUPN>

 

I only included the -UserPrincipalName so that you can hopefully reuse existing refresh token.  The Prefix parameter will make all the Exchange Online cmdlets be like this:  Get-EXOv2Mailbox, Get-EXOv2MailboxPermission, Get-EXOv2OrganizationConfig, etc.

 

You can choose the prefix of your choice, not sure all the rules but see the help for Import-PSSession to get the details on that.

Microsoft

@Jeremy Bradshaw CertificateThumbprint with App-Only parameter support has been announced Public preview here - https://techcommunity.microsoft.com/t5/exchange-team-blog/modern-auth-and-unattended-scripts-in-exch... 

Steel Contributor

@navgupta Thanks very much!  This is so exciting.

Copper Contributor

The PowerShell team over on GitHib have been going well ensuring that PowerShell supports other operating systems that aren't Windows.

I, for example, use PowerShell on macOS on a daily basis to administer my clients MS365 instances.

It is becoming a problem however that new tenancies have modern authentication enabled by default, and PowerShell on macOS only supports legacy authentication.

I would love to be able to use these on macOS and Linux to administer MS365 and EXO without having to spin up a Windows 10 VM every time.

@The_Exchange_Team - are there any plans to support this on non-Windows operating systems?

 

When installing on macOS, I get the following error:

 

PackageManagement\Install-Package : Unable to load shared library 'api-ms-win-core-sysinfo-l1-1-0.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libapi-ms-win-core-sysinfo-l1-1-0.dll, 1): image not found

Copper Contributor

We found some interesting behavior when EnableErrorReporting is enabled on the Connect-ExchangeOnline command in EXOV2. 

Without:

Connect-ExchangeOnline
Get-Mailbox $testMailbox
Get-MailboxPermission $testMailbox

These commands work as you would expect.  The first positional parameter is treated as the identity to be retrieved. 

 

With EnableErrorRecording:

Connect-ExchangeOnline -ShowProgress $false -EnableErrorReporting -LogDirectoryPath 'C:\temp\ConnectExchangeOnline.log'
Get-Mailbox $testMailbox

The Get-Mailbox command returns this error:

TerminatingError(Invoke-Command): "Cannot bind parameter 'ErrorAction'. Cannot convert value "jblack-o365" to type "System.Management.Automation.ActionPreference". Error: "Unable to match the identifier name jblack-o365 to a valid enumerator name. Specify one of the following enumerator names and try again:
SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend""
Get-Mailbox $testMailbox -ErrorAction Stop

Adding an explicit ErrorAction parameter returns info for 1000 mailboxes, ignoring the identity positional parameter.

 

Get-Mailbox -Identity $testMailbox

Adding an Identity parameter gives the expected results.

 

Other examples:

Get-MailboxPermission $testMailbox
TerminatingError(Invoke-Command): "Cannot bind parameter 'ErrorAction'. Cannot convert value "jblack-o365" to type "System.Management.Automation.ActionPreference". Error: "Unable to match the identifier name jblack-o365 to a valid enumerator name. Specify one of the following enumerator names and try again:
SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend""
Get-MailboxPermission $testMailbox -ErrorAction Stop
cmdlet Get-MailboxPermission at command pipeline position 1
Supply values for the following parameters:
Identity: 
Copper Contributor

We have been updating OWA signatures using Set-MailboxMessageConfiguration for the past 6+ months. Suddenly, and with no change on our part, Set-MailboxMessageConfiguration has started to have no effect. Our business heavily depends on this cmdlet and we would really appreciate your feedback/guidance. Someone else posted the same issue on SO here: https://stackoverflow.com/q/69764573/152630.

Example (that previously worked):

 

Set-MailboxMessageConfiguration -Identity "joe@domain.com" -SignatureHTML "My new sig" -AutoAddSignature $True -AutoAddSignatureOnReply $True
 

Interestingly, after manually running Set-MailboxMessageConfiguration in a local PowerShell, we see the correct result in Get-MailboxMessageConfiguration (https://www.screencast.com/t/X9i4BY1jSb) but NOT in the OWA UI. Please advise.

Version history
Last update:
‎Jun 05 2020 09:36 AM
Updated by: