Understanding E911 in Microsoft Teams with Eric Marsi

Tom Arbuthnot: 0:05

This week on Teams Insider podcast, we have Eric Marsi. Eric is a multi time MVP and friend of the community, really, really deep on Skype, Teams and voice. And he takes us through E911 and E911 compliance. Really useful show. This is a regulatory requirement, so really important you understand it. And there are some key details here that Eric takes us through in a really easy to understand way. Thanks to Eric for the show and also many thanks to AVI SPL, the sponsor of this podcast. Really appreciate their support of Empowering Cloud. Hey everybody, welcome back to the pod. Excited for this one. This is one of the top videos on our community is a rule around E911. And I've been wanting to do a pod and kind of get into it for a while. So I reached out to Eric, who's a friend in the community. And he agreed. Not many people want to talk about E911 because it's quite specific. Eric, do you want to just introduce yourself? Give us a little bit of context.

Eric Marsi: 0:57

Sure thing. So my name is Eric MVP in the M365 apps and services space. And I'm also a senior Microsoft consultant for Converge once. Happy to be here. Thank you for having me. I appreciate Eric.

Tom Arbuthnot: 1:09

And your history is pretty interesting around the community. And you've been pretty hardcore in the hardware space, pretty hardcore in the Skype server space as well, but we're dragging you into the cloud. So I leave it

Eric Marsi: 1:18

surely slowly. I still run it. I still run Skype three pools.

Tom Arbuthnot: 1:22

Yeah, I think you're going to be the last multi pool Skype server instance running probably. Probably

Eric Marsi: 1:28

like,

Tom Arbuthnot: 1:29

you know, I'm on one. Let's start from the beginning. We're gonna take this from more of it. Obviously, you're in the U. S. From a U. S. Perspective. So first off, what is that?

Eric Marsi: 1:36

So you know, one is the way of locating where a user is at the time of placing a 911 call from their Microsoft Teams client or even beyond just Microsoft Teams. Any phone system that supports you 911 one. And it's more or less making sure that the person that's dialing 9 1 1, their location being sent to the public service answering point, or known as a PSAP, is the accurate location of the user and not something that's a few states over or completely unrelated to where they're located. Awesome. And this

Tom Arbuthnot: 2:03

is different around the world to the, some other countries have similar regulation, lots have none, but in, in America is very specific and it's even, Is it even slightly different state to

Eric Marsi: 2:13

state as I understand it? Correct, yeah. So every single state has their own individual laws. There are some states that just abide by the federal law, but there are some states that have way stricter 9 1 requirements on top of what the federal requirements are. The US as a whole has the strictest 911 laws out of any country. And so it's something that has to be looked into and made sure that the information being put into whatever telephony system you're building is 100 percent accurate because there's a lot of liabilities and other things in the background.

Tom Arbuthnot: 2:41

So, yeah. And rightly or wrongly, it's a legal requirement. So it'd be the same requirement on the Old system and moving to teams, but very often I see in projects as you move, that's a checkpoint for, Oh, okay, we really need to meet those requirements now. So often the bar goes up when you're moving to teams. I find

Eric Marsi: 3:00

correct. Yeah, a lot of times I will find pretty much I would say 90 percent of every customer that I migrated from the previous telephony system to Microsoft teams. Um, their old telephony system, it may have supported 911. They never deployed it. So you run these scenarios where like, okay, we need to get you to teams immediately, but we also need to make sure when we get you to teams, we've got everything built properly. So then that way you're compliant and that there's less of a liability issue in play there versus before. Awesome.

Tom Arbuthnot: 3:29

And so let's dig into how it works, because it's not just about what's in the box with teams. There are these E911 service providers. So how does that work alongside? I've got my telco, but I also need an E911 provider.

Eric Marsi: 3:42

