Skip to the main content.

ScriptRunner Blog

Introduction to the new Exchange Online V2 Cmdlets

Table of Contents

Post Featured Image

The new set of cmdlets in the Exchange Online V2 Module proves to be a boon and somewhat of a bane for those engineers that move mailboxes to Exchange Online or manage Exchange Online in general.

They are a boon because the nine new cmdlets are simply more robust and faster than their predecessors. They are also a bane because they will require script re-coding as well as learning the new methodologies (PropertySets and Properties) that are now present in these cmdlets.

Overall Microsoft has sought to balance use, speed and compatibility with the previous PowerShell module for Exchange Online.

In order to use the new Exchange Online V2 Module, we need to make sure that we meet certain prerequisites. Let’s dive into that first.

 

Prerequisites

 Exchange Online V2 Cmdlets have four prerequisites that need to be met prior to even installing the new Module. These prerequisites may already be met by your jump box or regular workstation. However, if they are not, these prerequisites may require installation. None of them are unusual, but all provide a better PowerShell experience for the administrator using the new PowerShell module. The four prerequisites are as follows:
  • NuGet – version 2.8.5 or newer
  • PsGallery – Trusted PS Repository
  • PackageManagement – needs to be v.x
  • PowerShell Get – should be v.x or greater

Let’s break down the installation for each of these components.

NuGet
 NuGet is simply a package manager that the Exchange Online V2 PowerShell module relies on. It allows Microsoft to share code and admins to download the new modules. If we are missing this package manager on our workstation, we will see something like shown in figure 1:
Screenshot of a system message containing the following:

Fig. 1: This message shows, that NuGet is not installed on the system

A basic install would look something like this:

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force -Confirm:$False

If we wanted to verify NuGet needs to be installed, we can also verify the version installed or if any version is installed, like so:

$PackageProviders = (Get-PackageProvider -ListAvailable).Name If ($PackageProviders -NotContains 'NuGet') {write-host 'NuGet is missing.'}

Now if NuGet is missing, then we run the installation code above, if however, NuGet is installed, we can force an installation of the correct, minimum version using the previous cmdlet either way.

More Information on NuGet.

Notice that the build numbers go all the way up to 2.12.1, but we only need to have 2.8.3 or higher.

 

PSGallery – Trusted Repository

PowerShell galleries are repositories that store scripts, modules and DSC resources that are available for downloading. Microsoft hosts one repository called the PSGallery, which contains their PowerShell resources for admins that support their products.

In the case of the Microsoft Exchange Online PowerShell V2 Module, we need access to this repository in order to download the module. By default, this repository may not be trusted and as such we will need to make sure that it is. First, let’s verify if it is or not trusted from our workstation:

(Get-PSRepository -Name "PSGallery").InstallationPolicy
Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
Then we can verify the change:
(Get-PSRepository -Name "PSGallery").InstallationPolicy

Tip: Always verify the change to prevent any future errors, especially with dependent processes.

 

PackageManagement

In addition to having the correct version of NuGet, we also need to make sure that PackageManagement is of the correct version as well. The PackageManagement package provides a unifying package management system for Windows OS’s. As such it will work in conjunction with NuGet which we upgraded earlier. Also note that NuGet was first and PackageManagement follows next, as this is the order of upgrade that we need to follow.

For PackageManagement we need to make sure that we have at least version 1.4.5. Let’s check this with PowerShell:

Get-Package PackageManagement -MinimumVersion 1.4.5

If PackageManagement is not installed, we will get an error like this:

Screenshot of an error message that states

Fig. 2: The error message states that PackageManagement is not installed

In order to install PackageManagement properly, we may need to perform some gymnastics.  That is because there are dependencies that can cause the upgrade process to hiccup.  However, if all goes well, this is the only line we need to install PackageManagement:

Install-Module PackageManagement -Force -SkipPublisherCheck
Then when we verify the installation we see this:
Screenshot: The output of

