Teams Rooms Resource account configuration using Staged Rollout

Published Sept. 22,/2023

This article explains how to use Azure Active Directory Staged Rollout with your MTR resource account.  This applies to resource accounts used for Teams Rooms on Android and Teams Rooms on Windows devices.

Scenario:  Your company does not want to create ‘cloud only’ accounts, or .onmicrosoft.com accounts.  They want all accounts to be created onprem in Active Directory and then synchronized to the cloud.  This allows you to maintain full control of the account in onprem Active Directory.

Goal:  You want to follow Microsoft’s guidance.   You need to have the MTR account bypass all onprem Identity solutions, such as Active Directory Federation Services (ADFS) or other 3rd party Identity solutions that provide the same functionality.   The MTR account should authenticate directly to Azure AD, like a ‘cloud only’ account does.

Solution:  Configure Staged Rollout of Cloud Authentication.  This configuration essentially achieved the goal of Microsoft’s recommendation.   A ‘cloud only’ account authenticates the same way as an on-premise synced account that is configured for Staged Rollout.  

1. Azure AD Connect (now called Entra Connect) server must be configured to use Password Hash Sync

2. Your Azure Active Directory tenant is configured to use Staged Rollout, which allows some accounts to authenticate directly to the Azure AD, if they are put into the AAD group that is associated.

For more information, watch this video on steps to configure this  How to configure staged rollout in Azure Active Directory

UNSURE??  If you are not sure if you need to do this, you can check your MTR account with this PowerShell cmdlet.  Your deployment engineer or admin may have modified your synchronized MTR account and turned it into a true ‘cloud only’ account by removing the ImmutableId.

To check the status of your MTR account use the ‘Get-MsolUser -UserPrincipalName user@domain.com | fl’ cmdlet and look for the ImmutableId.  If the ImmutableId is present, this means the account is still being synchronized from onprem AD using Azure AD Connect.  So this account is NOT a ‘cloud only’ account.   This also means that onprem AD is still in full control of this account and any changes to the account in AD, will be synced up to the cloud via Azure AD Connect. 

If the  ImmutableId is not present, this account has been turned into a true ‘cloud only’ account and you do not need to add this account to a Staged Rollout group.

Testing and Troubleshooting:

After you have implemented Staged Rollout of Cloud Authentication, this is how you test it to make sure its working.

• You want to check the federation status of the MTR resource account using this URL, which we can see, it is bypassing ADFS and authenticating directly to Azure AD. https://login.microsoftonline.com/common/UserRealm?api-version=1.0&user=avaya1@sfbteams.com

• To be sure, test this with a similar URL using your own account or a fake account with the same domain suffix, https://login.microsoftonline.com/common/UserRealm?api-version=1.0&user=user@sfbteams.com.  We see that other accounts using that domain suffix are being routed through ADFS for authentication.

Microsoft Guidance for onprem Active Directory accounts used with MTR’s, does not speak to this. However, onprem AD accounts that are synchronized to the cloud are supported per this document. https://learn.microsoft.com/en-us/microsoftteams/rooms/create-resource-account?tabs=m365-admin-center%2Cactive-directory1-password

NOTE:  This has not been tested in GCC, GCC-H or DOD tenants.  It is unknown if it will work in those environments.

How to bulk enroll your Teams Rooms on Windows devices (MTRw)

By: Traci Herr Published on 5/11/2023

Scenario: You or your company has purchased a lot of MTRw devices and you need to get them deployed and signed in. These MTRs are in different locations and you plan to send a technician onsite to the locations you are not at. You don’t want to give the onsite technician the password or UPN of these MTR accounts. You might be asking your AV installer to assist you with this process and they might not be computer savvy. In any case, you need an automated way to do this.

Using this method, you can ensure you don’t have to share any credential information and that all MTRs will be configured the same way.

First we have to configure Azure Active Directory settings

Prerequisites for this requires some configuration in Azure Active Directory. The most secure way to do this is to create a group and only allow that group in the device settings for who is allowed to join and register devices in Azure AD

For a less secure method, reference this article: https://techcommunity.microsoft.com/t5/intune-customer-success/bulk-join-a-windows-device-to-azure-ad-and-microsoft-endpoint/ba-p/2381400

This group can be a Security Group or a Dynamic User Group. Since we are talking about a specific scenario of having an onsite technician enroll these devices with a USB drive, this is the most secure method.

Only the DEM user account needs to be assigned to this group. This DEM account also needs to be the same account used in the Windows Configuration Designer package to “Get Bulk Token”.

Then we configure the Mobility (MDM and MAM) in Azure Active Directory. Add application and select Microsoft Intune.

Reference: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enroll#configure-automatic-mdm-enrollment

Now we configure the Windows configuration Designer package

1. First we use Windows Configuration Designer to create a package to Auto Enroll. The Windows Configuration Designer is a free app that you can download from the Microsoft Store app.

2. The goal might be to rename the Windows Computer name of the MTR and join it to Azure AD using an Intune DEM account.

DEM account needs to be the same account that is a member of the Azure AD group that is associated with the AAD Device Settings/ Azure AD join and registration settings / Automatic Enrollment settings.   

DEM account needs to be of ALL 4 of these AAD Roles.  Cloud App Security Administrator, Intune Administrator, Global Administrator and Password Administrator.  Its does NOT work if you are only a Global Administrator.

Reference: https://techcommunity.microsoft.com/t5/intune-customer-success/bulk-join-a-windows-device-to-azure-ad-and-microsoft-endpoint/ba-p/2381400

DO NOT install applications on to Teams Rooms on Windows devices. These should be treated like appliances. They are not like normal Windows PCs that you would install normal software on like Antivirus and Group Policies. Installing additional applications on MTRoW devices will lead to issues and opening support cases. Instead, it is recommended to secure these devices using Intune and Conditional Access.

Certificates on these devices are not required. However, you may want/need to add a certificate if you are using a network access control solution (NAC) in your environment.

The package that gets created looks like this. It will be put in your Documents folder. You then need to copy these files to a USB flash drive, directly at the root, not in a folder.

3. Now that you have your package created and copies to your USB flash drive, you would give this flash drive to the installer technician that will be onsite with the MTR device.

Instructions for the Technician or AV installer onsite.

1. After connecting the compute box, touch console and display together, power on the device. Then insert the USB drive into the compute (usually a NUC or ThinkCenter)

2. Login to the MTR with the local Administrator account. Default password: sfb.

For this process, you can reference: https://techcommunity.microsoft.com/t5/intune-customer-success/enrolling-microsoft-teams-rooms-on-windows-devices-with/ba-p/3246986

To assign a Windows configuration Designer package, open Windows Settings as an Administrator. From the Windows Start menu, select Settings and then sign in with a local Administrator account (if you are not already signed is as a local Admin).

In Settings, select Accounts > Access work and school > Add or remove a provisioning package.

In the Provisioning packages dialog, select Add a package.

Then select and add the package we created earlier from the USB drive.

Using these articles, I was able to configure Auto Enrollment in my lab with my MTRw.   Tested successfully having the Windows Configuration Designer package rename the PC and join it to Azure AD using the DEM account.   

https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enroll#configure-automatic-mdm-enrollment

https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-apply-package

https://learn.microsoft.com/en-us/windows/iot-core/manage-your-device/intunedeviceenrollment

https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-bulk-enroll

How to use custom Extension Attributes on Teams Devices

Published July 17, 2023

This article applies to Teams Phones, Teams Rooms on Android, Teams Displays and Teams Panels. (Android devices only)

What is a custom Extension Attribute? It is similar to the custom attributes you will find in Exchange, but those cant be applied to device objects.

Custom Extension Attributes on Device objects show up when you are viewing the device object in the Azure Active Directory portal

Why would you want to use a custom Extension Attribute on your Device objects? If you don’t want to enroll your devices in Intune but you still need a way to exclude your Teams Device objects from Conditional Access policies, this is the best way.

Prerequisites: You will need to install the Graph Powershell Module Install the Microsoft Graph PowerShell SDK | Microsoft Learn. Be sure to run this with a Global Administrator account.

To create a custom Extension Attribute for your Teams devices and apply it to all of your Android device objects, you can use this PowerShell script:

Import-Module Microsoft.Graph.Identity.DirectoryManagement
Select-MgProfile -Name "beta"
Connect-mgGraph -Scopes Device.Read.All, Directory.ReadWrite.All, Directory.AccessAsUser.All

$AzureADRegisteredDevices = Get-MgDevice | Where-Object {$_.TrustType -eq "Workplace"}

ForEach ($device in $AzureADRegisteredDevices) {

$uri = $null
$uri = "https://graph.microsoft.com/beta/devices/" + $device.id

$json = @{
      "extensionAttributes" = @{
      "extensionAttribute1" = "Teams Corporate Devices"
         }
  } | ConvertTo-Json
  
Invoke-MgGraphRequest -Uri $uri -Body $json -Method PATCH -ContentType "application/json"
}

NOTE: This script will affect all Android device objects in your tenant, including mobile phone device objects.

This script is looking for any devices that used the WorkPlace Join method of joining Azure AD. Windows devices do not use this method.

If you didnt want to affect all Android devices, you could be a little more custom and only stamp this extension attribute onto devices with specific Display names. When a Teams Android device starts the Workplace Join process, it creates the device object with a Display name of ‘ManufacturerModelNumber’. Example: YealinkMP56

Using this method means this script has to be run seconds after you start signing into these Teams Android devices, otherwise the display name will change and no longer look like YealinkMP56. You have about 5-15 seconds before the display name gets automatically changed when the WorkPlace Join provisioning process is complete and then this script would not work. While this is a safer way to go by ensuring you are only affecting the Teams device objects, it is a little trickier because of the time constraint.

The script would look like this:

Import-Module Microsoft.Graph.Identity.DirectoryManagement
Select-MgProfile -Name "beta"
Connect-mgGraph -Scopes Device.Read.All, Directory.ReadWrite.All, Directory.AccessAsUser.All

$AzureADRegisteredDevices = Get-MgDevice | Where-Object {$_.DisplayName -eq "YealinkMP56"}

ForEach ($device in $AzureADRegisteredDevices) {

$uri = $null
$uri = "https://graph.microsoft.com/beta/devices/" + $device.id

$json = @{
      "extensionAttributes" = @{
      "extensionAttribute1" = "Teams Corporate Devices"
         }
  } | ConvertTo-Json
  
Invoke-MgGraphRequest -Uri $uri -Body $json -Method PATCH -ContentType "application/json"
}

To view your Extension Attribute, you would to to https://portal.azure.com/, Azure Active Directory, Devices, All Devices. Then search for one of your Teams Android devices.

Once you have the extension attribute applied to the device objects, then you can filter these objects in Conditional Access and exclude them from the policies that are harmful to the Teams Android devices. If you did have the devices registered in Intune, then you could use the Manufacturer or Model number attributes to filter on. This may work better in some cases.

Example: Conditional Access Device Filter

Credit goes to Daniel Bradley for helping me to figure this out. If you want to put Extension Attributes on your Windows devices, use his article here: https://ourcloudnetwork.com/configure-device-extension-attributes-in-azure-ad-with-powershell/

USE AT YOUR OWN RISK. You expressly agree that use of this script is at your own and sole risk. You understand that I cannot and do not guarantee or warrant that the script will not interfere with other code that may manifest contaminating or destructive properties. I do not assume any responsibility or risk for use of the script. You understand and agree that downloading or copying any materials through this Site is done at your own discretion and risk, and that you will be solely responsible for any damage to your Azure tenant or loss of data that results from your activity.

Teams Phones not failing over to use local SBA when Internet Connection is lost

Published by: Traci Herr Date 5/15/2023

When you are implementing a Microsoft Teams Survivable Branch Appliance (SBA) you may run into issues with having the phones failover to use the local telco egress. Reading the Teams Device logs will help you narrow down the issue. You should gather these logs from Teams Admin Center using this process. https://learn.microsoft.com/en-us/microsoftteams/troubleshoot/teams-rooms-and-devices/collect-device-logs

First you need to open the correct log inside the log bundle that you get from Teams Admin Center.

What log do you look in?

• If it’s an AudioCodes phone, go to the AdminAgent.zip and open the logcat.log file
• If it’s a Poly phone, go to the AdminAgentLogs.zip and open the app_XXXXXXXXXXX.log
• If it’s a Yealink phone, go to the AdminAgentLogs.zip, Open the MPXX-SERIALNUMBER-Syslog.zip, open the Datalog folder, open SERIALNUMBER.log

When reviewing the device logs, look for these highlighted words:

EXAMPLE of a successful failover and failback with Internet connection is lost:

• 2022-08-03 04:27:17.076 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Current app state: online, details: isNetworkAvailable=true, trouterStatus=connectedToCloud, isNetworkAvailableWhenPostActive=true
• 2022-08-03 04:27:38.333 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Current app state: online, details: isNetworkAvailable=true, trouterStatus=connectedToCloud, isNetworkAvailableWhenPostActive=true
• 2022-08-03 04:29:38.753 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Current app state: online, details: isNetworkAvailable=true, trouterStatus=connectedToCloud, isNetworkAvailableWhenPostActive=true
• 2022-08-03 04:30:54.148 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Current app state: offline, details: isNetworkAvailable=true, trouterStatus=disconnectedFromCloud, isNetworkAvailableWhenPostActive=true
• 2022-08-03 04:30:54.150 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Try to request account config change, switchToApplianceMode=true
• 2022-08-03 04:30:54.152 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Found a random online appliance candidate: sbc-sba1.onpremdomain.com
• 2022-08-03 04:31:14.994 4386-314/? I/SurvivabilityService: ProcessId: 4386, Thread: pool-2-thread-50, appliance reached successfully
• 2022-08-03 04:31:14.995 4386-314/? I/SurvivabilityService: ProcessId: 4386, Thread: pool-2-thread-50, Account config change requested
• 2022-08-03 04:31:15.824 4386-4885/? I/TeamsUserAvatarProvider: ProcessId: 4386, Thread: SurvivabilityThread, updatePresence: update presence to Offline success
• 2022-08-03 04:33:09.025 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Current app state: offline, details: isNetworkAvailable=true, trouterStatus=connectedToSBA, isNetworkAvailableWhenPostActive=false
• 2022-08-03 04:35:59.264 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Current app state: online, details: isNetworkAvailable=true, trouterStatus=connectedToSBA, isNetworkAvailableWhenPostActive=true
• 2022-08-03 04:35:59.266 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Try to request account config change, switchToApplianceMode=false
• 2022-08-03 04:35:59.268 4386-4885/? I/SurvivabilityService: ProcessId: 4386, Thread: SurvivabilityThread, Account config change requested

NOTE: Presence will be offline when a device or client has failed over to use the SBA for outbound calls.  This is normal and expected behavior.

EXAMPLE: Thread: SurvivabilityThread, updatePresence: update presence to Offline success

EXAMPLE: Error phone cannot failover to use SBA:

• 08-03 05:30:27.630  2032  2105 I SurvivabilityService: ProcessId: 2032, Thread: SurvivabilityThread, Current app state: offline, details: isNetworkAvailable=true, isNetworkValidated=true, trouterStatus=disconnectedFromCloud, isNetworkAvailableWhenPostActive=true
• 08-03 05:30:27.631  2032  2105 I SurvivabilityService: ProcessId: 2032, Thread: SurvivabilityThread, Try to request account config change, switchToApplianceMode=true
• 08-03 05:30:27.631  2032  2105 E SurvivabilityService: ProcessId: 2032, Thread: SurvivabilityThread, No online appliance available
• 08-03 05:30:27.632  2032  2105 E SurvivabilityService: ProcessId: 2032, Thread: SurvivabilityThread, Cannot switch to appliance mode, could not find appliance candidate

