Thursday 1 December 2022

Teams PowerShell Module - Certificate Authentication

There are several ways to get the Teams PowerShell module to authenticate against Azure in order to get access to running Teams PowerShell in your Tenancy. Most people will be used to using the interactive method, where you just run the basic Connect-MicrosoftTeams command and get an interactive Azure auth screen that pops up and you enter your user account details into. This is fine if you are manually connecting and doing this by hand. However, what if you want to run an Azure Function that needs to authenticate automatically each time it executes? Well, for that you want to use an application authentication method.

Currently as of the module version 4.9.1, Microsoft officially supports two methods for application authentication when connecting to the Teams PowerShell module:

  • Certificate based authentication – In this method you have a certificate with private and public keys. The PC connecting to Azure needs to have a copy of the private key and Azure needs to have a stored copy of the public key. As part of the connection the private key will be used to sign the connection and if Azure can decrypt the information with the public key then the PC is trusted to connect. This essentially makes the private key like a password that you need to ensure that no one else has access to.
  • Token based authentication – The token-based method requires that you set up a Client Secret in Azure. When you connect to Azure using the PowerShell module, you authenticate against the Token Service using the Client Secret and get Tokens back that you can use to connect to the service. In the case of the Teams module, you need to get two tokens to be able to run all the commands. You can find out more about this option here: Token Auth Post

In this post we are going to focus on the certificate-based authentication method. Here are the steps for setting up and connecting using certificate-based authentication:

 

Step 1: Generate a Certificate:

The good news here is that the certificate you need does not need to be signed by an internet-based Certificate Authority. You can simply create a self-signed certificate on a PC and use this for connection. Below is a PowerShell command you can run (you must run the PowerShell window as Administrator to execute it). The most important flag in the command is the KeySpec flag which tells it to generate a certificate that can be used for Key Exchange.

New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -Subject TeamsAppTestCertificate01 -KeySpec KeyExchange

 

Step 2: Export the Certificate:

In order to export the certificate you can either run PowerShell or do it by hand with the Certificate Snap-in. Both options will be detailed below. Choose the one that you’re most comfortable with.

Export the Private Key (This step is only needed if you want to run PowerShell from a different machine that you have created the certificate on, for example, a Function App, etc):

PowerShell:

$password = ConvertTo-SecureString -String "SpecialPassword123!" -Force –AsPlainText

Export-PfxCertificate -Cert "cert:\LocalMachine\My\8E4CKSHDUSG873F66D99AC7935F53" -FilePath "C:\temp\AuthPrivateKey.pfx" -Password $password

Note: The thumbprint to be used here will be output from the New-SelfSignedCertificate command you previously ran.

 

Or Windows UI:

Once again, this is is only needed if you want to run PowerShell from a different machine that you have created the certificate on, for example, a Function App, etc.

Search PC for mmc.exe > File Menu > Add or Remove Snap-in > Certificates > Add > Computer Account > Personal > Certificates Folder > Right Click on the Certificate > Export…

Export Certificate Wizard:

Click Next...


Select: "Yes, export the private key":


Go with the default export options:


Enter a password for the PFX file and ensure that you select TripleDES-SHA1 (I have found that importing on some platforms is not supported with AES):


Enter a name and location for the pfx file to be output to:


Export the Public Key (to be uploaded to the App Registration in Azure)

PowerShell:

Export-Certificate -Cert "Cert:\LocalMachine\My\8E4CKSHDUSG873F66D99AC7935F53" -FilePath "C:\temp\AuthPublicKey.cer"

Or Windows UI:

Click Next... 


Do not export private key:

Select the format of the file (DER is okay in this case) and click next:


Select the name of the file and click next:


Step 3: Configure the App Registration:

Open the Azure AD Portal and select the Azure Active Directory > App Registration section:

 Click the "New Registration" Button:

 

Fill in a name for the application and click the Register button:


The App Registration will now be created, however, there is still more config to do:



Go to the “Certificates & secrets” blade:



Select the location of the public key certificate that you exported earlier. Add a description and click OK:


