Jun 15 2021 03:10 AM
Hey community fellows,
I wanted to check if anybody else face the same challenge with Teams Android Devices for personal usage in combination with Intune MDM profile for users. We started to face issue on Teams Android IP phones on latest firmware that our users are not able to sign-in and they are looping on screen with the sign-in code. We found out that it is because of missing Android Device Administrator enrollment method in Intune MDM profile. Once we enable this enrollment method for users the sign-in is possible. Audiocodes stated that within latest release of their phone software 1.10 they followed the requirements of Microsoft to meet requirements especially in area of Intune.
As described here the Android Device Administrator enrollment is used and needed for Teams Devices.
https://docs.microsoft.com/en-us/microsoftteams/devices/phones-displays-deploy I see it as highly conflicting with another recommendation and statement of Microsoft in the article about this enrollment method not to use it.
https://docs.microsoft.com/en-us/mem/intune/enrollment/android-enroll-device-administrator
Anybody else facing same challenge adjusting this policy for users just because of Teams phones? Maybe question to Teams devices product team if there is future strategy to move away from ADA to Android Enterprise? Or is it the choice of IP phone vendors?
Jun 15 2021 06:05 PM
@DaveChomi Yes, this has been a common issue for over a year now. You need to enable device administrator in order to get Teams Desk Phones to sign in at all. It's a huge flaw.
Jun 18 2021 04:10 AM
Oct 25 2021 10:23 AM
Oct 25 2021 01:51 PM
SolutionAfter discussing this topic with Softies I have confirmation that ADA is for now the only way. "For now" is the important part of that statement. So there are already thoughts to change that but currently nothing on roadmap. That means we have to live with ADA still for some time and there is no other way around :(
Feb 17 2022 01:46 AM
Hi @DaveChomi,
Did you allow Android DA in the default enrollment restriction assigned to the "all devices" group so that a normal user can sign in?
I did that but it's still not working. I tried creating a group with DA allowed and assign it to "all users" group but it didn't work either.
Please help! I'm desperate here.
Thanks.
May 21 2022 01:32 AM
Jun 04 2022 09:24 AM
^^ that would be the method. We also did a large "blocked manufacturer" (why can't it be allowed manufacturer?!?!) list in future planning to prevent end users from enrolling their personal android devices as we use MAM in that space.
Jun 07 2022 10:45 AM
@DaveChomi , The customer ended up using a Device group and finagling the ADA and conditional access to get the phones to log in. However, they still get issues with logging in these phones (or keeping them logged in). I hope MS finds a better solution and provides a detailed deployment guide or some sort of template to use for customers who just want to get their Teams phones signed in.
Jun 07 2022 10:48 AM
In our configuration it was advised that we not only needed to bypass CA on the accounts, but also create a device filter on the policies to exclude them. They had no firm reasoning behind it other than "they act strange if you don't filter them out."
Which I can confirm, before we did that I'd have sporadic device accounts just magically sign themselves out.
Jun 07 2022 11:00 AM
Jun 07 2022 09:26 PM
For our environment we are using this as a exclude: device.model -in ["mp56, uc-p10-c, vp59, crestron-touchpanel-1070-t, crestron-touchpanel-770-t"] (in addition to excluding the device acct's)
That was under the guidance of their support engineer that specializes in Teams Android devices in general, she stated without the exclusion they have a habit of acting strange. She stated any CA policy that has either android platform selected, or browser/mobile apps selected in client apps needs to have the devices filtered out. I had been chasing random device account logouts for months and this calmed it down even though it on the surface didn't appear it should have done anything as the accounts already were excluded and we never saw a logged hit on the policies.