If you’re a Microsoft Teams Admin, like me, you are probably aware that setting up a new Online PSTN Gateway in Teams Admin Center (TAC) or via PowerShell requires the domain of the SBC’s FQDN to be activated. This is done by creating at least one account using the SBC’s FQDN as the UPN Suffix.
Domains
Now keep in mind that there are two ways how you can add an Online PSTN Gateway in Teams. Either you use your own Gateway in which case the domain usually has one segment less and is a subdomain of your main domain. E.g.
sbc.domain.com
In this case you don’t need to create a user to activate the domain because domain.com is already used for other UPNs and thus already known in your tenant.
If you want to use Direct Routing offered by one of the various managed service providers, your FQDN might look something like this. E.g.
customer1.customers.domain.com
In this case you need to add a user with the following UPN. E.g.
domainactivation@customer1.customers.domain.com
Microsoft Docs
The information on Microsoft’s official documentation is a bit controversial. They have two sections mentioning the activation of the domain. One time for the base domain (Carrier Tenant) and one time for the subdomains (Customer Tenants).
As of writing this article, the information looks like this.
After you have registered a domain name, you need to activate it by adding at least one user with Phone System license and assigning a SIP address with the FQDN portion of the SIP address matching the created base domain.
Previously, Microsoft always said that this user needs an E5 License. This is still visible in their screenshots. If you want to review the change history of this particular documentation, you can always see it here on GitHub.
If you’re a customer and want to add a domain name assigned to you by your managed service provider, you don’t need to worry about this part. The assigned licenses will determine what voice capabilities your tenant has. You can check this by running the following in a Teams PowerShell session.
(Get-CsTenant).ProvisionedPlan
This will return an XML string containing all assigned licenses. It’s still a little weird that they only mention Phone System. Because Phone System is just an add-on which can’t be assigned without a corresponding Enterprise License (one of the SKUs which actually triggers the creation of an SfB user object), unless you use Common Area Phone.
Oddly enough though, for the subdomain they don’t mention licensing at all. The subdomain part describes what needs to be done in the customer tenant.
After you register a domain name, you need to activate it by adding at least one user and assign a SIP address with the FQDN portion of the SIP address matching the created subdomain in the customer tenant.
Here they just say that the user needs to be assigned a SIP address, which is not possible without assigning a SfB Online Plan 2 license. Unless you keep on reading…
What will assigning the license do?
So why is a License needed in the first place? Assigning a user a SfB License will provision an SfB Online user object for each licensed user.
Once the SfB user is provisioned, the domain will also be stored in your tenants DomainUrlMap. If the FQDN of your Gateway is not present in your DomainUrlMap, you will not be able to create the gateway. MVP Luca Vitali has en excellent Blog Post about that.
Do we really need a license to create the Gateway?
Based on my various tests, it really doesn’t matter if it’s an E1, E3, E5 or even a Business Basic License. As long as the SKU includes SfB Online Plan 2, a SIP address and an entry in the DomainUrlMap for that domain will be created.
So, I asked myself, is there an easier way to activate the domain? One without assigning a license which would help automate things even further? Turns out there is indeed!
A resource account in Teams does not need a license, unless you want to assign a phone number to it. If you create one without a license, Microsoft 365 will still provision an SfB Online object for this resource account and add its domain to your DomainUrlMap.
By running Get-CsOnlineApplicationInstance we can query our resource accounts in Teams.
After a few minutes, the account will also be visible when you run Get-CsOnlineUser. I always create my resource accounts using ra_aa_ as a UPN prefix. Another easy way of identifying resource accounts is to look for the Department Attribute. A resource account will always have Microsoft Communication Application Instance set as Department.
Caveats
The only caveat is that you don’t usually configure the SfB Online DNS entries for a domain which you want to use for your Direct Routing Gateway domain. If the DNS records are not configured, creating a resource account using your SBC FQDN will fail. Jeff Brown over at Jeff Brown Tech also has a great Blog Post covering this topic.
According to my research and testing, the only record that’s needed in order to create the resource account is the SIP Federation TLS SRV Record. The other three SfB records can be ignored.
Once this record is created you will be able to create a resource account using your SBCs FQDN as UPN suffix. Now you just have to wait for the account to be provisioned and for the domain to show up in your DomainUrlMap. This usually takes around 5–15 minutes but can take a lot longer sometimes.
You can check your DomainUrlMap using this command:
(Get-CsTenant).DomainUrlMap
Based on my Testing, DomainMapUrl was not available anymore in Teams PowerShell Modules above version 2.6.0. This caused my provisioning script to end up in an infinite loop because it was checking the DomainUrlMap every few minutes but always returned empty.
The last module I know of which returned the DomainUrlMap was 2.3.1. Since we’re now at version 3.1.1 I suggest to query the SfB users by using Get-CsOnlineUser to check if the domain is already activated. However, it might still take a few minutes before the gateway can be created. By working with Try {} Catch{} and a Do-Until loop you can keep trying to create the gateway until it succeeds.
Conclusion
So, there you have it. It’s indeed possible to create a PSTN Online Gateway without ever assigning a license. Not every tenant even has available licenses and not every tenant has the same type of available licenses. This means that you don’t need to make sure anymore that your script is assigning the correct license or even that enough licenses are available in the first place. In scenarios where you want to automate everything using unattended scripts, this comes in quite handy.
Because the license and the user can be removed after you created the gateway, I see no problem in setting up a resource account without a license. Unless you’re setting up the carrier tenant. In this case you don’t usually have any other production users which means that you need to keep at minimum one license assigned. Otherwise, the tenant will lose its voice capabilities and break your Direct Routing configuration for all your customers.