Current Version is 2.5.0
Updated 30 August 2021
On August 16 2021, Microsoft published V2.5.0 of the Microsoft Teams PowerShell module in the PowerShell Gallery. The release notes for the module give some information about the changes (see below).
Updating the module is easy. In an administrator PowerShell session, run the command:
Update-Module MicrosoftTeams -RequiredVersion 2.5.0 -Force
Clearing the Deck for the Retirement of Skype for Business Online
Microsoft upgraded the module to 2.0 in March 2021. This was a big update because it marked the incorporation of the cmdlets from the old Skype for Business Online connector. 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 earlier versions are now addressed.
Updates and Issues in 2.5.0
Here are some details of the changes in the 2.5.0 module:
- Updates for AccessToken login with Connect-MicrosoftTeams. The Access Token login for the Connect-MicrosoftTeams cmdlet now uses a unified token array instead of separate parameters for each resource access token. Some fixes are also included for interactive logins using Connect-MicrosoftTeams in CloudShell.
- Improvements to New-Team cmdlet for team creation scenarios. The improvements are bug fixes to address issues reported when running New-Team to create new teams. However, the improvements appear to have introduced a new set of issues (see below).
- TeamsUnassignedNumberTreatment cmdlets are now available. No further details are available.
- The Get-CsCsOnlineDialInConferencingBridge and Set-CsOnlineDialInConferencingBridge cmdlets are available (if you have Teams Voice licenses).
- “Modernized” (Graph-based) versions of the Get-CsTenant and Get-CSOnlineUser cmdlets (using the identity parameter only) are available. The Get-CSOnlineUser cmdlet, which returns details of a Teams user and the policies assigned to their account, is often used in scripts. Modernization should ensure that output is the same as the old version of the cmdlet but experience tells that this is sometimes not the case, so it is wise to test scripts which use the cmdlet to validate that everything works as expected. For instance, the LineURI property no longer has a “Tel:+” prefix.
I will update the list as more information becomes available.
One problem reported in 2.5 is that the New-Team cmdlet does not return the GUID (object identifier) of the newly created team. A new team is created successfully but New-Team returns Graph target resource information which must be parsed to extract the GUID. For example, before 2.5, the $TeamId variable would contain a valid GUID. You can see what it now gets from New-Team:
$TeamId = New-Team -DisplayName "Auxerre Lovers" -Description "Auxerre people" -MailNickName Auxerre.Team -Owner Tony.Redmond@office365itpros.com -Visibility Public C:\> $TeamId TargetResourceLocation ---------------------- /teams('75c2bd1a-d67d-417c-99c8-faa14e8be918')/operations('3f6d0c84-e20d-493d-972e-0b5d2f420bb3')
You can extract the GUID from the information returned by New-Team and use it. For example:
$GroupId = $TeamId.TargetResourceLocation.SubString($TeamId.TargetResourceLocation.IndexOf("'")+1,36) Get-Team -GroupId $GroupId GroupId DisplayName Visibility Archived MailNickName Description ------- ----------- ---------- -------- ------------ ----------- 75c2bd1a-d67d-417c-99c8-faa14e8be918 Auxerre Lovers Public False AuxerreLovers Auxerre people
Obviously, going through the extraction is a royal pain.
Update August 30: Microsoft has withdrawn the original 2.5.0 module to reissue it with the old version of the New-Team cmdlet. The plan of record is to re-release the upgraded version of the New-Team cmdlet (making sure that it returns a GUID) in 2.5.1, expected in mid-September.
For some reason, although the documentation for the Connect-MicrosoftTeams cmdlet includes the option to use a certificate thumbprint to authenticate, the cmdlet in 2.5.0 is missing the CertificateThumbPrint parameter. I’ve asked Microsoft why.
Updates in 2.3.1
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 module updates, we recommend you download and test your scripts against the latest version of the Teams PowerShell module as soon as convenient. If the tests prove successful, then you can deploy the new module into production.
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.