Microsoft Teams auto attendants and call queues use resource accounts for their configuration. You assign license and phone numbers to these resource accounts for the voice applications to work. However, if you are missing some DNS configuration, you might run into an error creating them.
When creating my Teams voice PluralSight course, I ran into a weird issue with creating resource accounts. I initially signed up for a 30-day E3 trial to get the tenant started, then accidentally let it lapse a few days before renewing the trial for another 30 days.
In between those two events happening, I lost the ability to create resource accounts for call queues and auto attendants, which I desperately needed to work on my next module in the course. After a month of troubleshooting with Microsoft support, the engineer had me try something that unexpectedly resolved the issue.
Resource Accounts Error in Microsoft Teams Admin Center
When creating a resource account in the Teams admin center, it would error out without much explanation:
We can’t save changes to <username>.
The error also occurred when trying to create the resource account using PowerShell. After creating a remote PowerShell session out to Skype for Business Online, I used the New-CsOnlineApplicationInstance command that produced an even more cryptic error:
This cmdlet is for online domain only. Please run corresponding on-premises cmdlet for on-premises domain.
The thing about this tenant is it is online only, no hybrid or on-premises environment to worry about.
I worked with a few engineers to gather Fiddler logs from the web and verbose output from PowerShell. This didn’t lead to any reason why this was happening. Licensing was good, and everything seemed to be in order.
The Solution
The engineer mentioned that I didn’t have any Skype for Business Online DNS records for federation, lyncdiscover, etc. Since the tenant was recording demos for the course, I didn’t worry about setting up any records. I would only be working in Teams, no Skype for Business Online components, or worry about federation. I decided to give it a try and created the required records.
To my surprise, it began to work almost immediately. I was able to create auto attendants and call queues in both the admin center and PowerShell. The engineer did not know which record was required for this to work (and I was told an escalation would not answer the question), so I decided to experiment.
I remembered a Twitter conversation a few years ago about adding your own domain as an allowed federated domain before call queues would work:
@UC_Crab Did some testing today, only had to add my SIP domain to Allowed for closed federation for call queue to work. Very interesting! pic.twitter.com/7TIFpYhsMG
— Jeff Brown Tech (@JeffWBrown) October 11, 2017
I decided to start with my federation record. I deleted the SRV record, and again, immediate failure on creating call queues and auto attendants. Recreate the SRV record, and it started working again immediately.
This issue was definitely a head-scratcher that I imagine won’t affect too many organizations. It only affected me as this was just a demo tenant and not being used for production. Moving forward, this might affect more organizations but only in a specific scenario of starting in Teams Only mode, not creating those Skype for Business Online records, and not worrying about federation with other organizations.
Closing
One final note, in my personal tenant, I have two domains: jeffbrown.tech and upstarttech.com. The upstarttech.com is configured as the default domain, but I don’t have any of the four Skype for Business Online DNS records created. I can still create auto attendants and call queues for this domain despite no SRV record, even when the SRV record for jeffbrown.tech is missing. Definitely odd behavior that I don’t have an answer for.
Enjoyed this article? Check out more of my Microsoft Teams articles!
