This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
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
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:
…can now be written as:
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:
- Properties – it accepts one or more (in comma separated form) name of the output property
You can specify PropertySets as well as Properties at the same time:
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.
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:
You will then need to re-load the PowerShell session; you can do this with the command:
You should then be able to successfully use the latest version of PowerShellGet
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.