Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET
Microsoft Teams|Office|Office 365

Teams Doesn’t Need Two PowerShell Modules (But Why Two Exist)

One for Teams, One for Skype for Business Online

One of the blessed PowerShell mysteries is the necessity to use two modules to manage Teams. There’s the Teams module and the oh-so-wonderful Skype for Business Online module. The two modules are very different.

The Teams PowerShell module is based on the Microsoft Graph. Its original implementation was flawed because the cmdlets available in the module mimicked the same ability to change settings as available to users in the Teams desktop and browser client. Over time, Microsoft gradually improved the module, notably to incorporate support for team management needed by the Teams Admin Center.

Generally Available PowerShell for Teams

All this work was presented by Microsoft as a preview. They eventually released a generally available version of the Teams module in April 2019. Unfortunately, the GA module suffers from some notable defects, the most obvious of which being its slowness when retrieving sets of teams. Filtering is another area ripe for improvement.

But the biggest improvement Microsoft could make is to dump the Skype for Business Online module. As far as I can see, the only reason this module lingers on is that it was easier for Microsoft to build it out with the policies needed by Teams.

Sponsored Content

Say Goodbye to Traditional PC Lifecycle Management

Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.

Policy-Driven Advantages

Policies are good because they allow administrators to apply a very granular level of control over different aspects of Teams. It would have been great if Microsoft had created cmdlets to manage the policies used by Teams in the Teams module, preferably after making sure that the policy cmdlets worked in a consistent manner to the rest of the cmdlets in the module.

Why Policies Remain in Skype for Business Online

They didn’t. Probably because it’s easier and faster in software engineering terms to extend an existing framework to add some extra policies, we’re left with two incoherent modules. It’s also correct that we’re in the middle of the transition from Skype for Business Online to Teams, so a case can be argued that keeping the policy cmdlets in the Skype for Business Online module is sensible.

Of course, software engineers never have to manage actual tenants, so they don’t see just what a pain it can be to have functionality split across multiple modules. As far as the engineers are concerned, their code works. And to be fair, the cmdlets in the Skype for Business Online module do work. That is, if you keep a session active as the module likes to time out and then won’t reconnect. Apparently, there’s a cmdlet “coming” to fix the problem, but I see no trace of it as I write.

The Big Seven Policy Cmdlets for Teams

In any case, not much is going to change soon, which means that Teams administrators need to understand how to work with the policies that affect Teams. Running the Get-Command cmdlet reveals that there are 18 sets of policy cmdlets in the Skype for Business Online module. Each set has a Get- cmdlet (fetch policy settings), Set- cmdlet (update policy settings), New- (create new policy of the type) and Grant- cmdlet (assign a policy to a user). Some policy cmdlets in the module (like the *-CsTeamsNotificationAndFeedsPolicy set) are undocumented.

The Teams Admin Center does a good job of making it easy to create and manage policy settings and to assign policies to users (Figure 1).

Figure 1: Assigning Teams policies to a user in the Teams Admin Center (image credit: Tony Redmond)

However, when the time comes to assign a policy to multiple users, you’ll want to know how to do this with PowerShell. Table 1 outlines the seven policy cmdlets of most interest.

Cmdlet Set Purpose


Controls which apps Teams users can access. See Permissions policies under Teams apps in the Teams Admin Center.
*-CsTeamsAppSetupPolicy Controls the set of apps pinned to the Teams app bar. See Setup policies under Teams apps in the Teams Admin Center.
*- CsTeamsCallingPolicy Controls the calling policies available within a tenant. See Calling policies under Voice in the Teams Admin Center.
*- CsTeamsChannelsPolicy Controls the org-wide settings for channels (including private channels in the future). See Teams policies under Teams in the Teams Admin Center.
*- CsTeamsFeedbackPolicy Controls the display of feedback surveys and Give feedback option for Teams clients. This policy isn’t available in the Teams Admin Center.
*- CsTeamsMeetingPolicy Controls the type of meetings users can create and the features they can use in meetings. See Meeting policies under Meetings in the Teams Admin Center.
*- CsTeamsMessagingPolicy Controls the messaging features available to users. See Messaging policies in the Teams Admin Center.

Table 1: Essential Teams Policy Cmdlets

These are the most commonly used policy cmdlets. Other aspects of Teams, like Live Events, are controlled by other policy cmdlets (*-CsTeamsMeetingBroadcastPolicy).

Grant cmdlets are available to assign policies to users. For example, I don’t like the idea of Teams presenting end users with feedback surveys (where the data flows to Microsoft without any tenant oversight), and the easiest way to stop this happening is to create a new feedback policy and use the Grant-CsTeamsFeedbackPolicy cmdlet to assign the policy to users.

Looking Forward

PowerShell is messy within Office 365. Too many modules, too many inconsistencies across modules, too little cooperation between engineering groups. It would be nice if the Teams developers took the initiative to unify the Teams cmdlets into one module. Maybe it will happen when Skype for Business Online bites the bullet in 2021. Only two more years to wait.


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (3)

3 responses to “Teams Doesn’t Need Two PowerShell Modules (But Why Two Exist)”

  1. <p>I used to use Slack before, but changed to Microsoft Teams after reading <a href="; target="_blank" style="background-color: rgb(255, 255, 255);">Why Microsoft teams is better than Slack</a>. As a working professional, I still use Teams. But after this article, my stance has changed somewhat. I can't understand why Teams needs to have TWO Powershell modules. Also the article mentions, there are inconsistencies across modules and the engineering of the product is not upto the mark.</p><p>Microsoft needs to pull itself together and bring a better product for us consumers.</p>

    • <blockquote><a href="#16571"><em>In reply to ruskinf:</em></a><em> The Skype for Business Online module will go away, but only when Skype for Business Online retires in July 2021. I can't see Microsoft investing any more engineering resource in it until they have to… Even so, that shouldn't be a reason not to use Teams. All software has rough edges. This is just one of those that Teams administrators must cope with.</em></blockquote><p><br></p>

Leave a Reply

Tony Redmond has written thousands of articles about Microsoft technology since 1996. He covers Office 365 and associated technologies for and is also the lead author for the Office 365 for IT Pros eBook, updated monthly to keep pace with change in the cloud.
Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: