Emergency Calling: Trusted IP Addresses

When you’re configuring Microsoft Teams emergency calling, there are two end-user experiences. One is where Teams automatically establishes where the user is, based on network information that you’ve configured in Teams. The other is where the client depends on the OS location services and/or the user for a physical address.

For Teams to automatically establish your location, there are a number of pieces of network information that are required. The first of these is what Teams calls a “Trusted IP Address”. That’s maybe not the clearest name, but to be fair the name would get pretty huge if it was any more description.

A Trusted IP Address is any of your organizations public IP addresses that are dedicated, typically statically assigned. When a Teams client accesses Teams using one of these public IPs, Teams can trust that your client is inside your network. There are a few key points here:

Dedicated – The address cannot be shared like some cloud security services do, nor can it be dynamic and change at the whim of your ISP. Fixed IP addresses are typical, though we do sometimes see DHCP assigned “fixed” addresses.

Any – Yes any. Configure the entire range in Teams, not just one IP that clients typically use. This saves your bacon should the firewall guys change which IP clients egress from. It also means you’re covered if someone does something weird like plugging a phone into the server VLAN in the server room.

Trusted IP addresses are configured in TAC under Locations, Network Topology, Trusted IPs. If you click add, the dialog looks something like this:

Pretty straight forward! In the description field, put something meaningful to human. This has nothing to do with your location for emergency calling, but something meaningful like I’ve shown above is very helpful once you have more than one Trusted IP range.

If you’re a PowerShell fan, check out New-CsTenantTrustedIPAddress.

Note that your organization may already have assembled a nice list of these addresses in Azure for Named Locations in the MFA/Condition Access settings. You can spot-test if you’ve got an address in your list by having someone in a site browse to https://www.whatismyip.com. If their public IP address isn’t listed as a Trusted IP Address, you should first investigate if it meets the “dedicated” criteria above, then add it to the Trusted IP Address list.

I’ve been asked “If we monitor our dynamic public IP address for changes, can’t we just have a script run to update that in Teams?”. Well yes you could, except there will be a period of time for the IP change to work its way through Teams and down to all of the clients that require it. So, don’t do this. Instead, sites with dynamic public IP addresses will need to use the “work from home” or “External location lookup mode” as it’s more properly called. I’ve already posted a bit about this function, stay tuned for more.

Office 365 is now Microsoft 365 – Business Voice Changes

It looks like it’s time to rename something at Microsoft again. Today’s change is Office 365 becoming Microsoft 365, especially around the Business plans that Business Voice packages work with, the first three on the list:


Despite some possibility for confusion with the “Premium” moniker shifting spots, I’m please to see “Basic, Standard, Premium”, which makes far more sense than “Essentials, Premium, Business”.

Remember that you can add Microsoft 365 Business Voice calling plans to any plan that has Teams, with the exception of the F series of licenses for Frontline workers. You can add up to 300 to any organization, then you need to step any additional users up to the fully Cloud PBX and Calling Plans(or Direct Routing)

And finally, Business Voice is coming to the US market as of April 1, 2020.



Channel vs Chat Smackdown

During one of those long, philosophical conversations with a colleague, we were discussing governance/guidance around the usage of channels vs chats.  That spawned a few other conversations Here’s what we came up with:

First, chats will store documents in the OneDrive for Business of the person sharing the file. Channels will store documents in the SharePoint library for the Team/channel. That could be impactful if you are applying different retention policies on the Team/channel.

One very adamant opinion was that if there is a Team that the post could possibly belong to, it should be posted there so it can be seen by other Team members, whether or not it’s felt that this is something they “need” to see. This was described as “working out loud” in another discussion on private channels.

To the contrary, others felt that only very specific “final” content should be posted to a channel conversation, and that “drafts” or “side discussions” should take place in chats.

A rule of thumb that one person uses, is that if the conversation is private or can be “easily forgotten” about by the organization without any impact, then a chat is fine.

