May 04 2019 12:03 PM
May 04 2019 12:03 PM
I'm unable to assign a newly acquired service number to a resource account, so that I can setup an Auto-Attendant. We're a Teams-Only Org with Cloud voice/Calling plans.
1. Acquired a new service #. Its status is "Activated". It's been active several hours. It's listed as such in the Legacy Skype for Business Admin Portal (Voice-->Phone Numbers).
2. Now, I want to assign that servie # it to a resource account, but it doesn't appear in the drop-down list of available service #'s. Teams Admin Center (Org Wide Settings-->Resource Accounts, select the resource account, and click "Assign/Unassign"). See attached screen shot.
I know this whole resource account thing is new, and I've seen some recent postings on service number issues. Anyone able to reproduce this? Or maybe I've missed a prerequisite.
Thanks as usual,
May 04 2019 03:06 PM
I think I see the issue.
Apparently you can no longer simply assign a service number to an auto attendant. You actually have to purchase a license (E1/3/5) for the resource account first if you want to associate a service number with it!
If this is true, then this is a sneaky, sure to be hell-raising change for my clients, who are about to find out that they have to purchase additional licenses for all their service-numbered auto attendants. I can't believe this...can anyone confirm?
May 05 2019 02:15 AM
So it is required at the moment, but they are working on an 'appropriate licensing model' in the future. My previously create call queues in the old portal seems to work without licensing. I agree it seems like a rather muddled change and I'll see what else I can find from Microsoft, however these things do tend to be 'done deals'.
May 05 2019 07:36 AM
May 06 2019 09:11 AM
Am I right that this change was not announced anywhere? I watch the Message center in the Microsoft 365 admin centre pretty closely but I don't recall seeing any advance notice about this.
May 07 2019 09:45 AM - edited May 07 2019 10:06 AM
yes we are having the same issue, except the issue is we can not assign toll free service numbers through powershell. We have an open and active ticket with MS on this. Quick questions what tenant are you all on? I am on Admin1a. Just trying to confirm how big of an issue this is. I think MS understands the issue now but this does not seem to be well tested, thought out migration on their part. No communication. Does MS answer back on these forums?
May 07 2019 10:18 AM
@Robert_Hurd I did notice that Get-CsHuntGroup now returns no results. It appears to have been replaced by Get-CsCallQueue. Instead of passing in a SIP URI to select a single call queue, e.g. Get-CsHuntGroup -PrimaryUri "sip:email@example.com", you must now retrieve the Identity property of the call queue and pass that in, e.g. Get-CsCallQueue -Identity 5e3a575e-1faa-49ff-83c2-5cf1c36c0e01. It seems to return similar output as get-CSHuntGroup did, except that Agents are referenced by their Identity GUID rather than their SIP URI.
May 07 2019 10:37 AM
Yes I agree that the -identity is possibly the root issue as you can not use sip address but what would the instance ID be or how would you get them for AutoAttendant I have used Get-CsOnlineApplicationInstance and that gives the details about the auto attendants. I have tried using object ID and user principal name as the -identity. I will look into the queues like oyu have and see if I can find anything. But I think the key is to find out what the Identity property of the auto attendant is now. This is also broken in teams portal so may just not work at all until they fix this. Thanks for your insight.
RunspaceId : bea4e8fc-b741-4368-a9fc-12345678
ObjectId : b9e3137c-0795-4a2b-989c-12345678
TenantId : f63c0b06-d743-4fbb-a68e-12345678
UserPrincipalName : firstname.lastname@example.org
ApplicationId : ce933385-9390-45d1-9512-12345678
DisplayName : Auto Attendant
PhoneNumber : tel:+1234567890
May 07 2019 11:24 AM
So I have tried the get-csautoattendant and I do receive the Identity same as you found with call queues. But when I run the set-csonlineapplicationinstance or the set-csonlinevoiceappliationinstance found in this article it tells me the application instance is not found in AAD. The big issue seems to be the -telephonenumber field will not accept any syntax I try I have tried tel:+1234567890, +1234567890, 1234567890 and also with "". I think this may just be broken. I am trying to find a temp work around but this is a hard one. Any other ideas?
May 07 2019 12:29 PM - edited May 07 2019 01:08 PM
so I was able to fix this issue for resource accounts by creating a new resource account in Online Powshell only, assigning the required e5, communication credits, calling plan licenses and then running the set-csonlinevoiceapplication instance command in the above MS documentation link. Seems like when making them in the teams portal they are not being flagged as voice application instances and thus you can not set a number properly. Now I have been able to set this number with the set-csvoiceapplicationinstanstance command and all is working. Still a much bigger issue of why the resource accounts are not working properly in teams portal but at least documented powershell seems to work.
May 20 2019 06:30 AM
What also seems to be working, it purchasing a E1+PhoneSystem+Calling Plan subscription. Assign it to a resource account. After creating the Autoattendant or queue, remove the 3 subscriptions from the resource account and create the next resource account, if needed, and assign the 3 subscriptions and follow the steps again.
May 20 2019 08:19 AM - edited May 20 2019 12:28 PM
This is ridicolous Microsoft. You have pulled a bait and switch on all your cloud telephony clients. This is unacceptable. To think you have to license a basic feature of any cloud-based service is absurd. What the hell is going on?
May 20 2019 12:31 PM
May 20 2019 01:10 PM
It's absolute bananas. Nor sure what is more ridiculous, the strange setup requirement or the zero communication part 🤷:male_sign:
May 20 2019 01:12 PM
May 24 2019 02:39 PM
I have encountered the same in a test tenant and some research I've found that this is already a known issue and the workaround is below.
To mitigate this issue, you can run the following Cmdlet to set the department parameter. Set-MsolUser -UserPrincipalName -Department "Microsoft Communication Application Instance"
Jun 24 2019 01:07 AM
We have had the same issue but managed to fix this with help from Microsoft.
Apart from licensing every ressource account (and every user who will be used for mailbox purposes) we needed to change the department of the ressource accounts. Those accounts were migrated by Microsoft, but it seems they forgot something.
Get-MSolUser -UserPrincipalName ....username..... | format-list ObjectId
Set-MsolUser -ObjectId " ObjectID" -Department "Microsoft Communication Application Instance"
After that we were able to assing numbers.
It just took us 2 weeks with the Microsoft support, a Senior Engineer and three escalations..
Looking forward to the new license model
Jul 03 2019 07:42 AM - edited Jul 03 2019 07:43 AM
I just came across this issue, and found an update in the article linked in another reply above (https://gorovian.000webhostapp.com/?exam=t5/Microsoft-Teams-Blog/Auto-Attendant-and-Call-Queues-Service-U...) stating that "a $0 application license (Phone System - Virtual User) can be acquired and assigned to these resource accounts."
Not that it's listed as an option in purchase services (which, as a separate issue, currently only works for me under the old admin interface). I'm guessing it's something they want you to ask support for. I'll find out.
Jul 03 2019 08:12 AM
Where did you find the new license in the portal. I am not seeing it yet. I use a CSP so that may be the issue.@stalley