Fig. 3: Since PackageManagement is installed, we can verify it via PowerShell

Notice that the “Source” for this package is the PowerShell Gallery which we allowed earlier.

 

PowerShell Get

In addition to the previous package management software, we also have a module that will allow Admins to discover, install and update PowerShell modules, DSC resources, scripts and more. This is the last prerequisite for installing the EXO V2 module.

How do we install it? First, do we have it installed? We only need version 2 or higher, so we will check to see if we have a module installed whose Major version is 2:

[int32]((Get-Module PowerShellGet).Version).Major
 
On new machines, we should see this as the default:
Screenshot: The output of the command

Fig. 4: The output states that the major version of the installed cmdlet is “1”

Now, let’s upgrade this to at least 2.0:

Install-module PowerShellGet -MinimumVersion 2.0.0.0 -Force -Confirm:$False -SkipPublisherCheck
If all goes as planned, we can verify our new version and see this:
Screenshot: The output of the command

Fig. 5: The output still states that the major version is “1”

Wait. What? This should be two now. What happened? Is the package updated on our machine now?

Get-Package PowerShellGet
Screenshot: The output of Get-Package PowerShellGet

Fig. 6: The output of Get-Package shows that the current Version is 2.2.5

OK. So, we have the right version, why was 1 displayed in our check? That’s because the module that is loaded is the old one. Well, that is an easy fix:

Screenshot: Removing the old PowerShellGet version via PowerShell and Importing the new version

Fig. 7: After removing and then again importing PowerShellGet, our prompt shows the correct version

We see now that 2.x of PowerShellGet is loaded and ready for us. Now onto downloading the module:

 

Download EXO V2 Module

Once we have our four prerequisites installed, we can now download the new module with the same method as any other module for PowerShell:
Install-Module ExchangeOnlineManagement
Verify it is installed:
Get-InstalledModule ExchangeOnlineManagement
Screenshot: The output of Get-InstalledModule ExchangeOnlineManagement

Fig. 8: The output of “Get-InstalledModule” shows that the new EXO V2 Module is installed

Note: Your version may vary by the time you read this as 2.0.4 is the current version as of the writing of this article. However, in the past year or so this version has changed multiple times, as this screenshot of the version history shows:

the Screenshot of the ExchangeOnlineManagement version history shows that new versions of the package are being released every 1 to 2 months

Fig. 9: Version history of ExchangeOnlineManagement in the PowerShell Gallery

 

Exchange Online V2 Cmdlets

Now that we have the prerequisites out of the way and the new module installed, what does this grant us? First, let’s connect and see what Microsoft says has changed:
Connect-ExchangeOnline
We are prompted for MFA or at least Modern Auth like other modules for Office 365. Before connecting we see this informational blurb:
 
Screenshot: Connect-ExchangeOnline delivers a wrap-up of old and new cmdlets in the module

Fig. 10: Connect-ExchangeOnline delivers a wrap-up of old and new cmdlets in the module

The module provides replacements for nine cmdlets, but also continues to provide the other 700+ original cmdlets from the original Exchange Online module that we have used for many years.

When we review our loaded modules, we see the new one on the top of the list, but we also see the original cmdlets listed in the last module (figure 11).

Screenshot: Output of Get-Module

Fig. 11: Get-Module gives us an overview of the available modules and the cmdlets they contain

 

Free PowerShell Scripts

ActionPack for Microsoft Exchange Online

downloadDownload our free PowerShell script collection for managing distribution groups, mailboxes, resources, and services with Microsoft Exchange Online.

Free on GitHub >

 

 

Why use the Exchange Online V2 cmdlets?

  1. Reducing Data: Traditional PowerShell cmdlets return all data, even if all the data is not displayed. The EXO V2 cmdlets only return a subset of the data, which may challenge an admin to determine what they need.
  2. Property Sets: Grouped sets of data that can be returned by PowerShell cmdlets.
  3. Speed: With the two previous examples, combined they provide some additional speed and reliability for the nine new cmdlets.