The certificate should now show up in the certificates area:


Now open the API Permissions tab within the App Registration, Click "Add a permission":


You will need to add the following Graph API permissions to the App Registration:

User.Read.All

Group.ReadWrite.All

AppCatalog.ReadWrite.All

TeamSettings.ReadWrite.All

Channel.Delete.All

ChannelSettings.ReadWrite.All

ChannelMember.ReadWrite.All

These permissions are documented by Microsoft here, so you may want to check to see if there have been any updates for the PowerShell version you're using: https://learn.microsoft.com/en-us/microsoftteams/teams-powershell-application-authentication


Click the "Microsoft Graph" option:



Select "Application Permissions":

Select the permissions that were listed above:


Ensure that you have added all the permissions. If you missed any then repeat the above steps for all the permissions in the list…

 

After adding all the permissions, you need to click the “Grant admin consent for <tenant id>” button on the main Permissions screen:


At the end of this procedure, you should have the following permissions all assigned with admin consent granted:


In a final twist in this adventure, you also need to make sure you assign Teams Administrator privileges to the App Registration in order for it to be able to run CS commands. You do this by going to the Active Directory tab > Roles and Administrators > Teams Administrator Role:

 


Assign the Service Permission that is named the same as your App Registration to the RBAC Role:



Connecting To Teams PowerShell

 

Now that all the backend work has been done we can get down to doing some connecting. When you connect it needs to be from a machine that has access to the certificate. On a PC this means it has to be in the certificate store. If it’s from a machine in Azure there are various methods for doing this too (which I may well get to in another post…).

You will need to know the ApplicationId that was given to the App Registration in Azure. You can find this out by looking going to the Overview tab and looking for the GUID that has the title “Application (client) ID”. The TenantId is the base domain name that was first given to your tenancy when it was created or alternatively can be the GUID that’s in the Overview tab named as “Directory (tenant) ID” (both options will work).

 

Teams Module Connect Command:

Connect-MicrosoftTeams -CertificateThumbprint "3ab0e057bc3278ecb2a33123042e5a7a8001ff8c" -ApplicationId "319d0a47-9a48-45b0-b416-14aca00e7ece" -TenantId contoso.onmicrosoft.com

 

When connection is successful, you’ll get back an object displayed in the PowerShell window that tells you the Account, Environment, Tenant and TenantId values. From here you should be able to run almost all of the commands from the module, with the following exclusions:

As of 4.9.1; All cmdlets are supported now, except for the cmdlets mentioned below:

  • New-Team
  • [Get|Set|New|Sync]-CsOnlineApplicationInstance
  • *-CsUserCallingSettings
  • *-CsUserCallingDelegate
  • *PolicyPackage*
  • *-CsTeamsShiftsConnection*
  • *-CsBatchTeamsDeployment*

  

The Wrap Up

 

Congratulations, you’re now an expert at certificate-based authentication with the Teams PowerShell module. If you are interested in Token Based Authentication using the Teams Module, then you can check out my post on that over here: Token Auth Post.




Read more →

Teams PowerShell Module – Token Authentication

There are several ways to get the Teams PowerShell module to authenticate against Azure in order to get access to running Teams PowerShell in your Tenancy. Most people will be used to using the interactive method where you just run the basic Connect-MicrosoftTeams command and get an interactive Azure auth screen that pops up and you enter your user account details into. This is fine if you are manually connecting and doing this by hand. However, what if you want to run an Azure Function that needs to authenticate automatically each time it executes? Well, for that you want to use an application authentication method.

Currently as of the module version 4.9.1, Microsoft officially supports two methods for application authentication when connecting to the Teams PowerShell module:

  • Token based authentication – The token-based method requires that you set up a Client Secret in Azure. When you connect to Azure using the PowerShell module, you authenticate against the Token Service using the Client Secret and get Tokens back that you can use to connect to the service. We will dig further into this method in this post.
  • Certificate based authentication – In this method you have a certificate with private and public keys. The PC connecting to Azure needs to have a copy of the private key and Azure needs to have a stored copy of the public key. As part of the connection, the private key will be used to sign the connection and if Azure can decrypt the information with the public key, then the PC is trusted to connect. This essentially makes the private key like a password that you need to ensure that no one else has access to. If you would like to know more about this method, please check out my post here about it: Certificate Auth Post.

