05-16-2019 12:22 AM - edited 05-16-2019 12:23 AM
05-16-2019 12:22 AM - edited 05-16-2019 12:23 AM
I want to assign a SfB Online Service number to a Resource Account, but its not working. I cannot assign it via TAC because absolutely no numbers are shown, and I cannot assign it vie SfB Admin Center because this feature is already migrated to the TAC :(
Therefore I tried it vie Powershell, but I get an error:
Set-CsOnlineVoiceApplicationInstance -Identity email@example.com -TelephoneNumber +34943123412
WARNING: The following Application Instance not present in BVD: f262200f-1696-4421-90b5-3e14d0dbae87
Cmdlet invocation error
+ CategoryInfo : NotSpecified: (:) [Set-CsOnlineVoiceApplicationInstance], CmdletInvocationException
+ FullyQualifiedErrorId : Error processing cmdlet request,Microsoft.Rtc.Management.Hosted.Bvd.SetVoiceAppEndpointC
+ PSComputerName : admin1e.online.lync.com
Could anybody help? :)
05-16-2019 04:35 AM
FYI: There is a problem right now at MS with the number assignement of Call Queues. MS is working on that. As a workaround you can use an Auto Attendan instead of a call queue, assigning numbers to AAs is working! ;)
05-16-2019 11:45 AM
I have the same problem with both IVR & Queue. Waiting resolution of this issue and except requested to transform service number to user number in order to route the office number to Teams user in failover mode I didn't find any workaround (customer migration to Phone System with Calling Plan tomorrow morning !)
In my experience with same licenses on both ressource account (AA/IVR or Queue) I can see service number for Queue but not for AA/IVR. In any case I cannot assign phone number
I assigned Phone System and Calling Plan to Ressource Account as required in this update I don't know if it's the root cause but for each Ressource Account MCO licenses are always in PendingInput status indefinitely.
Calling Plan = 120 ' FR
05-16-2019 12:38 PM
@Timo Klinger We are having same issue with both AA's and Call Queues, hope MS fixes this soon. We just ported two offices and can't get the main numbers working.
05-22-2019 08:48 AM
@Mark Linman and all-
Same issue here. I ported a number in as a service number and went to assign it to a call queue. It would give me a "saved successful" banner but upon page refresh, the assigned number was gone. Opened a ticket with MS Support and was simply told it was a provisioning issue (since now we have to temporarily license resource accounts...). 24 hours later the issue persisted. Off to Google I went.
Managed to fix it with PowerShell:
Set-CsOnlineApplicationEndpoint -Uri sip:hg_%replace_with_resource_account_URIfirstname.lastname@example.org -PhoneNumber +19999999999
Sent 4 follow up emails to MS Support on my ticket and have yet to receive a response. Regardless - the above PS fixed the Call Queue issue for me. Hopefully it will help someone else.
05-31-2019 11:50 AMSolution
@Timo Klinger when using the search field it is counter-intuitive. Try searching without a + and instead include the area code with spaces i.e. "1 479 555 5555"
06-04-2019 12:04 PM - edited 06-04-2019 01:19 PM
We are having the same issue. Ported numbers this past Friday and I'm unable to set those same numbers to the newly created call queue resource accounts. Have been working with Microsoft support and engineers with little progress. If you request new service numbers using Skype legacy portal, those numbers work. Seems to only be happening with ported numbers.
Our current workaround to ensure we are still receiving calls versus line down is to switch the service type numbers to user type numbers and assign them to licensed mailboxes.
A more current conversation taking place here - https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/Auto-Attendant-and-Call-Queues-Service-U...
06-21-2019 09:58 AM
@Sebastian Heredia we had the same issue with ported service numbers being down because they couldn't be assigned in Teams anymore (even though number assignment worked the week prior during pre-migration testing). Microsoft support wasn't very responsive, and even sent some PowerShell scripts that didn't work. I finally got the client's main number back online by following these steps.
06-25-2019 04:38 PM
Hi @Laura Curtis ,
I have created an account and assigned it a domestic calling and msoft e5 account. Is there another license that it needs?
06-27-2019 10:11 AM
Hi @JP223, not with the E5 license. You'll need E5 plus Domestic Calling, and that's it. If you've got E3, you'll need Domestic Calling plus Cloud PBX. Make sure the resource account is listed as a Service account in Skype for Business Admin. If the number you want to use is not a Service number but a User number, you'll need to email PTN@microsoft.com to request they convert the User number to a Service number.
07-07-2019 02:57 PM
This still seems to be an ongoing issue. I have been through the whole process with MS Support who have been trying to help me assign service numbers to resource accounts. This includes the whole powershell setup as listed in the replies.
Has anyone heard from MS if this is something they are able to fix? I am suprised to see it has been going on for so long. I am lucky as these are routing numbers I need and I had the main numbers setup whilst we were on SfB. I can imagine MS are upsetting alot of customers if they are unable to route their main line numbers.
09-19-2019 01:23 PM
Thanks for this post, this fixed it for me. Definitely counterintuitive because when you do the search the + sign IS in the results.
09-19-2019 09:56 PM
10-24-2019 11:42 AM
Why is this not at the top of the discussion as the solution. Thank you, thank you, thank you!!!!
02-21-2020 02:46 AM
David, you are the man! i cannot beleive MS support did not even mention this, i have had 2 support tickets open, 3 engineers, 2 weeks later and they still couldnt work it out! your message solved it instantly! number assigned to resource account finally!
02-21-2020 02:05 PM
@bluelights No problem. They have a lot of holes in the UI side, especially when it comes to searches. I'm still trying to figure out how to properly do a wild card search in Azure AD.
If you are assigning an onprem/hybrid non-MS number you have to use powershell.
03-31-2020 05:49 AM - edited 03-31-2020 05:52 AM
@David Stowers This is true. you have to avoid + up front when searching numbers. I also noticed that the Resource Account in Office 365 / Azure must have same location as the country of the number. When the Location of the account was US, I could not find polish number. After correction of the location I could. I found it out thanks to Power Shell error notification "The Telephone Number assignment failed. The country of the user’s Usage Location US and the country of the Telephone Number PL do not match."
04-24-2020 11:32 PM
06-11-2020 11:28 AM
Oh my god really
Is that all it was!
All they need to do is put in a little tip on the screen to say you dont need to include the plus symbol