Unable to assign service number to a resource account

Regular Contributor

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,


43 Replies

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?

@Bob Manjoney have a look at https://docs.microsoft.com/en-US/microsoftteams/manage-resource-accounts?WT.mc_id=TeamsAdminCenterCS...


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'.

Thanks. Another annoyance about this change is that I can no longer find the option test an Auto Attendant/CQ from the Teams admin center GUI, and without actually licensing a calling plan for it you can't even test it manually before making it "live". Licensing model notwithstanding, that's surely going to create a problem for us.

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.

@Ryan Steele 


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?


@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:hg_a82e2406b9b5474a9878e9659f32dbc3@litwareinc.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.

@Ryan Steele 

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 : oaa@example.com
ApplicationId : ce933385-9390-45d1-9512-12345678
DisplayName : Auto Attendant
PhoneNumber : tel:+1234567890

@Ryan Steele 

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?




@Ryan Steele 


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.


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.

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?

I'm in complete shock about this change. My clients are going to be raging pissed about paying extra for a basic functionality.

It's absolute bananas. Nor sure what is more ridiculous, the strange setup requirement or the zero communication part 🤷‍:male_sign:



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" 



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

@Robert_Hurd This was what did it for me as well. 


Thanks for posting!

@Bob Manjoney 

I just came across this issue, and found an update in the article linked in another reply above (https://techcommunity.microsoft.com/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.

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