Enrolling Microsoft Teams phones and Microsoft Teams Rooms on Android in Microsoft Intune (2024)

By Jacob Scott | Support Escalation Engineer - Microsoft Intune

This is the second post of our two-part series that walks you through setting up and enrolling your Microsoft Teams phones and Teams Rooms on Android in Microsoft Intune.

What features are supported?

Below is a breakdown of feature areas that can be applied to these devices with a quick recap of how it works and known limitations.

Enrollment:

• When you sign-in to these devices, and the user is licensed for Intune, the device will attempt Intune enrollment.
• Conversely, when you sign-out of these devices, that triggers the device to un-enroll (retire) from Intune.
• These devices are enrolled to Intune using only.
  • These devices do not have Google Mobile Services (GMS).
  • Android device administrator enrollments are considered personal by default.
  • Corporate identifiers can be added to indicate devices as corporate during enrollment if the device is Android 9 or lower.
• Enrollment restrictions will apply to the user account that is attempting sign-in.

Conditional Access

• Not all Conditional Access settings are supported, this document lists what is supported today.
• Conditional Access will apply to the sign-in (if configured).
• When new Conditional Access policies are turned on, they will take effect on the device the next time it authenticates with Azure.

Device Configuration

• The Teams Admin Center provides the ability to set a few device configurations.
• Teams Admin Center configurations will override Intune policy.

Intune device configuration profile information

• Device restrictions
• The only supported setting for these devices is 'block camera' assuming the device has an Android version below Android 10.
• All other settings are unsupported (including all password settings).
• Custom settings
• These are supported for delivery of the profile to the device only. Microsoft will not provide support if the contents of the profile do not cause the device to respond in the way that is intended.
• Trusted certificate
  • Note: If a trusted certificate profile is assigned, the user may get a prompt from the Company Portal app to install security credentials each time the device checks in to the Intune service. If the user accepts the prompt, the profile may show successful in Intune reports.
• Unsupported due to OS restrictions.
• PKCS certificate
  • Note: If a PKCS certificate profile is assigned, the user may get a prompt from the Company Portal app to install security credentials each time the device checks in to the Intune service. If the user accepts the prompt, a new certificate may be issued to the device. This type of profile will generally always show error status but may show success.
• Unsupported due to OS restrictions and lack of trusted certificate support.
• PKCS imported certificate
• Unsupported. PKCS imported certificates are intended for use with S/MIME encryption, but these devices do not have access to email.
• SCEP certificate
  • Note: If a SCEP certificate profile is assigned, the user may get a prompt from the Company Portal app to install security credentials each time the device checks in to the Intune service. If the user accepts the prompt, a new certificate may be issued to the device. This type of profile will generally always show error status but may show success.
• Unsupported due to OS restrictions and lack of trusted certificate support.
• VPN
• Unsupported due to inability to deploy a VPN client to the device.
• Wi-Fi
  • Note: Deployment of enterprise Wi-Fi profiles may partially function on the device, however due to the dependency on certificates, it may not function as intended.
• Basic type Wi-Fi profiles are supported.
• Enterprise type Wi-Fi profiles are unsupported.

Device Compliance

• Some device compliance policies from Intune are supported while many are not.
• These documents list the currently supported compliance policy settings.
• Phones:Supported device compliance policies for Teams phones.
• MTR-A: Supported device compliance policies for Meeting Teams Rooms.
• If an unsupported setting is deployed to a device, it may never show compliant for that specific setting rendering the device 'not compliant.' This may cause the device to fail to sign-in depending on environmental restrictions (i.e., Conditional Access).

App Management

• App deployment, configuration, and protection are unsupported on these devices.

Device Actions

• Most device actions are supported with these devices.
• However, these actions may not apply immediately due to the lack of GMS.
• The action's success is reliant on the device checking in to the Intune cloud service to get the action.

Environment Setup

If your organization already uses Intune, it's very likely one or more of the below steps have already been completed.

1. MDM Authority in Intune must be set to Microsoft Intune.
2. Enable Android Device Administrator enrollment in Intune.
3. Set existing enrollment restrictions to allow the Android Device Administrator platform and personally owned devices in Intune.
1. Note: Personal devices can be blocked if the corporate identifiers are added to Intune.
2. Corporate identifiers are only supported on Android 9 and earlier.
4. Ensure Conditional Access policies don’t have unsupported settings.
   1. See section "Unsupported Conditional Access Filtering" below for more information.
1. If a user attempts to sign into these devices with an unsupported Conditional Access setting, the sign-in will fail.
2. Either he user needs to be removed from the unsupported Conditional Access policy OR the devices need to be filtered from the unsupported Conditional Access policy.
5. Ensure Intune compliance policies don’t have unsupported settings.
1. Note: Compliance policies are only needed if a Conditional Access policy that has "require device to be marked as compliant" is assigned.
2. If an unsupported setting is assigned to these users/devices, the device may never become compliant, which could lead to Conditional Access blocking the device from being usable.
3. The user/device will either need to be removed from the targeted Conditional Access policy that contains the control "require device to be marked as compliant" OR the assignment(s) will need filters to exclude these devices from the policy.
6. Ensure user has an Intune license assigned and not disabled.

1. This is easily checked using the Intune Troubleshooter.

Unsupported Conditional Access Filtering

• Conditional Access rules can use a couple options to exclude these devices from evaluation on unsupported policies
• Option A)
  • Why this part is needed: Some of the properties that are evaluated in Conditional Access filters are populated at a different rate than others. Device information is propagated back to Azure AD from Intune after Intune enrollment completes and this can take time. The sign-in attempt will likely timeout/fail before the information fully propagates back to Azure AD for usage in the Conditional Access filter.
  • How to resolve: Add a filter to the unsupported Conditional Access policies with property "deviceName" inclusive operator "MakeModel" where MakeModel is the actual make and model of the device.
  • Example: "deviceName" equals "PolyCCX500"
  • Any of the inclusive operators (in, contains, startswith, endswith, equals) are valid options but each have their own drawbacks in how ‘open’ or ‘exact’ they are.
  • Weigh the options carefully with respect to possible extra white spaces appearing in fields (extremely rare, but has happened), introduction of new models into the environment, security, etc.
  • Why this works: When these devices first register with Azure, the display name is “MakeModel". Once the device completes Intune enrollment, Intune updates the Azure AD device's display name to the Intune device’s management name.
  • Note: Android Intune enrollment types do not use the hostname of the device as the device name, but other platforms may. Because of this, it would be recommended to also scope the policy down to apply to Android devices only and make a second policy for the non-Android platforms that do not include this filter.
  • Why this part is needed: Once the device's name gets updated to the Intune management name, the filter in part A will no longer apply, which could lead to devices getting blocked during their next check-in.
  • How to resolve: Add a filter to the unsupported Conditional Access policies for a property that doesn't change once the device is fully enrolled such as "model" inclusive operator "Model" where "Model" is the actual model of the device.
  • Example: "model" equals "ccx500"
  • Any of the inclusive operators (in, contains, startswith, endswith, equals) are valid options but each have their own drawbacks in how ‘open’ or ‘exact’ they are.
  • Weigh the options carefully with respect to possible extra white spaces appearing in fields (extremely rare, but has happened), introduction of new models into the environment, security, etc.
  • Why this works: Once all the model information has been written back to Azure AD, these properties should function as expected.

    Option A: Conditional Access Filter Example.

• Option B)
  • Add named locations as an exclusion to the policy.
    • Both “All trusted locations” and “Selected locations” are valid options.
  • Note: Remember this would exclude any device within scope of the policy that is also at the same named location so make sure to evaluate this scenario meets your goals.

    Option B: Conditional Access Named Locations.

Enrollment flow deep-dive

Now that your environment is set up in a healthy manner, let’s walk through the on-device experience.

Initial screen:

Initial Device Sign-In Screen.

1. Tap the gear icon to access the settings menu. In the settings menu, you can:
   1. Change the cloud to authenticate to (eg. Public, GCC, GCC-High, GCC DoD)*.
      1. Note: The URL that is used for “sign in from another device” may change based on the cloud selected. Make sure to choose the appropriate cloud for sign-in.
      2. *Teams phones are supported in all clouds listed in the UI.
      3. *Teams Rooms on Android are not supported in GCC-High / GCC-DoD clouds as of this writing. Check Teams Rooms on Windows and Android feature comparison for the latest status on supportability.
   2. Provision the device.
   3. Report an issue.
   4. Change device settings.
2. You can sign-in from another device by following the listed steps.
   1. The other device does NOT need to be enrolled into Intune nor joined/registered with Azure nor have the user signed-in to the browser.
3. You can sign-in directly on the device using your credentials.
   1. The first screen is a Teams screen to enter the UPN.
   2. That UPN is passed to the Company Portal where you enter your password.

Post-Credentials sign-in flow:

