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.
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.
KruthikaPonnusamy
Microsoft
MicrosoftBrandonJ365 Thank you for taking time to add your detailed comment. A few things:
1. For dialpad issues, please create a ticket and IM me the ticket number. I will help follow up with what is going on there. From our support tickets, I dont believe that this is a common occurrence. If it is frequent, this definitely warrants detailed investigations and we will look into it.
2. As long as you are on the latest firmware/app versions, if your phone signs out, you can setup alerts to notify of a device that has signed out. Microsoft Teams Monitoring and Alerting - Microsoft Teams | Microsoft Docs.
3. You are right that we require a verification code to be entered on the device for provisioning. This is ONLY for first time deployment of devices and is a security requirement. Once this is done, all authentication can be done remotely. So, if previously signed in devices sign out, you can remotely sign in from TAC.
- I greatly appreciate your time in responding! For your points:
1. I will try to open another ticket on this as soon as I have the time and will send you the case # at that point.
2. I'll admin that I hadn't even seen the option for notifications so I appreciate you making me aware. However, I don't think that's going to work for this situation. At least in my version of the TAC, it appears that the only option here is for health status of "offline". It's grayed out and thus doesn't seem I can change it to "logged out". I also see that you must scope it to specific users which must be manually set. So I'm going to have to manually add hundreds of device user accounts to this list and keep up with that as more are added? That is not an Enterprise grade solution. Lastly, even if I could set the condition to monitor for a "logged out" situation AND I didn't have to manually maintain the user list, it still wouldn't help. As stated in my previous comments, as far as the TAC is concerned, it shows the phones to be logged in despite us looking directly at the phone and seeing it at a login screen. Again, if we power cycle it, it usually (but not always) will log right back in with it's proper original credentials. In a few cases, the phone had to be complete re-authed. The correct solution here is for the phone to attempt to re-auth with it's stored credentials. If it can do that after a power cycle, then why did it not keep retrying after whatever caused the "logout" to begin with? Btw, I had case open about this earlier in the year and the "fix" was for MS to disable the "health reboots" happening every 8 hours of inactivity but was told it would be resolved in newer code. That was several versions ago and I don't know if whatever was done on our tenant to disable "health reboots" is still in place or not. That said, I can't say for sure if those health reboots are even causing this now like we saw before. For all I know...we could have had a network blip. Nonetheless, the phones should retry logging in...over and over.
3. It's nice that if a phone truly is signed out as far as TAC sees, that it can be logged back in remotely. Unfortunately we don't necessarily know which account a specific phone should be using because we don't rename or tag the devices as they come online, again, because we simply have too many to do this and keep up with it manually and there doesn't seem to be a bulk way to do it. I have one phone right now that's fully logged out. When I try the remote sign-in, TAC does give me the "most recent signed in user"....cool. Unfortunately, this goes back to point 2 where the phone at some point was left sitting at a login screen and a random user took it upon himself to log in with his own credentials. So basically we're stuck until someone at that site can determine which conference room this phone is in to know which account it should be signed in with.I also have the issue of phones showing as offline in the admin center even though they are working fine. Along with devices never showing up in the admin center. So with 2 people reporting this issue its clearly a Microsoft issue.
As for the phones logging out we do get this but isn't common. However this remote provisioning is something I've never heard of? Is there a guide for this?
Also what is the best/official way to report these issues as i have done so via azure portal & 365 portal with next to no success?
Overall i would say teams phones are very hit & miss possible not mature enough yet with information like the Intune bit scattered all over a number of MS articles which makes it hard. For example this mentions nothing of Intune https://docs.microsoft.com/en-us/microsoftteams/set-up-common-area-phones
Lastly when setting up a new BNIB phone and your lucky enough to get the device to show up in TAC is it possible to patch to the last firmware/app in one go? its rather annoying when you have to repeat this step multi times as it goes up the versions?
Thanks
- Jeff Schertz has done a guide on remote provisioning. Generally speaking, he's the best source for useful information: https://blog.schertz.name/2021/03/provisioning-teams-android-devices/
My account Team urges that the proper way to report these issues is to open cases. For some issues, that's not too much of an issue. For issues of phone logging out, it would be like finding a needle in a needle stack to catch one that it's happened to and actually get useful logs. At least on a Trio C60, the logs are rolling in 24 hours or less.
Regarding your issue with pushing code from the TAC, yes, it's frustrating.....end of story.