In this post we are going to focus on the token-based authentication method. Here are the steps for setting up and connecting using token-based authentication:

 

Step 1: Configure the App Registration:

Open the Azure AD Portal and select the Azure Active Directory > App Registration section:

 

Click the New Registration Button:


 

Fill in a name for the application and click the Register button:


 The App Registration will now be created. However, there is still more config to do:



Go to the “Certificates & secrets” blade:


Enter a name for your client secret that makes sense for you and click "Add":



You will now seen your new Client Secret. Copy the secret value and put it somewhere safe:

I'll say it again, before leaving this screen take a copy of the Client Secret Value because it will not be available when you return later. Also, it’s important that you treat this secret as you would a password because it can give anyone the keys to your Teams castle… which would be very bad.

 

Configure the Application Permissions:



You will need to add the following Graph API permissions to the App Registration:

User.Read.All

Group.ReadWrite.All

AppCatalog.ReadWrite.All

TeamSettings.ReadWrite.All

Channel.Delete.All

ChannelSettings.ReadWrite.All

ChannelMember.ReadWrite.All

These permissions are documented by Microsoft here, so you may want to check to see if there have been any updates for the PowerShell version you're using: https://learn.microsoft.com/en-us/microsoftteams/teams-powershell-application-authentication

 

Click the "Microsoft Graph" option:



Select "Application Permissions":

Select the permissions that were listed above:


Ensure that you have added all the permissions. If you missed any then repeat the above steps for all the permissions in the list…

 

After adding all the permissions you need to click the “Grant admin consent for <tenant id>” button on the main Permissions screen:


At the end of this procedure you should have the following permissions all assigned with admin consent granted:

 

In a final twist in this adventure, you also need to make sure you assign Teams Administrator privileges to the App Registration in order for it to be able to run CS commands. You do this by going to the Active Directory tab > Roles and Administrators > Teams Administrator Role:


 

Assign the Service Permission that is named the same as your App Registration to the RBAC Role:

 

Connecting To Teams PowerShell

 

Now that all the backend work has been done, we can get down to doing some connecting.

You will need to know the ApplicationId that was given to the App Registration in Azure. You can find this out by looking going to the Overview tab and looking for the GUID that has the title “Application (client) ID”. The TenantId is the base domain name that was first given to your tenancy when it was created or alternatively can be the GUID that’s in the Overview tab named as “Directory (tenant) ID” (both options will work). And you need to know the Client Secret that was created at the beginning of the App Registration creation process (I did tell you to take note of this -- if you didn’t then you may not be able to see the secret in the portal anymore. If so, then you need to create a new one).

  

The Connection PowerShell:

$ClientSecret   = "P_1a3~cNhA1Jd~iS9.mdUh2ffe_qp~u9Leuk4aYa" # Your Client Secret

$ApplicationID = "00000000-0000-0000-0000-000000000000" #Your Application ID

$TenantID = "YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY" #Your Tenant ID

 

$graphtokenBody = @{  

   Grant_Type    = "client_credentials"  

   Scope         = "https://graph.microsoft.com/.default"  

   Client_Id     = $ApplicationID  

   Client_Secret = $ClientSecret  

} 

 

$graphToken = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantID/oauth2/v2.0/token" -Method POST -Body $graphtokenBody | Select-Object -ExpandProperty Access_Token

 

$teamstokenBody = @{  

   Grant_Type    = "client_credentials"  

   Scope         = "48ac35b8-9aa8-4d74-927d-1f4a14a0b239/.default"

   Client_Id     = $ApplicationID  

   Client_Secret = $ClientSecret

}

 

$teamsToken = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantID/oauth2/v2.0/token" -Method POST -Body $teamstokenBody | Select-Object -ExpandProperty Access_Token

 

