All issues are DNS until proven otherwise.System Administrators Everywhere
When I was working on creating my last PluralSight course over Teams phone system services, 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.
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 it a remote PowerShell session out to Skype for Business Online with 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 engineer mentioned that I didn’t have any of the typical Skype for Business Online DNS records for federation, lyncdiscover, etc. Since the tenant was for just recording demos for the course, I didn’t worry about setting up any of those records as I was only going to be working in Teams, no Skype for Business Online components or worry about federation. I decide 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:
So 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.
So 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 off in Teams Only mode, not creating those Skype for Business Online records, and not worrying about federation with other organizations.
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 for it. 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.