In a discussion, someone felt that chats were useful to make sure that someone responded to an item, and that things would get lost in a channel. While this could happen, it was pointed out that use of @mentions should work to prevent the conversation from getting lost. Others contributed that there were still some misgivings or reluctance to @mention people in Teams (or even Outlook). Finally, it was mentioned that threads in channels provide for a much more scalable multi-conversation experience than multiple chats.

Another person commented that a chat might be used if you think the person you are contacting has the answer to a question, which a channel would be for a multi-person “help me! Who knows XYZ”.

Finally, one person compared the difference to Facebook wall posts vs a Messenger chat.


Private Channel Use Cases

I love the concept of private channels. Working with Microsoft partners to deploy Teams solutions for customers, it’s a natural fit to have a Team per customer and then project based channels underneath that. Key staff from the customer are usually added as guests. With the release of private channels a few months ago, we can now have an “Internal Only” channel for discussions and drafts. Previously, we’d have to set up a second Team to achieve this same security boundary.

I was curious about what other organizations were using private channels for now that we’re a few months in. I posted on a social media, asked around at user groups, and here’s what I found:

For events, private channels can be used for speakers, or groups of speakers. Organizers or staff with different roles might have their own private channels. Overall though, Team members were able to access non-sensitive areas to promote “working out loud”, which serves as a sort of replacement for hallway conversations.

A managed services organization uses a Team per customer approach, with channels to organize various aspects of services for the customer. A private channel is used for internal conversations and planning.

Another use was to allow guests – from various partners or sub-contractors to interact with the main organization, or possibly each other, without needing to create numerous Teams. This approach does require that nearly every channel would be private, since there is no way to invite guests to just a channel.

Some organizations don’t feel that private channels are ready yet, and disable them. Reasons were around information protection and the ability to properly control their intellectual property. Others had concerns over “SharePoint Sprawl”, as each private channel gets its own site collection. Along these sames lines, one organization did like the lack of ability to “privatize” and “publicize” channels – they felt the lock-in once the channel was created could cause pain down the road if they made the wrong choice.

Others noted that some features, like Planner, are O365 group based and aren’t supported in private channels. Private channels (and “vanilla” channels) don’t have O365 groups, while the Team is O365 group based.

I think it’s fair to say that private channels are useful for many who need an administrative way to separate things. It’s likely also fair to say that private channels currently fall short of what other organizations need in terms of governance and compliance.



Calling Plans vs Direct Routing

A significant decision for any organization looking to deploy Teams voice workloads is whether they will use Calling Plans, Direct Routing, or some combination of the two. I couldn’t find a decent comparison between the options, so I wrote this one.

Calling Plans

Calling plans are where your PSTN calling services are provided by Microsoft. Essentially, Microsoft becomes your telco (telephone company). Currently Calling Plans are only available in less than a dozen major countries, with no plans to roll out service to more.

Direct Routing

Direct Routing is where you connect a certified SBC to Microsoft Teams, and then any service you wish can connect to the SBC. This includes PSTN access from a telco, but can also include other PBXs (I’m looking at you Avaya and Cisco) or analog devices like enterphones/door buzzers and overhead paging.

Mix and Match

A user can be assigned a phone number from Calling Plans or Direct Routing. This is a per-user decision – Kim in cube 123 can be on Calling Plans, while Sam in cube 124 is on Direct Routing.

Note here that we’re talking about the user’s phone number. A user who’s PSTN services are provided by Calling Plans can use Direct Routing to reach an Avaya system or analog devices. Calling Plan users cannot be reached via the Direct Routing trunk. If an Avaya user calls a Calling Plan user, the call must be routed via the PSTN.

Here are some other comparisons:

Calling Plan

Direct Routing

Pay per user, per month. Multiple plans available, minutes pooled between users in same country with same plan.

Usually pay per channel. Generally cheaper as more users are added.

No channel limit

Connections will have hard channel limits, or limits with burst capability, but are not unlimited

Users are allocated a number of minutes per month

Generally no minute limitation

Microsoft is your telco, billed with the rest of O365 services

Can use any telco service available, separate bill from the telco

Does not require additional equipment

Requires a Session Border Controller – purchase costs (physical or virtual), ongoing maintenance, channel limits, hosting costs (in your office, a datacenter, or cloud based). Multiple will be required for HA. Will need SBC located in same country as services (typically)

