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

Thanks for taking this up. I have voted.

This solution was already put in this thread by me. The point here is that using Intune is a workaround for the root issue. The logon loop when not using Intune is the real issue here. In fact when we started with the IP phones in 2020 there was no need to use Intune to connect the IP phones to the Teams Admin Center.
It was after an update of the Teams app that this issue started happening. I have been in a ticket about this issue with Microsoft since May of this year and there statements about the solution have changed a couple of times.
To me Microsoft does not want to admit they caused the issue in the first place. Our company want to manage the IP phones just like we manage other Teams Devices by just connecting them to the Teams Admin center. And not Intune, because that does not give an added value.

By they way this issue does not occur if you use AAD user accounts for the IP phones....
My ticket with Microsoft will remain open until the fix it.

Same for us. I still have an open ticket with MS and they keep asking me to reproduce the issue and send logs. But no confirmation the issue is on their Teams client. So it is good that finally someone within MS is acknowledging this.

For the User devices we do use the Intune enrollment with Device Administrator which prevents (at least for us) the logon loop issue. We have not seen any issues on the phones coming from Intune management so don't really understand what happened in your case.

For CAP's we are using AAD accounts bypassing the ADFS authentication and the need to add an Intune license. This works well for us. (So far)

But it is interesting to see if the new Teams client for Yealink devices will remediate the need to enroll devices into Intune. Because I agree that for the IP phones their is no real added value to have them enrolled. The TAC management is fine for us.

Very interesting. I've been "screaming" about logout issues for a long time now and have yet to be given any indication that anyone else has had those issues, any code fixes, or anything! I have been told that we aren't the only ones with the new InTune enrolled devices NOT checking in daily like they should. I tend to believe this is related to the logout issues but can't say for sure.

If you have some time to wait, I'd strongly suggest you consider waiting. This space is FAR from mature at this point. Aside from just a few personal and common area phones, we're only deploying Teams conference room phones right now and even ignoring this whole CA/InTune mess, it's still an ongoing rocky road.

We've had numerous issues along the way and continue to. Perhaps the worst issue of all at this point is the phones logging out for whatever reason and not logging themselves back in. I can't say for sure if the issue of logging out is on our end or Microsoft's but it was never an issue on Skype conference room phones. When (not if) something happens that causes the phones to log out, rather than logging themselves back in, they sit at a login screen. We've had several cases where a user will then walk in to a conference room, see the login screen, and log it in as their own personal phone in order to conduct a meeting. Then it will stay that way and be completely useless as a conference phone for anyone else until an administrator can go and log the phone back out and log it back in with the proper conference room account. And it's not that the phone "forgot" the conference room credentials when it logged out. If you catch it before a user does and simply reboot the phone, it will usually log itself back in to it's proper account. The catch is, you have no way of ever knowing, without visual inspection, that the phone has even logged itself out. According to Teams admin center, the phone is logged in despite visually seeing the login screen on the phone itself.

We've also seen situations where phones never show up in Teams admin center despite being fully functional and we even have at least one or two right now that show "offline" in Teams admin center despite the phone being online and 100% functional. Even rebooting the phone hasn't made it start showing online again.

Then we've had numerous phones that never get a dial-pad for making outbound calls. When you first provision an account for Teams enable enterprise voice, give it a line URI, dial plan and voice routing policy, it can take several hours before a dial-pad will eventually show up for that user. In some cases, it hasn't shown up after days/weeks despite numerous reboots. The "solution" for that one, after having to open a case, seems to be going back and disabling and re-enabling enterprise voice on the account. Then after a few hours, the dial-pad usually eventually shows up. Unfortunately, I have at least one phone that I've done this a couple of times over the past week and it STILL has no dial-pad. I've not opened another case just yet because I'm simply too frustrated right now to do so for another Teams phone issue. And God knows how many of the hundreds of conference room phones deployed globally are actually missing their dial-pad right now. I have no way of knowing until it gets reported. I'm sure there are plenty for us that simply haven't been reported yet since thanks to COVID, our conference rooms aren't being heavily utilized just yet. Perhaps that's the one silver lining for us.

And of all of those things aren't a big enough problem, there's the lack of ability to 100% remotely log a phone in. Recently, Microsoft added the "remote" provisioning feature. Apparently we have a different definition of "remote" though because for it to work, you have to give someone a code to punch in the screen of the phone before you as the administrator can then going into TAC and provide the credentials you'd like that phone to use. If there was truly an option for 100% remote login capability, then maybe the issue of phones logging out and not logging themselves back it would be a little less troublesome....but again that assumes you even know it's stuck at a login screen despite TAC showing is being logged in.

And if you're going to do conference room and common area phones, you'll want to search for Jeff Schertz's blog posts about IP Phone Policy as it's not terribly well documented elsewhere. The policy setting is something that currently must be done via PowerShell and set on the account the phone will be logged in to. Along with the "SignInMode" option, you'll also want to look into "hot desking" which is enabled by default with a 2 hour idle timeout. You'll want to either completely disable this feature for common area and conference room accounts or at least set the idle timeout to something more reasonable like 5-15min.

If you're a small shop and can logistically physically "babysit" the phones easily, then maybe you'll be fine. If you're a global shop, best of luck to you. It's been a bit of a nightmare thus far. I've almost gone to the point of reverting the phones to Skype profile mode and just logging them in that way in hopes of greater stability for the time being....and that actually does work. However, then I'm left with hundreds of phones that at some point will have to be all physically touched again (due to lack of 100% remote login capability) to eventually convert them back to Teams native mode. The one touch meeting join experience is definitely nice but we had that with phones in Skype mode before already so that's nothing new just for Teams.

I've had sporadic success with doing a factory reset after or before doing a firmware update. Not sure if the local cache is keeping some data that might be the cause or not. If I remember correctly, you can hold the * and # keys when you plug the power in to clear the Teams cache on Yealink devices.

I just did an MP56 and a T56a, both having been factory reset before (mostly because I was an idiot and signed into the wrong phone admin interface), and both successfully logged in after coming back up. I've got more testing to do (login to another tenant without adfs, etc) to see if I can break it again.

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.