In Microsoft Teams Phone, voice routing, dynamic emergency calling (E911), and bandwidth optimization policies depend critically on understanding a client’s physical location. Because corporate laptops frequently migrate between corporate campus headquarters, branch offices, home Wi-Fi networks, and public coffee shops, the Teams cloud architecture must reliably evaluate whether a client is connecting from within an enterprise managed network perimeter or via the unmanaged public internet. Microsoft Teams determines internal network boundaries by comparing the client’s public internet egress IP address against the tenant’s configured Trusted IP Addresses. Using the Microsoft Teams PowerShell module and the CsTenantTrustedIPAddress cmdlets, voice administrators can register, manage, and audit corporate public IP ranges to ensure flawless network roaming, location-based routing, and emergency compliance.
Understanding Teams Trusted IP Addresses and Network Topology
In the Teams Phone network topology hierarchy, Trusted IP Addresses represent the first line of boundary verification. Key architectural roles include:
- External Network Egress Matching: When a Teams desktop client or mobile device registers with Microsoft 365 services, the service inspects the client’s public source IP address. If this public IP matches an entry defined in
CsTenantTrustedIPAddress, Teams marks the client as connecting from an internal, corporate-managed network. - Prerequisite for Dynamic E911 and LIS: Location Information Server (LIS) sub-location mapping (matching internal subnet, BSSID, or Ethernet switch port) is evaluated only if the client’s public egress IP is recognized as a trusted IP. If the public IP is untrusted, Teams assumes the user is working off-premises.
- Location-Based Routing (LBR) Enforcement: LBR prevents toll bypass by enforcing geographic PSTN routing rules. If a user connects from an untrusted public IP, LBR restricts outbound PSTN calling to protect telecom compliance.
- Network Roaming Policies: Allows enterprise administrators to apply different bandwidth limits or disable video feeds based on whether the endpoint is on a trusted enterprise campus or remote network.
Prerequisites and PowerShell Session Initialisation
Managing trusted IP addresses requires the modern Microsoft Teams PowerShell module. Ensure your administrator account is assigned the Teams Administrator or Global Administrator role in Microsoft Entra ID.
Install or verify the latest Microsoft Teams module version:
Get-Module -ListAvailable -Name MicrosoftTeams
Install-Module -Name MicrosoftTeams -Scope CurrentUser -Repository PSGallery -Force
Connect to the Microsoft Teams tenant:
Connect-MicrosoftTeams
Confirm cmdlet availability across the tenant session:
Get-Command *TenantTrustedIPAddress*
Inspecting Existing Trusted IP Addresses
Before registering new corporate internet egress points, inspect the existing trusted IP addresses configured in your tenant.
Retrieve all configured trusted IP address objects:
Get-CsTenantTrustedIPAddress
Format the output as a table to view the IP addresses, CIDR prefix lengths, and descriptions clearly:
Get-CsTenantTrustedIPAddress | Format-Table Identity, IPAddress, MaskBits, Description
If the query returns no objects, the tenant has not yet established an enterprise network topology, meaning all client connections are currently evaluated as untrusted/remote.
Adding a Trusted IP Address Using New-CsTenantTrustedIPAddress
To register an enterprise internet breakout—such as a corporate proxy, NAT gateway, or firewall public IP—use the New-CsTenantTrustedIPAddress cmdlet.
To register a single public IPv4 egress address (using a /32 subnet mask):
New-CsTenantTrustedIPAddress -IPAddress "198.51.100.15" -MaskBits 32 -Description "Corporate Headquarters Primary NAT Gateway"
To register an entire contiguous block of public IPv4 addresses representing an enterprise data centre or campus egress range (e.g. a /28 CIDR block containing 16 addresses):
New-CsTenantTrustedIPAddress -IPAddress "203.0.113.0" -MaskBits 28 -Description "EMEA Regional Hub Internet Egress Pool"
To register a public IPv6 enterprise network prefix (e.g. a /64 prefix):
New-CsTenantTrustedIPAddress -IPAddress "2001:db8:abcd:0012::" -MaskBits 64 -Description "APAC Headquarters IPv6 Egress"
Confirm that the new IP ranges appear in the tenant directory:
Get-CsTenantTrustedIPAddress | Where-Object { $_.IPAddress -eq "198.51.100.15" } | Format-List
Modifying and Updating Trusted IP Descriptions
When ISP contracts change or network descriptions require updating, use Set-CsTenantTrustedIPAddress to modify existing objects.
Update the administrative description of an existing trusted IP record:
Set-CsTenantTrustedIPAddress -Identity "198.51.100.15" -Description "Corporate Headquarters Primary NAT Gateway - Fiber Link 1"
Note that if the actual IP address or subnet mask changes, the existing object should be removed and a new object registered with the updated address parameters.
Removing Obsolete Trusted IP Addresses
When decommissioning old internet service providers, retiring branch office routers, or consolidating data centres, remove obsolete trusted IP addresses to prevent orphaned network entries.
To remove a specific trusted IP object:
Remove-CsTenantTrustedIPAddress -Identity "198.51.100.15" -Confirm:$false
To verify the deletion:
Get-CsTenantTrustedIPAddress | Where-Object { $_.Identity -eq "198.51.100.15" }
Troubleshooting Trusted IP Evaluation and Network Roaming
When users report that location-based routing or emergency civic addresses fail to resolve, investigate these common architectural factors:
- Dual ISP Active-Active NAT Breakouts: If a corporate campus uses active-active multi-homed internet connections across different ISPs, both public egress IP addresses must be registered in
CsTenantTrustedIPAddress. If traffic leaves via secondary NAT circuits that are unlisted, clients will unexpectedly drop into untrusted status. - Cloud Security Gateways and SASE Proxies: When deploying cloud security proxies (such as Zscaler, Cloudflare One, or Palo Alto Prisma Access), Teams audio and video media traffic should bypass SSL inspection and egress directly via local internet breakouts. If Teams traffic is routed through centralized proxy cloud nodes, the public egress IP reported to Microsoft will match the proxy vendor, failing trusted IP evaluation.
- Replication and Propagation Time: Updates made via
CsTenantTrustedIPAddressreplicate through Microsoft 365 worldwide directory services within 2 to 4 hours. Endpoint clients evaluate updated trusted statuses after their next authentication or network interface refresh.
By properly defining and maintaining Trusted IP Addresses with CsTenantTrustedIPAddress, voice administrators ensure reliable Location-Based Routing, accurate Dynamic E911 emergency dispatch, and consistent network policy enforcement across Microsoft Teams deployments.