Some telcos offer hosted SBC services along with SIP trunk services.

Cannot provide access to on-prem equipment

Can provide access to on-prem equipment

May have limited advanced emergency calling capabilities for your country

Excellent options for emergency calling in all countries. Usually via SBC but sometimes via feature-rich 3rd party integration.

Limited number translation inbound/outbound

SBC provides for wide array of number translation options

Hit me up in the comments or @bumpinthenet on Twitter and let me know if I’ve missed anything!

Easy Deployment of the Teams Client

If your organization is running Skype for Business and you’re trying to establish the easiest method to install Teams for your users, there’s a super easy one.

Head to the Teams Admin Center, Org Wide Settings, and Teams Upgrade. Under App preferences, you’ll see an option to have the Teams app download in the background for SfB users:


Turning this “on” will cause the Teams client to be downloaded to the PCs. This only happens, however, if the Coexistence mode for the user is Teams Only, or since maybe that’s too late, if you’ve enabled “pending upgrade” notifications in the coexistence mode settings:


setting this to “on” places a yellow banner at the top of the Skype for Business client to notify the user that they will be upgraded to Teams soon. (Note that this option isn’t available in my screenshot since my Tenant is already in Teams Only)

Set Teams as Default Chat Client in Office

The Microsoft Office suite of clients offers integration with the default chat app, historically Skype for Business. This allows a user to interact with other users on that platform from within the office application, typically when co-editing, but largely throughout Outlook in features such as contact cards.


When you’re in a migration scenario, especially if you’re in Islands Mode, you’ll want to have Office pick one client over the other. You do this from within the Teams Client.

Click on your photo in the top right, then settings, then tick the box shown below: RegisterTeamsChatApp

And once you’re done this, make sure you restart Office. You may also need to wait a few minutes for the setting to take effect.

Note that if you switch to Teams-only mode, this setting is asserted for you – no need to manually configure it.


SBC Call Routing With Multiple Phone Systems

It’s not uncommon to have some combination of Skype for Business, Teams, and other PBXs in an organization, especially during migrations. One of the most challenging aspects in a scenario like this is maintaining call flow inbound from the PSTN, to the correct destination.

The magical way of doing this is to have contiguous blocks of numbers move from one platform to the next. In the real world, this almost never happens. That leaves us with the ugliness of static routing with a ton of rules to match the various number ranges and exceptions to them, or seeking some automated routing method.

One automated method is to have the SBC do a lookup in Active Directory, or some other LDAP directory. The SBC performs a lookup for the called number in a certain field, and can then look in a related field for that same user to understand the destination it should route the call to.

When a user is homed on a Skype for Business server, there phone number (lineURI) is stored in a field called msRTCSIP-LineURI. When an organization has just SfB server and another phone system, this allows for an easy “yes/no” decision. When there are multiple other phone systems, this task gets more challenging, as none of these other phone systems have a field like msRTCSIP-LineURI. This, by the way, includes Teams, which is rather ignorant of AD given that it’s a cloud platform.

There are a couple of solutions to this challenge. The first is for you to administratively populate the phone number and some sort of routing code/PBX identifier into unused fields in AD, AAD, or another LDAP platform. You can (but shouldn’t, yuck!) do this manually. Instead, populate these fields with scripting or another automated process. Now you can perform lookups and routing decisions based on the details that you’ve populated. However, you’ll need to keep these fields up-to-date with any adds/moves/changes to users and their numbers. This could mean that a user won’t receive their calls to the appropriate system until after an update completes.

A quick-and-dirty solution to this problem is to insert a series of alternate routes at the bottom of your routing table, that will try each of your phone systems in sequence, and if they receive a “404 not found”, they’ll roll to the next system:



Send to:


If LDAP Lookup says SfB

SfB Server


else if LDAP lookup says Cisco



else if LDAP Lookup says Avaya






If 404 return from Teams



If 404 returned from Avaya

SfB Server


If 404 returned from SfB Server