So one of the vendors that I utilize pretty much for every Teams Voice project is Intrado. And Intrado has a service called ERS. I forgot what the actual acronym stands for, but just Intrado ERS. That's what you need to know. And whIntradoato provides is the connection point between you and your business with your telephony system and the local 911 PSAPs, those public service answering points. And so Intrado is the middleman. And so when we look at the team's configuration side of things, depending on how the call originates, how the location is learned depends on how that call flows through Intrado's network. As an example, just being quick to the point, if the location is learned dynamically from the database built into teams. The location, we know the address, we know you're at that specific spot, we're already, Intrado's design is to automatically forward you to the nearest PSAP. However, if you didn't enter a location, if you're working off site, uh, or you, you know, your location was learned via another means where it's not 100 percent accurate, Um, Intrado offers a global call center, which pretty much screens the call. And they'll either say, okay, is your, um, address what we see here, or is it something else? And then they get you to the nearest PSAP based on the information they collect from you on those calls. That's really what Intrado provides for your business. Um, when you're utilizing direct routing, uh, in Microsoft teams. And

5:01

that's

Tom Arbuthnot: 5:02

seems to be a requirement. So you couldn't do this natively without one of those. I think three are

Eric Marsi: 5:06

certified. Yeah, there's like Intrado. I think Red Sky bandwidth, I think is the other one. I don't know them off the top of my head, but.

Tom Arbuthnot: 5:13

No, I think you're there. I think you're there with them. Yeah. So that's interesting. So you jumped in there to dynamically discovered versus typing the address in. So that's right in old school phone system, right? The phone was physical, so we knew where the phone was. So that's pretty easy, right? In our team's world, the phone is Anywhere. The phone is a physical IP, but the phone is on my mobile. The phone is on my laptop. So how does teams deal with that?

Eric Marsi: 5:37

Yeah. So teams, um, is designed to be a dynamic, you know, one system, um, regardless if you're in the U S or not outside the U S there's, you know, different countries have different laws, but you know, it's not as strict as the U S. But inside the U S if you are, you know, if your business is fully inside the U S you want to make sure that you're deploying everything based on the, uh, two laws in the U S which is Carrie's law and Ray Baum's act without going to the details of those What happens in the background is teams has to determine your location based on the network and how you're connected into the environment. And so the first thing that teams looks at. It's like a if, and then an or, and then another and on top of that to be able to determine your location. First thing it looks at is what's known as a BSSID. Another acronym, don't know what it stands for, but I'll at least tell you what it is. So every wireless access point that you have in your organization has what's known as a base AP radio MAC address. This is a base MAC address that everything else is derived from on that access point. And while this changes from a manufacturer based on how it derives these, or depending on how many radios you have, it changes the requirements on what you have to actually put into teams. So as an example, you have one access point, you have two SSIDs. So maybe you have a corp network and you have a guest network. So very basic standards that you see in a lot of organizations.

Tom Arbuthnot: 6:54

And that could be the same SSID. I just looked it up as we were talking, it's a basic service set identifier, which I definitely knew as well. But you often have an SSID that spans many access points, but the BSSID is telling them which is your

Eric Marsi: 7:07

