Home » Microsoft Teams » Microsoft Teams, Policies, Islands and Interoperability

Microsoft Teams, Policies, Islands and Interoperability

If you are considering rolling out Teams into your organization that already has a Skype for Business user base, you will need to understand the effects of Microsoft Teams policies, Client Modes and Interoperability.

Out of the box functionality takes care of the standard interop between Skype for Business Online and Teams. By default, users are placed in Islands Mode and have Global Teams policies that enable all the functionality possible.

But organizations looking to ease Teams in will want to control features, run proof of concepts and pilots and prevent unauthorised users access to features that have not been approved by their release cycle.

Organizations with Skype for Business who are looking to adopt Teams will not be migrating in a big bang over a weekend. There are two deployment models that organizations can adopt, Single client migrations and dual client time bound side by side migrations.

With single client migrations, a user will be using Skype for Business client one day and the next Teams. With dual client migrations users will be using both Skype for Business client and the Teams client for some communication and collaboration workloads.

There are benefits of adopting either approach and I am not going to tell you which one you should do as it depends on how you want to augment Teams into your organization. Instead I am going to tell you what you need to consider when deploying them.

The Single Client method is by far the most traditional method of migrating from one platform and another. It offers the best control as well as client experience and adoption as the end user is made aware of when the change will happen, what to expect, will have been trained and most importantly they know that all features will be available in one client post migration.

When doing this between Skype for Business and Teams, this means that you should apply the UpgradeToTeams Upgrade Policy to the user to migrate them

Grant-CsTeamsUpgradePolicy -Identity user@domain.com -PolicyName UpgradeToTeams

However, what you have to remember is that there will be some others with the person’s communication sphere that will still be on Skype for Business, so the migrated user will need to be able to chat and call them post migration.

This interoperability is controlled by the Teams Messaging Policy. The global default policy allows user chat. However, coming from the Skype for Business world we are in the habit of least privilege model, so our normal way of working is to disable functionality at the Global level and enable by user policy.

With Microsoft Teams this is not the same when you have interop to worry about. If you are native Teams then yes, the old way of working is fine. But in order to get interop to work between Teams and Skype for Business the global policy must allow at least user chat. The rest of the settings within the messaging policy can be turned off.

Set-CsTeamsMessagingPolicy -Identity Global -AllowUserChat $true

If you do not allow this then interop will not work. Users in Teams when they try to chat to a Skyope for Business user will get a message stating “Administrator has disabled Teams Chat for this user”

And the Teams user will not be able to establish a communication channel to them. However, should the same target user use Skype for Business to initiate a chat to the Teams user, they are able to send a chat to the Teams user, but the Teams user cannot reply.

So it is important that -AllowUserChat is enabled for everyone.

When it is enabled and the Teams user tries to initiate the chat to the Skype for Business user they still get the same message but they are able to click the link “Start a Skype for Business Chat” to establish the Teams to Skype interop

Once clicked the user is able to chat to them using the interop

For the Skype for Business user they must be in one of the following Client Modes; Islands, or SfBOnly.

Client modes tell Office 365 back end how to deliver chat and media traffic, whether to Skype for Teams. There are a few nuances that you need to understand so I will briefly cover those.

First of all chat and media have to be delivered to one client, whether that is Skype or Teams. You cannot split them.

In Islands mode, a user can use both Teams and Skype at the same time. However, if the user in islands mode logs into Teams then chat and calling from another Teams user will be delivered to their Teams client from that moment on.

This may not be a problem, but consider a scenario whereby a user’s colleague has been migrated and you have a savvy user who tries to log into Teams via the web pre-migration they will inadvertently mess up their communication delivery. If they sign in once, then never sign in again, other users will be able to send messages to that user, they just won’t be delivered to their Skype client. Instead they will get missed messages in e-mail format.  This adds complexity and confusion for these users and of course it will not be their fault. For this reason when doing a single client migration I always recommend to set the organization tenant interop mode to SfBOnly and then assign users the Teams upgrade Policy.

Dual client side by side time bound migrations allow organizations to instantly benefit from Teams collaboration features. This appears a positive strategy for organizations but has some more problematic technical and end user complexities over the single client approach.

If you’re going to adopt this method then the default coexistence mode (Teams Upgrade Mode) should be set to islands.

This allows the users to use both clients simultaneously. However, when someone using Teams sends a chat or internal P2P call to another user, this will deliver to the Teams client. All is well if the target user is signed into Teams. If not and they’re just in Skype for Business, the chat will come by missed email message and the P2P call will be diverted to their voicemail service.

Furthermore, users will be able to place outbound PSTN calls via Teams and Skype but inbound calls will always be delivered to Skype for Business in this mode. This again means that if a user is just signed into Teams and not Skype for Business, then inbound PSTN calls, or P2P calls from another Skype user will be diverted to voicemail service even though the user is available in Teams.

Although technically these nuances can be understood, it is very hard to translate this message to end users and makes change management and adoption a lot harder as a result. Even with a lot of resources spent on awareness, the end user experience is confusing and will end up with negative feedback.

When deploying dual client migration methods, you really should consider turning chat, meetings and calling off in Teams until you are ready for the users to move across to Teams completely. You can create a custom message policy to disable chat

New-CsTeamsMessagingPolicy -Identity NoChat -AllowUserChat $false

Then grant the policy to the users. To disable calling grant the following policy

Grant-CsTeamsCallingPolicy -Identity user@domain.com -PolicyName DisallowCalling

Then disable Teams meetings

Grant-CsTeamsMeetingsPolicy -Identity user@domain.com -PolicyName AllOff

What this does is provide a consistent platform for users to communicate i.e. Skype for Business and then they use Teams purposefully for collaboration only.

When you are ready you can then release features consistently through the business. Starting first with perhaps chat or meetings, you would release features on an organizational level. For instance you may choose a date whereby all meetings should be scheduled using Teams instead of Skype for Business. On that day just enable meetings for everyone. Then release chat in the same way and finally voice.

In the end everyone will be using Teams and the migration carries less risk and complexity once everyone is catered for.

Ultimately the approach needs to be one of these scenarios and not mix and matched or you’re going to get into a mess in understanding what problems are as a result of design vs the way that you’re trying the enable.

If you have on-premises Skype for Business the migration process is more complicated and the journey from that to Teams is probably worth another blog post or two. However, in order for your on-prem users to be able to chat to Teams users from their Skype client and vice versa you need to have properly configured Skype for Business hybrid mode.



1 Comment

  1. Nice article as always Mark. When you suggest enableing chat at the global level effectively for Teams only users, but then applying the usr level policy to the SfB Only (or SfBwithCollab for example) did you find that resolved the issue of seeing the admin has disabled caht with no ability to communicate? MS have previously advised to use the portal GUI policies only otherwise you may run into issues, which is kind of what is happening here. I’ve seen the issue you refer to here but not tried the Global policy approach, and effectively reverse the use of scope so the SfB users have the user scope policy.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: