Introduction to the new Exchange Online V2 Cmdlets

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

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:

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:

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:

 

On new machines, we should see this as the default:

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:

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

Get-Package PowerShellGet

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:

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

 

Install-Module ExchangeOnlineManagement

Verify it is installed:

Get-InstalledModule ExchangeOnlineManagement

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:

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:

 

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).

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:

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

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