Refresh of Exchange Online PowerShell Module Now Generally Available
A New Start for Exchange PowerShell
Last November, Microsoft announced a refresh of the Exchange Online PowerShell module at the Ignite 2019 conference. The big change was the introduction of nine cmdlets built on REST APIs to replace older cmdlets like Get-Mailbox and Get-MailboxStatistics. These cmdlets have been part of Exchange PowerShell since its introduction in Exchange 2007.
Apart from being some of the most used cmdlets, the common thread linking the nine chosen cmdlets is that they often retrieve large amounts of mailbox data. The older Remote PowerShell implementation works well with small numbers of mailboxes but begins to suffer problems as mailboxes mount into the thousands. In a nutshell, the old cmdlets are slow and unreliable in large tenants.
Upgrading to the Generally Available Version
After being in preview since Ignite, the new cmdlets are now generally available and the module can be downloaded from the PowerShell Gallery. Somewhat confusingly, Microsoft refers to the module as “Exchange Online PowerShell V2” while the version of the generally available module is 1.0.1 (Figure 1). But hey, what do numbers mean anyway?
Installing the module is easy. If you have never used the module before, run Install-Module (the command is shown in Figure 1) to fetch the code from the PowerShell Gallery, and if you’re upgrading from a previous release, run Update-Module as shown in Figure 2.
The Case for Change
Microsoft makes a strong case for people who develop PowerShell for Exchange Online to start using the V2 module straightaway. I agree for these reasons:
- Loading the new module into a PowerShell session includes both the nine new cmdlets and all the other cmdlets used by Exchange Online, including the older Remote PowerShell cmdlets (aka V1) that can now be replaced.
- Converting to the REST cmdlets (for instance, from Get-Mailbox to Get-ExoMailbox) is easy. Many of the issues identified in the preview have been addressed to reduce the friction of conversion, like dealing property with date formats and supporting mailbox aliases as a valid identity. This doesn’t mean that migration of a script is possible without some planning and testing; it does mean that you should be able to convert most scripts without too much pain. But do remember to test.
- V2 uses modern authentication. It’s part of the journey to eliminate basic authentication for Exchange Online connections (the most recent development was OAuth support for POP3).
- The REST cmdlets are faster. Not with small numbers of mailboxes when some overhead is incurred to support paging, but certainly they are much faster and more stable once you start processing hundreds or thousands of mailboxes. Microsoft says 3x-4x faster; your mileage will vary – but you won’t be disappointed.
Support for authentication in non-interactive situations (i.e. when someone isn’t signed in to enter a password) is due to be upgraded soon through support for service principal and certificate-based auth.
Glitches in V2
As you might expect with the first release of a new module, some glitches remain. For example, I don’t like that the Connect-IPPSSession cmdlet (used to connect to the Microsoft 365 compliance center endpoint) unloads the Exchange Online cmdlets. After connecting to the compliance center endpoint, you can run Get-Label to find details about sensitivity labels in the tenant, but you can’t run Get-ExoMailbox because the cmdlets have been unloaded. Indeed, PowerShell complains bitterly if you do try to run Get-ExoMailbox (Figure 3).
This issue has been around for a while and it should not fall into the category of “tough computer science problem” beloved of Microsoft spokespeople when dancing around the question of why something doesn’t work. The older approach of creating a separate session for the compliance center and using the AllowClobber parameter to override the clash in cmdlet names works (or give compliance center cmdlets a separate prefix). I hope Microsoft can resolve this problem soon because it is a real irritation. Some other useful points are available in the release notes.
Numbers Never Lie
Finally, my attention was drawn to the statement in the Microsoft blog post saying:
“In the month of May 2020 alone, we saw 150 million commands executed against Exchange Online using the new module.”
This sounds impressive, but it’s not really. Instead, it’s one of those statistics beloved of marketing writers to embellish announcements with something that’s impressive on the surface. But without context and supporting data for a component running in an environment supporting hundreds of millions of manageable objects, the number is worthless. Apart from proving that some testing happened, of course.
I asked Microsoft to clarify what the data meant and learned that the 150 million command executions were for the nine REST-based cmdlets (I bet Get-ExoMailbox was the most popular cmdlet). Microsoft also said that 15,000 tenants had used the new cmdlets, but they were unwilling to divulge what percentage of the overall Exchange Online PowerShell cmdlet execution the use of the new cmdlets represented. Microsoft noted that they were pleased with the uptake during the preview as the use gave them confidence that the new cmdlets were valuable.
Microsoft won’t give the entire context because they are cautious about releasing data for Office 365 operations. I guess it really doesn’t matter whether the new cmdlets were run 100 million or 200 million times in May. What is important is that people start to transition to the new module soon to take advantage of the improvements it delivers.