SOLVED

Teams emergency location sticky

Brass Contributor

Has anyone experienced the Teams client dynamic emergency location sticking and not updating properly? 

 

We currently have an office location configured according to Microsoft documentation.  Civic Address verified, places configured under civic address (i.e. bldg 1, 2, etc.), public IPs configured, LIS DB configured based on BSSID, BSSIDs attached to places under civic address.  We've found that at first connect the Windows 10 Teams clients (similar for mobile clients), pick up the dynamic emergency location correctly.  Upon moving the Windows client to another emergency location (i.e. moving from bldg 1 to 2), the client never updates the emergency location.  The only reliable way of updating the client emergency location, after it has been moved, is to log out of Teams and log back in.  In several testing situations the client does not update automatically in over 24 hours.

 

I have an open case with Microsoft which has been closed and re-opened twice since originally reported.  I was notified last month that the fix was included in a Teams patch applied to version 1.4.00.7174 which has come and gone and been tested.  The Teams client still won't update automatically.  The case is open again and I'm awaiting feedback from Microsoft after providing additional logs from our testing.

 

In short the emergency locations work just fine, it is the automatic change of emergency location which is not.

 

I performed an additional test recently between civic addresses.  I connected to a network at civic address 1 and then moved the client to civic address 2.  The client kept the emergency location of civic address 1.  Only after reboot of the client or restart of Teams client did the emergency location update to the proper setting.

 

Lastly I tested a fresh Teams client on a non-company computer to potentially rule out security configurations of the client.  The same behavior existed.  While not conclusive I suspect this points back to a Teams client issue.

 

Has anyone else experienced this and has been able to narrow this issue down to a bug or 3rd party cause?

18 Replies
Yes, we do have the same issue. Log out login back will show the right location. It seems to be a bug and MS is working on it. So as of now, it works when switching from one network to another but not between the access points.
I was told by Microsoft that a fix had been pushed to customers but have not yet been told which version would contain the fix. On Friday we received an update to version 1.4.00.11161. I've since tested it and the patch either wasn't in this version update or did not fix the issue. I've opened the case again.
I've been told by Microsoft the fix will be included in slimcore version 2021.10. I've found reference to the current slimcore version in the logs that download when pressing ctrl, alt, shift 1. Log file named "MSTeams Diagnostics Log <date>_<time>.txt"
The release date of this patch is still unknown. Do you know any information on the release of this patch?
We have tested this in Slim Core Verison: 2021.14.41 and yet no luck. The location didn't change automatically when moving from one access point to another. Only after a restart of Teams client, the emergency location appeared.

@radz Thank you for this update.  I still have an earlier version of slimcore so haven't been able to test yet again.  I'll let Microsoft know this news and work on getting another update.

@dwilliamsucb I got an update that the actual fix is expected to release in Slimcore Version 2021.22 :( and no ETA when it will be released.
Thanks for this update. Unfortunate that there is no ETA.
@radz It took some time for us to receive the version that you tested in June. I just received the version update that included slimcore 2021.14.41 and can confirm your results that the bug is not fixed. Since you seem to be receiving the updates a bit quicker than me, would you mind posting your results after you receive the 2021.22 update?
@dwilliamsucb The fix is released in Slim core version 2021.22. however, it is taking 8-10 min for the location to update once the user moves from one WAP to another.
Thanks @radz. 8-10 minutes is not ideal but it is better than where we are now. I suspect we'll receive this update in the upcoming weeks and I'll test as well.

@radzInteresting thing happened around two weeks ago (approximately Aug4). My client is now updating like yours after 8-10 minutes.  I have the previous slimcore that you had 2021.14.41 update. I received this update on July 23. Directly after this update the problem seemed worse. I had a cached location showing up even after logging off and logging back on. Then around August 4 the client started updating like you described after 8-10 minutes. It seems fairly consistent at this point. With that said, the only conclusions I can come to are 1) Microsoft has done something on the backend that explains the behavior we are seeing or 2) it took some time and multiple reboots for slimcore 2021.14.41 to change what we are seeing. The second point seems unlikely. I still have the ticket open and waiting for a response from the product support team.

