Forum Discussion
Solved
Teams Phone device refuse login with 1449/1.0.94.2021033002 firmware and ADFS
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 firmwa...
So I have a small update from Microsoft on this, and it's more of a temporary fix from what I understand.
- Login to https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesEnrollmentMenu/enrollmentRestrictions
- Create a new Device Type Restriction
- Give it a name
- On "Platform Settings" change "Android Enterprise (work profile)" to BLOCK
- Make sure "Android Device Administration" is set to ALLOW
- Click Next
- Click Next
- Under Assignments click Add Group and select the group of users that are signing into devices.
- Click through to finish the setup
Wait a few minutes, and reboot the phone, login again.
I'm still trying to find out how to resolve the issue correctly, but this seems to have helped most of the cases I've had issues with so far.
Just chiming in to hopefully get this more visibility. Our organization is considering Teams phone as our next PBX and in the midst of trialing phones I am running into the same issues.
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.
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.