closest access point. Correct. That is that globally unique access point. So when you roam between them for that same SSID, it's what identifies, Hey, you're connected to this AP or connected to this other AP that has a higher signal strength. And so one access point, if you've got two SSIDs, so your corp network and your guest network, they usually have two radios. So a five gigahertz and a two gigahertz radio. Those two radios each have their own BSS IDs per SSID. So, general rule of thumb is that if you have two SSIDs, you have four BSS IDs for that one access point. Now, depending on the manufacturer, different manufacturers have different requirements. Uh, Cisco Meraki as an example. Every BSS ID is derived in a way that you have to add every single one to Teams per access point, which can get very clumbersome with, uh, data entry. But like a Cisco, uh, catalyst or Aaron at AP, you can just add in a single Mac address with a star at the end because the way that it derives the BSS IDs, but again, specifics based on manufacturer changes on. Yeah. So that's going to be more or less focused on your wireless clients. You build the BSS IDs into teams and when you build them into teams, there's two, um, terms you need to become familiar with one is known as a civic address. And one is known as a location. So the way to think about this is that every building in your organization that your company owns, rents, operates has to be built in as a civic address. And teams, the civic address and teams is the street address with latitude and longitude that says, this is where that building is in the world. Now, the civic address against the building, but then the locations within that are sublocations of that building. And so there's three big ways that you have to look at the building. If the building is a single floor where there's no basement, no, no attic, no, any, no possibility of there being multiple floors. It's one building, one floor, and that floor is less than 60, 000 square foot. You don't need a location because it's just that one physical building. But the moment that it's a shared building where there's different suites or multiple floors or whatever else you need to build locations in there. So typically a general rule of thumb is a location is more or less like a suite, a floor or something that is globally unique and identifying sublocations within one location so that you can get specific to every single part of that building. So as an example, if you have, um, an office space that you rent on the sixth floor, you would add a civic address in and you would add a one location that says sixth floor, something that is unique that says we are on the sixth sense. Now, again, the way you build these locations also is dependent on what is specific to your state and also federal law. General rule of thumb at the federal level in the United States is that if it's 60, 000 square foot or less, You can put that entire floor into Microsoft teams. If it's 60, 000 square foot or more, at that point, you have to go ahead and build multiple sub locations for that one floor. So that would be like six floor North, six floor West, six floor East. And something that divides that floor up into multiple sections. So that emergency services knows what side of what area that floor you are on. Some States take that all the way down to 40, 000 square foot. And there are, um, so you definitely want to check your local laws, check with your state to figure out what is specific to your state. Chicago, Illinois is a great example of that one that requires it to be 40, 000 foot max. So really, you have your civic addresses, you have your sublocations, and then those sublocations is where you're building all of that data into inside of Teams. So, as an example, going back to where we were talking about how we determine that location dynamically. If we start with the BSSIDs, we build those BSSIDs in for every access point that we know is on that specific floor in that specific part of the building. So, if you've got four floors in the building, you would hopefully know where each one of those access points is so that you can build those BSSIDs into Teams, get that data up to the cloud. That covers your wireless clients. However, when you, we talk about wired clients, that's where things get a little bit different because when we have preexisting networks that are built, typically we run into where we've got subnets to span multiple floors of that building. So it's not something that we easily just identify and say, okay, we're going to match by in the subnet. We're going to call it a day. So before we even get to matching a subnet, uh, for the building, we then go into what's known as a switch port slash switch chassis ID inside of teams. So it pulls two different bits of data and together utilizing LDP. So every switch has a base ethernet Mac address, like our access points have a base AP Mac address. We also have our switches that have a base ethernet MAC address. So every port, um, has its own Mac that's derived from that base MAC address. And that base MAC address is known as the switch chassis ID. So that is what identifies that switch on your network. Now, utilizing the LDP protocol, that's link layer discovery protocol. The Windows PC, the Mac client, as an example, can determine what port and what switch chassis ID is connected to. If LDP is enabled in your network, as an example, if you've got a 48 port switch and let's just say that 48 port switch has the first 24 ports assigned to the third floor and the second, the last 24 ports assigned to the fourth floor, you can build into teams and say, okay, ports one through 24 on floor three, ports 25 through 48 are on floor four. So when you plug in your computer to that and it does an LDP discovery request, it's going to come back and show that you are plugged into that port and therefore you should be tied to that floor in that building. So that is when you have a switch that is split between multiple floors where you have to identify where each port is. The problem with that is that can become very cumbersome. If you've got, let's just say you don't have anything contiguous where you've got ports 1, 3, 5. 10 and 12 on floor three can become very problematic because especially if you've got a network admin, maybe it's some, you know, lower level engineer that comes in there and, Oh, we just got to flip your port around. Now your location is not known well within the environment. The recommendation is that if you can get everybody on a specific floor to one switch chassis, do it. Because then also we have one entry then in teams, we're not managing 48 ports for one switch, we're just putting one entry inside of teams. And that's where we head into that third match, which is the third potential match, which is the switch chassis ID. So that's switch chassis ID, no port specific requirements. It's just every port on that switch is tied to that floor. So again, can you think of it like a flow chart? We're starting with the BSS ID. If we don't match there, we're going to the switch port. We don't match there. We're going to the switch chassis. The last thing that teams will attempt to match on is known as the subnet. So that's going to be your layer three subnet, your standard IP. Let's say 10, 10, zero, zero slash 22 standard subnet. If team sees that it's going to try to match that subnet to a location in teams. The problem with that again, is that it, a lot of times buildings are set up, their networks or where they span multiple floors, which can be very problematic and also not accurate as to where that person's location is. Okay. And so if you're building a brand new building and you're, let's say you're building a new corporate office and you're building into teams, make sure you build it to where you have a subnet per floor. And the reason why I like recommending that is that without having, without having a subnet per floor, you're relying on LLDP, a protocol that has to be fully working and fully validated in the environment protocols sometimes have failures and maybe your location can't be determined all that well. And so we're matching based on subnet. We're just pulling the network information of your computer or your device directly into teams. There's not outside