I am working with a customer who is having the same issue. We have tried roaming between access points and even switching from WiFi to Wired with no change in the location information for what seems to be at least 5-10 minutes. My understanding is that when the Teams client detects the network change it will update settings such as E911 location or after an undetermined amount of time. It would be nice to know what the expectations are in the client for the refresh rate of this. It would be easier to explain to the customer if I had this information. I'm tempted to open a ticket with Microsoft but I don't feel like going through the Tier 1 mumbo before getting someone to answer my questions. Anyone else have anything to share on this?
best response confirmed by dwilliamsucb (Brass Contributor)
Solution

@JBoslooper_Magenium so I have received some feedback from Microsoft with an explanation of how this works.  The main issue where the emergency location was stuck or not working appears to be resolved. I believe it was a backend fix instead of client update.  Anyway around August the client started updating consistently at first a 10 minute window and now consistently at 5 minutes. 

 

Microsoft described to me that a network change would start a timer on the client.  At 5 minutes the client will send a request to Teams backend to check for its emergency location.  If the Emergency Location is different it will update the client.  This is what I'm experiencing at this point in time.  If I change from wired to wireless, 5 minutes after this change the location updates.  Same goes with other network changes (i.e. BSSID change, leave one building and reconnect in another, disconnect Wi-Fi adapter and reconnect).

 

Two additional points were made by the Microsoft contact.   First, the location is "hashed and cached for 4 hours (or until there is a network change)".  Second, if there was no event (Teams startup or network change) for 4 hours, the Teams client will send a new request.

That is GREAT information! Thank you so much for following up on this. While that's not necessarily a perfect solution, at least the explanation of what the client behavior SHOULD be and my customer will be happy knowing there is an answer. I'm going to check this behavior the next time I'm on site. Thank you again!

@JBoslooper_Magenium 

This is happening to our site today DEC 14th, 2022.

even after 15 mins, no change to correct room mapping.

 

New ticket being started...

 

@dwilliamsucb So would that mean if a laptop is being plugged in to ethernet without disconnecting the wireless, the Teams client would not see a network change because the wireless is still connected?

@JustinDonut. I can't say for sure but would believe that would be considered a network change as the ethernet adapter did not have an address before and now does. Probably best to test that theory. With-in 5 minutes you should know. By the way you can check the Microsoft diagnostics file on the local computer, the network information that is matching and which policies are applied to the machine based on your network information. With Teams in the foreground of your screen, press ctrl, alt, shift, 1 keys together and you should see a bunch of files download to your downloads folder. Look in the diagnostics folder that shows up with current date/time in the downloads folder. Open it and check the "web" folder for a .txt file ending with "_calling.txt". Open it and you'd find this information and more.
1 best response

Accepted Solutions
best response confirmed by dwilliamsucb (Brass Contributor)
Solution

@JBoslooper_Magenium so I have received some feedback from Microsoft with an explanation of how this works.  The main issue where the emergency location was stuck or not working appears to be resolved. I believe it was a backend fix instead of client update.  Anyway around August the client started updating consistently at first a 10 minute window and now consistently at 5 minutes. 

 

Microsoft described to me that a network change would start a timer on the client.  At 5 minutes the client will send a request to Teams backend to check for its emergency location.  If the Emergency Location is different it will update the client.  This is what I'm experiencing at this point in time.  If I change from wired to wireless, 5 minutes after this change the location updates.  Same goes with other network changes (i.e. BSSID change, leave one building and reconnect in another, disconnect Wi-Fi adapter and reconnect).

 

Two additional points were made by the Microsoft contact.   First, the location is "hashed and cached for 4 hours (or until there is a network change)".  Second, if there was no event (Teams startup or network change) for 4 hours, the Teams client will send a new request.

View solution in original post