1. Once the password has been confirmed (from either sign-in on another device, or sign-in locally), Conditional Access targeting “All Cloud Apps” and/or “Microsoft Intune” with MFA requirement is evaluated.
2. Registration to Azure AD is attempted.

   Registering your Device to Azure AD Screen.

   1. MFA targeting “Microsoft Intune Enrollment” is evaluated.
   2. Device record in Azure AD with the name format “MakeModel” of the device is created if successful.
3. Enrollment into Intune is attempted.

   Enrolling Device into Intune Screen.

   1. Tenant wide activation of Android Device Administrator is evaluated.
      1. Is the Android Device Administrator platform enabled tenant-wide?
         1. Yes > Continue to 3b.
         2. No > Enrollment / sign-in fails.
   2. Intune enrollment restrictions are evaluated.
      1. Is the Android Device Administrator platform enabled in the enrollment restriction?
         1. a) Yes > Continue to 3bii.
         2. b) No > Enrollment / sign-in fails.
      2. Corporate identifiers are checked to determine if the device is corporate.
         1. Identifier found in Intune> corporate enrollment attempted.
         2. Identifier not found in Intune > personal enrollment restrictions evaluated (3biii).
      3. Is personal enrollment allowed?
         1. a) Yes > Personal enrollment attempted.
         2. b) No > Enrollment / sign-in fails.
   3. If enrollment is successful, device record in Intune with the name format “UserFirstName_Android_EnrollmentTimeStamp” is created.
   4. That device name is sent to Azure AD to overwrite the initial “MakeModel” device name.
4. Intune enrollment is completed, policy targeting calculation/delivery & compliance evaluation starts.

   Finishing up Intune Enrollment and Initial Policy Application.

   1. Device compliance state will initially report based on the “mark devices with no compliance policy assigned as” compliance policy setting / tenant configuration.
   2. Policy delivery is generally ‘quick’ but not instantaneous.
      1. Static assignment groups are evaluated significantly quicker than dynamic groups.
      2. Dynamic groups may take up to 24 hours to recognize the device. Sign-in might time out and fail before the device gets into the appropriate dynamic group.
      3. Due to this, user targeted policy assignment is recommended.
5. Sign-in to Teams is attempted (via Company Portal passing an SSO token).

   Teams "Verifying a few things..." Screen.

   1. All supported Conditional Access policies targeting “Office 365”, “Microsoft Teams”, “Office 365 SharePoint Online ”, and/or “Office 365 Exchange Online” are evaluated.
      1. It’s possible the device is not “compliant” yet, if that is the case, the user may get stuck on the above “Verifying a few things” screen for a while or get the below screen for “Get access to this resource”. The user can try tapping “Open” on the prompt after 5-10 minutes to re-evaluate the device’s compliance status again.

         "Get access to this resource" Azure AD Conditional Access prompt.

6. If you made it to this screen, congratulations, your environment is setup correctly!

   Device Home Page Post Successful Sign-In.

Still having troubles?

• Manually update your devices to the latest available software versions in the Teams Admin Center.
• The Azure AD Conditional Access What If tool is helpful for making sure there are not unintended Conditional Access policies targeting the user.
• If this is a new deployment and you have made environmental changes, a quick factory reset sometimes helps to clear out anything cached on the local device.
• Check the enrollment flow section to determine where in the process the enrollment / sign-in is failing. The screenshots, device name(s), and locations you find records are incredibly helpful and can help narrow down the problematic area.
  • The Intune Troubleshooting tool can be helpful in determining if the device at least enrolled into Intune, then failed after enrollment likely pointing to a Conditional Access related issue.
• Check the Sign-in logs in Azure Active Directory for clues (both interactive and non-interactive sign-ins).
  • The error “50199- For security reasons, user confirmation is required for this request. Please repeat the request allowing user interaction” has many causes (not an exhaustive list):
    • An unsupported Conditional Access policy being applied to the user.
    • Android Device Administrator enrollment type is not enabled in the tenant.
    • The user has an enrollment restriction blocking Android Device Administrator enrollment.
  • The error “53002- Your device is required to be compliant to access this resource.” Is typically caused by:
    • A supported compliance policy assigned, but not evaluated quick enough for Azure AD to mark the device compliant.
    • An unsupported compliance policy assigned, so the device never becomes compliant.
      • See the Device Compliance section above for more information.
      • Depending on the device’s software version, you may see the error 50199 instead of 53022.
    • Check the Known issues in Teams Rooms and devices document.
    • Open a Microsoft Intune Support request.

If you have any questions, let us know in the comments or reach out to us on Twitter@IntuneSuppTeam.