Ben Lee - MCA Microsoft 365 Teams Administrator Study Guide

PowerShell is also an extendable language, meaning you can import modules that give you access to new sets of cmdlets depending on what product you want to work with. Until recently you had to use the Skype for Business Online PowerShell module to work with the communications elements of Teams. The Teams PowerShell module (from version 1.1.6) has merged the required components of the Skype for Business Online modules with other Teams cmdlets, meaning that if you do not need to perform any Skype for Business Online–specific tasks, you only need to install the latest version of the Teams PowerShell module now. Be aware for the exam that some questions might have been written before this changed, so you may still see references to the Skype for Business Online Connector.

While the new Teams PowerShell Connector contains the relevant Skype for Business Online elements, you do still need to connect to them independently, depending on what tasks you are looking to carry out.

It is assumed for this guide that you have worked with PowerShell previously and are familiar with the standard formatting of PowerShell cmdlets (such as Get-, Set-, Remove-). If you haven't used PowerShell before, take a look in the reference list at the Microsoft PowerShell overview materials and get familiar with how PowerShell operates.

From a computer running PowerShell 5.1, first install the Teams module from the PowerShell Gallery at powershellgallery.com. If the machine has Internet access and administrative rights, you should be able do this directly from inside PowerShell itself by running the following command (see Figure 1.12):

Install-Module -Name MicrosoftTeams

You will need to accept the confirmation prompt, and if you have the Skype for Business Connector already installed, you will need to also use the -AllowClobberswitch to overwrite some of the existing cmdlets with the ones from the Teams module (as Teams now includes the required Skype for Business components).

If you are unable to automatically download the module from the PowerShell Gallery repository, refer to the site where it provides instructions about how to manually download and copy files to the correct locations for PowerShell to find them.

FIGURE 1.12Installing the Teams PowerShell module

Next, we need to load up the Teams module and start a connection to our tenant. Depending on what you want to work with, you may have to connect twice: once to Teams and once to Skype for Business Online (remember that Teams shares a lot of its voice components with Skype for Business Online). When establishing the connection, there are several ways you can pass through credentials, depending on if you are using modern authentication with multifactor authentication (MFA) enabled. It is generally recommended that if you are going to perform automated scripting you have an account that does not require MFA (or at least does not require MFA from wherever you are running the script, for example, inside the company network) as this can be a challenge to automate.

#Import the Teams / SfBO module Import-Module -Name MicrosoftTeams #Connect to Teams Connect-MicrosoftTeams #Create an SfBO session and connect to it $SfBOnlineSession = New-CsOnlineSession Import-PSSession $SfBOnlineSession

As you are connecting to each service, you will see two modern authentication prompts (see Figure 1.13) where you can enter your credentials. (It should be an account with some Teams administrator permissions; otherwise, you won't be able to get very far, but more on that in later chapters!)

FIGURE 1.13PowerShell modern authentication prompt

Now you have a connection to O365 and can start viewing and updating settings. Just be careful because while PowerShell is an amazing management tool, you can easily modify settings for large numbers of users in one go, so make sure you thoroughly test any scripts or commands you are going to run. Usually PowerShell cmdlets that modify settings have both a -WhatIfand -Confirmswitch that you can use as a bit of a safety net.

To get an overview of PowerShell, visit docs.microsoft.com/en-us/powershell/.

To find out more about the Microsoft Teams PowerShell module, visit powershellgallery.com/packages/MicrosoftTeams.

For Microsoft's guide to managing M365 with PowerShell, visit docs.microsoft.com/en-us/microsoft-365/enterprise/manage-microsoft-365-with-microsoft-365-powershell.

Teams uses policies to control what features and functionality are available to users and devices. These policies are usually grouped by category, for example calling, messaging, or app integrations (see Figure 1.14). Unlike with Windows Group Policy where policy objects are merged to produce the desired outcome, in Teams each user or device takes their settings from only one policy of each type.

FIGURE 1.14Policy list for a user in the TAC

You can typically assign policies directly to users (either individually or in bulk) or auto-apply them based on group memberships. If no specific policies are assigned, the org-wide policy (this will be called global if you are using PowerShell) will apply. This gives good flexibility when deciding how best to apply policies, but does mean that you need to carefully consider what settings you want to place in the org-wide versus individual policies and weigh the administrative overhead of managing/assigning policies. For example, do you put the most restrictive settings into the org-wide policy and then remove these restrictions as required with individual policies, or vice versa? This will mostly depend on your company culture and what the risks might be of having a user picking up the wrong policy by mistake. The best rule of thumb is to try to keep things simple and not make things too complex, which usually means putting the most common settings into the org-wide policies and then only modifying them as required for users after that.

As a user can have only one effective policy, there is an order of precedence applied to determine which settings a user will get. They are applied as follows:

1 Policy directly assigned to a user

2 Policy inherited from groups (by rank order)

3 Policy inherited from org-wide policy

This is great until you realize that you can have a user who is a member of more than one group that you are using to apply policies. Fortunately, when you assign policy objects to groups, you have to specify a policy ranking. The rankings are a numerical value with number 1 being the highest rank. If a user who does not have an individual policy assigned is a member of more than one group with a group policy assignment configured, they will take their settings from the highest rank (but lowest number!) policy. Group assignments for policies are dynamic, so as users are added or removed from the groups, their settings will be modified, but these changes will be subject to O365 replication delays, so they are unlikely to apply immediately. The TAC will show you what policies are being applied to a user if you look up their specific user account and find the Policy tab.