This indicates that no DNS name for the SBA was found, so you should check the policy applied to the user account and the SBA configuration in the cloud via powershell.

Get-CsTeamsSurvivableBranchAppliance

Get-CsTeamsSurvivableBranchAppliancePolicy

Get-CsOnlineUser -Identity username@domain.com |  Select-Object TeamsSurvivableBranchAppliancePolicy

If the SurvivableBranchAppliance is not configured or the policy is not configured or the policy is not assigned to the user, this can be the cause of what you see in the logs above.

EXAMPLE: Error phone cannot failover to use SBA:

• Apr 26 08:01:37 GUI [1093:1156]: ANDR<6+info  > 1992  2579 I SurvivabilityService: ProcessId: 1992, Thread: SurvivabilityThread, Current app state: offline, details: isNetworkAvailable=true, trouterStatus=unknown, isNetworkAvailableWhenPostActive=false
• Apr 26 08:01:37 GUI [1093:1156]: ANDR<6+info  > 1992  2579 I SurvivabilityService: ProcessId: 1992, Thread: SurvivabilityThread, Try to request account config change, switchToApplianceMode=true
• Apr 26 08:01:37 GUI [1093:1156]: ANDR<6+info  > 1992  2579 I SurvivabilityService: ProcessId: 1992, Thread: SurvivabilityThread, No online appliance available, return a random appliance: sbc-sba1.onpremdomain.com
• Apr 26 13:20:43 GUI [1093:1156]: ANDR<3+error > 1992  8189 E SurvivabilityService: ProcessId: 1992, Thread: Pool-NetworkPool-Thread-90, Cannot switch to appliance mode, ping appliance candidate failed
• Apr 26 13:20:43 GUI [1093:1156]: ANDR<3+error > 1992  8189 E CheckApplianceLiveness: ProcessId: 1992, Thread: Pool-NetworkPool-Thread-90, javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

This indicates that the SurvivableBranchAppliance policy in the cloud is configured correctly because the phone found the SBA DNS name.   This also indicates the phone can not PING the SBA and thinks it is offline.   Likely due to a bad test scenario.   When a you stop internet access to the phone, the phone still needs to continue to to have access to the local internal network so it can get to the onprem local SBA server and possibly the local SIP Gateway, Analog Gateway or PRI gateway.

This also indicates there is a certificate issue.  There is an issue with case sensitivity between the DNS FQDN name in the cloud, check Get-CsTeamsSurvivableBranchAppliance, and the DNS FQDN name on the certificate that is installed on the SBA. 

Checking Intune Compliance Policies for unsupported settings

Contributors:  David Paulino and Traci Herr Last Updated: 10/3/2023

This cmdlet does a check on each one of the Conditional Access policies in a tenant.   It is checking for unsupported settings for the Teams Android devices.

Azure AD permissions that are required to run this script: Global Administrator or Intune Service Administrator

The unsupported settings are referred to in this article https://docs.microsoft.com/en-us/microsoftteams/rooms/supported-ca-and-compliance-policies?tabs=phones

For Commercial Tenants: The way you run this PowerShell script is by using these commands:

Install-Module -Name UcLobbyTeams
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All","Directory.Read.All" 
Test-UcTeamsDevicesCompliancePolicy -detailed -ExportCSV

If you run the script out the | ft, it will give you all the information in the Comment section.

For GCC-H Tenants: The way you run this PowerShell script is by using these commands:

Install-Module -Name UcLobbyTeams
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All","Directory.Read.All" -Environment USGov
Test-UcTeamsDevicesCompliancePolicy -detailed -ExportCSV

If you see unsupported settings for any policy that is associated with the Android Device Administrator platform and is assigned to the user account signing into the phone, add a Device Filter and associate it to their Compliance Policy.

You must create the Compliance Policy Filter here, before you can apply the filter to the Compliance Policy.

For more information and the script for checking Conditional Access policies go here:

How to Check Conditional Access Policies and Compliance policy unsupported settings for the Teams Android Devices

How to Check Conditional Access Policies and Compliance policy unsupported settings for the Teams Android Devices

Contributors: Traci Herr, David Paulino and Gregory Brunn Last Updated: 10/23/2023

This cmdlet does a check on each one of the Conditional Access policies in a tenant. It is checking for unsupported settings for the Teams Android devices.

The unsupported settings are referred to in this article
https://docs.microsoft.com/en-us/microsoftteams/rooms/supported-ca-and-compliance-policies?tabs=phones 

Azure AD permissions that are required to run this script: Global Administrator or Conditional Access Administrator

For Commercial Tenants: The way you run this PowerShell script is by using these commands:

Install-Module -Name UcLobbyTeams
Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"
Test-UcTeamsDevicesConditionalAccessPolicy -detailed -ExportCSV -All

(If you run the script without the | ft, it will give you all the information in the Comment section.)

For GCC-H Tenants: The way you run this PowerShell script is by using these commands:

Connect-MicrosoftTeams -TeamsEnvironmentName TeamsGCCH
Install-Module -Name UcLobbyTeams
Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All" -Environment USGov
Test-UcTeamsDevicesConditionalAccessPolicy -detailed -ExportCSV -All

• If you see unsupported settings under TeamsDevicesStatus, then check for a Device Filters.
• Device Filters will make the CA configuration supported, when they have unsupported settings.
• Without Device Filters configured on these types of policies, we cannot troubleshoot customer sign-in or signout issues.

Here is an example of a Device Filter to exclude the Teams phones. Advise customers to use the following Operators with Model and Manufacturer: In, StartsWith, Contains. Using Equals may cause intermittent issues with this kind of filter.

Another brand new way to for issues is using the new Teams Android Desk Phone Diagnostic in the Microsoft Remove Connectivity Analyzer

https://techcommunity.microsoft.com/t5/microsoft-teams-support/new-diagnostic-teams-android-desk-phone-diagnostic-now-available/ba-p/3957808

Please up vote this request for the Azure team to make Device Filters easier for the Teams devices. https://feedback.azure.com/d365community/idea/c0679f3e-e0e9-ed11-a81c-000d3a7a16ce

Checking Intune Compliance Policies for unsupported settings

TM434639 Common Area Phone license cannot be used with Microsoft Teams Rooms devices

Message Center Post – September 2022

TM434639: Microsoft Teams Service Health Notification

User Impact: If action isn’t taken, Microsoft Teams rooms devices using Common Area Phone licenses will lose access to the service.

We discovered through our audit and license enforcement that your organization may be using a Common Area Phone license with Teams Rooms application version 4.14.24.0, which is incompatible. Please follow the steps provided in Recommendations to bypass impact.

Recommendations: In order to avoid disruption of experience and service, a valid Teams Rooms license must be assigned to the device resource account.  https://aka.ms/room-license

TM447858 Common Area Phone license cannot be used with Microsoft Teams Rooms devices

Message Center Post – October 19, 2022

User Impact: If action isn’t taken, Microsoft Teams rooms devices using Common Area Phone licenses will lose access to the service. We discovered through our audit and license enforcement that your organization may be using a Common Area Phone license with Teams Rooms application version 4.14.24.0, which is incompatible. Please follow the steps provided in Recommendations to bypass impact. This communication will expire in 30 days.

Docs link: https://learn.microsoft.com/en-us/microsoftteams/rooms/rooms-licensing

Teams Devices Learning Videos

Published by: Traci Herr 10/12/2022, updated 4/4/2024