These cmdlets were chosen for two reasons – most likely to be used, but also the most likely to be slow or fail due to the amount of data returned and the load put on Exchange Online servers.

Change in Operation

When using these cmdlets, it is important to note that we do indeed need to be aware of syntax and proper usage of the new parameters in order to get the correct data in Exchange Online.

Property Sets Example:

Old Method

Get-Mailbox | Where {$_.IsResource -eq 'True'} | Ft Name, Alias, PrimarySMTPAddress, *quota

New EXO V2 Method

With the new cmdlets, we need to rely on either PropertySets like this:

Get-EXOMailbox -PropertySets Minimum, Resource, Quota | Where {$_.IsResource -eq 'True'} | ft

Properties Example:

Get-EXOMailbox -Properties Name,Alias,PrimarySMTPAddress, IsResource, IssueWarningQuota,ProhibitSendQuota, ProhibitSendReceiveQuota | Where {$_.IsResource -eq 'True'} | ft

While this provides the same results, it is already becoming quite unwieldy. Thus, choosing between Properties and PropertySets should be based on how many attributes one would need to display.

How do we tell which parameters/properties are usable with a Property Set? It is not documented in Get-Help or in the online help of Microsoft Docs. Let’s take for example Get-EXOMailbox from the previous example. We can see the list of all Property Sets listed in Get-Help for the cmdlet:


Minimum AddressList Audit Archive Audit Custom Delivery Hold Moderation Move Policy PublicFolder Quota Resource Retention SCL SoftDelete StatisticsSeed

If we were looking for all Quota attributes, we see that there is a Quota Property.  Using this reveals a lot of properties for an account:

Get-EXOMailbox Ted -PropertySets Quota
Screenshot: Output of

Fig. 12: Using the property ‘Quota’ reveals more details on a certain account

Notice that there are some properties that are not Quota related but instead are identifiers for the mailbox – UserPrincipalName, PrimarySMTPAddress and Identity. What are the minimum reported properties? Let’s review the example below as the default (no specified PropertySets) is “Minimum”:

Get-EXOMailbox Ted
Screenshot: Full list of properties put out by

Fig. 13: Unfiltered list of properties

 

Real World Experience with EXO V2 cmdlets

From the brief time that these cmdlets have been publicly available I have noticed the following:
  • Fewer Timeouts – on a dataset of 7,000 mailboxes, the new EXO V2 cmdlets were able to query all mailboxes, looking at each folder and finding a large number of items in folders (100k+) without timing out. With the older cmdlets, this would have failed.
  • Speed – The EXO v2 cmdlets do run much faster. We have a query performed with both Get-Mailbox and Get-EXOMailbox:
    • Get-Mailbox [full run, unlimited results, 7,600+ mailboxes]:
      Screenshot: Execution time for Get-Mailbox

      Fig. 14: Execution time using Get-Mailbox

    • Get-EXOMailbox [Full run, unlimited results, 7,600+ mailboxes]:
      Notice that the EXO V2 cmdlet is about twice as fast as the regular cmdlet. Your experience will vary depending on your environment, but in general it should be much faster and responsive.
      Screenshot: Execution time for Get-ExOMailbox

      Fig. 15: Execution time using Get-EXOMailbox

       

Conclusion

While the prep-work for the ExchangeOnlineManagement PowerShell cmdlets may seem a bit intimidating, the script located here will help alleviate any install issues. Once installed you now have access to a robust set of PowerShell cmdlets. While, as an avid PowerShell user, the author thinks there are still some bumps in the road with these cmdlets, they certainly are better in some respects when it comes to reliability and performance. Also, Microsoft is making constant investments in upgrading the administrators PowerShell performance, and we should certainly see some of these over the next year or two.

Related posts

2 min read

VMUG Webcast: Mastering VMware Management with PowerCLI

3 min read

Automate your spring cleaning with PowerShell

5 min read

Mastering PowerShell with Get-Help

About the author: