Exchange Online V2 Cmdlets – Part Two – Module and New Cmdlets

In the first part of this series on the new Exchange Online V2 (ExO V2) cmdlets, we reviewed how to get the prerequisites needed to simply download the ExO V2 cmdlets installed on a new machine. Now we have an even playing field with an workstation that already had the prerequisites and a new machines that had some PowerShell components upgraded to allow for ExOv2 to be installed. What’s next?
The New Cmdlets
In all, Microsoft recreated ten cmdlets in order to take advantage of some tweaks as well as the REST protocol for better performance and reliability for those managing Exchange Online with PowerShell. The new cmdlets are listed below with their older counterparts:

So what makes these cmdlets different from the previous version? One change is that these cmdlets utilize the Representational State Transfer (or REST) API to make their connections. Why is this important? Feel free to read this BLOG POST for some in depth information.
Another change that these cmdlets bring is greatly reducing the amount of information (properties and values) that is returned by the cmdlets. Many times the values are not needed or empty, all causing load and network slowness due to the effort there is to query and display so much information. Reducing the data returned does provide good performance feedback when running the cmdlets.
** Working with these cmdlets requires some restricting of the way one thinks about Exchange Online and how to use PowerShell cmdlets in general. With the old cmdlets we had all the output we could want provided at once. The new cmdlets require us to think about exactly which properties we actually need from an object before hand. Getting to know properties and property sets will be important.
Reducing Data
(Ref: http://Exchange Online v2 Property Sets)
In order to get this performance, Microsoft needed to reduce the data returned. The data returned can be quite pared down and in fact can be pared own too far [ IMHO ]. Two different settings help with this reduction and those are Properties and PropertySets. These two different methods will help determine how much data is pulled when one of these new cmdlets is run. Getting to know these will help us get to know how to use them properly and efficiently. Let’s review these items:
PropertySet
A Property Set is a predefined group of object properties that Microsoft has thought to be a logical grouping. These sets reveal properties that can then be revealed by the new ExO v2 cmdlets. We won’t be able to simply list all of the properties of an object and filter them on output. We need to decide what we want and pick the properties sets available to us. Let’s take the Example of Get-Mailbox:
Scenario – need to check quotas on all resource mailboxes, while listing basic information about the mailbox itself.
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 Name,Alias,PrimarySMTPAddress,IsResource,IssueWarningQuota,ProhibitSendQuota,ProhibitSendReceiveQuota

If we did not add the PropertySets, the cmdlet would just return an empty result set as no properties for the objects would have been returned for PowerShell to filter, let alone display to the screen. Now, we do not have to filter the results from a cmdlet using the PropertySets and instead just have PowerShell return all values for a property set. For example, if we chose the Quota property set, but did not filter the results, we would get all of these properties for each object – ArchiveQuota, ArchiveWarningQuota, CalendarLoggingQuota, xternalDirectoryObjectId. IssueWarningQuota, ProhibitSendQuota, ProhibitSendReceiveQuota, RecoverableItemsQuota, RecoverableItemsWarningQuota, RulesQuota and DatabaseQuotaDefaults.

Property
Properties are the single values that makeup the various PropertySets for the new cmdlets. We can use Properties to reveal singular values for an object instead of relying on a full set of properties. While this allows for targeted value pulls, it can quickly grow out of hand depending on the number of properties needed. For example if we rely on choosing our properties for the previous Get-Mailbox cmdlet above, we would get something like this:

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

While this provides the same results, it is already becoming quite unwieldly. Thus, choosing between the two options (Properties or PropertySets) can be important for your scripts. My advice would be to review the source post for list above and get familiar with all of the properties and property sets.
Real World Experience
From the brief time that these cmdlets have been publicly available I have noticed the following:
* Less Timeouts – on a dataset of 7000 mailboxes, the new ExO V2 cmdlets were able to query all mailboxes, looking at each folder and finding large number of items in folders (100k+) without timing out. With the older cmdlets, this would have failed.
* Speed – These cmdlets do run much faster. I do not have any real world numbers to share at the moment.

Next Steps
Now that we have an understanding on how to use them (part 2) and prepare a workstation to use them (part 1), next steps would be to modify any existing scripts that have the old cmdlets in them. In order to do this properly we cannot replace the name of the old cmdlet for the new cmdlet name as this would cause the new cmdlet to fail if there are parameters chose and/or properties selected that were not ‘translated’ for the new cmdlet. Even a one-liner as simple as ‘Get-Mailbox -Archive’ will need some work because if we replace ‘Get-Mailbox’ with ‘Get-ExOMailbox’, the resultant set of data is different. Whereas the output of the Get-Mailbox cmdlet defaults to a Table, the Get-ExOMailbox cmdlet defaults to a List of properties. The properties for Get-ExOMailbox are limited to ExternalDirectoryObjectId, UserPrincipalName, Alias, DisplayName, EmailAddresses, PrimarySmtpAddress, RecipientType, RecipientTypeDetails, Identity, Id, ExchangeVersion, Name, DistinguishedName, OrganizationId, Guid. Get-Mailbox create a table of these basic attributes – Name, Alias, Database, ProhibitSendQuota and ExternalDirectoryObjectId. In this scenario, some adjustment may need to occur depending on what attributes we intend to work with as well as possibly using ‘| FT’ for the Get-ExOMailbox cmdlet.
What about a different one-liner that selects various properties of a mailbox object to be displayed in table form? How do we translate that and make a new cmdlet? Let’s use this one-liner as a good example cmdlet:

Get-Mailbox | Select DisplayName,PrimarySMTPAddress,AuditEnabled,AuditLogAgeLimit,AuditAdmin,AuditDelegate,AuditOwner | Ft -Auto

A literal translation will leave us with blank values:

Get-ExOMailbox | Select DisplayName,PrimarySMTPAddress,AuditEnabled,AuditLogAgeLimit,AuditAdmin,AuditDelegate,AuditOwner | Ft -Auto

As we can see above, property values are lost in translation (from the ExO to ExO v2 cmdlets) which is a direct result of the changes made to ExO v2 cmdlets’ reduced data returned. In order to accommodate for these changes we need to tell the ExO v2 cmdlets which properties we need. We can either do that with a blanket coverage with PropertySets or a more targets approach with Properties. Both ways will work and both should be more efficient than the older cmdlets. The parameters we need to find are DisplayName,PrimarySMTPAddress,AuditEnabled,AuditLogAgeLimit,AuditAdmin,AuditDelegate,AuditOwner. The first two properties are in the ‘Minimal’ PropertySet as shown here:

Whereas the rest of the properties are in the ‘Audit’ PropertySet:

Using the new cmdlets and the two different methods, we can break them up like so:

Get-ExOMailbox -Properties DisplayName,PrimarySMTPAddress,AuditEnabled,AuditLogAgeLimit,AuditAdmin,AuditDelegate,AuditOwner | Ft DisplayName,PrimarySMTPAddress,AuditEnabled,AuditLogAgeLimit,AuditAdmin,AuditDelegate,AuditOwner -Auto

Get-ExOMailbox -PropertySet Minimum,Audit | Select DisplayName,PrimarySMTPAddress,AuditEnabled,AuditLogAgeLimit,AuditAdmin,AuditDelegate,AuditOwner | Ft -Auto

While the first one is a bit wordy, if we neglect to put values after ‘FT’, then the putput will also contain the ‘ExternalDirectoryObjectId’ which may not be ideal:

Remember that each cmdlet has a separate set of Property Sets to work with so it would be worthwhile to review the tables listed on this page –> ExO V2 Property Sets <– before re-writing old cmdlets or creating new ones.