Blog Post

Exchange Team Blog
5 MIN READ

Faster and more reliable Exchange Online Management using PowerShell V2 Cmdlets

The_Exchange_Team's avatar
Mar 04, 2020

For more updates on this module, please see Announcing General Availability of the Exchange Online PowerShell v2 Cmdlets.

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. These cmdlets are generally 4-8 times faster and have proven to be highly reliable for bulk-retrieval scenarios. We have seen more than 50,000 total downloads of the V2 module available via PowerShellGallery and have seen around 11 million V2 cmdlets being executed in the past 30 days. Many large enterprises have already started using the new cmdlets in their production environment and we’re very proud of that.

The new EXO V2 module contains all the old Remote PowerShell cmdlets as well as (currently) 9 new V2 cmdlets. These 9 cmdlets use REST API to fetch data. This change alone makes them faster and highly reliable.

Since the new module is available on PowerShellGallery, it can be easily installed using the command line. Compared to the MFA PowerShell module, which required a Click-2-run installation, the new module is far better suited to automation scenarios.

The module is currently in Public Preview and will be released as “Generally Available” soon.

What’s new post Ignite?

Support for managing customer tenants using Delegated Authentication

The new module also supports CSP delegation for DAP (Delegated Admin Privileges) partners. Delegate admins can manage customer tenants by passing their customer tenant ID during Connect-ExchangeOnline

 

$cred = Get-Credential
$customerTenant = “contoso-electronics.onmicrosoft.com”
Connect-ExchangeOnline -DelegatedOrganization $customerTenant -Credential $cred

 

Read more on how to use it in MFA PowerShell module here

Identity is now a positional parameter and it supports name/alias

The initial release of V2 module didn’t support using name and alias as Identity parameter. This was a conscious call to provide better performance of cmdlets as resolution of name and alias was a costly operation. However, with the constant feedback from preview community, we learnt that a lot of scenarios require quick data access for a small set (most commonly 1) of mailbox using PowerShell interactively. And in those scenarios having support for positional parameter and using name alias brings a lot of convenience.

For example:

 

Get-ExoMailbox -Identity contosoadmin@fabrikam.com

 

…can now be written as:

 

Get-ExoMailbox contosoadmin

 

Assuming contosoadmin is the alias of user contosoadmin@fabrikam.com of course.

Improved error handling, reduced data type differences and many more bug fixes

The latest version of client module contains bug fixes across Get-Help, unwanted session kills, almost all the properties have same data-type across RPS and V2 cmdlets thus reducing script migration overhead. Also, the dateTime property now honors the client-side locale and shows time according to your local machine time zone.

Please read the detailed release notes here

How do you get the best out of V2 cmdlets?

Use PropertySets and Properties parameters

Traditionally, RPS Cmdlets returned all mailbox properties in the output object. Most of these properties were not usually required but were part of the returned object which caused performance degradation.
In the new module we have bucketized certain related set of properties and called them “PropertySets”. These PropertySets are simply buckets of 2 of more Properties. We have exposed 2 new parameters in EXO Cmdlets: Properties and PropertySets.

  • PropertySets – it accepts one or more (in comma separated form) names of the properties buckets i.e. PropertySets. The following example will return all the properties mentioned in Minimum, Archive & Custom:

 

Get-ExoMailbox -PropertySets Archive, Custom

 

  • Properties – it accepts one or more (in comma separated form) name of the output property

 

Get-ExoMailbox -Properties LitigationHoldEnabled, AuditEnabled

 

You can specify PropertySets as well as Properties at the same time:

 

Get-ExoMailbox -Properties IsMailboxEnabled, SamAccountName -PropertySets Delivery
Get-ExoCASMailbox -Properties EwsEnabled, MAPIBlockOutlookNonCachedMode -PropertySets ActiveSync 

 

We have also introduced a new concept call “Minset” which is a bare minimum set of properties. If you don’t specify any PropertySets, you will get the bare minimum properties every time. If you specify a PropertySet while invoking a cmdlet, you will only get the “Properties” specified in the PropertySets parameter and you won’t get the properties listed in “Minimum” bucket.

Read more about property sets here.

Use Piping to get multi-threading benefit

Pipelines act like a series of connected segments of pipe. Items moving along the pipeline pass through each segment.  The V2 module invokes multiple threads on the client machine to parallelize execution and retrieval and thus provides a better performance in data retrieval.

It can be clearly seen that for-looping took 900 seconds to get Mailbox Statistics for 100 mailboxes while it only took 48 seconds for the same operation using pipe operator. Nice!

What's Next?

Support for PowerShell Core

The V2 module works only on Windows PowerShell version 5.0 or lower. It doesn’t work on non-Windows Operating Systems i.e. Linux, Mac.

We plan to add the support for PowerShell 6 and 7 in the new V2 module so that it works seamlessly on Linux, Mac and windows.

Support for Automation using Certificate Based Authentication

Exchange Online management didn’t have official support for app-only scenarios i.e. background jobs authentication, scheduling etc. Currently, we are working on support app-only authentication using Certificates and Service Principal objects available in AzureAD. This is really important work and will help get you off Basic Authentication in Exchange Online, which as we hope you know, is being retired.

Frequently asked questions

How to handle the Windows 10 PowerShellGet Error?

For PowerShell version 5.1 which got shipped with Windows, a known issue causes an error during a module installation from PowerShell Gallery.The error message is shown below and the installation doesn’t succeed when this warning is shown:

Warning: The specified module ‘ExchangeOnlineManagement’ with PowerShellGetFormatVersion ‘2.0’ is not supported by the current version of PowerShellGet.

The current workaround is to forcefully install PowerShellGet using the below cmdlet:

 

Install-Module PowerShellGet -Scope AllUsers -Repository PSGallery -Force -AllowClobber

 

You will then need to re-load the PowerShell session; you can do this with the command:

 

PowerShell

 

You should then be able to successfully use the latest version of PowerShellGet

 

Install-Module -Name ExchangeOnlineManagement -Verbose -Scope AllUsers -Force

 

In case above steps doesn’t work for you, please read this on how to install the PowerShellGallery module manually.

Basic Auth still needs to be enabled on your client machine

The new PowerShell V2 module uses Modern Auth to establish connection for enabling all the 9 (as of this writing) REST-based V2 Cmdlets. In addition to V2 cmdlets, it also allows you to access 700+ of the older Remote PowerShell Cmdlets which requires a Remote PowerShell session to be established. Establishing an RPS session on Windows machine require WinRM BasicAuth to be enabled on the client machine even though it used Modern Auth mechanism to authenticate. The WinRM Basic Auth pipeline is essentially used for transporting Modern Auth tokens. If WinRM Basic Auth is disabled on the client machine, the new V2 cmdlets will continue to work (but the older RPS cmdlets will not)

We really hope you enjoy using the new Exchange Online V2 module, and we look forward to your feedback as we continue to improve them.

The Exchange Admin Team

Updated Jun 03, 2020
Version 6.0