These videos are for anyone who is responsible for consulting, designing, deploying and installing solutions for Teams Android Devices (Phones, Panels, Displays and Teams Rooms on Android.

Teams devices for IT Pros 1: Intune Compliance & Conditional Access with Teams Rooms on Android

Teams devices for IT Pros 2: Intune Compliance & Conditional Access with Teams Android devices

MTR Technical Bootcamp Training – May 10. 2023

Teams Phone Summing – Using Intune when deploying Teams Phone Devices March 6, 2024

Micro-learning Troubleshooting videos (5 minutes each) Topics relate to troubleshooting Teams Android Devices when Conditional Access, AAD and Intune are causing problems with the devices.

Your favorite troubleshooting gameshow “Can You Stump Herr?”

Teams devices for IT Pros 3: Can You Stump Herr? Episode 1

Teams devices for IT Pros 4: Can You Stump Herr? Episode 2

Teams devices for IT Pros 5: Can You Stump Herr? Episode 3

Teams devices for IT Pros 6: Can you Stump Herr? Episode 4

Protect your Teams devices from Conditional Access

Published August 22, 2022, Last updated 5/3/2023

This article is related to all Teams android devices i.e. Phones, Meeting Rooms (MTR), Panels and Displays.

It is necessary and required to configure Intune and Conditional Access in a supported way for the Teams devices. The most common issues are not being able to sign in, randomly signing out, freezing/crashing and sign-in loops. The random sign out issue is mostly caused by Conditional Access marking device objects as non-compliant, however the Intune Compliance policies can also mark the device objects as non-compliant.   When the device object is marked as non-compliant, our Azure AD token issuing service stops renewing the tokens for the device object and in some cases revokes the token.  Thus making the phone sign out because it can’t get an updated authentication token.   So the goal is to protect your device objects from being marked as non-compliant.  

This is a very common issue with all Teams device customers.  These unsupported settings for the Teams devices, have likely been preconfigured to affect mobile phones or laptops, in Conditional Access policies.  Any or all of those unsupported settings will cause the device object to be marked as non-compliant.    

Check your device object to see if its being marked as not compliant in AAD and Intune.

There is another settings in Conditional Access that is supported but will cause the same bad behavior and that is a Session control for “Sign-in Frequency”.  This will force periodic reauthentication which makes the phones sign out randomly depending on how many of your CA policies have different sign-in frequencies set.   The sign-in frequency specifically causes the token to be revoked which will make a new device object get created under the user account every time they sign in. This can be problematic because it could cause you to hit the Azure AD device limit or Intune device limit which will prevent the user from being able to sign-in to the phone.

The Terms of Use feature in Conditional Access is another one of those….its supported but it causes problems with the Teams devices. 

The fix for all of the issues caused by the Conditional Access settings, is to create a Device Filter on each policy to exclude the devices using filter.   Here is an example of what the filter should look like.   This will exclude only your device objects from being marked as non-compliant or from forced reauthentication.   It does not exclude the user accounts.  All settings will still apply to the user as they sign-in.   Currently this is the only way we have to protect the device objects so they can continue to receive the necessary authentication tokens.

Use DisplayName and Manufacturer or Model. Operators that work best: Contains, Starts With, In

NOTE: If you have not successfully enrolled your Teams devices in Intune, the device filters will not work. This is also true for the Azure AD Dynamic Device groups. You need to have the devices enrolled because Intune is responsible for taking the manufacturer and model attributes and making them available to Azure AD.

As a Teams Administrator you may not have access or permission to view and change things in Conditional Access and Intune. When talking to individuals that manage those platforms you can share the articles below with them. Since you cant sign-in to anything with a device object, excluding them it doesn’t provide any additional access.   It is more risky to have these phones signed out and then have an emergency where you would not be able to dial 911 from these phones because they are signed out.    These device filters are required to fix this issue and many other issues with these Teams devices.

Please review this first article while looking at each and every one of the settings in all of your Conditional Access policies and Intune Compliance Policies. 

https://docs.microsoft.com/en-us/microsoftteams/rooms/supported-ca-and-compliance-policies?tabs=phones

https://docs.microsoft.com/en-us/mem/intune/apps/app-protection-policy#microsoft-teams-android-devices

https://docs.microsoft.com/en-us/microsoftteams/rooms/conditional-access-and-compliance-for-devices

https://docs.microsoft.com/en-us/MicrosoftTeams/devices/authentication-best-practices-for-android-devices#using-filters-for-devices

https://docs.microsoft.com/en-us/microsoftteams/troubleshoot/teams-rooms-and-devices/rooms-known-issues#teams-phone-devices

How can you prove that Conditional Access is the cause of your Teams devices signing out or being marked as not compliant? Go to the Azure AD Sign-in logs. Filter for Status: Failure and Application: contains Teams. Look at the User sign-ins (non-interactive) tab.

Look for failures with the Application type: Microsoft Teams, Microsoft Teams Service or Microsoft Teams – Device Admin Agent

530002 is caused by the Conditional Access Session Control “Sign-in frequency” setting. In this case the device objects were compliant but the details of the error message make it look like its a compliance issue. As stated above, this setting causes the authentication token to be revoked which forces the sign out.

Select the Conditional Access tab to see which policy caused the failure.

Click on the policy showing Result: Failure. In this screen shot, you can see that the device objects was affected but the user object was not.

Here is a video to show you how to properly configure your Intune and Conditional access environment for the Teams Devices.

Advanced Calling for Common Area Phones

Date published: 8/11/2022

The following calling features are available for supported Teams phone device models enabled with a Common Area Phone license and the latest Teams App update (minimum version – 1449/1.0.94.2022061702):

• Call park and retrieve
• Cloud-based voicemail through Exchange Online Plan 2
• Call queues
• Auto attendants
• Group call pickup
• Forwarding rules

To use the calling features on supported Teams phone device models, you need to enable the “Advanced Calling” setting in the Teams admin center or on your Teams phone device and sign in through your Common Area Phone account. Learn more about how to disable cloud-based voicemail from your devices. To access advanced capabilities, ensure that you purchase the right hardware models.

Common Area licensed phones are only permitted to use the Common Area Phone interface (signin mode).  Overriding this using the Set-CsTeamsIPPhonePolicy is not permitted.  https://docs.microsoft.com/en-us/microsoftteams/devices/teams-android-devices-user-interface#override-automatic-user-interface-detection

Example phone is Poly CCX500:  This shows you the differences in the screens between the User Interface and the CAP interface with Advanced Calling turned on.

Home Screen.   Notice the Calendar button does not show.

Even though you can turn on Bluetooth on the Admin Only menu, there is no option here to “Connect a device” like you would see when using the User interface.   “Set Status Message” does not show on this menu either.

Settings menu (available to users).  Many options have been moved from this menu and put under the Admin Only menu.

Device Settings (even though it says Phone Settings at the top).  (available to users)  Many options have been moved from this menu and put under the Admin Only menu.

Available only to Admins, you must enter the Admin password to get to this screen.   This is where all options you would see on the other menues got consolidated.

Tap the Calling option from the Admin Only menu.

More shown at the bottom.

From Home screen tap the “Calls” button and it brings you here.   We have Favorites and Recent.  We also have the phone with a P icon in the upper right corner to pickup a parked call.

Favorites tab

Recent tab

Voicemail button:  You can play or read your voicemail from here.

People button

More options

Walkie Talkie

You have the Common Area Phone license, which dictates that you are using the Common Area Phone Signin mode.  The signin mode makes the phone show up under the Common area phone tab in Teams Admin Center.

The Configuration profile with Advanced Calling turned on, must be assigned from Teams Admin Center, to the phone for the Advanced Calling features to show up on the device.

Use Case Scenarios:

1. Security Guard booth where many security guards work and do not have their own phones.  They would have a shared phone line and shared voice mailbox for security.  Any security guard would be able to check voicemail for that line.
2. Warehouse workers usually don’t have their own phone lines or desks, so they use shared phone lines and shared voicemail boxes.
3. Schools can use CAP phones with Advanced Features to use the Walkie Talkie feature.  Having a phone in each classroom would allow them to use the Walkie Talkie feature to make their morning announcements.  This could replace overhead paging systems.

Opposite Use Cases: You likely do not want any of these Advanced Calling features for these scenarios.

1. Phone that is sitting in the main lobby of a building
2. Phone in a kitchen
3. Phone in a hall way.