Connect-MicrosoftTeams -AccessTokens @("$graphToken", "$teamsToken")

 

I know what you’re thinking… That’s a lot of PowerShell code to just connect to PowerShell and you are correct in thinking that. However, this code, while looking ominous, is actually not all that complicated when you break it down.

Let’s break it down; The first 3 lines are variables where you need to fill in your specific Secret, Application ID and Tenant ID. These are the only three lines that you need to edit, so you can relax. The other lines of code basically run two separate REST calls to Azure to get access to two different tokens. One token is for the Graph API and the other is for Teams. Once you have these tokens you then pass them to the Connect-MicrosoftTeams command which uses them to authenticate against the service.


Note: The tokens have a lifetime of 1 hour, so if you were going to make an app that was going to make a lot of connections over the course of an hour you make want to cache the tokens and reuse them.


When connection is successful, you’ll get back an object displayed in the PowerShell window that tells you the Account, Environment, Tenant and TenantId values. From here you should be able to run almost all of the commands from the module, with the following exclusions:

As of 4.9.1; All cmdlets are supported now, except for the cmdlets mentioned below:

  • New-Team
  • [Get|Set|New|Sync]-CsOnlineApplicationInstance
  • *-CsUserCallingSettings
  • *-CsUserCallingDelegate
  • *PolicyPackage*
  • *-CsTeamsShiftsConnection*
  • *-CsBatchTeamsDeployment*


The Wrap Up

 

There’s all you should hopefully need to know about setting up a simple Token Authentication based connect to Microsoft Teams PowerShell. At the beginning of the post I also mentioned Certificate-based authentication. If you would like to know more about Certificate-based authentication, don’t forget you can check out my post here about it: Certificate Auth Post.





Read more →

Teams PowerShell Certificate or Token Based Auth WinRM Error

I ran into an issue the other day that was difficult to troubleshoot due to the obscure error that arose. The scenario: I was attempting to use Certificate or Token based Authentication to do an application-based authentication with Azure (instead of the regular interactive password based authentication).

After setting everything up and connecting to Teams PowerShell, there was a persistent error any time a Skype for Business *Cs* command was run. The error referenced the WinRM client not being able to process the request. Here’s the error in question:


PowerShell Error:

PS C:\> Connect-MicrosoftTeams -CertificateThumbprint "897a047bc435843b2a32126544e5a7a8001fee8c" -ApplicationId "216d0455-8988-45b0-b425-222ca02e8ede" -TenantId contoso.onmicrosoft.com

 

Account                              Environment Tenant                               TenantId

-------                              ----------- ------                               --------

219d0455-8988-45b0-b425-222ca01e8ece AzureCloud  6364a50-c3d7-4eee-834c-21a2371df363 6364a50-c3d7-4eee-834c-21a237...

PS C:\> Get-CsOnlineUser

2022-11-22T23:02:46Z [Error] ERROR: Connecting to remote server api.interfaces.records.teams.microsoft.com failed with the following error message : The WinRM client cannot process the request. The authentication mechanism requested by the client is not supported by the server or unencrypted traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configuration or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.

 

