At the beginning of August Microsoft released the 5.5.0 version of the Microsoft Teams PowerShell module.
The official release notes mention the following changes:
Releases New-CsTeamsHiddenTemplate cmdlet.
Releases [New|Get|Set|Remove]-CsTeamsTemplatePermissionPolicy cmdlets.
Adds a new paramater -IncludePhoneNumbers to Get-CsTenantNetworkSite.
[BREAKING CHANGE] Deprecates EnableShiftPresence parameter from TeamsShiftsPolicy.
Contains a new implementation of [Get|Set]-CsTeamsUpgradeConfiguration, [Get|Set|Remove|New]-CsTeamsComplianceRecordingPolicy, [Get|Set|Remove|New]-CsTeamsComplianceRecordingApplication, New-CsTeamsComplianceRecordingPairedApplication. Functionality remains the same as previous implementation.
However, there is more. Let's talk about them!
The most mysterious feature comes first. We're getting custom prompts along with a custom prompt package. The cmdlets are:
For the custom prompt itself, we can set the following properties:
All the parameters accept strings. Only three of them are mandatory: Id, Type, and Locale.
The policy package contains the following properties:
Id, DefaultLocale, and Name accept string values. Recording prompt values accepts PSListModifier[string] type. From the documentation of PSListModifier, we will be able to supply multiple prompts for each type.
Unfortunately, we cannot test it yet. Both New-CsCustomPrompt and New-CsCustomPromptPackage cmdlets currently return the same error:
Could not find the resource "XsdClassGeneratorStringsResources.resources" among the resources "" embedded in the assembly "Microsoft.Teams.Policy.Administration.Cmdlets.Providers.PolicyRp", nor among the resources in any satellite assemblies for the specified culture. Perhaps the resources were embedded with an incorrect name.
Checklist for New-CsCustomPrompt:
Checklist for New-CsCustomPromptPackage:
We get two more new cmdlets containing custom prompts in their names:
The Set- cmdlet accepts:
Similar to custom prompt packages, we will be able to add multiple prompts using
For now, both Get- and Set- cmdlets return an error:
Provided type TeamsAudioConferencingCustomPromptsConfiguration is not valid Please check your request parameters.
Checklist for Get-CsTeamsAudioConferencingCustomPromptsConfiguration:
Checklist for Set-CsTeamsAudioConferencingCustomPromptsConfiguration:
New-CsTeamsComplianceRecordingPolicy and Set-CsTeamsComplianceRecordingPolicy now have three new parameters:
CustomPromptsEnabled and RecordReroutedCalls accepts a boolean value. They both default to false. Setting both parameters already work:
CustomPromptsPackageId accepts a string. We can assume it will need a package identifier from New-CsCustomPromptPackage. The default value is an empty string.
When trying to provide an identifier we get the same error message as for New-CsCustomPrompt and New-CsCustomPromptPackage:
Checklist for CustomPromptsEnabled and CustomPromptsPackageId:
Checklist for RecordReroutedCalls:
New-CsTeamsEventsPolicy and Set-CsTeamsEventsPolicy now have three new parameters:
Get-CsTeamsEventsPolicy cmdlet already returns these parameters.
AllowedTownhallTypesForRecordingPublish and AllowedWebinarTypesForRecordingPublish both default to Everyone. They both accept the following values:
How can we check it? We can pass a random value and inspect the error:
For TownhallChatExperience it is not that easy. It accepts any string value and does not return any error. However, it effectively does nothing:
In events policies, the word townhall refers to Live Events. That gives us some ideas. For webinars, we already know about on-demand recording (123052, MC661825). We will get similar functionality for Live Events, but it is not announced.
We will also get chat functionality in Live Events, which is big news. However, no details are available about the timeline or functional details.
Checklist for AllowedTownhallTypesForRecordingPublish:
Checklist for AllowedWebinarTypesForRecordingPublish:
Checklist for TownhallChatExperience:
New-CsTeamsMeetingPolicy and Set-CsTeamsMeetingPolicy now have two new parameters:
Get-CsTeamsMeetingPolicy cmdlet already returns these properties.
From the first parameter’s name, it might seem that we will have the option to store recordings locally. Zoom has a similar parameter in the SDK. I can see one big pro of local recordings - they will not expire. However, this Pull Request suggests that the parameter is for Microsoft internal use only.
The other property suggests connecting to meeting controls by something that does not natively belong to Teams. Is it for Elgato Steam Deck or for something else? We don’t know yet.
Checklist for AllowLocalRecording:
Checklist for ConnectToMeetingControls:
The routing policy for shared calling is a new type of policy introduced in the 5.5.0 release. The entire set of cmdlets is already available:
Granting policy to a group is available with the -Group and -Rank parameters for Grant- cmdlet. The policy contains the following configurable parameters (via New- and Set-):
Get-CsTeamsSharedCallingRoutingPolicy cmdlet already returns these parameters. However, seting or creating anything ends with our well-known error:
I found an announcement that might be related to this policy. Its title is Call delegation feature enhancements. It is described as the ability for delegates and delegators to join active calls, if permitted. Roadmap item 123753 and Message Center entry MC649047 (non-admin mirror) describe it quite well.
Checklist for shared calling routing policy:
New-CsTeamsVoiceApplicationsPolicy and Set-CsTeamsVoiceApplicationsPolicy get three new parameters:
The default value for all three parameters is Disabled. The available values are:
Get-CsTeamsVoiceApplicationsPolicy cmdlet already returns these parameters. Surprisingly, all the parameters are already described in the Manage voice applications policies for Microsoft Teams article.
Checklist for new parameters:
NetworkSiteID parameter is now available for Get-CsPhoneNumberAssignment and Set-CsPhoneNumberAssignment.
It is currently unknown what is the site identified for. Is it possible that the number assignment will be dynamic, based on the network?
Checklist for NetworkSiteID:
Searching for this parameter is difficult as there are other cmdlets using it. Therefore, the checklist might be misleading.
Set-CsTeamsUpgradeConfiguration gets one new parameter: BlockLegacyAuthorization. It accepts a boolean value. Its default value is false.
The parameter was already visible in Get-CsTeamsUpgradeConfiguration since May 2023. However, it is still unclear what it does.
There is plenty of articles on the web showing how to block legacy authentication (using Conditional Access). However, the parameter name is about authorization, which is a different topic.
Checklist for BlockLegacyAuthorization:
Quite a long article, isn’t it? But that is because there were plenty of hidden features introduced in this version.
Which one do you find the most interesting? Let me know in the comments if you want!