Upgrades Available for Exchange and SharePoint PowerShell Modules

Important to Apply Updates for PowerShell Modules

Some important changes are available in recent refreshes for the Exchange Online and SharePoint Online PowerShell modules. In general, it’s good practice to download and use the latest available module to take advantage of bug fixes and new functionality. The problem is knowing when these updates are available as few of us have the time to check.

The latest versions of these modules are:

• Exchange Online PowerShell V2: 0.4578.0.
• SharePoint Online: 16.0.19927.0.

Exchange Online PowerShell V2 is the module containing the new-REST based cmdlets (like Get-ExoMailbox). The module also includes access to the older Remote PowerShell cmdlets (like Get-Mailbox). You should be using this module whenever possible, especially when needing to deal with large sets of mailboxes or mailbox-associated objects.

Over time, as Microsoft removes the ability to connect to PowerShell with basic authentication (along with ActiveSync, IMAP4, POP3, and SMTP), the V2 module will become the only way to access Exchange Online with PowerShell.

Updates in Exchange Online PowerShell

Notable updates in the current Exchange Online PowerShell V2 module are:

• Support to allow tenants to enable and disable Cortana Daily briefing emails (the Get-UserBriefingConfig and Set-UserBriefingConfig cmdlets). This feature is in preview.
• A new Disconnect-ExchangeOnline cmdlet to break the link between Exchange Online and PowerShell. This cmdlet removes the access token from the workstation’s cache and is intended for use in situations where a long-running session connects and disconnects from Exchange Online periodically

The Connect-IPPSSession Cmdlet and the Compliance Center Cmdlets

Version 0.4368.1 introduced the Connect-IPPSSession cmdlet as a way to connect to the Compliance Center endpoint. There’s no logic behind the name, which some speculate means Information Protection PowerShell (IPPS). The cmdlet has been around for a while and now joins the Exchange Online management module.

For the moment, I don’t recommend that you use the Connect-IPPSSession cmdlet. Although it does load the Compliance Center cmdlets into a session, it does so by removing any previous session connected to Exchange Online, which means that you end up in a situation where you can’t use the two sets of cmdlets in the same session. This problem has been around since 2017 and Microsoft didn’t fix it when the cmdlet transitioned to the Exchange Online management module.

The older approach supports the use of both sets of cmdlets, even if cmdlets with the same names exist in the two sets using the AllowClobber parameter to import the cmdlets with Import-PSSession. A great example of how this is done is in Michel de Rooij’s mega-script to connect to Office 365 services with PowerShell. You can also use a prefix to identify the cmdlets from the different sets.

Issues Installing Update for SharePoint Online PowerShell

Version 16.0.19927.0 of the SharePoint Online PowerShell module supports some new functionality with Conditional Access policies. Normally, updating this module is a matter of downloading the latest version from Microsoft’s site and installing it on a workstation.

In this case, my PC had version 16.0.19418.12000 installed and after the update, I was puzzled that PowerShell continued to load that version. I blamed a bad download, so I downloaded and installed the new module again. Version 19418.12000 persisted. And persisted.

Even a cycle of removing the module, rebooting the PC, and installing the new module refused to dislodge 19418.12000. Eventually, I discovered that the files for this version were in C:\Program Files\WindowsPowerShell\Modules\Microsoft.Online.SharePoint.PowerShell while those for 16.0.19927.0 were installed into C:\Program Files\SharePoint Online Management Shell. After I deleted the older files, PowerShell picked up the new version.

This is obviously not the way that things should work. Microsoft is investigating… In the meantime, I’m chalking these problems down to yet another event along my rich voyage among PowerShell modules, just like the issue I had with OneDrive’s known folders and the Active Directory module.