Dynamic E911 in Microsoft Teams: The Complete Setup, Compliance, and Troubleshooting Guide

Emergency calling configuration is the one area of Teams voice where "we'll get to it later" can have life-or-death consequences. I've seen organizations deploy thousands of Teams Phone users with beautifully configured dial plans, voice routes, and policies — but with emergency calling configured as an afterthought. That's not just a compliance risk. It's a liability.

This guide covers everything: the regulatory landscape, how dynamic E911 actually works under the hood, step-by-step configuration for all three PSTN models, ERS provider setup, remote worker considerations, and a comprehensive troubleshooting section born from real deployment failures.

The Regulatory Landscape: Why This Isn't Optional

Kari's Law

Named after Kari Hunt, who was killed in a hotel room in 2013 while her daughter tried to call 911 but couldn't get through because the hotel phone system required dialing "9" first for an outside line. Kari's Law mandates:

Direct 911 dialing — No prefix required. Dialing 911 (or 999/112 in other countries) must work immediately from any endpoint.

Notification — A designated person at the facility must be notified when a 911 call is placed.

Callback capability — 911 dispatchers must be able to call back the caller.

RAY BAUM's Act (Section 506)

RAY BAUM's Act goes further than Kari's Law by requiring dispatchable location information:

Not just a building address — the specific floor, suite, room, or wing must be conveyed to the PSAP (Public Safety Answering Point)

Applies to all multi-line telephone systems, including cloud PBX (which includes Teams Phone)

FCC enforcement began January 6, 2022 for fixed phones, and January 6, 2025 for non-fixed devices

The Penalties

Non-compliance can result in fines up to $10,000 per violation plus $500 per day for ongoing violations. Beyond fines, if someone can't reach 911 or responders are sent to the wrong location because of improper configuration, the liability exposure is enormous.

How Dynamic E911 Works in Teams

The Location Detection Process

When a Teams user connects to the network, the Teams client performs location detection through this sequence:

Step 1: Network Discovery

The Teams client identifies its network connection — WiFi BSSID (access point MAC), Ethernet switch port/chassis ID, or IP subnet.

Step 2: Location Information Service (LIS) Query

The client sends its network identifiers to Microsoft's Location Information Service. The LIS checks against the network topology you've configured in your tenant.

Step 3: Location Match

If the LIS finds a match (e.g., "WiFi BSSID AA:BB:CC:DD:EE:FF = Building A, Floor 3, Room 301"), it returns the emergency address to the client.

Step 4: Location Applied

The Teams client stores the location and includes it in any emergency call as PIDF-LO (Presence Information Data Format - Location Object) data.

Network Element Priority

When multiple network elements match, Teams uses this priority order:

WiFi Access Point (BSSID) — Most granular, room-level accuracy

Ethernet Switch/Port — Floor or wing-level accuracy

IP Subnet — Building or site-level accuracy

Best practice: Always configure WiFi access points as your primary location source. Subnets are too broad for dispatchable location compliance in multi-floor buildings.

Configuration: Step by Step

Step 1: Define Emergency Addresses

Emergency addresses are the civic (street) addresses of your locations. Create these in Teams Admin Center or PowerShell:

Teams Admin Center:

Locations → Emergency Addresses → Add

PowerShell:

New-CsOnlineLisCivicAddress -HouseNumber "100" -StreetName "Main" -StreetSuffix "Street" -City "Seattle" -StateOrProvince "WA" -PostalCode "98101" -CountryOrRegion "US" -Description "HQ Building" -CompanyName "Contoso"

Important: Microsoft validates addresses against Azure Maps. If your address doesn't validate, you'll need to use the map pin-drop feature to set the geo coordinates manually.

Step 2: Define Places (Sub-locations)

Places are specific locations within a building — floors, wings, rooms. This is what makes your location "dispatchable" per RAY BAUM's Act.

New-CsOnlineLisLocation -CivicAddressId -Location "Floor 3, East Wing"

New-CsOnlineLisLocation -CivicAddressId -Location "Floor 5, Server Room"

New-CsOnlineLisLocation -CivicAddressId -Location "Building B, Loading Dock"

Step 3: Configure Network Elements

Map your physical network infrastructure to emergency locations:

WiFi Access Points (most accurate):

Set-CsOnlineLisWirelessAccessPoint -BSSID "AA:BB:CC:DD:EE:FF" -LocationId -Description "Floor 3 East AP1"

Ethernet Switches:

Set-CsOnlineLisSwitch -ChassisId "AB:CD:EF:01:23:45" -LocationId -Description "Floor 3 IDF Switch"

IP Subnets (least granular):

Set-CsOnlineLisSubnet -Subnet "10.10.30.0" -LocationId -Description "Floor 3 Subnet"

Step 4: Configure Trusted IP Addresses

Trusted IPs help Teams determine if a user is inside or outside your corporate network:

New-CsOnlineLisTrustedIP -IPAddress "203.0.113.50" -Description "HQ External IP"

Step 5: Emergency Calling Policy

Create a policy that defines notification behavior:

New-CsTeamsEmergencyCallingPolicy -Identity "HQ-E911-Policy" -Description "HQ Emergency Policy" -NotificationGroup "e911-security@contoso.com" -NotificationDialOutNumber "+14255551234" -NotificationMode "ConferenceMuted" -ExternalLocationLookupMode "Enabled"

NotificationMode options:

NotificationOnly — Send notification but don't conference security desk into the call

ConferenceMuted — Conference the security desk in, muted (recommended for most orgs)

ConferenceUnMuted — Conference the security desk in, unmuted (use for small facilities)

Step 6: Emergency Call Routing Policy (Direct Routing)

For Direct Routing, you must tell Teams how to route emergency calls:

New-CsTeamsEmergencyCallRoutingPolicy -Identity "DR-E911-Routing" -EmergencyNumbers @{add=New-CsTeamsEmergencyNumber -EmergencyDialString "911" -EmergencyDialMask "911" -OnlinePSTNUsage "E911-Usage"} -AllowEnhancedEmergencyServices $true

For 933 testing (Bandwidth):

Set-CsTeamsEmergencyCallRoutingPolicy -Identity "DR-E911-Routing" -EmergencyNumbers @{add=New-CsTeamsEmergencyNumber -EmergencyDialString "933" -EmergencyDialMask "933" -OnlinePSTNUsage "E911-Usage"}

Step 7: Assign Policies to Users

Grant-CsTeamsEmergencyCallingPolicy -Identity user@contoso.com -PolicyName "HQ-E911-Policy"

Grant-CsTeamsEmergencyCallRoutingPolicy -Identity user@contoso.com -PolicyName "DR-E911-Routing"

Or assign by network site for dynamic assignment.

ERS Providers vs ELIN: Which Approach?

Emergency Routing Service (ERS) Provider — The Modern Approach

An ERS provider is a cloud service that receives your 911 calls (with PIDF-LO location data) and routes them to the correct PSAP based on the caller's location. The two main providers are:

Bandwidth:

Most widely deployed ERS for Teams

Supports all Microsoft-certified SBCs

Provides 933 test calling capability

Dynamic Location Routing (DLR) technology

Requires PIDF-LO enabled on SBC and tenant

Intrado (now part of Lumen):

Long-standing E911 provider

Emergency Gateway (EGW) integration

Supports PowerShell-based sync with Teams

Strong in legacy PBX migration scenarios

ELIN (Emergency Location Identification Number) — The Legacy Approach

ELIN uses your SBC's built-in ELIN application to substitute the caller's number with a pre-provisioned ELIN associated with their location. The PSAP looks up the ELIN in the ALI (Automatic Location Identification) database to determine the caller's location.

When to use ELIN:

You already have an ELIN infrastructure from a legacy PBX

Your carrier doesn't support PIDF-LO

You're in a region without ERS provider coverage

When NOT to use ELIN:

New deployments — go with ERS

Multi-building campuses — ELIN scaling is painful

Remote/WFH users — ELIN can't handle dynamic locations

Calling Plans, Operator Connect, and Direct Routing: E911 Differences

Remote Workers and WFH: The Hard Problem

RAY BAUM's Act applies to remote workers too. If a Teams Phone user works from home and dials 911, the correct home address must be conveyed to the PSAP. This is one of the hardest problems in E911.

Option 1: User Self-Service Location (Recommended for WFH)

Enable ExternalLocationLookupMode in the emergency calling policy:

Set-CsTeamsEmergencyCallingPolicy -Identity "WFH-E911" -ExternalLocationLookupMode "Enabled"

With this enabled, when users are outside the corporate network, they can manually enter their emergency address in Teams Settings → Calls → Emergency Location. Teams prompts them to confirm or update their address periodically.

Option 2: VPN-Based Detection

If WFH users connect via VPN, subnet-based detection can work — but only with split-tunnel VPN. Full-tunnel VPN routes all traffic through the corporate network, making the user appear to be at HQ.

Recommendation: Use split-tunnel VPN for Teams traffic AND configure WiFi AP-based detection as primary. Subnet-based detection over VPN is unreliable.

Option 3: Device MAC Address Mapping

For users with corporate-issued devices on known home networks, you can map their home WiFi AP BSSID to their home address. This is labor-intensive but provides automatic detection.

The Gotchas Nobody Warns You About

Gotcha 1: Subnet Masks Matter

When you configure a subnet in LIS, the subnet mask determines what's matched. A /24 subnet (255.255.255.0) matches 254 hosts. If your floor uses a /22, you need to configure the correct prefix length. A mismatch means no location match.

Gotcha 2: WiFi BSSIDs Change

If you replace access points or change WiFi infrastructure, all your BSSID-to-location mappings break instantly. Build a process for updating LIS whenever network infrastructure changes.

Gotcha 3: Teams Desktop vs Mobile vs Web

Location detection behavior varies by client:

Desktop: Uses WiFi BSSID, switch, and subnet

Mobile: Uses device GPS/location services (may override LIS)

Web: Uses subnet only (no access to WiFi or switch info)

Gotcha 4: Guest and Shared Devices

Common area phones and meeting room devices need emergency addresses too. These are often overlooked because they don't have "users" — but they can dial 911.

Gotcha 5: Address Validation Failures

Azure Maps may not validate all addresses, especially in new developments, rural areas, or recently rezoned locations. Use the pin-drop feature and manually enter coordinates when validation fails.

Gotcha 6: Policy Propagation Delay

After assigning emergency policies, it can take 30-60 minutes for changes to take effect on the client. Don't test immediately after making changes.

Testing Your E911 Configuration

Test 1: Verify Location Detection

Connect to your corporate network (wired or WiFi)

Open Teams → Settings → Calls → Emergency Location

Verify the displayed address matches your expected location

Move to a different floor/building and verify the address updates

Test 2: 933 Test Call (Bandwidth ERS)

Ensure 933 is added as an emergency dial string in your routing policy

Dial 933 from Teams

Listen for the text-to-speech playback of your provisioned location

Verify the address, phone number, and user name are correct

Confirm notification was received by the security desk

Test 3: Notification Verification

Have someone place a test emergency call (use 933, not 911)

Verify the designated notification group received the alert

Verify the notification includes caller name, number, and location

If using ConferenceMuted, verify the security desk was conferenced in

Test 4: Remote Worker Testing

Disconnect from corporate network

Open Teams → Settings → Calls → Emergency Location

Enter a test home address

Verify the address is saved

Test with 933 to verify the address is conveyed correctly

PowerShell Quick Reference

View all emergency addresses:

Get-CsOnlineLisCivicAddress

View all network-to-location mappings:

Get-CsOnlineLisSubnet

Get-CsOnlineLisWirelessAccessPoint

Get-CsOnlineLisSwitch

View emergency policies:

Get-CsTeamsEmergencyCallingPolicy

Get-CsTeamsEmergencyCallRoutingPolicy

Check a user's emergency policy:

Get-CsOnlineUser -Identity user@contoso.com | Select EmergencyCallingPolicy, EmergencyCallRoutingPolicy

Bulk assign policy to all DR users:

Get-CsOnlineUser -Filter {EnterpriseVoiceEnabled -eq $true} | Grant-CsTeamsEmergencyCallingPolicy -PolicyName "E911-Policy"

Maintenance Checklist

Perform these checks quarterly:

Verify all buildings have current emergency addresses

Confirm new floors/rooms have Places defined

Update WiFi AP mappings after any network infrastructure changes

Test 933 from each major location

Verify notification recipients are still active employees

Review remote worker address compliance

Test from different client types (desktop, mobile, web)

Document any exceptions and remediation plans

Final Thoughts

Dynamic E911 in Microsoft Teams is technically straightforward but operationally demanding. The initial configuration is a one-time effort. The ongoing maintenance — keeping network mappings current, onboarding new locations, managing remote worker addresses, and periodic testing — is where most organizations fall behind.

My advice: treat E911 as a living system, not a set-and-forget configuration. Assign an owner. Build automated testing into your operations. And never, ever skip the testing phase.

Need help with your Teams voice deployment? SwiftM365 generates production-ready dial plans, voice routing policies, and complete voice configurations for 203 countries — including the emergency calling patterns that feed into your E911 routing.

---

Have questions about E911 configuration or compliance? Reach out via our feedback page or contact me directly at +91 9011070193.