03-26-2019 05:01 AM - edited 03-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?
03-26-2019 07:08 AM - edited 03-26-2019 07:09 AM
@Chris Cooper
Check if the Azure AD Object is actually EV enabled in Azure AD (I have had this and seems/think to be an intermittent issue with provisioning an EV Teams user in the O365)
If you find this is false then please run:
Get-CsOnlineUser <SIP Address of Effected Teams Users> | Set-CsUser -EnterpriseVoiceEnabled $true
03-26-2019 03:35 PM
@Mehmet_Kocak Thanks Mehmet, I'm having issues running the powershell command in your screen grab, what module are you connecting to in powershell, how are you connecting to check if the Azure AD Object is actually EV enabled in Azure AD?
Many thanks
03-26-2019 04:06 PM
04-02-2019 05:27 AM
@Mehmet_Kocak Hi Mehmet, I was following this conversation but it looks like it did not progress. I have upgraded few users to "Teams Only" but we noticed that our dialpad is missing as well hence, we cant make external calls. Ive ran the recommended script above and here's the result.
PS C:\will> Get-CsTeamsInteropPolicy
Identity : Global
AllowEndUserClientOverride : False
CallingDefaultClient : Default
ChatDefaultClient : Default
Identity : Tag:DisallowOverrideCallingTeamsChatTeams
AllowEndUserClientOverride : False
CallingDefaultClient : Teams
ChatDefaultClient : Teams
May I know if this is an app limitation or there is something I need to enable through powershell.
Please see attached photo for reference.
Thanks!
William
04-02-2019 05:28 AM
Heres another screenshot. dial pad is missing
04-02-2019 05:31 AM
I tried this keyboard shortcuts too but it did not display the dialpad.
04-02-2019 05:31 AM
@WilliamTan30Have you EV enabled your Teams users ? (Phone System Licence, and depending how you route your PSTN Calls Direct Routing Voice Routes and/or PSTN Calling Plan Assignment Voice Routes...)
But at a bear min as far as I know you need to EV Enable your Teams users for the dial pad to appear...
04-02-2019 05:35 AM
@Mehmet_Kocak how would i know if my EV is enabled?
04-02-2019 05:36 AM
@Mehmet_Kocak if you are refererring to my Enterprisevoiceenabled, yes this feature is on "true". please see screenshot
04-02-2019 05:37 AM
@Mehmet_Kocak Hi Mehmet, thanks for this, it turned out, my machine was at fault so I had to connect on a different server, the result were all true, thanks for the help with this.
@Mehmet_Kocak wrote:
No worries, if you follow this link it explains how to connect
https://docs.microsoft.com/en-us/office365/enterprise/powershell/connect-to-all-office-365-services-...
Then if you run just get-csonlineuser <sip address> | select "*voice*","*team*"
Check if the enterprise voice is enabled, and other settings matches expectation compared to your other users that is working
EnterpriseVoiceEnabled : True
04-02-2019 05:40 AM
@Mehmet_Kocak My EVenabled is "True". Please see attached.
04-02-2019 05:52 AM
@Mehmet_Kocak Currently our setup is like this;
We do not have a calling plan (Denmark) that's why we are using CCE server to connect our calls to SFB
I have Enterprise e3, Audioconferencing and Phone system licenses.
I hope this would help.
Thank you in advance! :)
04-02-2019 05:54 AM
04-02-2019 05:55 AM - edited 04-02-2019 06:02 AM
@WilliamTan30 So you have OPCH configured (CCE), but your Teams EV Users cannot leverage this feature, as OPCH is only for SfB Online Users consuming telephony via the CCE device, you will need to setup Direct Routing (SIP Trunk between On-prem supported SBC and Teams SBC) and/or use Calling Plans.
I can see that the page shot shows this particular user has not got a CsOnlineVoiceRoute configured which is configuration setting for Teams Direct Routing....
However as a side note sounds like there is some issues in general with the Dial Pad as Chris pointed out above...
04-02-2019 06:57 AM
@Chris Cooper Thanks for your inputs. This could be an issue or a glitch
04-02-2019 06:58 AM
@Mehmet_Kocak how can I setup a direct routing for Teams SBC? calling plan is still not available in denmark
04-02-2019 07:12 AM
@WilliamTan30Yep! I would recommend you read:
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-configure
I hope this helps (BTW do not think this is related to your Dial Pad issue and more likely an issue within the MS Teams stack itself)
Thanks
04-02-2019 07:59 PM
04-03-2019 05:51 AM
I checked both Mac and PCs this morning; both exhibit the same behavior. The dialpad and Voicemail tabs are missing in Teams. I signed out of Teams and back in and still no dialpad/voicemail. My iPhone, however, still has the dialpad/voicemail. I can place/receive calls from iOS Teams just fine.
04-03-2019 06:32 AM
@OmarVegaI wonder if setting EV to false then back to true again gives any difference in behaviour ?
Please bear in mind backend replication can take anywhere from a few mins to 24 hours to apply settings in Azure/O365
(i.e. submit/commit a setting change in Teams at the right time may show up in a teams client a few mins later....not sure what that "right time" is however! - I take a guess that MSFT queues its tenant changes at set intervals into different classes so another our setting change falls in to the higher class for replication or lower class for replication - This is a total (attempted educated) guess however and could be totally wrong
04-03-2019 08:15 AM
@Mehmet_Kocak - Good idea; will try that now. Yeah, I've noticed the same on changes...some take place very quickly and others overnight. Not always convenient for users waiting on changes. Hopefully MS will get better with replicating changes.
04-05-2019 12:54 AM - edited 04-05-2019 01:55 AM
@OmarVega I have the same issue since two days in a direct routing scenario and nothing seems to get it fixed. User has no dial pad but can receive inbound PSTN calls! I guess it's time for a ticket to MS. Fortunately, we are not production with this system. It's so immature.
04-05-2019 05:12 AM
@Adrian Gularek I ended up opening a ticket with O365 support yesterday. Of course, they wanted to do level-1 troubleshooting, which I've already done. After they saw everything I did, they have escalated the ticket; I'm still waiting to hear from whomever on it.
It's definitely something with my account - what? I don't know... Looking at the Teams debug logs (CTRL-ALT-SHIFT-1), I see this very early on in the log (and repeated later):
call-contact-card: [updateAudioCallBtn] mri: "8:orgid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", isPstnCallingAllowed: false, isAudioCallBtnVisible: true, isToggleOBOMenuBtnVisible: false
I don't know why all of a sudden Teams thinks that PSTN calling is not allowed for my account. I have two test accounts...that are setup the same way as mine and PSTN calling is true. Not sure what would have changed over last weekend...everything was working fine until I logged in Monday morning.
04-05-2019 06:32 AM
@OmarVega I would really appreciate it if you could share the update from Microsoft? Ive been researching for this fix as the recommended steps from microsoft is not working.
04-05-2019 06:43 AM
@OmarVegaI have also opened a ticket with MS and I can also see I have isPSTNCallingAllowed:false in the log.
04-05-2019 10:23 AM
@WilliamTan30 I'll definitely post up whatever is found. Right now, they've been having me collect & send them logs, still no resolution from them.
04-05-2019 10:27 AM
@Adrian Gularek They sent me a tool to collect a Fiddler trace...just sent them back the results; hopefully that will offer some insight for them. Curious if the resolution is the same for all of us...
04-05-2019 11:40 PM
Have exactly the same issue on my testbed. I was testing with the Voice routing Policy, I removed the existing voice routing policy and assigned a new voice routing policy and then the Dialpad vanished.
Couldn't get the dialpad back since last 18 hours.
This is really not stable and reliable.
04-08-2019 04:38 AM
@Thangavel MudaliarToday around 12:00 CET my dialpad magically re-appeared (no configuration changes since Wednesday). If we had EV fully on Teams, would users be unable to call for 3 days ? That's scary.
04-08-2019 04:41 AM
Hello Adrian,
I was able to resolve the issue over the weekend by disabling the EV and re-enabling for my test accounts.
04-08-2019 04:52 AM
Hi@Thangavel Mudaliar Thank you I suspected this may work as mentioned above, hopefully its the same case all others experiencing this issue!
04-08-2019 05:27 AM
Interesting...
My Teams dialpad is back. The only thing I did on Friday before leaving for the day was to change my TeamsUpdatePolicy from 'TeamsOnly' back to 'Islands' - as I was unable to make phone calls all week due to lack of dialpad. When I logged in this morning, the dialpad is back in Teams.
Sometime last week, I tried disabling EV and re-enabling and that didn't work for me.
I'm going to report my findings to Microsoft, see if they have anything to say about it.
04-08-2019 06:52 AM
SolutionI forwarded my findings to the MS case and the 'Case Ambassador' called me and said that he was told that the backend team did identify an issue and applied a 'Global fix'. When I asked him to explain further, he could not, stating that he doesn't have access to what exactly was done other than something was done. Seems fishy to me, but a 'global fix' being applied does seem to support what we've seen on this thread - several users having issues are now working again.
04-08-2019 06:59 AM
@OmarVega Yes very fishy, all working again for my user too, so looks to be resolved, thanks to everyone's contributions to this issue.
Great result!! Thanks.
05-25-2019 08:10 AM
05-28-2019 02:06 PM
06-02-2019 03:26 AM
If you do not have dialer (or adjust anything in the Teams telephony) you need to check (adjust) the settings simply (if they are up to the ones MS recommends):
* Direct Route trunk
* User enable + DiD assigned
* Some sort of call routing is there (ONLINE Dial plan, Online Voice Pol, Online Usage, etc is there)
* Online Voice policy is granted
THEN you need to wait. Even though the power shell seems to be instant however, it can take anywhere between 5 minutes to 40 (80?) hours the settings to take into effect. (Eg. you can create and start the Online PSTN gateway in 2 minutes, but 30 minutes was not enough to pick up any modification such as port, options on off etc. )
What you need is confidence and a massive amount of patience with this MS service.
06-15-2019 10:58 AM - edited 06-15-2019 10:59 AM
Was this issue resolved, for anyone in this thread. I opened a ticket with Microsoft, Ticket # 14779431, on the 10th. MS support has not made headway with this yet. We are in the cloud, no on-premises servers.
I cycled the EV settings (True, False, True). I cycled the licenses (calling plan & Phone system, on/off/on). I cycled the TEAMS UPDATE (Teams only, Islands, Teams only). I gave the system time to ripple through when making these changes (2:45 hours on the licenses, 36 hours on the Teams Update, ok, only 10 minutes on the EV).
06-15-2019 11:18 AM
06-16-2019 01:22 PM
@Deleted yes, because of the loose connections between systems, I've come across occasions when things can get confused.
06-17-2019 09:11 AM - edited 06-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.
06-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 user@domain.com | fl UserPrin*, Ent*, HostedVoiceMail
07-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?
07-03-2019 06:23 PM - edited 07-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.
07-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.
07-04-2019 04:17 AM
07-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.
07-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.
07-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.