Teams Dynamic 911 address validation & troubleshooting

Now that Microsoft Teams supports Dynamic Emergency Calling, how can you troubleshoot or validate your configuration? This post will cover the steps to help if your configuration is not populating the proper address when emergency dialing or testing via 933.

I will not be covering the configuration of Dynamic Emergency calling with Teams; if you need a refresher, I suggest taking a look at the Technical Training Video and the accompanying PPT deck.

The next few steps will show you how to create the diagnostic logs in a Teams Desktop app and analyze it for Dynamic Address validation for troubleshooting. 

  1. First, you need to completely Exit Teams client and reopen it, then navigate to the Calling Icon on the left rail to trigger the client to detect the network.

2. Get the client logs from a Teams client by pressing CTRL+ALT+Shift+1 simultaneously on the Desktop client. A Diagnostic Log file will be generated and below are the locations based on the host’s Operating System:

  • Windows file location:
    %userprofile%\Downloads\MSTeams Diagnostics Log <timestamp>.txt
  • Mac file location:
    %userprofile%\Downloads\MSTeams Diagnostics Log <timestamp>.txt

3. Open the MsTeams Diagnostics Log <timestamp>.txt file in a text editor program like Notepad, Visual Studio, or Notepad++

4. To check to see what the Teams client is reporting as the client’s public NAT’d IP address, do a search for ipaddr

To see what the clients public IP address is, visit or
If IPv6 is detected, then you should enter the IPv4 and IPv6 IP address in your Trusted IP list in the Teams Admin Portal

5. Now do a search for EndPointNetwork to see if client’s public IP address is trusted or not. If it returns as Unknown, then there is no match for the Trusted IP of the Teams client and you need to review the configuration in the Teams Admin Portal.

  • Example of an unsuccessful Unknown endpointNetwork:
callingService: [setLocationInfo] set with [locationInfoType=1][content={“endpointNetwork”:”Unknown”,”networkSiteId”:null,”enableLocationBasedRouting”:false,”siteAddress”:null,”subnetId”:null}][context=locationResponse][mediaOptimization]

If it shows as Trusted, then the client is properly resolving the Public IP address as a Trusted IP. (You will also see the associated networkSiteId and other attributes that apply to that location)

  • Example of a successful Trusted endpointNetwork:

callingService: [setLocationInfo] set with [locationInfoType=1][content={“endpointNetwork”:”Trusted”,”networkSiteId”:”LAB LAN”,”enableLocationBasedRouting”:false,”siteAddress”:”LAB LAN”,”subnetId”:”″}][context=locationResponse][mediaOptimization]

Now that you can produce and analyze the diagnostic log file, you can search for a plethora of items that might help you during configuration or troubleshooting, such as:

  • Emergency Calling Policy (“emergencyCallingPolicy”)
  • Emergency CallRouting Policy (“emergencyCallRoutingPolicy”)
  • Longitude / Latitude

Hopefully this help point you in the right direction when troubleshooting or validating the address and Trusted IP discovery of the Teams client.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.