At first glance, this table seems to duplicate things – why do we need row 5 sending to the Avaya system if row 3 sends to Avaya? We wouldn’t, if row 3 was always able to receive up-to-date, perfectly synchronized lookup data, and there were never any system errors. That’s not reality though, so placing rules 5-7 at the bottom to simply brute-force try all the systems is a nice catch-all.

The “dirty” part of this “quick-and-dirty” solution is that the SBC logs will see the 404 failure each time these rules are used. You’ll need to tune your systems to not throw alarms and freak out due to those, and you’ll need to do a bit of extra work when you’re doing any syslogs or call traces. Of course, a spike in the appearance of 404s in your logs indicates something broken, so don’t ignore them completely.

The noise of all of these 404 entries is also why I’d never recommend only using this type of logic in a production environment. Performance really doesn’t take a hit, but good luck trying to troubleshoot calls when all you can see in your traces is 404s. However, doing pure brute-force can be useful during a rapid migration where LDAP lookup results will never stay in sync. You can also shift the priority of your rules in such a scenario so that the system likely to receive the most calls is at the top of the routing list.


Merging Multiple SfB On-Prem Orgs to One Tenant

Mergers, acquisitions, and other optimization activity can lead to a scenario where you want to merge multiple on-premises Skype for Business organizations into a single O365 Tenant, be that for Skype for Business Online or Teams.

Usually, the organization starts this process by synchronizing the on-prem AD contents from all organizations with Azure AD. This is followed by Exchange hybrid configuration. Both AD/AAD and Exchange support simultaneous hybrid configurations with multiple on-prem organizations.

Skype for Business, however, only permits one on-prem organization to be in a hybrid configuration at a time. The first organization is configured for hybrid, and the first SfBO or Teams users appear. Shortly after that, a report will come in to helpdesk about the online users not being able to reach the non-hybrid on-prem SfB organizations. Investigation shows that the on-prem users in the hybrid organizations can, however, reach these other organizations.

What’s going on can be a maddening process to unravel. For once, it’s not DNS or the network! When the AD/AAD sync is configured, the domain for the non-hybrid on-prem SfB organization is configured in the tenant (AD, Exchange, or a number of other reasons). This causes O365 to think that it now owns this domain for all O365 services, including SIP. The traffic to the user never leaves the hybrid organization via the federation processes, and results in a user not found scenario.

The solution is a simple one: Run the Disabled-CsOnlineSipDomain cmdlet against the non-hybrid on-prem SfB domain, from SfB online powershell. This tells O365 to ignore that domain for SIP purposes (but leave AD, Exchange, and others alone). Now the traffic will leave the organization and reach the intended user via federation. Problem solved!

Port Exhaustion

When you have devices on an internal network that access the Internet via NAT, your firewall with perform what’s called “Port Address Translation”, or PAT.

When a device sends IP packets, it has both a source and destination port. The destination port is whatever service you’re access (like 443 for HTTPS), and the OS is typically in charge of selecting a source port, though an application (like Teams) may specific source ports to use.

Since you’ll have a number of systems behind your firewall, there’s the possibility that some of them will select the same source port to use in a conversation. This is especially true with an application like Teams that allows a source port range to be selected to facilitate QoS. PAT translates these source ports (whether or not they’re conflicting) to an unused port on the firewalls outside IP.

Problems can arise, however, if there is sufficient traffic on your LAN to use up all of the ports on the outside of your firewall. This can be because of a specific application using numerous ports, numerous applications running on a system, the overall number of systems on the LAN, or usually some combination of all three. This is called port exhaustion, as the supply of available ports is exhausted. Any modern enterprise or business class firewall will let you monitor the number of ports being used, and the good ones will generate an alarm. If you’re encountering port exhaustion, the most practical solution is to add IP addresses to the pool of IP addresses that the firewall can use.

If this isn’t possible, a much less favourable solution is to adjust timeout values on the firewall. Be aware that this can lead to poor application performance as connections need to be re-established for the application to run, rather than being left open.

Finally, you can use this article for guidance on planning the number of users/applications/devices per IP address. Note that these are only guidance, and different applications will use ports differently. Monitoring is key!