Exchange Online and Teams Get Important PowerShell Updates
PowerShell Critical for Office 365
Although the Microsoft Graph is gaining popularity as the method for automating administrative processes for Office 365 workloads, there’s no doubt that PowerShell remains the most common automation tool. The two approaches can be mixed to create solutions when neither is quite good enough and Microsoft is still working on a PowerShell module for the Graph, but sometimes you just want to do it all with PowerShell. It’s therefore important that Microsoft keeps on improving the capabilities of the PowerShell modules for Office 365 workloads, as they do for two modules described here.
Support for Unattended Exchange Online Scripts
In Office 365 notification MC217815 (July 3), Microsoft announced the “public preview of a modern authentication unattended scripting option.” More information about this important announcement, which lays the foundation for tenants to use the Exchange Online Management V2 module in unattended scripts, is in an EHLO blog.
New Module Much Better Than the Old
After a launch in preview at the Ignite 2019 conference. the Exchange Online Management V2 module attained general availability in June. This module contains a set of nine Get- cmdlets (like Get-ExoMailbox) that are much faster and more robust than their older counterparts. When you load the V2 module, you get the nine new cmdlets and all the older cmdlets. There’s no need to make two separate connections to Exchange.
The old Exchange cmdlets belong to the era when on-premises servers dominated. The foundation of the speed and robustness of the new cmdlets is that they use a REST API to access Exchange Online instead of connecting to a remote server. Given the number of servers running in Exchange Online and the way that Microsoft moves servers around to balance workload, connecting to a specific server and maintaining that connection can be quite a task. This isn’t a problem if you only need to work with a few mailboxes; it leads to all sorts of script failures due to connection drops if you need to process data for large numbers of mailboxes. In addition to moving away from remote connections, the new cmdlets support multithreading and pagination and are better able to recover from errors. Overall, using the new cmdlets will make scripts much faster, especially in large organizations where the need exists to process thousands of mailboxes or other objects.
Steps to Eradicate Basic Authentication from Exchange Online
The EXO V2 module is a part of Microsoft’s plan to eliminate basic authentication connections from Exchange Online in the second half of-2021. Remote PowerShell is one of the connection protocols (Exchange ActiveSync, IMAP4, POP3, and Exchange Web Services are the others) that Microsoft plans to disable for basic authentication to close off holes commonly exploited by attackers.
Exchange Web Services and ActiveSync already support modern authentication and Microsoft recently enabled OAuth support for IMAP4, POP3, and SMTP AUTH to help developers create clients that don’t use basic authentication to connect to Exchange Online. Some popular applications, like the Thunderbird email client, can already be configured to connect with IMAP4 to Exchange Online with modern authentication.
PowerShell scripters have been able to use the V2 module with modern authentication since its inception. The problem is that many scripts are written to run in the background to generate reports, monitor services, and generally get stuff done. The change announced on July 3 is a preview to allow scripts to use the V2 module and authenticate with certificates instead of embedded passwords.
Upgrading Authentication for Scripts
Swapping new cmdlets into scripts isn’t something that can be done without thinking. The new cmdlets behave differently in subtle ways, mostly to make sure that they can deliver the expected performance boost. For instance, unless you specifically ask a cmdlet to return a mailbox property (one of 255), it probably won’t, unless that property is one of the 15 always returned.
When the time comes to upgrade scripts, you should think about how the script will authenticate to gain the necessary permissions to do its work. It’s time to move to modern authentication and replace hacks like embedded password, fetching passwords from files, and so on. The good news is that the V2 module supports modern authentication (even for the older cmdlets) and the change now announced is specifically to enable unattended script execution.
Essentially, scripts will use a certificate associated with a registered app in Azure AD to provide credentials and authenticate. The app can be assigned permissions that become available to the script. When the script connects to the Exchange Online Management endpoint, it provides its certificate to authenticate. Once Azure AD is happy and authentication completes, the script can run as normal. An excellent write-up by MVP Vasil Michev dives into the detail of what needs to be done.
The Beginning of the End for the Skype for Business Online Connector
In their June 2020 roundup, the Teams development group reported that they are moving to amalgamate the Teams and Skype for Business Online modules into a single module. For historical reasons, Teams has depended on the Skype for Business Online module for access to policy management cmdlets. For instance, to manage Teams meeting policies, you use the Cs-TeamsMeetingPolicy cmdlet.
With the retirement of Skype for Business Online just a year away, it’s time to remove dependencies from Teams, and that’s what we see happening. What is now available is a preview version of the Teams PowerShell module which includes the Skype for Business Online connector. Up to now, the connector must be downloaded and installed separately. The connector is used to connect to the Skype for Business Online endpoint and download the cmdlets into a PowerShell session.
One Teams Module to Rule Them All
Teams stores its production (general availability) and public preview (beta) PowerShell modules in the PowerShell Gallery. The preview version contains cmdlets that are being worked on. These cmdlets shouldn’t be used in production, but they are useful in getting a heads-up for what’s coming to Teams soon. To download and install the preview module, you might have to update the PowerShellGet modules to use the AllowPreRelease switch.
Version 1.1.3-preview is the latest beta module available at the time of writing (Figure 1). I installed the modules as follows:
Install-Module -Name PowerShellGet -Repository PSGallery -Force Install-Module -Name MicrosoftTeams -RequiredVersion "1.1.3-preview" -AllowPreRelease
Mixing Teams and Skype for Business Online Cmdlets
Once the Teams preview module is installed, you can connect to Teams as usual and connect to the Skype for Business Online endpoint without having to install the Skype for Business Online connector.
Connect-MicrosoftTeams -Credential $MyCredentials $SkypeSession = New-CsOnlineSession -Credential $MyCredentials Import-PSSession $SkypeSession -AllowClobber
In the example, $MyCredentials is a PowerShell credentials object pre-populated with a password.
For now, the cmdlets imported from Skype for Business Online are keeping the “Cs” moniker. Over time, I expect these cmdlets to be renamed to match the other cmdlets in the Teams module. No doubt Microsoft will provide suitable aliases to allow for backwards compatibility in scripts. See the release notes for more information on what’s happening with Teams PowerShell, including a list of the cmdlets available in the two modules.
You can’t run the generally available and preview modules together. If you need to switch, you need to uninstall the other module, close PowerShell, start a new session, and install the module you want to use.
Moving Forward
The importance of PowerShell to Office 365 won’t decline anytime soon. With that in mind, it’s good to see these kinds of changes. Now all we need is a module for Planner, and Yammer, and Stream, and all the other bits that aren’t quite covered. That would be nice.