From the error it seemed like an issue on the client side to do with the method being used to authenticate or communicate with the cloud endpoint on the client side… However, after exhaustively chasing down anything to do with the client side WinRM settings, nothing was working… This was on the latest 4.9.1 Teams PowerShell module which in its release notes listed application authentication as being made GA (https://learn.microsoft.com/en-us/microsoftteams/teams-powershell-release-notes). As a result, it’s not likely there was a bug in the module that meant that all *CS* commands just didn’t work...

At this point I looked to the cloud. When configuring application-based authentication for the Teams PowerShell module, you need to set up an App Registration and assign it permissions and RBAC roles to allow it to access Teams. In the deployment I was working on, the following permissions were assigned:

 


The documentation (https://learn.microsoft.com/en-us/microsoftteams/teams-powershell-application-authentication) from Microsoft says that the following settings were required:

User.Read.All

Group.ReadWrite.All

AppCatalog.ReadWrite.All

TeamSettings.ReadWrite.All

Channel.Delete.All

ChannelSettings.ReadWrite.All

ChannelMember.ReadWrite.All

Note: For the record, you also need to assign the Teams Administrator RBAC role to the Application Service Principal in the Roles and Administrators area (but this wasn’t the issue in this case).

It appears that all of these permissions were included. So it should be fine, right?


….Wrong.


What I found out was that the “Skype and Teams Tenant Admin API” permissions that were included here were to blame for the error. After removing and revoking both of the innocuous “Skype and Teams Tenant Admin API” permissions, I was able to connect and run *CS* commands to my heart's desire…


So to anyone who says “you can never have too many permissions” it appears that you actually can... 

Note: There may be other permissions that also cause this to happen, so make sure you haven't assigned more permissions than are required.


The Solution


Remove the offending “Skype and Teams Tenant Admin API” permissions:


Once removed, the permissions get demoted into the "Other permissions granted for <tenant name>" area, where you need to then "Revoke all admin consents" before they will be fully removed:


After this you should have these permissions left:


After this, you shouldn't get the WinRM error anymore when running CS commands! 

Be sure that you have applied the Teams Administrator RBAC role to the App Registration Service Principal as well. Go to: Azure Active Directory > Roles and administrators > Teams Administrator > Add Assignments Button > Search for your App Registration Name and assign it:

 


The Wrap Up


I hope that helped out a few of you poor people banging your head against the wall about the WinRM error situation. If you want to check out a full walk through of setting up Certificate or Token based Authentication with the Teams PowerShell Module, check out these posts:

Certificate-based Authentication post

Token-based Authentication post

See ya next time!




Read more →

Sunday 23 October 2022

Microsoft Teams Phone Configuration and Licensing (2022 Edition)

There have been quite a few changes recently to feature sets and licensing of Microsoft Teams Phones. This post digs into the details of the various phone modes and licensing options in 2022.  Note, this post is being released just after Ignite 2022 when it was announced that the Common Area Phone licence is being renamed to the Teams Shared Device licence in "a couple of months". In this post I am going to be sticking with the Common Area Phone licence name until we have further information on any new capabilities that will be included with the Teams Shared Device licence for phones.


User Interface Modes


There has been three user interface available on Teams phone devices for a while now, which allows you to tailor the experience to different scenarios. In the past these required PowerShell configuration, however, the Teams will now try to auto-magically choose the interface for the phone based on the licence the user account has been assigned.

For regular users logging in with E3-E5 licensing, the system assumes that the User Mode interface should be used. When a Common Area Phone licence (announced at Ignite 2022 to be changing names to the Teams Shared Device licence) is assigned the Common Area Phone interface will be selected by default. Lastly, when a Teams Meeting Room licence is assigned to the phone, the Meeting Room interface will be shown. When testing this I have found that in most cases the licence based auto assignment works, but for some reason this sometimes doesn't work and the phone falls back to User Mode. As a result, I would still recommend using the PowerShell command to select the interface mode for more consistent outcomes.

There are also now two different versions of the Common Area Phone mode. The original mode is now called Common Area Phone Basic and an extra special Common Area Phone Premium mode. The premium mode take into account a bunch of new capabilities in the updated Common Area Phone licence updates that came in mid-2022. Without further ado - let's have a more detailed look at the modes...


Common Area Phone Mode (Basic)


Common Area Phone (Basic) mode is used for devices that have their own user accounts and are (usually) assigned a Common Area Phone licence. The default Common Area Phone user interface has a basic keypad layout for dialing phone numbers. All the other bells and whistles like calendar, voicemail, etc at nowhere to be seen in this interface. Below is an example of the default Common Area Phone user interface:

 

   

Note: The About screen on the phone will show Common Area Phone (Basic) when you're in this mode.

For Common Area Phone Basic mode there is another setting where you can turn on or off the user search capabilities on the device. You may want to use this if you have a phone sitting in a lobby of a building and you don’t want people to be able to find out people that work there using the search function.

SearchOnCommonAreaPhoneMode = Enabled
SearchOnCommonAreaPhoneMode = Enabled

It is recommended that if you want to use a phone in Common Area Mode that you create a Teams IP Phone Policy and assign it to the Common Area Phone account. A Common Area Phone account should be a regular user account. You should not be using room accounts for these devices. Here’s an example of setting up the Phone Policy:


New-CsTeamsIPPhonePolicy -Identity CommonAreaPhone -SignInMode CommonAreaPhoneSignin

 

Grant-CsTeamsIPPhonePolicy –Identity 'testuser@contoso.com' –PolicyName ‘CommonAreaPhone’

 Note: The quickest way to get this change to take effect is to sign the phone out and back in again.


Common Area Phone Mode (Premium)


Since mid-2022 (Teams app version 1449/1.0.94.2022061702) the licensing for Common Area devices was expanded to include some new features (Voicemail, Call Forward settings, Call Park, Call Queues, Auto Attendants, Intune enrollment into Endpoint Manager). As you can probably imagine, the very basic default Common Area Phone user interface is not going to give you the flexibility to use all these features. So Microsoft went for a user interface that looks mostly like the User Mode interface, only without the meetings section.

The Common Area Phone Advanced Calling interface looks like this: 

 

    

Note: In the about page you will be able to tell that it's in this mode because it says "License Details: Common Area Phone (Premium)".

These devices are still geared towards being an admin controlled device, so if you want to access the Call Forwarding settings on the device you need to access the Admin level of settings in the phone - for example:


Note: Wow, cool animated GIF… If you want to make your own, download my Teams Phone Screen Capture Tool script: https://www.myteamslab.com/2020/10/teams-phone-screen-capture-tool.html


The new features are called Advanced Calling features and are controlled by a setting within Configuration Profiles in Device Configuration in the Teams Admin Portal. Personally, I would have preferred this setting be a Teams IP Phone Policy rather than an individual device profile… however, Microsoft sometimes enjoy making things a little more complicated.


To enable a device for Common Area Advanced Calling features you need to create a new Configuration Policy and turn on the "Advanced Calling" Setting:


After this you have to assign the Configuration Policy to the devices that you want to use it:


After doing this you need to wait a while for the configuration policy to be pushed to the phone. You will have to have the phone registered to the cloud and signed in for this to happen.


As for the Common Area Phone Basic mode, it is recommended that you create a Teams IP Phone Policy and assign it to the user account. Here’s an example:

New-CsTeamsIPPhonePolicy -Identity CommonAreaPhone -SignInMode CommonAreaPhoneSignin

 

Grant-CsTeamsIPPhonePolicy –Identity 'testuseradvanced@contoso.com' –PolicyName ‘CommonAreaPhone’

 Note: The quickest way to get this change to take effect is to sign the phone out and back in again.


Meeting Room Mode


Meeting Room mode is for devices that you want to put in Meeting Rooms (Surprise!). Most commonly this would be for a conference room style phone, however, it could also be for small rooms where you might have a desk phone running the meeting room interface.

The Meeting mode was recently updated to have a new look which is more in line with the other Microsoft Teams Meeting Room device interfaces. This is great when you have a combination of video meeting rooms and basic conference phone rooms in your organisation. The similar interface allows for a consistent user experience for booking the rooms in both cases and having a one-touch join button can make meeting more likely to start on time and be much more streamlined.

Here is an example of the new Meeting Room interface:

 

  

When creating Meeting Room accounts it’s usually a better idea to create the phone account as a Room account rather than a User account. This gives you the option to have the room auto accept meeting invites and be shown as a room in Teams meeting invites. Here is an example of creating the room account:


Step 1: Add A Room Resource In Microsoft 365 Admin Centre. Click the "Add resource" button:



 Step 2a: Fill in the details of the account you will be creating:



 Step 2b: Optionally you can edit the booking options:

Step 2c: Ensure that you have “Auto accept meeting requests” ticked for your device so it will display the meetings properly:


Step 3a: Open the User Information pane in Microsoft 365 Admin Centre:


Step 3b: In the Licenses and Apps tab, assign a Microsoft Teams Room Basic (I would recommend also adding a Teams Phone licence for PSTN calling capabilities) or Teams Room Pro license:


Step 3c: Reset the account Password by clicking on the Reset Password button at the top this panel. This will allow you to sign into the Room account:



After setting up the account you can also force the Meeting Room mode by run the following Team Module PowerShell commands:

New-CsTeamsIPPhonePolicy -Identity MeetingRoomPhone -SignInMode MeetingSignIn

 

Grant-CsTeamsIPPhonePolicy –Identity 'testuser@contoso.com' –PolicyName ‘MeetingRoomPhone’

 Note: The quickest way to get this change to take effect is to sign the phone out and back in again.


As a bonus you can also add the Teams room to the list of locations that show up in the Teams client meeting invite screen:


How to create a Room Location (Distribution Group Room List):

Connect-ExchangeOnline

 

New-DistributionGroup -Name “City Office” -RoomList

 

#Add the affected room mailbox to that distribution group

Add-DistributionGroupMember -Identity “City Office” -Member TeamsRoomPhone01@contoso.com

 

As an additional super bonus, you can help to indicate that this is an Audio only room in Outlook when scheduling the meeting by configuring Place information for the room (see the little Audio symbol, wheelchair symbol and room capacity value. Subtle but useful).

 


Here's some example PowerShell for doing this:

Set-Place -identity TeamsRoomPhone01@M365x52543986.onmicrosoft.com -IsWheelChairAccessible $true -AudioDeviceName "Poly C60 Conference Phone" -Capacity 4 -Building “City Office”



User Mode


User Mode is the mode that any regular user that signs into a Teams Phone will see. It has the full suite of features available including Calls, Calendar, Voicemail, People, etc. Here is an example of the User mode interface:

 

     


Usually you shouldn’t have to set Teams IP Phone policy to achieve user mode. By default, when a user has E3-E5 licencing SKUs the phone will default to this mode (unless you have the IP Phone Policy set to one of the other modes for the user). If you want to force User Mode, you can do this with the following PowerShell commands:

New-CsTeamsIPPhonePolicy -Identity UserPhone -SignInMode UserSignIn

 

Grant-CsTeamsIPPhonePolicy –Identity 'testuser@contoso.com' –PolicyName ‘UserPhone’


Note: The quickest way to get this change to take effect is to sign the phone out and back in again.


Licencing Microsoft Teams Phones


As previously mentioned, the licensing of Teams Phones can control what the default interface shown on the phone will look like. However, it begs the question: if you do choose to override the default interface can you choose any of the UI modes with any licence combination?


Firstly, in all cases you need to ensure that your phone software is up to date. The testing for this post was with version 1449/1.0.94.2022090705 of the Teams Phone App. There have been a few iterations of the way licensing works on the phones, so older versions may behave differently. I've also found that when you do a full config reset on a phone it will actually drop the Teams Phone version back to the version that shipped with the base firmware. After doing a config reset on the phone you will likely have to upgrade the Teams Phone App again - so be sure to check this.


After extensively searching the Internet, I found a docs page that does the bare minimum to describe what happens when you use Teams IP Phone Policy to override the license based automatic configuration: https://learn.microsoft.com/en-us/microsoftteams/devices/teams-android-devices-user-interface


The important note on this page being:

"The license assigned to the user account must have at least the same license entitlements as the desired user interface. The Common Area Phone licence allows the Common Area phone user interface. The meeting room license allows meeting room and common area phone user interfaces. An E3 or E5 license supports all sign-in modes."


Note: This statement doesn't include E1 licensing. E1 only has Plan 1 Exchange licensing, and doesn't include Voicemail -  which may be the reason for this omission..? It has been left out of this support statement, so use E1 at your own risk... 


I have created the table below to try to give you a quick idea of the options for licensing Team Phones for the various modes (including some important Add-On licences):

 

Base Licence

Supported 

Interface 

Modes

Teams Phone 

(Direct Routing /

 Operator Connect)

Conditional

Access

Intune   

Calling Plans

(Microsoft PSTN, 

i.e. Not Direct 

Routing)

Common Area Phone Licence

Common Area Phone (Basic / Premium)

Included

Included

Included

Add-On Required

Teams Room Basic

Meeting Mode,

Common Area Mode

Teams Phone Add-On

Add-On Required

Add On Required

Add-On Required

Teams Room Pro

Meeting Mode,

Common Area Mode

Included

Included

Included

Add-On Required

M365 E3

User Mode,

Meeting Mode,

Common Area Mode

Teams Phone Add-On

Included

Included

Add-On Required

M365 E5

User Mode,

Meeting Mode,

Common Area Mode

Included

Included

Included

Add-On Required

Office 365 E3

User Mode,

Meeting Mode,

Common Area Mode

Teams Phone Add-On

Add-On Required

Add-On Required

Add-On Required

Office 365 E5

User Mode,

Meeting Mode,

Common Area Mode

Included

Add-On Required

Add-On Required

Add-On Required

 Note: There are various ways to get the Add-On licences including individual or bundled licences. Speak to your local licensing expert for more details on these.


When talking about licensing for a Teams phone devices, in most cases a Common Area Phone licence (to be renamed to the Teams Shared Device licence) will do if it’s a phone that is out in a public space and users just need to dial PSTN numbers. The updates recently to the Common Area Phone licence that expanded capabilities (allowing Common Area Phone Premium mode) have made the supportable scenarios for common area devices even broader. 


If it’s a meeting room based device (e.g. a dedicated conference phone device) for which you want to use the Meeting Room Mode user interface, then you must use a Meeting Room licence (https://learn.microsoft.com/en-us/microsoftteams/rooms/rooms-licensing) or an E3-E5 licence for the device. Here I would like to note that Microsoft did announce that MTR devices will not support E3-E5 licencing as of 2023. However, it doesn't appear at this stage that this includes phone devices. With the pricing updates to the Meeting Room Pro licensing, this could end up being more expensive than you anticipated. You can use Meeting Room Basic licences for the first 25 meeting room phones but you will have to pair this with a Team Phone add-on licence for PSTN calling (and potentially Azure P1 and Intune licensing if this functionality is required for your deployment). When you run out of Teams Meeting Room Basic licences, you will need to step up to Teams Room Pro licences (which are $40US each per month) or fall back to E3-E5 licensing. If this is too rich for your blood, then you could choose to deploy your meeting room phones as basic Common Area Phone devices (i.e. with the Common Area Phone user interface and Common Area Phone Licence). This would make for a lesser user experience though, and have you trading the One-Touch meeting join button for users having to do audio conference dial-in using the Audio Conferencing number and Phone Conference ID for every call. 

Microsoft at this point have announced that the Teams Shared Device licence update in 2023 will bring support for Teams Displays which can use this licence to connect to Teams for shared device usage: (https://techcommunity.microsoft.com/t5/microsoft-teams-blog/microsoft-inspire-2022-innovations-coming-to-teams/ba-p/3559351). It feels like Microsoft really should be considering including the Meeting Room interface scenario for phone device with the new Teams Shared Device licence as well... However, there is nothing confirming this at the moment. Until further information comes to light we will have to hold our breath on this one. When more information becomes available, I will be back to update this post... Stay tuned.


Update 16/11/2022: According to a response from Microsoft on their latest post on Tech Community about the Shared Device Licence, it will not be supporting one touch join (i.e. I take this to mean the Meeting Room UI experience). Comment: "One touch meeting join will be available only with Microsoft Teams Rooms licenses. It will not be supported on the Teams Shared Device license." 


The Wrap Up


Hopefully that has given you some insights into what configuration and licensing you need to achieve your desired Teams Phone outcomes! If you have any comments or corrections, feel free to send them through. I plan to keep this post up to date with information on the new Teams Shared Device licence, so check back later for updates or follow me on Twitter to stay in the know.




Read more →

Popular Posts