Welcome back! In part 1 of this blog series we covered at a high level what coexistence and interoperability between Skype for Business and Microsoft Teams involved. This time, we’ll take things a step further by looking at the technical view of interoperability scenarios you’ll need to know in order to implement this in your organization. With that being said, let’s start discussing what you’ll need to know as an administrator to ensure a successful upgrade!
Technical Requirements
Azure AD Connect
First thing you’ll want to take a look at involves Azure Active Directory Connect. If you currently have Lync/Skype for Business Server on-premises the first thing you’ll want to do is ensure Azure AD Connect is up and running. This is by far the most critical piece in ensuring a success upgrade to Teams, as you won’t be able to get to Teams without this in place. I will also stress that this will need to be the first step in your upgrade process, since you will need to ensure a proper sync is done between your on-premises AD directory and Azure AD before you can start creating Teams users. Without doing this step, you will have issues with duplicate DNS entries, user accounts, broken routing experiences, and even broken policy assignments. This will also include the synchronization of the ‘msRTCSIP’ attributes from the on-premises environment to Azure AD. For some additional information around this, I encourage you to check out the Microsoft documentation here.
Skype for Business Hybrid
Next thing up is the configuration of Skype for Business hybrid/split domain to allow coexistence between the Skype for Business Server on-premises and your Office 365 tenant. Although hybrid isn’t a strict requirement, it is highly recommended as interoperability between Skype for Business and Teams will require that hybrid be in place. So in essence, if this is not configured and you have some users in Teams Only mode while others are still on-premises Skype for Business Server, then they will be unable to communicate with one another. In addition, if you plan on migrating your users from Skype for Business on-premises to Skype for Business Online (or straight to Microsoft Teams) then you will need hybrid/split domain configured to achieve this. For some addition details on this subject, check out Microsoft’s documentation here.
Interop Flow Breakdown
Now that we know what the technical requirements entail, let’s take a look under the hood on what each of these interop flows will look like so you can more easily determine which scenario fits your organization best. But first, some things to note:
Routing will be determined by:
- Recipient’s mode (Islands vs one of the Sfb modes vs TeamsOnly)
- Originator’s client of choice (Teams vs Skype for Business)
- Where originator’s Skype for Business client is homed (on-premises vs online)
After you’ve determined those 3 points above you should then be able to determine if the communication will be possible or not. You’ll see a prime example of this in one of the examples below.
SfBO** and TeamsOnly (In-tenant) flow
In this first scenario we have a Skype for Business Online user (User A) trying to talk to a Teams Only user (User B). In this scenario User A has a Skype for Business Online client but does not have the Teams client. On the other end we have User B who is running in Teams Only coexistence mode and although they have the Skype for Business Online account, they won’t be able to use this since they are in “TeamsOnly” mode. So, how do we know User B has a Skype for Business Online account? Well, if they didn’t then you would be unable to assign the user to TeamsOnly mode. As mentioned earlier, this is one of the requirements for Teams Only mode, that you ensure your on-premises Skype for Business server users have been migrated to Skype for Business Online. As far as how these two users communicate with one another, they will leverage the gateway inside of the Teams service in Office 365 which is provided by Microsoft and won’t require any additional overhead on your part. When the Skype for Business Online user (User A) goes to talk to the Teams user (User B), the Skype for Business Online client actually thinks it is talking to another Skype for Business Online client. However, the Teams service will determine that this is actually enabled as a Teams Only user and instead redirect the conversation to the gateway and from there the conversation will appear on User B’s Teams client. This is how the interop between the two clients is established behind the scenes.
Note**: The scenarios above covers all SfB scenarios (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings) since they all function the same from a routing perspective
SfB On-premises** and TeamsOnly (In-tenant) flow
This scenario is a little different than the one above, in that now we are dealing with a Skype for Business on-premises user trying to communicate with a Teams Only user. Assuming we have hybrid/split domain configured between the on-premises Skype for Business server and the Office 365 tenant, the Teams Only user (User B) will function the same way as in the previous scenario where the Skype for Business on-premises user (User A) will try to talk with the Teams Only user (User B). User A’s client will think that it is talking with a Skype for Business Online user when in reality the receiving end is a Teams client. Like before, the service will realize that this client has been upgraded to Teams and in turn will send the request to the gateway which will forward that request to the Teams client and we’ll have the interop thread established successfully! Once this is all said and done the sender (User A) will see a little yellow banner indicating that the person they are looking to talk to (User B) is not on a Skype for Business client.
Note**: The scenarios above covers all SfB scenarios (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings) since they all function the same from a routing perspective
Islands Online and TeamsOnly (In-tenant) flow
This scenario is a bit different from the two previously mentioned. In this scenario user A would be in Islands mode, meaning the user’s Skype for Business account is in Skype for Business Online as well as Microsoft Teams. User B on the other hand will be a TeamsOnly user which means they will have a Skype for Business Online account but the account will not be available to that user because they have been upgraded to the ‘TeamsOnly’ coexistence mode. If the Islands mode user (User A) uses their Teams client to talk to the TeamsOnly user (User B), this communication will happen natively inside of Teams. As you may have remembered from our last blog, Islands means that all communications that starts in that client will end with the same client type on the receiving end. With that being said, if the user wanted to use their Skype for Business client instead to talk with the TeamsOnly user (User B), the TeamsOnly user will technically have a Skype for Business Online account provisioned. However, since this account only serves as a “shadow” account and cannot be used by the TeamsOnly user the communication will go from User A’s Skype for Business Online account to User B’s Skype for Business Online shadow and then will be routed to the gateway. The gateway will then forward this on to the Teams client instead, which will establish the interop thread between the Islands user (User A) and the TeamsOnly user (User B).
Note: The routing mechanisms are driven by the coexistence mode assigned to the target user.
Islands On-premises and TeamsOnly (In-tenant) flow
Was the previous scenario too easy for you? Well, let’s use the previous scenario but throw in some additional complexity. Let’s say instead of having User A’s account being homed in Skype for Business Online, we’ll have this user homed on-premises. First things first, you should remember that we need hybrid connectivity in order to a Teams Only user. So assuming you have hybrid configured within your environment, if the Islands mode user (User A) uses their Teams client to talk to the TeamsOnly user (User B) then this will occur natively inside of Microsoft Teams. Now, if the Islands mode user (User A) tries to talk to the TeamsOnly with their Skype for Business on-premises client, then this will work the same way as in the previous scenario. Assuming hybrid is configured properly the Skype for Business on-premises client will try to talk to the Skype for Business Online account for User B. However, since User B is in TeamsOnly mode and they are unable to use their Skype for Business Online account, this “shadow” account will have the service forward this request on to the gateway where it will send this on to the Teams client. Thus the interop thread will be established between the Teams client and the Skype for Business on-premises client. You may be thinking, “well that was easier than I thought it would be”? Luckily Microsoft does a great job of making this whole process seamless for not only the end user but for the administrator as well!
Islands Online and SfB** (In-tenant) flow
In this scenario we have User A in Islands mode wanting to speak to User B whom is in one of the SfB modes (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings). So, to break this down User A is homed in Skype for Business Online but will also have a Teams account and they will be able to utilize all features available in both clients. User B on the other hand will have a Skype for Business Online account but not a Teams account because they are in one of the SfB modes listed above. This means that the chat and calling capabilities will not be available to this user within Teams. Now, when User A (Islands mode user) uses their Teams client to talk to User B (one of the SfB modes), User B will only be able to receive messages within their Skype for Business client. From the clients perspective Teams will send this communication to the gateway which will be able to route this message through Skype for Business Online over to Skype for Business (User B). This would then establish the interop between the Teams client at User A, and the Skype for Business client (User B).
Note**: The scenarios above covers all SfB scenarios (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings) since they all function the same from a routing perspective
Islands On-premises and SfB** (In-tenant) flow
In this last scenario we will have User A in Islands mode but this time their account is homed on-premises. Since they are in Islands mode though, they will be able to utilize both clients with all features available. User B is setup in the same way as the previous scenario where they are in one of the SfB modes, meaning they will not have the ability to use the Teams client for chat and/or calling. Provided hybrid/split domain is properly implemented, when User A (Islands on-premises user) uses their Teams client to talk to User B (one of the SfB modes), User A will go to the gateway and the gateway will realize that User B is in one of the SfB modes and does not have the ability to utilize the Teams client to call/chat. So, the gateway will attempt to route this back to the client, however since User A is homed on-premises the client will be unable to use the interop gateway thus they will be unable to communicate with User B. The same concept holds true to any type of federation, as this will use the same interop gateway. To combat this, User A will be forced to use their Skype for Business client instead in order to communicate with User B.
Note**: The scenarios above covers all SfB scenarios (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings) since they all function the same from a routing perspective
ATTENTION: Islands mode users homed on-premises utilizing their Teams client will be unable to communicate/federate with SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings users. In order to communicate in this use case, they must use their Skype for Business on-premises client.
To bring it all home Microsoft has so graciously provided a 1:1 interop chat/calling routing table that you can reference. Just as a recap, routing will always be determined by the co-existence mode that is assigned to the recipient/target. You can use this table to determine where the conversation will land. As an additional point of reference you can visualize the “From originator” as User A, and “To target” as User B from the examples above.
This concludes this weeks blog on managing coexistence and interop in Microsoft Teams. Check back in soon where I’ll be finishing this blog series by discussing external access/federation routing in detail and summarize the key learning from this series!
