Mar 26 2019 05:01 AM - edited Mar 26 2019 07:02 AM
Mar 26 2019 05:01 AM - edited Mar 26 2019 07:02 AM
We have recently migrated all our users from SfB to Teams , and one of my users now is unable to dial out to external phone numbers?
He has a E3 licence, Phone system, Domestic calling plan, Communication credits licences applied, and had his phone number assigned, but he has no dial pad in Teams.
He is able to receive external calls to his Teams phone number?
I have logged him onto another PC and signed into Teams but the same happens there is no dial pad.
The teams desktop app settings >Calls > has no call answering rules available as if there is no licence assigned.
Has anyone seen this before?
Jun 16 2019 01:22 PM
Jun 16 2019 01:22 PM
@Deleted yes, because of the loose connections between systems, I've come across occasions when things can get confused.
Jun 17 2019 09:11 AM - edited Jun 17 2019 09:20 AM
Jun 17 2019 09:11 AM - edited Jun 17 2019 09:20 AM
Thank you, @Deleted! My problem was resolved by turning off both licenses, 1) Phone Service, 2) Calling Plan. Left this off for 30 hours. Turned licenses on again.
For the details … Turned off licenses Sat 11:30 AM. Turned on Sunday 17:15 PM. Checked Mon 6:15 AM, had the dial-pad. Had just turned calling on, earlier in the week, in our system, for two accounts. So turned off licenses for both (all) accounts.
Jun 20 2019 06:07 AM
I've noticed that temporarily removing licensing from an account will cause the EnterpriseVoiceEnabled parameter to revert back to the default $false value.
So, if you are replace licensing on an account it's always a good idea to double check the status of the accounts afterward to make sure that Enterprise Voice is still enabled.
To show all accounts:
Get-CsOnlineUser | ft UserPrin*, Ent*, HostedVoiceMail
To show one account:
Get-CsOnlineUser -Identity firstname.lastname@example.org | fl UserPrin*, Ent*, HostedVoiceMail
Jul 03 2019 05:26 PM
@Jeff_Schertz and all - I'm having this dialpad issue as well for several of our Teams Direct Routing pilot users. I can receive calls to my DID, I just can't make any outbound. I'm on day 6+ of no dialpad showing up after running through all our commands. I put a ticket in and they said not to flip policies on the individual account from Teams only to Islands and back again - as they were going through the logs I sent. I got fed up and did it anyway - and so far with no luck.
Question - how long should I make the change for, and what change should I do? Should I just disable Phone System for several hours? How long? Should I do the co-existence policy change? If so, how long before going back?
Jul 03 2019 06:23 PM - edited Jul 03 2019 06:23 PM
@phake, On my IDs, I removed both the 1) Phone service license, and 2) the calling plan license. Left it this way for 30 hours. Turned both back on. This resolved my issue. I was only working with two IDs at the time.
If you are on the Office E5 (that includes the Phone Service), expand the E5 option (looking at licenses for that ID), deselect the Phone Service option.
I will be rolling out Teams Calling to more IDs, later this week. I'll see if the dialing pad shows up for these IDs, or if I will need to remove 1&2 licenses above, then add them again.
Jul 03 2019 06:47 PM
@Paul Beiler very cool - I just removed Phone System (I am utilizing Direct Routing so no need for Calling Plan), so hopefully this will click it into gear.
That being said, I have to do this for 300 people and 120 of them only perform outbound calling (Sales) in about 4-5 months - so this should be interesting.
Jul 04 2019 04:17 AM
Jul 05 2019 12:07 PM
@Paul Beiler We are a rolling out customers with Teams DR since December 18, we have done about 50 different tenants from January 19 to let's say May 2019, during this time we had one issue that EV enabling didn't work out within an acceptable time, it actually took 9 days to get it appear, don't ask me what happened in the back-end and why it finally appeared. But starting end of May things got worse, we currently face the issue, that EV enabling can take from 4h to 12 days and more, its pure random - in one tenant it works properly on the other it does not - so no way to plan or predict anything.
Also enabling/disabling phone add-on, removing EV and re-enabling with PS doesn't seem to change anything, its pure random we believe. Finally I think it's a back end synch issue with Microsoft. The very same is true for any AA or CQ configurations lately, some work, some don't and you have to open a ticket and hope that the guy on the other end has ever heard about Teams DR at all, it will take you easily 14 days to get an answer if any, so to put it this way, the system is unpredictable and we cannot migrate any other customers right now, we are trying to talk to Microsoft, but hey that's not easy to find someone to talk to that can help at all.
Another issue that we face and which is the real pain - Teams clients in different tenants start to lose their forwarding settings (e.g. delegates, or forward to call groups set in client.). You can set it in the client (doesn't matter if on App, Windows or in Edge), it will work and boom a couple of hours later it's gone and you can repeat this game forever- it's pure random. All started when they enabled forwarding in the back end as a GUI option I would say. You can also set the forwarding in the back end, it will happen anyway.
Anyone facing this issues too? Please contact me or send me a note, this is highly important as we cannot use Teams phone system like this and we have currently 4 cases with Microsoft logged but as I said, it's moving so slowly that we cannot move any other customers to Teams DR before those 2 things above are fixed. And yes there are other issues that make life harder.....feel free to contact me, happy to share our experience.
Jul 05 2019 03:30 PM
@Christoph Schoch That's pretty crushing news. 12 day? Oh no...
I'm on day 7.5+ now for my SIP address. Turning off Phone System for 12+ hours didn't work - and it was making it confusing for my guy on the Microsoft ticket side for troubleshooting. I flipped it back on.
For a company that does all outbound calls from the Sales side, that seems like suicide to do. How did your customers survive without a dialer? Was it just for some users in the tenant? This doesn't seem like a bug to me - this is a propagation issue that MS needs to address - and seems fixable.
The forwarding issue for calls is troubling. Is it consistent for every user in the tenant, or again, just random? That seems like a bug for sure. Let me know if you get any traction on the issue. I can test on my tenant as well.
Jul 05 2019 10:14 PM
@phake Well, customers are not happy at all that we miss the deadlines when moving to Teams from a different PBX. But we have started to plan to execute the preparation work (prepare users, licenses, EV enabling, AA/CQ etc.) at least 2-3 weeks before going life date (in cases where this is doable, sometimes you can't for many reasons), so we learned from past installations and in most cases this was a good workaround and therefore not an issue for the customer. But it's still a pain, also for resource planning internally because it's not reliable and to be honest, far away from a mature system.
Regarding forwarding issue, it happens randomly on all users and that in 4 different, independent tenants, sometimes a couple of times a day with the same user and then on other users after 2 odr 3 days only once, we haven't found a pattern or a reason for it. If there would be a way to fix this by Powershell we could at least have a workaround but this way it's all manual work to re-enabled them and to check the settings regularly. Waste of time and resources.
As I can't find anyone else having those issues here, I start to believe it's either an issue with localized versions (German, French versions of Teams etc.) of the Teams client or something else that I have missed when doing the forward settings in the client. The employees need their forwarding rules, e.g. cell or call groups, this is by far the worst issue we have and it's making the most troubles, beside other things that come along.
Jul 06 2019 01:39 PM
I miscounted, it’s been since last Thursday at noon, so I’m on day 9 now.
So @Christoph Schoch, you can apply Phone System license 2 weeks ahead of time, and you’ve noticed that works? You get the dialer / ability to place outbound calls within ~4 hours? Just make sure EnterpriseVoiceEnabled $true, HostedVoicemailEnabled $true, OnPremLineURI is enabled on the user’s account in the tenant?
I’ll keep my eye out for the call forwarding issue - thanks for the heads up!
Jul 08 2019 06:03 AM
@Christoph Schoch Ok, interesting. Looks like all our users are EnterpriseVoiceEnabled as we're Hybrid and it's grabbing that attribute from the Windows Server AD. It seems like you just enable the Phone System license 2 weeks prior to an engagement, then give it the weekend once you switch them to Teams Only and setup the extension in the SBC?
Jul 08 2019 07:13 AM
@Christoph Schoch Ya, honestly that doesn't make sense. All our hybrid users are EnterpriseVoiceEnabled $true and OnPremEnterpriseVoiceEnabled $true. It would only make sense if EnterpriseVoiceEnabled $true and OnPremEnterpriseVoiceEnabled $false parameters are set that take the 2 weeks - as that's what we're seeing now on the users we migrated to Skype Online then enabled for Direct Routing.
I'm on day 11 now for my SIP address and still no dialer.
Jul 08 2019 08:49 AM - edited Jul 08 2019 08:51 AM
@phakeFollowing up on my experience … Early last week, I added a CALLING PLAN license to 5 IDs. By Friday, these IDs did not have the dialing pad. (I am in the cloud completely, do not use direct routing). So, Friday morning I removed the Calling Plan license and the Phone Service license from the 5 IDs. 30 hours later, I added both of these licenses back. Two hours later I assigned phone numbers to the IDs. Somewhere in the night (between 10:00 PM and 6:15 AM, 6:15 being 18 hours after adding the phone numbers), the dialing pad showed.
By default, my IDs already have the Phone Service license assigned, a default when assigning the Office 365 E5 license to the ID. Definitely, there appears to be an issue with backend syncing that takes a long time. Is my system being thrown for a loop because the Phone Service is assigned yet there is no calling plan nor phone number assigned? Just thinking out loud.
And in all cases, the EnterpriseVoiceEnabled value always changed correctly, when adding/removing the calling plan. Of my IDs that have the Phone Service license but no calling plan, this parameter is set to $False.
Jul 09 2019 09:00 AM
@Paul Beiler thanks for sharing your experience!
Similar to your 'somewhere in the night' my dialpad showed up, so on the 13th day for my particular SIP account I have success. Mild cheer!
Still not sure what the issue is, as we have other test accounts with their dialpad not appearing in the Teams client(s), and they're on day 5+ now. In my MS ticket, our engineer said it's because of this: "isEvEnabled":null, (in the Teams logs we pulled).
Yesterday the logs showed "isByotEnabled":true, which was interested that the dialer still didn't work, and "disableCallingForHybridVoice":true,.
Our only working dialer SIP account had: "isEvEnabled":true, but "disableCallingForHybridVoice":true, - so maybe the "disableCallingForHybridVoice" doesn't matter.
Still trying to figure this out, as we have to do 300+ people in Q1 2020.
Jul 10 2019 12:32 AM
Jul 12 2019 05:39 AM
@Helios Comms Yep - looks like you're having your own struggles with this as well. Are you doing Direct Routing or Calling Plans? Sounds like the individual co-existence mode policies are messing up. Do you have a MS ticket open? What do they say?
Jul 15 2019 12:36 AM
Writing this, hopefully to help others.
I had the same issue as you guys. Using direct routing, if that matters. I setup the system about 5-6 days ago, and still no dialplad.
Talked to MS support, who fixed ind a mater of seconds by "refreshment on the system" due to replication time.
Issue description details: DialPad In teams Wasn’t showing After Activating PSTN.
Replication Time , And We Ran a refreshment on the system and it worked.
If it helps, you can referer to Ticket ID: 15343328