is a command line–based management shell that is usually used for bulk management and automation tasks. One of the great advantages of PowerShell is that it is object oriented. This means that unlike in the traditional Windows shell ( cmd.exe ) that uses only text-based inputs, everything in PowerShell is an object complete with a list of properties. For example, if you retrieve a user in PowerShell, what you will actually get is an object representing that user complete with a list of properties that you can then read or update. Once you have the object you want to work with, you can then pass it between commands quickly (called cmdlets) and easily, allowing you to reliably and repeatedly perform operations against it.
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.
Install and Connect to Teams PowerShell
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 -AllowClobber switch 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.12 Installing 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.13 PowerShell 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 -WhatIf and -Confirm switch 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.
Policy Management
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.14 Policy 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
