Last Update: Sep 04, 2024 | Published: Jun 04, 2020
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.
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.
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:
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.
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.
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.