Microsoft Releases V2.3.1 of the Teams PowerShell Module

No Major Changes Included in Updated Module

On April 30, 2021, Microsoft published V2.3.0 of the Microsoft Teams PowerShell module in the PowerShell Gallery. After receiving some reports about problems with 2.3.0, Microsoft released V2.3.1 on May 10 and eventually updated the release notes for the module. Unfortunately, the release notes don’t reveal too much about what’s in either update for the module, so it’s time for some interpretation (aka guesswork).

Head to the PowerShell Gallery to get Version 2.3.1 of the Microsoft Teams module
Figure 1: Head to the PowerShell Gallery to get Version 2.3.1 of the Microsoft Teams module

Clearing the Deck for the Retirement of Skype for Business Online

Microsoft upgraded the module to 2.0 in March. This was a big update because it marked the incorporation of the cmdlets from the old Skype for Business Online connector. Microsoft originally retired the connector in February. According to message center notification MC250940 (April 16), the connector will cease to work on 15 May 2021. Attempts to use the connector thereafter will likely fail. Removing the connector is part of the process to retire Skype for Business Online from Office 365 on July 31, 2021.

Replacing the Skype for Business Online connector with the Teams PowerShell module means that tenants must upgrade their scripts to ensure that the correct module is loaded. Although the New-CsOnlineSession is no longer necessary to connect to what is now effectively the Teams policy endpoint, the other cmdlets previously accessed through the connector are available after Connect-MicrosoftTeams runs to create a new session. A big advantage is that there’s no need to run the Enable-CsOnlineSessionforReconnection cmdlet to stop the session timing out after an hour.

Some Authentication Issues

Soon after the release of the 2.0 module, people realized that it didn’t work so well with integrated Windows authentication. This arose because of replacing the Active Directory Authentication Library (ADAL) with the Microsoft Authentication Library (MSAL). According to the release notes, V2.3.1 includes fixes for integrated Windows authentication to make the Connect-MicrosoftTeams cmdlet work better. However, some reports indicate that some problems still exist when running Connect-MicrosoftTeams. Organizations should test their scripts to establish if connection failures still exist and report the information to Microsoft.

Microsoft says that the errors in Set-CsUser and other cmdlets seen in V2.3.0 are fixed in V2.3.1.

Fixes with Small Number of New Features

The changes in V2.3.1 are mostly fixes and don’t stretch to much new functionality. Here’s what’s important:

  • A new cmdlet (Get-MultiGeoRegion) is available to get the multi-geo region for teams and groups. This is part of the Teams support for multi-geo organizations announced at Ignite 2021.
  • The release notes for V2.2.0 preview said that another new cmdlet (Get-LicenseReportForChangeNotificationSubscription) would “get details of total change notification events that can be sent to users,” whatever that means. This cmdlet hasn’t made it into V2.3.1.
  • The V2.2.0 preview also discussed some internal engineering in the refactoring of remote session management. As Microsoft observed at the time, this change should result in no functional change for tenant admins. There’s no mention of this work for V2.3.1, but Microsoft does say that they have fixed “a large latency issue while remoting commands,” which could be connected.
  • General availability for the cmdlets to manage custom group policy assignments. Group policy assignments mean that organizations can build packages (sets) of policies to assign to groups (security groups, Microsoft 365 groups, or distribution lists). Microsoft includes some standard packages in Teams. If you want to build custom packages, you need the famous Teams Advanced Communications license.
  • Microsoft notes “updates to input parameters and output formats” for many cmdlets. This appears innocuous (and seem to affect policy cmdlets like Get-CsTeamsMeetingPolicy and Get-CsTeamsMessagingPolicy) but might affect scripts which depend on a certain parameter being passed or returned data being in a certain format. Changes like this underline the need for testing against a new module.

Because of the bug fixes included in V2.3.1, it’s recommended that you download and use this version of the module as soon as possible.

Call to Action

With just a few days left before the May 15 deadline for the Skype for Business Online connector to stop working, it’s time for anyone who has PowerShell scripts based on the connector to upgrade their code and use the Microsoft Teams module instead. If you hit problems, let us know in a comment and we will relay the information to the Teams developers. In addition, make sure that you log a support call to record the problem formally. We might have some influence, but nothing beats a customer support call when it comes to getting Microsoft engineering to pay attention to a problem.

Stay acquainted with all the moving parts of Office 365 by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that we stay ahead of the game in terms of warning our readers when they need to take action.

18 Replies to “Microsoft Releases V2.3.1 of the Teams PowerShell Module”

  1. Apparently the new 2.3.0 Teams PWS module, is utilizing CPU drastically for now obvious reason.
    Why MS has decreased performance on their “new” Teams module beats me, but the good “old” Skype for Business Online PWS module doesn’t.
    I really hope, that MS will look into this problem and solve this before discontinuing the SfB module.

  2. With the Set-CsUser I am getting access denied – What do you think I should do to work around this or resolve it?

    1. Report the problem to Microsoft. As I note in the article, there are some errors in Set-CsUser. The more support calls come in, the quicker this gets fixed.

  3. Just switched over to the MicrosoftTeams module, but now I am unable to set a phone number to an Teamsaccount. The Set-CsUser thorws an ‘Access dienied’ error, see example below:

    Set-CsUser -id -Phonenumber “tel:+31123456789”
    Set-CsUser : Access Denied.
    At line:1 char:1
    + Set-CsUser -id -Phonenumber “tel:+31123456789 …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidOperation: ({ Id = tst7045@…putParameters }:f__AnonymousType50`2) [Set-CsUser_SetExpanded], UndeclaredResponseExc
    + FullyQualifiedErrorId : Forbidden,Microsoft.Teams.ConfigAPI.Cmdlets.Generated.Cmdlets.SetCsUser_SetExpanded

    Any ideas, suggestions how to solve this?

    1. As I note in the article, there are known issues with the Set-CsUser cmdlet. Please report the issue to Microsoft so that the development group see that they need to fix the problem quickly.

  4. version 2.3.1 solves the problem about Set-CsUser:
    Set-CsUser -Id xxx@xx.xx -EnterpriseVoiceEnabled:$true -HostedVoiceMail:$true -OnPremLineURI “tel:+33xxxxxxxxx”
    does work now (tested with PS 5 and 6)

  5. However, the issues with Connect-MicrosoftTeams -AadAccessToken is still failing to access SFB cs-online commands. Please let us know if there are any known workarounds for this? Thank you.

    1. I believe there are some known issues still with AadAccessToken. The news on the grapevine is that a new preview version of the Teams module should help. No timeline when this will be available…

  6. -AadAccessToken with -MsAccessToken allows Get-Team to run however does not help with SFB cmdlets like Get-csTenant etc.
    Is there any other way to use Skype four business cmdlets without using user credentials ?

    1. I know that Microsoft is doing some more work to make it the cmdlets better. However, if you have a problem, make sure that you report the issue formally in a support incident. This is the only way to increase the pressure on the engineers to deliver what you need to work.

  7. We have been using both module 2.3.1 and 2.3.2 for a few days now and at first glance it looks fine with good performance and low CPU utilization.

    But after a few days, the first initial call to any CS function (i.e. Get-CsOnlineUser) takes more and more time to answer, and meanwhile the CPU is sky high. The time to complete the first call is as high as 200 seconds for small tenants (<50 users). When the first call is completed, the performance is great again.

    Has anyone else experienced this behavior?

    1. Sounds like more authentication woes. The engineers are working to improve the issues around authentication. I’ll flag this issue to them.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.