Microsoft Teams Coexistence Mode Changes & Caching Delay
I recently changed the default coexistence mode for my entire organisation of 20,000 users from Islands mode to SfBWithTeamsCollab mode and learned a few things along the way which are probably worth sharing.
Our pilot of Microsoft Teams has grown organically over the last 12–18 months to ~5000 people and ~1000 teams. The org default coexistence mode was still in Islands mode and whilst this was incredibly useful to perform an evaluation of the Teams platform, it’s very hard (if not impossible) to perform any kind of decent, staged migration to Teams without using one of the SfB* coexistence modes on offer.
We were starting to see various issues caused by the Teams and Skype for Business platforms having no interoperability; separate presence, missed calls, calls when on calls in another platform etc. Also, our meeting rooms which were predominantly Polycom Group 500 were not ready to support Teams meetings, so this was just a problem waiting to happen as people began to use Teams more and more.
The decision was taken to move across to the SfBWithTeamsCollab mode to help us manage this migration in an better way.
What are coexistence modes?
For anyone looking for more info about the various coexistence modes these three pages on docs.microsoft.com will give you most of the info you need to know:
- Migration and interoperability guidance for organizations using Teams together with Skype for Business
- Coexistence with Skype for Business
- Teams client experience and conformance to coexistence modes
However, the greatest 53 minutes you can spend trying to understand all this is via this video hosted by Bryan Nyce, who is a Principal Program Manager in Teams Engineering. It really is a great video that I can’t recommend enough if you’re trying to get your head around all this.
For me, the bottom line is that if your org is using Islands mode, it’s very (very) difficult to move someone to TeamsOnly mode without them suffering a poor experience. Due to the fact that the recipient’s coexistence mode determines the destination for calls and chats, in an Islands mode organisation, that one TeamsOnly person will see all their calls and chats staying in Teams. So, in the case of my company, the TeamsOnly person would not be able to reach any of the ~15,000 people that had never logged in to Teams. The chats and calls will never reach Skype for Business. They’re literally on an island (GET IT?!?!)
A quick look at the usage reports via the O365 Admin Portal showed that we had a few very keen early adopters of Teams who were using private calls, private chats and Teams meetings a fair bit. So, to avoid forcing them back to using only Skype it was decided to keep a number of people on Islands mode until we could move them to TeamsOnly mode. They were already successfully working with both platforms so this wasn’t too much of an issue.
The general plan was as follows:
- Set the few eager-beavers explicitly to Islands mode
- Change the organisational default coexistence mode to SfBWithTeamsCollab
I performed the change on a Wednesday evening. It all appeared to go fairly smoothly. I logged into Teams as a couple of test users and had confirmed that they could no longer see the Chats or Calls icons in the client.
However, the next morning I noticed that messages from Teams (for my Islands or TeamsOnly users) were trying to deliver to Teams for all my recipients that I knew had been set to SfBWithTeamsCollab mode. Recipients would see the purple toast indicating the chat had arrived but were unable to view it now the chat section was not showing in the client. If they managed to catch and click the toast notification, they would get a message saying their administrator had blocked chat.
Wait, then wait some more…
It turns out there is a fair bit of caching involved in switching people’s coexistence mode. As a general rule, 24 hours should be enough time for this to all sort itself out but in certain circumstances this could take longer.
There are two caches; a service-side cache and a client side cache. Much like the address book in Outlook where the Exchange server generates it every 24 hours and then the client retrieves it every 24 hours, if triggered at the right (or wrong) time, it could be up to as much as 48 hours before the new one is downloaded.
So, my client still thinks these users are Teams users and is sending the chats to their Teams client. I confirmed this caching issue by signing in to the Teams web client which correctly displayed the recipients as Skype users which were still incorrect on in my desktop client.
There’s not a whole lot you can do about forcing the service-side cache, but if you can’t wait 24 hours you can force the client side cache by closing the client, deleting the %AppData%\Microsoft\Teams\IndexedDB directory and then starting the Teams client again. More details, including the path for Mac can be found here…
Once it is all working you should see the users you had previously chatted with in Teams show the following message. Clicking on the link will spark a new chat which will land in Skype:
The new chat will have a purple banner and will display a message explaining the lack of functionality with Skype for Business users:
In the chat list you will have a little Skype icon denoting a Skype chat:
This was the timeline to my change. Your mileage may vary:
- < 1 hour: Coexistence change took affect on client. Chat and Calling apps no longer showing after login
- ~18 hours: Messages still being sent to Teams despite SfB coexistence mode. Fresh download of client cache made no difference. Suspect service cache not updated yet.
- ~22-24 hours: Correct coexistence mode starting to show for some users in web client and other machines. Would show in desktop client if fresh client cache download was forced.
- ~36 hours: Changes confirmed on non-forced client.
If you can, build in a good 24 hours to allow things to settle down after making coexistence mode changes to a lot of users. In fact, if I had to do it again, I’d probably do it over a weekend to be safe.
I would also arm my service desk with the knowledge on how to force the client to update it’s cache. This could come in handy for a few users.
Hope this helps a few people out if you’re thinking about making these changes.