If you’re porting your numbers to Calling Plans, Operator Connect, or a new Direct Routing provider/trunk, you’ll need to plan when to assign those numbers to your users and auto attendants.
This blog post also applies to Direct Routing scenarios where you’re not changing PSTN providers but are directing the numbers from a existing PBX to Teams.
For Calling Plan and Operator Connect scenarios, you’ll submit your port request and once it’s approved (called FOC or firm order commit), those numbers will appear in TAC. At this point, you can change usages from user to voice app or conference, and you can assign them to users.
But should you? Maybe!
You can go ahead and chance number usages to voice app or conference (or back to user if you need), this has no impact on anything ongoing.
However, if you are moving your users to Teams in batches, you will need to assign numbers carefully. The first thing that Teams considers when a number is called from Teams, is whether Teams “owns” that number. If Teams does not own the number, it is sent out to the PSTN.
Consider a scenario where the Seattle office’s phone numbers port to Teams. If the Portland office’s numbers are porting in a few days, you could go ahead and assign those numbers to the Portland users. However, should a Seattle user attempt to call a Portland number, the Portland user’s Teams will ring, not their old phone. Teams owns the number, so routes it directly to the user with the number assigned to them.
This may not be a problem in your organization if your users are expecting Teams calls before their scheduled port date and time. Most often, I find that this is confusing to most users. The other challenge could be with end user devices. If your users will be using headsets they’ll be fine, however if you have to deploy Teams IP Phones you’ll need to ensure those are in place before you assign numbers. You may not be able to place those phones and connect them to a PoE ethernet run without first unplugging the old phone… which means they won’t receive calls from the PSTN.
When to do the number assigment
I recommend assigning the phone numbers a few hours before the port date/time. I also recommend scheduling a port for either first thing in the morning or at the end of the work day, whereever possible. If the port is scheduled for first thing in the morning, numbers can be assigned the night before. If the port is scheduled for last thing in the day, you can assign the numbers right before the port and you’ll have some buffer time should the assignment take a while.
In Teams Admin Center under Voice > Phone Numbers, you’re presenting with a table of your numbers and various bits of information about them, like who (or what) the number is assigned to. You also are shown the Type of service, License usages, and Available usages.
Type of service is Geographic for “regular” phone numbers. The other common type you’ll see here is toll free.
Available usages shows what that number can be used for within Teams. Options are typically user, conference, and voice app. User is your users, common area phones, SIP gateway devices like paging systems and things like MTR phone numbers. Voice app is typically a resource account for Teams auto attendants and call queues, or for 3rd party voice apps like contact center offerings from Landis, or a customer voice app/bot that you’ve developed. Conference is for dial-in conferencing. While Teams does provide shared dialin numbers for conferencing, some organizations want to use an existing vanity number, or want a number in a location that Microsoft doesn’t provide a number in.
After a port-in of numbers from another carrier, the numbers are set to User for the licensed usage. They are unable to be assigned to a resource account as those are a voice app. That’s not a problem, it’s a simple matter to change. First, select the number – sorry, just one at a time! – and then click the “Change usage” button:
Over on the right you’ll get a fly out with a drop-down. The drop-down has the usages that you can change the number to. Pick what you’re after and you are done!
I appreciate that the current usage of the number doesn’t appear in the drop-down. If you’re in a hurry to get your organization’s main number converted to voice app and assigned to the resource account for an auto attendant, it’s nice to have it a little more fool proof.
Once your port request order is approved, you should see your numbers available in TAC, despite them still “belonging” to the current/old/losing carrier. This is typically days before the actual port. At this point, you are able to change number usage and assign the numbers. In most cases, you’ll be able to call out from those numbers and to call them internally. You won’t yet be able to receive calls from outside your organization as those will still be routed to the losing carrier. It’s worthwhile to change number usages at this point, to reduce the amount of activity you have to do at port time.
If you are using Direct Routing, you do not need to worry about this setting.
Polices are used throughout Teams for assigning settings to users, and in some special cases, to Network Topology sites. There are a few methods to apply user based policies, each with their own benefits and drawbacks.
With Teams policies, only one policy is applied, and the entire policy is applied. This is different than other methods like Group Policy or NTFS permissions.
If you have not created any new policies, then only the default policy, called the Global policy, applies. This is the lowest precedence policy, Global settings are applied only if no other policy has already been applied.
The other policy is a user-assigned policy. It is applied as the name applies, directly to a user. If a user has a user-assigned policy, its settings will have precedence over a Global policy.
In certain cases, policies can also be assigned to Network Topology sites. There are three such policies:
These are the Network Roaming Policy, Emergency Calling Policy, and Emergency Call Routing Policy. Note that these policies can also be user-assigned and have Global/Default policies. These site-assigned policies exist because users may work from multiple sites, and for these three policies it makes sense to have them be site-assigned. A site-assigned policy takes precedence over a user-assigned policy and a global policy.
Let’s consider the Network roaming policy. You might be familiar with the term “call admission control”, that’s what’s happening here:
There are just two settings here. One is to allow Video conferencing – or to turn video off. The other is to set a maximum bit rate. The bit rate setting has an info icon beside it that is informative:
A bitrate entered here will affect audio and video, including video content shared in meetings. When a network roaming policy is applied to a site, it applies to every user present in that site. Each user may use up to the bit rate specified in the policy – this is not a “per site” restriction, it is a “per user at this site” restriction.
The idea behind this policy is that if you have a network site with low available bandwidth, you can restrict the amount that a Teams user’s audio and video can consume when they “roam” to that site. This will scale back resolution, refresh rate, video features, and codecs selected to stay under the cap. When a user “roams” to a different site, this policy no longer applies.
Like other policies, their is a Global policy. You shouldn’t modify this unless your entire network has terribly low available bandwidth. You can also assign a policy to a user, causing it to always take effect. There’s no practical reason that I can think of to do this outside of perhaps an April Fools prank. Nonetheless, it follows the same model as any other policy.
The Emergency Calling Policy and Emergency Call Routing Policy are where you configure various options for handling emergency calls. How you want these handled will most often be different for each site. Global and site assigned policies are both valid here, and commonly used together. Global policies act as a “catch all” for remote users, or in the event of a misconfiguration of the bits that establish which site a Teams device is in. In some cases it may be possible to use just Global policies here. It would be very rare to assign these policies directly to users. There is a requirement for that with certain shared calling configurations.
To summarize this first section, policies can be assigned Globally, to a site in certain cases, or directly to a user. Policies assigned to a site will take precedence over those assigned to a user, which in turn take precedence over a global policy.
But wait, there’s more!
With just these options, it could be painful to administer policy assignments. Imagine yourself as the Teams admin responsible for policies in a global organization with 50,000 users. You would invariably have different policies for different regions and groups of users. It would be ugly to have to assign policies directly to every single user!
There are two ways of making this easier. The first is Policy Packages. These are a “bundle” of policies that can be assigned versus the individual policies. This helps keep all of the users who need a set of policies aligned with the same policies. I see policy packages used extensively in education and healthcare. Microsoft has a number of policy packages pre-defined:
The second way of making things easier is with Group Assigned Policies. Instead of assigning policies directly to a user, policies can instead be assigned to a group. Members of that group then receive the policy.
There’s an issue that needs to be addressed with this concept, and that is “what happens when a user is in multiple groups with conflicting policies”. The answer is simple, the list of group assigned policies is ranked, and the highest-priority/lowest-numbered one is what is assigned. This can get a bit messy when your list of policies grows large. Good naming standards are helpful here.
When you view a policy, you can see if it is assigned to groups. There’s a tab here where you create the group policy assignment.
Now if you’re really cool, you’ll use groups to assign policy packages!
Drop me a comment if there’s an area of Teams policies that you’d like me to cover in more depth.
In my last post I talked about changing the “organization name” reflected in an emergency address. If you try to do this in Teams Admin Center, you’ll run into a brick wall:
Note the little “Why can’t I change this address?” at the bottom. Well, the good news is that you can indeed change it, but you need to use PowerShell.
First, head back to the Emergency Addresses page in Teams Admin Center and make note of the Location ID
We don’t want to modify the Location, we want to modify the Emergency Address. However, the Civic Address ID that represents the emergency address is no longer displayed in TAC. So, we’ll connect some dots in PowerShell to get what we’re after.
Now we have our CivicAddressID and can use that to view our Emergency Address/Civic Address
And here we can see our Organization Name/Company Name (sooo many things with different names in TAC vs PowerShell vs M365 Admin Center…)
Now, we want to ensure we’re making changes to the correct object. So hit the up arrow and edit that get- command to be a set- command, and add -CompanyName and the new name string
Triple check you have the correct Civic Address ID, then hit enter. Success!
And we see the same in TAC
You can use the same process to change most of the other fields that you see when you did the Get-CsOnlineLisCivicAddress. This is great for fixing typos, updating addresses or names, or just tweaking capitalization in spots because not having everything is painful to you.
It took me more than a few minutes to come up with that title, and I still don’t think it says what I want it to. Hopefully search engines piece things together for everyone!
A new feature has snuck out to the Microsoft 365 Admin Center. It’s not a big one, but it sure is a useful one. If you add a Calling Plan license to a user, you will now have the ability to assign a phone number to that user, right in M365 Admin Center.
You can also acquire a new number if you need to, and further, you can create a new emergency address if this is the first number for a location.
This is awesome, I think it cuts out a couple thousand mouse clicks through Teams Admin Center to accomplish the same task. It’s even better when licensing multiple users.
Here’s this new feature in action. In this scenario, I need a phone number for a new location so I need to also create a new emergency address.
The first step is to license the user. In this case, adding a PAYG Calling Plan:
Once that’s done, we get a yellow caution bar advising that they can’t yet make or receive calls. I wish the button on the right used the same language as the text “set up their phone number” vs “assign their phone number”. In any case, click the “Assign phone number” button.
Now we can either select an existing emergency address using the drop down, or we can select Add a new address. Let’s add a new one.
First, let’s clear up what an emergency address is. It’s really two things here.
One, Microsoft is you phone company, and it’s a requirement that every number have a static “emergency address”, sometimes referred to as a “service address”. This is not the address that the bill is sent to, aka the billing address. And of course, Teams is capable of dynamic emergency calling, where the location of the device placing the emergency call is reported instead of this static address.
Two, Microsoft needs to know what area code and city to select phone numbers from, either numbers that you already have or new numbers.
Here are the fields that you need to complete, and one optional field.
The “Place name or description” isn’t very well described here. Typically this would be a suite or unit number, such as “Suite 1601”. It could also be something like “Council Chambers” or “Electrical room”. It’s the “dispatchable location” that tells the emergency services where to go once they’ve pulled up to the front door. You should only leave this blank if the address provides all of the details needed to reach the location of the caller, such as a small building with just one company in it.
Like this:
Now you need to add the latitude and longitude. This help remove ambiguous things that come up with addresses, like “1501 West Street, North East Edmonton”.
Click Confirm address and then review everything on the next screen. Now you’re offered a phone number to assign to the user. My tenant didn’t have any numbers from that location, so Microsoft is offering one here, they’d held it for 15 minutes. Note that you don’t get to pick your number from Microsoft. If you really, truly need a certain number, your best bet is to acquire it through an existing telco – possibly a mobile provider – and then port it to Microsoft. (But honestly, that’s pretty 1998, isn’t it?)
Hit Finish assigning, and you’re done!
Here’s something to watch for with the process of creating a new Emergency address in this process. If you look at the address in Teams Admin Center after it’s created, you’ll see this:
Notice the organization name. It’s important here as it is included as part of the address information provided to first responders. My recommendation is that the “Organization name” here reflect what on your signage. “Tom’s Towing” is good, “81563534 Canada Ltd” is not so useful.
In this case, it’s picked my tenant name and all is well. However, if you organization has a tenant name that doesn’t reflect your organization’s name, you’ll need to head to PowerShell and change that. For example, I’ve seen things like “TimsTrucks” as an tenant name, but the organization is now “Smith Logistics”.
And lastly, if you’re the person in charge of your emergency addresses, you’ll want to keep an eye out for new ones popping up. Do some periodic cleanup to get rid of incorrect or unused addresses. Do some investigation and find out why 9999 Columbia Street showed up, when that’s actually not the address of your buiding in that city.
Should an organization need to deploy QoS in their environment for Teams, you’ll need to push settings out to your clients. Intune is the way to go, unless you’re still in the Active Directory phase of things and using Group Policy.
Well, there’s no point in me explaining how to do this, as Edgar Avellan has already done everything:
Now, a couple of caveats. First, I’ve long been a fan of NOT configuring QoS unless you are having call quality issues and can see issues in the Call Quality Dashboard or your network gear. Why not?
Most modern networks have more than enough bandwidth. QoS only helps when their is congestion.
There’s no QoS on the Internet. Only on your LAN/WAN.
You need to control the endpoint – byod devices won’t get prioritized
Okay, not 100% true. You could have your network gear mark traffic based on the source port number. However, this WILL lead to non-Teams traffic being marked. Marking the traffic on the client usually means that you can specific the executable name “ms-teams.exe” to avoid this. You will, however, need to use this approach to classify and tag traffic that isn’t generated from your managed endpoints:
Do you have a plan for your wifi? How much of your traffic in your offices is connected wirelessly vs wired?
Do you have a plan for marking inbound traffic? You need a firewall – or a router just past it – that can apply DSCP tags, as the traffic inbound from the Internet won’t have them. Otherwise, you’re only tagging outbound traffic.
What about non-Windows devices: web clients, Mac clients, and smart phones? Do you have control over these devices, and the ability to manage and monitor?
How about VPNs, SASE, ZTNA? What impact do they have on your DSCP markings? Do you enforce “always on”, so that traffic from a machine on your LAN in your office is immediately tunnelled out to the VPN/SASE/ETC device, even if it you’re communicating with someone who is also on your LAN in one of your offices?
If you’re thinking of doing QoS, your first step is to find evidence that says you need to do it (and user complaints about bad calls aren’t sufficient here). Then, plan, plan, plan, plan! Implementation and operations are significantly bigger that they appear at first glance.
When you’re configuring a SIP trunk to an SBC, there are a couple of network setup steps that you’ll need to implement to prevent pain and suffering down the road. That pain and suffering might be “just doesn’t work” or it could be “intermittent interruptions”.
If your SBC is behind a firewall, you’ll need to ensure that firewall isn’t killing things that it shouldn’t. This means turning off “deep packet inspection”, “SIP Session Helpers”, and “Application Layer Gateways”. The last two are really meant for SIP phones outside the firewall accessing a PBX inside the firewall. They can (and do) work well for that. Deep packet inspection has two main challenges. First, every major firewall that I’ve met is too dumb to understand SIP, and it breaks things. Second, it adds latency to real-time communications. That may not be an issue if everything else in the network path is adding minimal latency, but it can add enough to be a problem.
The solution here is to disable this functionality, and to use the IP addresses and ports associated with the SBC and SIP trunk provider to allow or deny traffic. (You should be doing this anyway – don’t depend on your cool, smart firewall when you can just outright block a ton of potential issues by IP address allow/deny).
If you are a security person and you’re freaking out over this outlandish proposal and insisting that you be able to deep scan everything, take a minute here to consider this: The SBC is a better SIP security device that your firewall will ever be. SIP security is part of its job! The carrier you are connecting to is very interested in the security of their end of that connection, as the most likely security issue is a bad actor making use of their SIP services for free.
Next, let’s talk NAT. Your firewall is likely translating your internal address space (10.10.10.27 for example) to a public IP assigned by your ISP (203.0.113.12 for example). This changes the “outside” of the IP packets, but doesn’t touch anything inside the packets. That’s fine for most things, but it can really break SIP.
The inside of a SIP packet has IP address information contained in it, too – that 10.10.10.27 is there. However, the SIP provider you’re passing this packet along to can’t access that, it is an internal IP range on your network (and since I used a popular range in this example, likely on many other networks too). The IP address inside the packet must also be translated to 203.0.113.12.
This is what firewalls are terrible at. They don’t speak SIP, they don’t know how to do this. SIP Session Helpers and Application Layer Gateways can take care of this for Internet endpoints accessing an internal PBX, but fail miserably on SIP trunks.
Good news, however. Your SBC has the capability to deal with this problem. There’s a field in the NAT configuration of your SBC for you to input the public IP (203.0.113.12) that your firewall will translate its traffic into. The SBC will send packets with the 10.10.10.27 replaced with 203.0.113.12 inside the packet. It leaves the 10.10.10.27 in place on the outside, however, as this is needed for the internal network path from your SBC to your firewall, which then translates this part.
There are a handful of license types for Microsoft Teams voice functionality. This seems painful, but really, it’s to your benefit – the licenses are “bundles” of features that you need for a specific function: user, auto attendant, shared lunchroom phone, etc. So, let’s dive in.
Throughout, I’ll use the full name “Microsoft Teams Room Pro” that you’d expect to see in the licensing tab of M365 Admin Center. I don’t stick formal names, but it feels like I should here if helping you find the right license.
Update: some name changes (surprise!) so I’ve updated this post. Update2: Where you see “E5”, that same bit applies to E7.
Microsoft Teams Phone Standard
This one used to be Cloud PBX, then Phone System. It’s what gives your Teams client a dial pad, the ability to dial out and receive calls from the PBX, and a bunch of functions you’d find in a phone system – caller ID, hold music, transfer, etc. Without this license, you can only do Teams-to-Teams voice chats and meetings.
This license is included in a number of “bundles” that I spoke of. It is included in E5/A5/G5, Shared Space, Resource Account, Microsoft Teams Rooms Pro. It is not included in E3/A3/G3 and below. If you’re running 3’s as your main license and adding Teams voice functionality, it might be time to consider bumping up to 5 (and 7!).
Calling Plans
These are really a family of licenses, they get you a phone number and dial tone from Microsoft. That last bit is important. This is “Microsoft the telco, like AT&T”, not “Microsoft the company that wrote Teams”. I’m not saying here that Microsoft is two companies, I’m only trying to demonstrate that Calling Plans are a “telco” thing and not a “Teams software” thing. Calling plans come in “minutes per user/month/country”, as well as pay as you go.
If you are using Operator Connect or Direct Routing, you do not need anything in the Calling Plan family of licenses.
Microsoft Teams Shared Space
These used to be called Shared Device, and CAP or Common Area Phone before that. From the voice perspective, this is a phone that isn’t assigned to a user. Rather, it’s assigned to a place or a role, eg “Lunch Room”, “Reception Courtesy”, “Duty Chief”. It also applies to a host of other things, mostly around Microsoft Places.
Microsoft Teams Phone Resource Account
This license solves the problem of “I have an Auto Attendant, how do I assign it a phone number so people can call it? And how do I assign it a UPN so that my Teams users can click-to-call it in a Teams-to-Teams call”. Think of this as a special type of user license that is severely restricted. It can’t actually log on, it doesn’t get a mailbox or SharePoint or Intune or whatever. The sole purpose of a resource accounts is to plug a phone number and UPN into your auto attendant (or call queue, or other custom voice app) – nothing more.
A resource account is based on a user account. Microsoft had a choice: copy the user account code and massively customize it to do everything a resource account needs without a license, or craft a purpose-built license that takes care of that, without requiring the rewrite. They chose the latter. That license is the Microsoft Teams Resource Account license. It is the ONLY license that you should assign to a resource account other than adding something from the Calling Plan family, should you be using Microsoft Calling Plans for your dial tone & phone numbers. In Teams Admin Center, resource accounts have their own section apart from users. In PowerShell, you’ll mostly use “user” commandlets.
And on the plus side? The license is completely free. You obtain it the same way you do any other license, but it’s $0. You need one of these for each phone number or UPN that you want to use to enable an auto attendant, call queue, or voice app to receive phone calls. (Note: if you have an auto attendant that forwards the caller off to a call queue, but you do not want that call queue to be called directly, you need only license the auto attendant. The call queue cannot be called directly, nor does it appear in the directory in Teams).
Microsoft Teams Audio Conferencing
This license allows the user to create a Teams meeting that allows dial-in capabilities. This is old school dial-in to a conference bridge. Those who dial in do not require this license, only the meeting organizer. It also allows dial out from the meeting to a phone number to add them to the meeting. This is an add-on, but it feels like it’s bundled with an awful lot of other licenses.
Did I miss anything? Hit me up in the comments if you’d like me to add or clarify something.
No, they’re not, and yes this is the first time I’ve started a post with a meme.
What am I talking about? I was working with a customer recently who needed to configure Teams to play something other than the “spa tunes” default hold music. In particular, the scenario was a call that comes to a call queue, is answered by an agent, and is then transferred elsewhere.
Here’s the Call Queue “Greeting and music” configuration with “Music on hold”:
And here’s the Call hold settings, with hold music:
And looking at these two screenshots, it’s not immediately clear what music/audio file (it doesn’t have to be music!) applies where/when.
Here’s the flow. When the caller first hits the Call Queue, they will hear the “Greeting” in its entirety. Then, they are placed into the queue and will hear the “Music on hold” while agents’ phones ring. Once the agent answers and begins the transfer process, the audio file from the “Call hold section” comes into play. That’s because the first part of a call transfer is to put the caller on hold.
If the Call Queue settings page referred instead to “queue wait music” and the Call hold settings referred to “hold music”, I think this would be clearer. It could also be helpful if there were info/tips on each page that explain when that music/file would be played.
Teams emergency call notifications meet all of the requirements of Kari’s Law, but they’re not super flexible. Microsoft received a bunch of feedback on this, and have a great solution.
At the most basic level of notification, you send a Teams chat message to a group of people. You can then layer on conferencing those same people into the emergency call, with or without the ability to unmute themselves. The users conferenced into the emergency call are the same list of users who receive the text notification, which isn’t great in some circumstances. For example, I would like to notify the intern sitting at the reception desk that an emergency call has been placed, but I would not want to conference them into a live emergency call. Anyone being conferenced in should be in the security department or similar, and not more “pedestrian” roles in the organization.
I recommend against allowing the ability to unmute, in most circumstances. The very last thing that a busy emergency call taker wants/needs is somebody unexpected talking over them as they’re trying to get the right response rolling. Unmute may be beneficial to a well-trained group of people who know to use it very selectively. The rest of us can just call 911 from a different phone, talk to a different call taker, and provide any additional information.
There’s also the option to conference in just one external phone number (which can also be just one internal number), with no method for them to unmute. This is a good option for a security desk where the staff don’t have Teams clients, or for a mobile phone.
For a more complex scenario – chat message to these people, email to these other people, conference in these Teams users, flash a light – there was no option in Teams that supported them. If an organization was using Direct Routing, some emergency service providers could offer additional services, and some people figured out how to have SBCs trigger a web hook when an emergency call was placed.
Microsoft has recently announced a preview of Graph API, with details available here. This API will provide the same information that Teams provides in its notifications, as well as to emergency services. As I become aware of services and apps that can consume this information, I’ll add their details to this post.
It is not an “either/or” choice of using the API or notifications built into Teams. You can easily configure both, using Teams for basic notifications, and the Graph API (and supporting applications) for richer flexibility.
Bump in the net 