Teams Phone device refuse login with 1449/1.0.94.2021033002 firmware and ADFS

[jangliss]

Has anybody been using ADFS with Teams noticed an issue with the last two firmware updates, when performing logins off-network?

I have a customer running Yealink MP56 phones and the latest firmware 122.15.0.36 running Teams App 1449/1.0.94.2021022403 or 1449/1.0.94.2021033002 can no longer login using either the device login code or typing user/pass. The login seems to get stuck in a loop between device registration and preparing the device.

I suspect this is partially to do with the ADFS configuration not using UPN for authentication, but this wasn't an issue prior to 1449/1.0.94.2021022403.

[#2]

Hi All,
We are experiencing the exact same issue described here using Yealink T55A IP phones off network. We have opened a case with our Teams telecom provider. Will update here if we receive any news.

[#3]

This ended up being an issue with a DNS server for my phone, but Microsoft and Yealink did not find it.

[#4]

Hi All,
An update on our side. We are using Intune and when we allowed the device to be enrolled when the user signs in the issue does not happen.
Not sure why but it seems stable.

[#5]

Jeroen, can you give additional details on what you had to do to fix it?
We use ADFS with synced accounts to AAD. When I update a phone to latest version, seems ok at first but if user logs out of that phone, they are unable to log back in. Almost like a log in loop. It prompts user for mfa and it almost looks like it is going to log in but then it goes back to original start page where it displays the login code. This happens on or off internal network. I did create a test@company.onmicrosoft.com and it seems to work fine.
Rolling back to older firmware like 6.0.X on Poly CCX phones, user is able to log in again.

[#6]

Hi _tricks, what I did was allow the IP phone to enroll into Intune. The Yealink T55A we use has Android version 7.1 and can only be enrolled into Intune as "device administrator" which we actually are blocking for personal devices.
So what we did was upload the serial number of the Yealink phone into Intune as a corporate identifier. This will then allow the device to be enrolled.

When we had the device enrolled into Intune we could log out and back in. Using different user accounts and the device kept working. As soon as I removed the device from Intune enrollment and tried the log out / log in it would get into the loop again.
So without Intune enrollment we still need to downgrade the Teams app version and device firmware......

So you could say this is kind of a workaround.

[#7]

I've done a single device test successfully doing what Jeroen described...a Trio C60. Our Android version "floor" is currently excluding the single AudioCodes C450HD test device I have and I've not pushed to have the floor lowered just for the test. Registering the device's serial along in InTune didn't get around our Android version limit.

[#8]

EVERYONE....please reach out to your TAMs, support engineers, whoever you can and push for greater visibility of this issue! We've had a case open for a month now and getting pretty much nowhere. Last week, MS engaged Poly support believing it to be their problem for some reason...as if it's a base firmware issue rather than a problem with the Teams app code itself.

As I understand it, the base firmware is "owned" by the phone manufacturers. Of course every manufacturers firmware is different. Our Poly phones run Android 9. I know the AudioCodes C450HD runs Android 7. It seems pretty obvious to me that the common thread between Poly, AudioCodes, and Yealink phones is the Teams app code itself, not the base firmware.

Keep in mind that we (the customer) haven't been given control to disable automatic firmware upgrades from Teams Admin Center. The best we can do is defer 90 days. Even if you back-level the code, the phone is going to get the upgrade forced back down to it by Microsoft. And if you miss one setting the 90 day deferral, that 30 days is going to be hitting you very soon.

[#9]

Hi, did you find a fix for this? we have the same issue.

[#10]

@jonasb120Unfortunately still dealing with support and "can we get more logs" phase. Having absolutely no luck so far. I would absolutely encourage you to open a case though, if you haven't already.

[#11]

Hi guys,

We've faced the same issue with T55/T56/MP56/CP960 Yealink Phones.
And I'm pretty sure that it's related to the 1449/1.0.94.2021022403
The simpliest test with them >> upgrade Firmware to the latest one to get 1449/1.0.94.2021022403 on it and then downgrade FW to previous version.
Teams Version will remain the same after downgrade until you make factory reset.
So even with downgraded FW it causes the same issue.
Once you roll back to previous Teams Version by factory reset >> it will work ok.

DIdn't yet test CCX phones with the latest Teams Version but suspect the same issue

[#12]

We have done the same procedure as described by Ruslan_Bakharev and came to the same conclusion. As soon as you upgrade the Teams app to 1449/1.0.94.2021022403 or 1449/1.0.94.2021033002 the logon loop issue occurs.
We have created a ticket with Microsoft and gave them all the usual stuff, logs, software version and even a video of the re-created issue. No useful reaction from MS yet.

Additional test:

-Using a cloud only account the issue does not occur. (So it seems linked to hybrid setup)

-Using a hybrid account and enroll the device into Intune, the issue does not occur. (Not clear why)

[#13]

@Jeroen Dijkman I have too raised with MSFT. thanks for the info. i'll keep this thread updated if i get anywhere with this.

[#14]

Well I've faced same issue with Intune managed device.
So for me both test phone account (without conditional access) and my personal one with Intune provisioned looked quite similar.
Overall I've noted in my env 3 different scenarios:
1) Device freezes during connection/registration stage
2) Device drops you to the main screen after some period of time during registration stage
3) Device drops you to the main screen after you provision it with account. It works just for couple of minutes and then nothing.
At the same time looking into Azure logs you don't see any blockage.
And even strange in case of scenario 3 Azure removes device completely from AAD which is quite strange.

I've opened a ticket with MS just recently as well providing logs and video showing the issue :)
Hope it will help at least to investigate it faster.
Same like BrandonJ365 I had to defer the phones auto update by 90 days in order to avoid impact on sites.

[#15]

So I received feedback from Microsoft. They actually told me to solve the issue you have to allow the IP phone to be enrolled into Intune! Which for me is crazy. The Yealink IP phones we are using still have the Android Device Administrator as management option. Something we do not want to use.
I have asked to Microsoft if they consider the Intune enrollment as a workaround. Because for me this is not the root cause of the issue.
I also asked "What if we do not use Intune?". What solution do they have then.
So I am awaiting their answer.

To be continued.....

[#16]

Hi Jeroen,

From my personal experience communicating with support regarding Teams Phone devices is that they don't understand how to properly support Teams Phones.
Recently I've got reply that I need to contact phone vendor for investigation regarding this issue :)
And it's frustrating.

Android Device Administrator was never properly adopted by Intune for Teams Phone devices that's why there are recommendations to disable multiple inspections for Teams Phones.
(typical example was Trio 8500/8800 which was never properly working with Intune).

Intune enrollment is completely not acceptable scenario in example for Common Area Phones which are running with Common Area Phone license (it has no Intune license in it).
My personal opinion that Teams Phones should not be rolled to Intune until Intune will properly recognize and process such devices.
Not like it's done right now.

I'm happy at least that CAP phones are not in Intune and we're trying to do the same for Conference Phones.
Unfortunately it's not possible for end-users because of Conditional Access.

[#17]

All of this really points to a lack of maturity in the native Teams phone space. At least as full experience user phones, all of the makes and models we've tested have been terribly slow/laggy in the user interface department. Attempting to manage software updates on them from Teams Admin Center has been frustrating....even ignoring this current issue. We ultimately decided to stay on 3PIP phones for all except conference rooms where there is truly an actual user experience benefit in a Teams native phone....the ability to one touch join a meeting. This at least keeps our pain level to a few hundred phones rather than a few thousand. Plus the user interface on the phones is much snappier when limited to a specific purpose (conference room or common area phone) using the IP Phone Policy.

[#18]

Totally agree. Current approach with Teams Phones is totally disappointing.
There are a lot things to count in mind for using this phones.
Intune, Teams Admin centre lagging and bugging. Without automated config applying based on subnet etc.
In example when we were targeting to implement Teams Phones we thought that we will not need provisioning server.
Now I'm thinking that it's the only alternative to make everything work properly at least from the settings perspective.
But mostly problems are because of this bugs, firmware modifications without proper testing etc.

Agree, CAP IPPhone policy is very limited.
Almost year ago I've asked if there will be speed dials for it because it will satisfy our needs but still nothing happens.
So CAP ipphone policy we use only in specific cases. Mostly we leave it with normal user interface. Yes even with non-working voicemail functionality (because of CAP license).
Conference phones we're trying to move out from Intune as well because I had a lot of issues with Trio 8500/8800 with Intune.
And all this thing is very hard to automate because Intune provisioning and especially intune issues troubleshooting takes much time.
For 3PIP phones it's also another story :) VVX phones with it are also not dat stable :)

[#19]

Hi All,
I received another update from MS Support. Basically the "politely" told me that enrolling the IP phone into Intune using the Android Device Admin is the solution the offer.
I told them again I do not agree with this and they are going to check one more time with the back end team. But I have very little hope another solution will be offered.

I have been working with MS solutions for over 20 years and this brings me back to the early days when they always forced their way of working on the customer. I have seen this behavior change since the CEO change some years ago, so I am pretty disappointed.

To any of the Microsoft Techs monitoring this thread, this is a shout out to assist if you can...

regard, Jeroen Dijkman

[#20]

Well I've officially received the same BS answer claiming that this change was intentional to "correct this issue" of Teams allowing phones to login that hadn't been InTune enrolled. They claim one solution is to remove InTune licensing if we don't want to InTune enroll. I have a test Common Area Phone account which does not have InTune licensing and it STILL can't login to Teams on this new code. They are obviously floundering here and have no clue. IF this was all intentional to resolve a known issue, why did it take them 2 months to figure that out and respond????

I'm inclined to believe that the only reason we are being given this answer is because you (Jeroen) discovered that InTune enrollment works around the issue. I'd bet had you never discovered that, Microsoft would still be scratching their heads trying to figure out what's going on.

[#21]

Intune enrollment works only for Jeroen :D
For me even Intune managed device is stucking in provisioning.

I honestly don't understand this support approach.
They waste tons of time instead of escalating it to developers.

Just interesting if Ilya Bukshteyn is aware about this situation