Welcome back! You’ve made it to the final blog in this series on managing coexistence and interoperability in Microsoft Teams! Last time we discussed in-tenant interop flows. This time we’ll wrap things up by discussing external access/federation and how this differs from coexistence. For those of you coming from the Skype for Business world, you probably have a love/hate relationship with federation and the benefits it can provide. With that being said, it remains a huge aspect in Teams especially when Skype for Business is in the mix. So without further ado let’s get our federation on!
Ever want to chat with someone outside of your organization within Microsoft Teams? I introduce to you….federation! By definition, federation is communication between users in two different tenants. Teams federation currently works in the same way that Skype for Business federation works, meaning every federated communication that happens within Teams is an interop thread back to the Skype for Business environment. This will also include the ability to see your federated contacts in your contact list (once added), as well as the presence of that federated contact. We’ll touch on the interop piece later in this article, but just know that the same prerequisites that are defined in interop will also apply for federation between users in different tenants (regardless of the client being used).
Note: Teams federation v2 is something currently being worked on by Microsoft. This will provide native Teams to Teams federation. This means that a Teams Only user in one tenant can communicate with a Teams Only user in another tenant with all the features available in a native teams conversation, as opposed to the current federation that is limited to the interop experience.
Since federation works in the same way that interop works this means there will also be certain cases where federation won’t work. For example, in the previous blog post we mentioned that interop from the Teams client in Islands coexistence mode where Skype for Business on-premises is deployed will not work. The same scenario holds true for federation, so be sure to keep this in mind when planning federation with other organizations.
How do we configure federation in Teams?
Now that you know what federation is and how it functions, let’s discuss how you go about implementing federation in your organization! In order to configure federation within your organization you’ll need access to the Microsoft Teams Admin Center. Once there you’ll just need to find the “Org-wide settings” tab on the left hand side of the admin portal. Expand that and you should see a tab entitled “External Access“. Click on that and you’ll be presented with a screen like the one below:
We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
To break things down even further, we have the following options when enabling federation:
- Communication is allowed with all external domains (default setting)
- Allow only specific external domains, all others will be blocked
- Block only specific external domains, all others will be allowed
In addition, you have the option of communicating with Skype commercial users if that floats your boat. One thing you may notice between Skype for Business and Teams federation is the lack of optimization available. So, if you want the full Teams experience it is recommended that you spin up a Teams meeting so you can get all that Teams has to offer.
If the table below looks familiar, that is because we covered something similar from the last blog post on interop-flows. As with interop, the routing will always be determined based on the recipient’s mode. After that, you should see what client the originator is using (SfB client vs Teams client) and lastly where the originator is homed (SfBO vs SfB on-prem). From there, we will know if the conversation is even possible (i.e. A user in Islands mode initiating the communication within the Teams client whom is homed in Skype for Business on-premises would fail).
With federation you’ll notice things are a little more clear cut, in that both Islands and SfB mode users will always land in their Skype for Business client (with the exception of the scenario in red above). In the exception above, you’ll see that any originator operating in Islands mode with Skype for Business on-premises and using their Teams client to initiate the federation will be unable to federate.
As mentioned earlier, federation goes hand in hand with interoperability. But what exactly is interoperability and why do we need it? Interoperability is the communication between a Skype for Business user and a Teams user. This will include the following chat and calling features:
- 1-on-1 experience only (no meetings)
- Plain text chat only (no fancy emoticons, GIF’s , etc.)
- Capabilities for chat and calling are identical in federated and in-tenant cases (have I stressed this one enough… 😉 )
So why do we need interop? Well, as with many companies you may see that going straight to TeamsOnly mode for your entire organization is not easy nor practical. This is where interop comes in, because it allows you to maintain communication with Skype for Business users in your organization even after others have been upgraded to TeamsOnly mode. Obviously we other workarounds where we can have the Skype for Business user in Islands mode and have that user utilize their Teams client to communicate with the other user in TeamsOnly mode. However, we may face a more complex scenario where a user only has access to their Skype for Business client, thus interop is needed to communicate between Teams and Skype for Business. Interop will typically occur in the following scenarios:
- Intra-org during migration: Commonly in scenarios where Islands mode (side-by-side) is not being leveraged but other coexistence modes are being used.
- Cross-org during and after migration: Federation between your organization and another organization.
Last but not least, let’s go over the required prerequisites for interop in Teams. As mentioned in prior blogs, when there is an on-premises environment in play you will need to ensure that Skype for Business is configured for hybrid/split domain to allow for intra-org interop. This also means that your Teams user’s account must be homed in Skype for Business Online to allow 1-on-1 interop chats and calls. Any Teams user that still has their Skype for Business client homed on-premises will not be able to interop or federate with their Teams client. Instead they will need to use their Skype for Business client.
Core Concept Summary
This concludes the blog series on coexistence and interop in Microsoft Teams! As you can probably tell, there are many different scenarios at play here and things can tend to get a bit confusing when introducing interop and federation between Skype for Business and Teams. However, if you had to take anything out of today’s blog (and previous blogs) it would be the following core concepts:
- Coexistence involves the Skype for Business and Teams clients working together in the same organization.
- You should utilize coexistence modes to control your user experience until you can upgrade to Teams Only mode
- If you currently have a Skype for business on-premises environment, be sure a properly implement Azure AD sync and establish hybrid/split domain in your organization prior to implementation.
I hope you have found this blog series beneficial and I’d recommend checking out the official Microsoft training here, as this content may change in the coming months as new features and functionality is introduced in Microsoft Teams!