Apr 13 2021 10:39 AM
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?
May 07 2021 11:25 AM
May 20 2021 05:33 AM
May 21 2021 02:24 PM
Jun 14 2021 01:58 PM
Jun 16 2021 02:28 AM
Jun 16 2021 05:28 AM
@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.
Jun 16 2021 09:47 AM
Jun 16 2021 09:54 AM
Jul 27 2021 01:27 PM
Aug 02 2021 10:24 AM
Aug 02 2021 12:34 PM
Aug 17 2021 06:13 AM - edited Aug 17 2021 06:15 AM
@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.
Oct 18 2021 12:30 PM
Oct 20 2021 07:29 AM - edited Oct 20 2021 09:14 AM
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.
Oct 20 2021 11:13 AM
Dec 14 2022 08:38 AM
This is happening to our site today DEC 14th, 2022.
even after 15 mins, no change to correct room mapping.
New ticket being started...
Jun 30 2023 10:24 AM
@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?
Jul 03 2023 12:45 AM
Oct 20 2021 07:29 AM - edited Oct 20 2021 09:14 AM
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.