Tom Arbuthnot: 14:53

of E911. It makes the rest of our troubleshooting life so much easier around CQD and knowing where people are and all that good

Eric Marsi: 14:59

stuff. Correct. Seth. So there's other things, part of teams, which we'll get into here as well. That. Rely heavily on the subnet. And if you're not separating that by floor or everything else, it, it doesn't work in the other areas. Uh, LDP is more or less. I like looking at it as like a bandaid in a way it's not a bandaid, but it is a bandit in a way. Um, where it works for you now one, but it's not going to work for the other parts of the team's admin center. Now, all of this is great. We can match on each one of these four options, but teams will not just say you're at that specific building in your corporate office, your branch location, or anything, because there is an end statement here as well. You have to also match on the external private public IP, which is a subnet that you guys would maybe own and have that inside a team. So if you match on BSS ID, it also has to match. Your public external IP database that you build into teams as well. And we do that because here's a great example. Your home network, it uses a 192. 168. 0. 0 slash 24 subnet. General example, if one of your corporate networks uses 192. 168. 0. 0 slash 24. Am I at home or am I in the corporate office? So we want to make sure our external IP is matched there. Yeah. Or

Tom Arbuthnot: 16:08

you use all 10s internally, which is common for enterprise, but you go to visit somebody else's office and they're using 10s as well, right? Is it your office or their

Eric Marsi: 16:16

office? Correct. So this also brings up another fun scenario. A lot of organizations still utilize full tunnel VPNs. If you're using full tunnel VPNs, try to get off of it. All sorts of reasons for tons of reasons, but I'm organizations that use full tunnel VPNs. Your internet traffic is going all the way back to the corporate office before going out the connection. Now you have to be careful with how you configure, you know, wanted teams, because if you put that subnet, that, that VPN. Appliance is issuing out into teams. When everybody in the VPNs in one corporate office, even though they cross the entire world. So you have to be methodical and careful in how you add that in. The other exception is if you utilize any form of VDI, if you're using a virtual desktops, We need to make sure that the subnet that those servers are contained in are not added to teams, because again, you can remote desktop into that VDI infrastructure from anywhere in the world. And so we don't want to dynamically learn your address, um, from that, uh, connection. Makes sense. So. The data that we put into Teams is very important that we get that accurate the first time. There is no, let's go back and fix it. We want to make sure that we get that in there correctly the first time. We also want to make sure that we maintain that data. Network changes happen, access points die, switches die. New buildings get added to the infor to the um, network environment. We wanna make sure that we always keep that up to date. And so it's not just a building into teams and forgetting about it. We need to update our internal IT processes to be able to include adding changes to teams whenever there's a network level change like that. That is how we determine our location inside of teams. But there are some additional portions around dynamic emergency calling in teams. And there's the first thing that we're going to talk about is the emergency calling policies and teams. Emergency calling policies do two things. The first thing that they do is that they specify a group of users or user that are to be notified whenever somebody places a 911 call. The general rule of thumb is that we build an emergency calling policy for every site in the company so that maybe at least somebody at that site can be notified. That's somebody at that site placing that one call. That's like your

Tom Arbuthnot: 18:26

security, your front desk, your reception, especially in a big environment, right? You want the reception or security to know they're expecting some potential inbound. I'm on one who that is and

Eric Marsi: 18:37

where that is as well. Correct. Yeah. So in teams, what will happen is by default, it will send a notification. So it creates kind of a group chat in a way inside of teams, a high priority one that says so and so placed emergency call from this phone number at this address on this specific floor. And then everybody in that group can see that message and see that that call was placed. The other policy there is a global policy. So the global policy is one that would affect any user where the location is not determined. So maybe you're a remote user, you're working from a Starbucks, you're working somewhere that your location was not learned, or even like a VDI as an example, where again, your location isn't dynamically learned. That's like a catch all type policy where anybody in that group is going to be receiving 911 notifications from people in those different scenarios. The other part that policy handles is what's known as external lookup mode. And this is a enable disable toggle switch. And what this toggle switch does is when you are not in a corporate office, External lookup mode allows the team's client to utilize Windows location services and also manual address entry within the team's client to be able to say I'm at this address. I'm working remote. Here's my address. Confirm it. And that's pretty much the one of the big toggle switches we want to make sure that we have enabled in the team's environment to really make sure that E9 1 is compliant with US law. And so that's kind of, you know, I wanted teams that are very high, but also a little bit of in depth. I know. I think you've explained it

Tom Arbuthnot: 20:04

really well there. And so, so, so if I'm in the Starbucks scenario, it's not going to map obviously to the subnets we pre mapped. It'll ask me for the address, but am I right in saying then the teams will then cash that locally? So it's not going to, if I go to the same Starbucks every other day, it's not going to keep hassling me at that point in time.

Eric Marsi: 20:20

Sometimes it will, sometimes it won't. I have noticed with the new teams client. So I teach you that one. Um, is that sometimes it does clear that cache. Uh, interesting. So your results may vary. Yeah. Well, at least the cloud things change. Yeah, for sure. So your results may vary. And the reason why I think they may have switched to doing a methodology like that to where it's not just caching location is. Maybe somehow your network at home is matching that Starbucks in some way or another where it's something changes. We don't want to say that you're at Starbucks still. We want teams to erase the address and either send no address or an estimated address based on windows location services.

Tom Arbuthnot: 21:00

Awesome. So if you're a customer and either you've got teams, you're about to deploy teams important to put some time aside to properly map out physical addresses. And also then you say the network, the switching the APS, there's a significant amount of project work to do that. And then, as you said, make that part of the change control process because it will change like switches go new offices come and go, Okay. You'll be to be legally compliant. It's not an option. You have to stay on top

Eric Marsi: 21:27

of that stuff. Correct. And I will say the biggest holdup for any team's voice project is always E911. And the reason why is that I cannot, as a consultant, legally enable a user for a team's voice for pilot. Or anything until that, you know, one data is in there, because if you place a now one call and you do not get connected to the emergency services, even if it's a pilot phone system, there are legal issues that can come up for both the implementation consultant and for the organization that is running that phone system. There's been multiple cases in the U. S. where people have been tried individually and also found guilty for misconfiguration. And it's something that as a consultant, you have to make sure you're mitigating risk. And mitigating the possibility that somebody who's enabled for a phone system without proper E911 isn't, you know, going to go without emergency service. Yeah, that's a really

Tom Arbuthnot: 22:18

good tip. Actually, on the consulting side is document all this process as well, because you're going to leave the project, right? And things are going to change. So showing it was configured correctly at time of deploy is going to be really important.

Eric Marsi: 22:30

And I typically recommend the moment that you're done with the project, if you still have access to the tenant, make sure you make a backup of the emergency configuration in the tenant. Because it's more or less, here's how it was when I was finished. Here's my moment in time. So it's a cover your butt type thing. It's, it's just something that I always do for every project because we want to make sure that if something were to come up, knock on wood, we're also protected as a consultant in that regard. Awesome.

Tom Arbuthnot: 22:57

Eric, you've explained that so well. Thanks very much for joining the pod. Um, just give us another kind of, where are you, the blog, the contact details, how can we get in

Eric Marsi: 23:04

touch with you? For sure. So I'm on my website, ericMarsi. com I post a lot of different code snippets, PowerShell scripts. One of my favorite PowerShell scripts is my Teams user provisioning script. So if you guys are ever enabling bulky number of Teams users, that is my go to that I use for every customer. Available on Twitter, Eric Marsi, YouTube, Eric Marsi, pretty much simple usernames across the board. Awesome. Thanks, Eric. Appreciate joining us. Thank you guys. I appreciate it for having me.