Sho Time

Restricting/Barring International Calling in Teams

From time to time, Teams admins may come aross the need to limit some (or all) Teams voice users’ calling capability to domestic-only. There are many different ways to implement this. But, I’m going to write up this method below as I found it to be the most effecient and can be used on both Calling Plan and Direct Routing.

First of all, there are 2 elements in this configuration. Their controls are in the same place but can be adjusted separately.

Audio Conferencing PSTN dial-out
- Any destination (Default)
- In the same country or region as the organizer
- Zone A countries or regions only
- Don’t allow
End-user PSTN dial-out
- International and Domestic (default)
- Domestic
- None

And, quoting Microsoft: “A call is considered domestic if the number dialed is in the same country where Microsoft 365 or Office 365 has been set up for the organizer of the meeting (in the case of audio conferencing), or the end user (in the case of end user PSTN calls).” So, please make sure you set the license usage location correctly (Well, you’d need to have the correct region anyway to have the correct dialplan applied).

So, the underlying policy that is responsible for this setting is this one: OnlineDialOutPolicy

There are many pre configured policies in Teams, and you can view them using the following GET command:

Get-CsOnlineDialOutPolicy

The default Global policy allows dial out to all destincations on both.

You can view what policy is granted to the user by running the Get-CsOnlineUser command against the user account. The attribute you are looking for is OnlineDialOutPolicy. If the value is blank, the Global policy is applied.

To change the policy configuration, you can use either the GUI/TAC or PowerShell.

GUI/TAC (Audio Conferencing Dial Out)

Go to Users, and select the user you want to change

Click the Edit button next to Audio Conferencing

Go to the “Dial out from meetings” drop-down menu.

Select your desired option.

Click Apply.

As an example, seleting “In the same country or region as the organizer” here is in effect setting the policy to DialoutCPCDomesticPSTNInternational (Verifed by runing Get-CsOnlineUser)

This policy allows domestic dial-out from conferences and leaves end-user PSTN dial-out as default, which allows international dialling.

GUI/TAC (End User Dial Out)

Go to Users, and select the user you want to change

Go to Voice tab, and click the “Dial-out settings for calling” drop-down menu

Select your desired option. There is no need to click apply.

As an example, seleting “In the same country or region as the organizer” here is in effect setting the policy to DialoutCPCInternationalPSTNDomestic (Verifed by runing Get-CsOnlineUser)

This policy allows end-user PSTN dial-out to only domestic destinations, but leaves conference dial-out as default which allows all destinations.

PowerShell

As you may have guessed, it is easier and more flexible to apply this configuration using PowerShell.

You can use the following line to grant the policy to user accounts:

Grant-CsDialoutPolicy -Identity <username> -PolicyName <policy name>

Or, it can be applied at tenant level using this line:

Grant-CsDialoutPolicy  -Tenant <guid> -PolicyName <policy name>  -Global

There are many pre made policies to cover all combinations so that you don’t have to create policies.

Of course, now it’s in PowerShell, you can script it to make bulk changes.

I hope that was helpful. Thank you for reading!

Referernces:

Outbound call restrictions – Audio Conferencing & PSTN calls – Microsoft Teams | Microsoft Docs

Country and region zones for Audio Conferencing – Microsoft Teams | Microsoft Docs

The dreaded “Cannot find specified Gateway”

For everyone who has been doing Teams Direct Routing deployments, the famous “Cannot find specified Gateway” error would definitely be up there being one of the most dreaded errors to see.

Cannot find specified Gateway error in PowerShell

There are a couple of places you may see this error, depending on the format of Teams Direct Routing you have chosen to configure:

Single tenant

Add the SBC FQDN as a domain in Microsofte 365 Admin Centre, and complete verification
Put a user account in the newly added domain
Assign a license to the user account to activate the domain (E.g. Business Basic or E1, or above)
You wait… I have seen the domain finish being activated in about half an hour but this step can take up to 24 hours
You come back to create the PSTN gatway by running New-CsOnlinePSTNGateway cmdlet
BAM!! Cannot find specified Gateway

Multi-tenant

Add the SBC FQDN as a domain in Microsoft 365 Admin Centre, and complete verification
Put a user account in the newly added domain
Assign a license to the user account to activate the domain (E.g. Business Basic or E1, or above)
You wait… I have seen the domain finish being activated in about half an hour but this step can take up to 24 hours
You skip the step to create the PSTN gatway if your provider use the derived trunk topology
You create the Online Voice Routes by running New-CsOnlineVoiceRoute, which reference the Online PSTN Gateway
BAM!! Cannot find specified Gateway

I have seen my fair share of the this dreaded error, and would like to summarise the scenarios to save some time and head scratching for you, my fellow Teams Direct Routing deployers.

Domain not activated

This could be one of the followings:

You, my friend, have forgotten or didn’t think of adding a licensed user account to the newly added domain to activate it. Solution: Add a licensed user to activate the newly added domain.
You, my friend, have made a typo in the domain name. E.g. Your carrier tenant SBC is “sbc1.contoso.com“. You were allocated an FQDN of “customer.sbc1.contoso.com“, but when you added the domain in your Microsoft 365 Admin Centre you actually typed in “customer.sbc.contoso.com“, which looked correct but it was not. The domain verification would have gone through without a hitch because ultimately the “contoso.com” domain belongs to the same service provider. You assign a licensed user account to the wrong domain and activates it. You will 100% see Cannot find specified Gateway when you create the Online PSTN Routes because your command would reference the correct FQDN. Similar error could also happen in the single tenant configuration. However, because the SBC FQDN is generally shorter, it is easier to spot. Solution: Delete your typo domain, and add it back in correctly, and activiate it with a licensed user account.

A Microsoft side issue

Although the occurrence is rather rare, I have actually encountered this scenario recently on a deployment.

I did everything by the book, but still hit the error after 48 hours of waiting.

Licensed user account to activate domain

In fact, I added multiple domains at the same time using the same method, but only 2 of them got “stuck”. So, I opened a support case with Microsoft. The support engineer went through everything with me on the phone, and checked the domains from his side, but he couldn’t see anything wrong. He then asked me to put additional licensed user accounts to the domains in question. I had my reservations but did what he asked.

Additional licensed accounts for activation

Guess what, the domains came to life after 30 mins. Very strange! I asked him what was the problem? His answer was “The accounts that were created could initiated a sync and resolved any errors.” I will update this blog if he comes back to me with a more detailed RCA.

So, there you go, if you have done EVERYTHING correctly but still seeing the error, try putting addtional licensed user accounts to the newly added domain for activation.

Microsoft documentation

If you Google this error you would also come across a Microsoft article (Link), specifically in the multi-tenant scenario.

As you can see in the screenshot above, Microsoft suggests EV enable the domain activation user account. The only issue I have with this is that most of the people and companies would use lower tier licenses for this purpose. E.g. Business Basic or E1. Which means, you’d also need to put the Phone System add-on to the activation account to enable Enterprise Voice. However, if you do have a bunch of spare E5s that can be used to do domain activation, or don’t mind adding Phone System to the activation account, this could be another fix for you if you are seeing this error. I haven’t tested it myself but I think it’d have the same effect as when they asked me to add additional licensed users to the domain in question – to initiate a sync and resolve any errors.

So there you go. I will update this blog if I come across any more scenarios or fixes. I hope I can save you some time and head scratching on your journey of Teams Direct Routing. Have fun!

Retirement of Skype for Business Online Connector

Back in December last year, Microsoft communicated that the Skype for Business Online Connector will be retired by February 15, 2021.

Well, that date is pretty much upon us. If you manage or deploy Enterprise Voice in Teams, you would have been using the SfB Online Connector to establish your remote PowerShell sessions. Therefore, this is quite an important part of Microsoft Teams voice. In case you haven’t already swtiched over to Teams PowerShell module, this is what you need to do:

Uninstall Skype for Business Online module in Control Panel
- You know the drill… go to Start\Control Panel… etc. etc.
Check your current PowerShell version
- Run the following command in an elecated PowerShell window
- Get-Host | Select-Object Version
- NOTE: Although the latest version is PowerShell 7, Microsoft recommend to use 5.1 with Teams Module due to some known issues with version 7.
Update the PowerShellGet module
- Run the following command in an elecated PowerShell window
- Install-Module PowerShellGet -Force -AllowClobber
Close and restart PowerShell window (elevated)
Uninstall your current Teams module(s) – if you have any
- Run the following command in an elecated PowerShell window
- Uninstall-Module MicrosoftTeams
Verify the removal
- Go to this directory and make sure you DON’T see a “MicrosoftTeams” folder
- C:\Program Files\WindowsPowerShell\Modules
Find the latest version of Teams module
- You can find the latest preview version by running the following command in PowerShell
- Find-Module MicrosoftTeams
- Optionally, if you want to try out the prerelease you can use the following command:
- Find-Module MicrosoftTeams -AllowPrerelease
Install Teams module
- Run the following command in an elecated PowerShell window
- For GA release:
- Install-Module MicrosoftTeams -RequiredVersion “2.3.1”
- For Preview release:
- Install-Module MicrosoftTeams -AllowPrerelease -RequiredVersion “2.4.0-preview”
Connect to a Teams tenancy
- Once completed, you can connect to a Teams tenancy using the following lines of PowerShell
- ~~$session=New-CsOnlineSession -OverrideAdminDomain “contoso.onmicrosoft.com”~~
- ~~Import-PSSession $session -AllowClobber -ErrorAction SilentlyContinue -WarningAction SilentlyContinue~~
- UPDATE: With the latest MicrosoftTeams Module, the New-CsOnlineSession is no longer needed. In fact, it’ll actually give you an error if you try to run it. You now only need 1 line to connect and manage everything in Teams:
- Connect-MicrosoftTeams

I hope I have been helpful. Thank you for reading!

Reference: Install Microsoft Teams PowerShell – Microsoft Teams | Microsoft Docs

[NEW] 1:1 Call Recording Policy

This is only a very quick post. If you use 1:1 call recording in Teams, you’d need to take a look at this and double check your configuration.

A change and impact alert labelled as “1:1 Call Recording Policy Introduction” under MC227292 has come through over the weekend.

The new –allowCloudRecordingForCalls switch in the Set-CsTeamsCallingPolicy cmdlet isn’t showing on the Microsoft documentation page yet (https://docs.microsoft.com/en-us/powershell/module/skype/set-csteamscallingpolicy?view=skype-ps), but it is available to use in the actual PowerShell command.

So, as mentioned in the Microsoft notification, you can plan and apply the setting now ahead of time to avoid any service disruption.

Voice routing for Teams Direct Routing explained

Direct Routing for Microsoft Teams is great. The voice routing configuration for Direct Routing, however, isn’t the easiest concept in the world to understand. I’d like to help people understand it to get the most out of Microsoft Teams voice. So here is my attempt on explaining the topic.

Before we begin, I’m more of a PowerShell guy than GUI when it comes to Team config. So this article will be based on configuring voice routing with PowerShell.

Key concepts

Online Voice Routing Policy – This is what we aim to create. This is the policy, or policies, to be assigned to user accounts to tell them where/how to route their calls. We’ll use the next 3 elements to contruct Online Voice Routing Policies.

Online PSTN Gateway – This is the reference, or pointer, to your Session Boarder Controller (SBC).

Online Voice Routes – Define the number pattern to match for routing purpose, using the good old RegEx, and associate it with the destination SBC.

Online PSTN Usage – A container, for Online Voice Routes, that can be referenced by different Online Voice Routing Policies.

Scenarios

Single route – This is the simplest form. All calls are sent to one SBC.

Load Balance – Same type of calls are sent to multiple SBCs for resiliency or load sharing.

Failover – Same type of calls are sent to a preferred SBC, and get rerouted to a backup SBC(s) when the preferred SBC is unavailable.

Least Cost Routing – When multiple SBCs in different countries and regions are available, calls can be routed based on the destination country to the in-country SBC. (Please be mindful of local legislation in this area.)

Configurations

Single Route

This is the simplest form of call routing. Only 1 SBC in the topology and all calls are routed to that 1 SBC.

First of all, we need to create the Online PSTN Gateway and an Online PSTN Usage. You’ll see that the Online PSTN Usage record is placed in a “Global” container. This container is literally here to hold these PSTN Usage records. You can’t change the name or create a new one with a custom name.

Next, we create an Online Voice Route. The RegEx number pattern here is saying “anything start with a + sign, followed by minimum 3 digits”. This is pretty much all phone numbers in E.164 format. Then associate it with our one and only SBC, and assicate the Online Voice Route with our Online PSTN Usage that we created in the previous step.

Next, we can contruct the Online Voice Routing Policy by creating a new one and add our Online PSTN Usage to it.

The last thing to do is assign our new Online Voice Routing Policy to the users.

Load Balance

When you have multiple SBCs at hand, you can create the voice routing config to route the same type of calls to multiple SBCs for resiliency or load sharing. Well, technically, this is probably more “resiliency” than “load sharing” because Microsoft’s official wording is “the SBCs in the routes are tried in random order”.

First, we need to create multiple Online PSTN Gateways and our Online PSTN Usage. In our example, we have an SBC in the UK and one in the US.

Next, we create our Online PSTN Route with the same catch-all RegEx pattern, but this time with 2 SBCs associated instead of 1. And then associate the Online Voice Route with the Online PSTN Usage that we created in the previous step.

To construct the Online Voice Routing Policy, we can simply pick up the Online PSTN Usage that we have just created and drop it in to a new Online Voice Routing Policy.

Finally, assign the policy to all users who need to be using Direct Routing.

Failover

What if you don’t want “the SBCs in the routes are tried in random order”? What if you want to set a preference in the routes? Like in our example, we have an SBC in the UK and one in the US. If the majority of our user base is in the UK and Europe, we’d want to use the UK SBC as the primary route and the US node as a failover route.

There are a few things that we need to do differently to achieve this.

Instead of creating 1 Online Voice Route with the catch-all RegEx pattern and associate it with 2 SBCs, we need to create 2 Online Voice Routes and each has 1 SBC associated.

The voice routes are weighed. By default, the ones get created ealier has a higher priority but you can change this later by using the “-priority” switch in the “Set-CsOnlineVoiceRoute” cmdlet.

Next, same as before, drop the Online PSTN Usage into a new Online Voice Routing Policy.

Now the policy is ready to be assiged to the users.

Least Cost Routing (LRC)

When you have mulitple regional SBCs available, you have the option to take advanage of Least Cost Routing. For example, if we have 3 SBCs in 3 different locations: US, UK and China. We could configure voice routing in such way that when our users call one of those countries the calls are routed via the SBC in the corresponding country, and therefore charged at national instead of international rate. Please be mindful, though, that not all countries in the world allow such configuration to bypass local telco. Please check local legislation before implementing such configuration.

Firstly, let’s create our 3 SBCs and our Online PSTN Usages. As shown in the diagram below that this time we are creating a lot more Online PSTN Usages than the scenarios above. This is because that for each country we want to specify the per country LCR routes at the top and everything else get routed via the “local” SBC.

Next, we need to create some Online Voice Routes, 6 in fact. 3 regional routes, each with spcified country codes (+1 for US, +44 for UK and +86 for China) and associated with the corresponding in-country SBC; and 3 catch-all routes for each country. We zoomed in on one of the Online Voice Routes.

We now need to construct 3 Online Voice Routing Policies, one for each country. The zoomed-in example below is the UK policy where calls to the US (+1) are routed to the US SBC, calls to China (+86) are routed to the China SBC and everything else are routed “locally” to the UK SBC.

Now we assign the Voice Routing Policies to the users in the corresponding countries.

Of course, you can mix n’ match with these configurations – e.g. LCR + Load Sharing, or LCR + Failover, etc.

I hope I have made it a bit easier to understand with the examples and diagrams. Have fun with Teams voice!

Reference: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-voice-routing

[Ignite 2020] Upcoming Calling Features in Teams

A few very welcome addtions to Teams calling capability have been announced at Microsoft Ignite 2020. Let’s take a quick look at them:

Modern Calls app

Straight to the very core – the Calls app in Teams client gets an major upgrade. The biggest change in the new Calls app is that now an amalgamated view of call history and voicemail takes centre stage, with the speed dials on the side.

The call history window is seachable and can be filtered.

The new Calls app allow you to dial both by phone number and by name (which the current Calls app isn’t able to do), AND a mixture of number(s) and name(s) for a group call.

Another addition is somthing I think was inspired by the good old Skype for Business client – a little menu at the bottom to act as shortcuts to call forwarding, call group and audio device settings. You can still change these setting in the old place by going to Profile photo\Settings.

The new Calls app is still in internal beta at the moment but will be rolling out later.

Collaborative Calling

This is a new and improved experience for users who are part of call queues. The new canvas allow agents to be able to better collaborate with their peers and their managers.

First of all, you can now create a call queue from a channel.

Once created, the channel will gain a new Calls tab, as well as a dial pad, option for the agent to opt in/out of the queue and queue status of other agents.

Once the agent is connected to the call, the agents can use the Posts tab to collaborate in real time.

AA/CQ Enhancements

A couple of eye-catching enhancements are coming to Auto Attendant and Call Queues.

Phone System Enhancements

Some behind-the-scene enhancements are also coming to Phone System.

For more information, please watch the actual Ignite video presentation here: http://aka.ms/OD265 .

Custom meeting logo in Microsoft Teams

A couple of new meeting features are coming to Microsoft Teams in September. I find the custom logo particularly interesting and useful. It would make your meetings look much more professional and stand out from the crowd.

The organiser would need to have Advanced Communication license to take advantage of this new feature.

A little recap on Advance Communication license:

Advanced Communications provides enhanced calling and meeting capabilities that address a spectrum of communication needs, including the following:

Reach larger audiences: Help your users stay connected with live events for up to 20,000 participants and interactive meetings for 1,000 participants with the capability to enable up to 20,000 participants in a view-only meeting experience.

Tailor and customize meetings: Drive standardization across meetings for your internal and custom-facing scenarios, with features such as custom branded meeting lobby. Implement with flexibility across your organization’s departments.

Connect meetings and calling to workflows: Integrate workflows to your communication system. For example, have your compliance recording policy automated, and become part of the communication workflow, without the need for manual intervention.

Manage your organization communications: Monitor, track, and analyze data on users and devices to ensure a smooth experience.

Advanced Communication license is available as an add-on for $12 per user per month.

Honorable Mention: Video Spotlight in Teams meeting

This new addition can also be quite helpful in keeping the focus on the speaker in a video conference. This feature too will require the organiser to have Advanced Communication license.

https://docs.microsoft.com/en-us/microsoftteams/teams-add-on-licensing/advanced-communications

Test Drive Microsoft 365 Connectivity Test

During this time more than ever, we all want to know if our network is good enough to work from where we are sitting. There is handy website provided by Microsoft, currently as a proof of concept, to run such tests against some key Microsoft 365 workloads.

The test is located at: https://connectivity.office.com/

It will test: Exchange Online, SharePoint Online and Microsoft Teams

The first thing you do after loading up the page is to set your location. You can either type it in manually or use the location service. The list will assist you as you type (powered by Bing).

Right after you have set the location, the page will give you some “off the bat” basic results.

This only provide you with quick but limited infomation. You can then choose to provide your Microsoft 365 tenant name to run an advanced test.

When you click “Run Tests”, your browser will prompt you to download an executable file. One file is associated with only one round of tests. You can refresh the page and run another round and you will need to download another file.

Before you double click and run the file you will need a couple of prerequisites to be installed on your computer:

.NET Core Runtime (Download)

.NET Core Desktop Runtime (Download)

Once you have completed the installation, you can double click the connectivity test executable to start the tests.

When it has finished, the application itself won’t return any results. Simply click the Close button and the results will be on the original web page where you entered your tenant name and downloaded the executable.

I did the tests in a few different scenarios to see if it would return the accurate and correct results. The outcome were positive.

VPN, without split tunnel

As the map shows: I’m in Cardiff but breaking out to the internet from London (our datacentre) and my DNS server is all the way in Belgium. This resulted my Microsoft 365 Front Door being in the Netherlands (a bit strange). So, not ideal!

The detailed information table confirmed the results.

VPN, with split tunnel

This is more like my actually daily working condition, and it is the recommended configuration for anyone who must use VPN. As the map shows, my internet breakout is now local to me in Cardiff and my Microsoft 365 Front Door is now in London. Much better!

The detailed information table also reflected the change.

Local breakout

This is the Microsoft recommended configuration – local internet breakout, no VPN. As the map shows, now all my traffic stay in the country: breakout in Cardiff, DNS in London and Microsoft 365 Front Door in London. The most ideal case.

The advanced test also provide additional information per workload (Exchange Online, SharePoint Online and Teams). Being an UC guy, I’m going to take Teams as an example.

As part of the advanced tests, when running the executable it downloads and installs the Skype for Business Network Assessment Tool in the background to run a media test. The test does a quick connectivity check to see if the necessary ports are open to establish the media stream. It also returns some network quality metrics.

It also provides network Trace Route results to Microsoft 365 service Front Doors.

Again, I will take Teams as an example but the tests also return results for Exchange Online and SharePoint online.

It took 3 hops, including my home Sky router, for me to get on the Microsoft network. In contrast, when my traffic was going through the VPN tunnel it took 2 more hops – confirms Microsoft’s recommendation of using local breakout.

To conclude, although this tool is not GA yet it is a very handy tool to give you some tangible idea of your network setup and condition when using Microsoft 365 services. I have only listed some of the information from the full testing results. To have a proper look, give it a go yourself. It only take a few mins.

For more technical information see here.

Thank you for reading!

Skype / Teams interop and hybrid, explained

The coexistence and interop between Skype for Business (Online and on-prem) and Teams have been an interesting topic since the day Microsoft Teams was introduced. It is not a new topic, but I feel it still needs clearing up. Hopefully this could help people and businesses understand the possibilities and implications, and in turn get the most out of the Microsoft UC stack, and have a smoother ride on their migration journeys.

So, can Skype and Teams live together in harmony? Yes, absolutely, as long as you get the coexistence configuration right.

There are 5 options, available as policies in Teams Admin Centre (TAC), when it comes to coexistence mode:

The fundamental here is peer-to-peer communication. From which platform does it start at the sender’s end, and where does it land at the receiver’s end. This applies to both Skype for Business Online and on-prem.

Let’s take a closer look at the modes and how do they work.

Islands

Users can run Skype for Business and Teams clients on their computers side-by-side. The 2 will operate independently to each other. All peer-to-peer communication (IM and call) will start and land in the same platform. No crossing.

Edit: 21/05/2020

This also applies to presence information. Skype for Business and Teams clients operate independently. The presence information in one platform does not try to match or sync with other one. The user can manually set presence, independently, in both Skype for Business client and Teams client. Other users will see presence information in the respective platform.

On top of that, users can generate and send out meeting invites from either platform.

Edit: 12/06/2020

A new policy parameter was added to CsTeamsMeetingPolicy (MC214700, 30 May 2020) to allow users in Islands mode set Outlook to only create Teams meetings.

The new parameter is PreferredMeetingProviderForIslandsMode. The default value is TeamsAndSfB, where both Teams and Skype for Business Outlook meeting add-ins are enabled.

You can set the meeting add-in preference to Teams by setting the parameter to TeamsOnly.

I would suggest you create a new Meeting Policy for good practice.

And use the Grant cmdlet to assign policy to users.

Please note, by setting the preference in the above policy, you’d only disable the Skype for Business Meeting Outlook add-in. The action will not trigger any meeting migration. It does not change existing Skype for Business meetings to Teams meetings. And vice versa, you can set the preference back to TeamsAndSfB and it will not change any Teams Meetings to Skype Meetings.

Is this good? Is this bad? We’ll discuss later on in this article. Let’s get the different modes out of the way.

Skype for Business with Teams Collaboration

Again, users can run Skype for Business and Teams client side-by-side. However, Teams client now only provides the “collaboration” features, which are teams and channels. There is no peer-to-peer IM or call, and no meeting function.

Edit: 21/05/2020

Presence information in Skype for Business take precedence over Teams. User’s Skype for Business presence is synced to their Teams client. Users are not able to manually set presence in Teams. E.g. If the user only have Teams client running, his/her Teams client will show as “Offline” and unable to be manually changed because Skype client is not logged in.

Skype for Business with Teams Collaboration and Meetings

Very similar to the one above, but this time Skype for Business don’t do meetings anymore. Users will generate and send out Teams meeting invites. Peer-to-peer IM, presence and calling remain in Skype for Business.

Edit: 21/05/2020

Presence information in Skype for Business take precedence over Teams. User’s Skype for Business presence is synced to their Teams client. Users are not able to manually set presence in Teams.

“Skype for Business only” and “Teams only” are quite self explanatory. Users either use ALL communication modalities in Skype or everything in Teams. Only one of the two client software is needed on the user’s computer.

Edit: 21/05/2020

The presence information from the respective platform is the effective presence for the user.

Edit: 12/06/2020

A few words on meeting migration behaviour. By default, a meeting migration is automatically triggered when a user is set to “Teams Only” or “Skype for Business with Teams Collaboration and Meetings“. This means the Microsoft Meeting Migration Service (MMS) will go through user mailboxes in Exchange Online and automatically update existing Skype for Business meetings to Teams meetings (new invites will be sent out). However, there is one catch: MMS is only triggered when the coexistence policy is applied at user level. So if you set it at org-wide/tenant level, the MMS will not do anything and no Skype for Business meeting will be updated to Teams meeting.

Which one should you use?

First of all, Islands mode is BAD! Although it is the default mode in 365 tenancy, it’s bad. Don’t get me wrong, it is there for a reason. It’s good for a very small group of pilot power users to try out Teams without doing or taking any consideration to Skype, but it’s bad to be put in production or applied to a wide user base. We’ll explain why, read on.

The principle when considering coexistence modes is that whatever you choose, do not have overlapping functionalities between Skype and Teams. For example, peer-to-peer IM, presence, and calling, make it only one of the two can do it, not both. Put yourself in the users position, if you find yourself facing a choice between the two when you try to use a specific feature you’ve got it wrong.

In many scenarios, businesses would have a mixed population of users running different coexistence modes. It could be a phased migration, or people/business want to take advantage of Teams meetings while their main communications platform remains on Skype for Business. (Want to know what’s the advantage? Read this.) This is where the fun starts, and where the benefit of getting coexistence mode right shines through.

To put your organisation in this mixed mode, you need to set one org-wide coexistence mode (not Islands) for the majority and apply user level policies to the subsets of users who need different modes. Setting the org-wide policy is quite straightforward and can be done in the TAC. To set the user level policy, TAC can only operate on one user at a time, so if you want to apply to bulk users you’d need to use PowerShell.

Now, let’s see how would those different coexistence modes interop with each other.

I made the diagrams below with directional arrows to indicate where does the communication start from and where does it land at the end. They are all “vice versa”.

See, as long as the coexistence modes are set correctly everyone can chat and call everyone else. The communication can flow across the two platforms without problems.

What happens when it’s not set right? Let me show you, and you will see why Islands mode is bad.

You see, in Islands mode people can run the two clients side-by-side at the same time. The problem is, they don’t always do. Islands mode can work, as long as everyone always have both Skype and Teams running to avoid un-deliverable peer-to-peer communications. Islands mode can work, but with a great risk of human error. Let’s be honest here, us humans are not as reliable as computers.

Hybrid

If you have a Skype for Business on-prem server deployment, you may wonder when/if you’d need to put hybrid in place to enjoy some Microsoft Teams goodness.

Skype for Business hybrid was originally created to allow users homed in Skype Online to communicate with users homed on the Skype on-prem server of the same organisation, and of course migrating from Skype on-prem to Skype Online.

Similar principle applies when it comes to Teams and Skype for Business on-prem. You will need hybrid if peer-to-peer communication (IM, presence, and calling) across the 2 platforms is required.

For example, when partial user base of an organisation is homed on Skype for Business on-prem server with coexistence mode set to “Skype with Teams Collaboration”, and the rest of that user base is homed on Microsoft Teams with coexistence mode set to “Teams only”.

Another approach is “Meetings First”, where organisations move their meeting workload into Teams while continuing to use Skype for Business on-prem server for peer-to-peer chat, presence, and calling.

In this scenario, all users are homed on the Skype for Business on-prem server; they would have their coexistence mode set to “Skype for Business with Teams Collaboration and Meetings”; they would have Skype for Business client and Teams client running side-by-side on their computers with no overlapping modalities.

As you can see, in this case the workloads are actually independent of each other. The users just have different modalities of their systems connected to different back ends. No user is actually homed in the cloud (AD Deployment Locator points to on-prem) and no peer-to-peer communication is going across Skype for Business and Teams, or across on-prem and Microsoft cloud. Therefore, hybrid is not mandatory in this configuration. The minimum requirement is the on-prem Active Directory to be synced with Online via AAD Connect.

Having said that, it is still a good practice to have hybrid in place at this stage. Why? To pave the road for next phases. Organisations normally use “Meetings First” to ease their way into Teams migration. And to complete a full migration, you guessed it, hybrid configuration is required. And if you choose to go through a phased migration, which most organisations would, you’d need hybrid to cope with the split user base period.

There. It was a bit long winded but I hope made things a bit clearer around Skype/Teams coexistence, interop and hybrid.

I hope I have been helpful. Thank you for reading.

Reference:

https://docs.microsoft.com/en-us/microsoftteams/migration-interop-guidance-for-teams-with-skype

https://techcommunity.microsoft.com/t5/microsoft-teams-blog/meetings-first-brings-microsoft-teams-meetings-to-skype-for/ba-p/828340

https://docs.microsoft.com/en-us/microsoftteams/coexistence-chat-calls-presence

https://docs.microsoft.com/en-us/skypeforbusiness/audio-conferencing-in-office-365/setting-up-the-meeting-migration-service-mms

“Our meetings are fine in Teams but not in Skype” – WFH

Since the lockdown started we have heard this statement quite a few times. The “Skype” here refers to Skype for Business on-prem server edition. Organisations who currently have a deployment of on-prem Skype for Business environment started to notice that Microsoft Teams deliver better meeting quality now the majority of their workforce work from home. As a result, more and more businesses have sped up their transition to Teams by putting in hybrid configuration and enabling “Skype for Business with Teams collaboration and meetings” to start having meetings in Teams while peer-to-peer and PSTN communication remain in Skype.

However, thinking about this, those organisations have had Skype on-prem for years and have all been “happily married”. What exactly happened that made Skype on-prem meeting experience fell from grace?

The key here is “work from home”.

To illustrate this clearly, we have to get a bit networky. I have prepared some diagrams to make things a bit visual and hopefully easier to take in.

First of all, there are a few networks that we’ll be talking about. They operate in parallel to each other and each serve a different purpose.

Because we are talking about conferencing specifically today, let’s zoom in on that.

In conferencing, there is this thing called MCU – Multipoint Control Unit. MCU isn’t a Skype thing or a Teams thing. It’s a conferencing terminology or concept. It is the element of the system that mix all the audio or video feeds together, merging individual streams into a group conversation and therefore produce a conference. So, although products like Skype for Business and Teams are the new shiny UC platforms, they still need the MCU or equivalent for conferencing. And the quality of the meeting experience largely depends on if the user endpoints can talk to the MCU in the most efficient way.

Let’s take a look at the MCU in Skype on-prem. Typically, the MCU is located on the Skype for Business Front End server or pool. Before the COVID-19 lockdown, the majority of the workforce were office based. That means when people were joining Skype meetings most of the attendees, if not all, were “on-net” with the Skype for Business server. The traffic could traverse from the users to the MCU via the controlled and optimised corporate LAN/WAN network, and in turn deliver a good quality and experience for all.

Now, let’s send everyone to work from home. All of sudden, you are no longer “on-net” with the Skype for Business servers. You are off the net, the corp net. Skype on-prem rely on its Edge role to accommodate remote users. The Skype for Business Edge server sits next to the Front End server “in the office” but facing the internet, and act as the Media Relay between the users at home and the Front End server “in the office”.

The traffic from all attendees will now have to traverse the uncontrolled internet to get to the MCU “in the office”, or more realistically the datacentre. Some people may live closer to the datacentre, some may be further away. Some people may have a good home broadband and all to themselves, some may have kids streaming and gaming while they are trying to join a meeting. Some ISPs may take 5 hops to reach your company’s datacentre, some may take 15. What this means is that there is a much higher chance for your Skype for Business data traffic to suffer from high latency (people end up talking over each other), high packet loss (robotic voice), and/or high jitter (missing words or syllables in speech).

What about Teams then?

Teams is a cloud based platform, so everything is over the internet. How can that be better? One thing Microsoft keep saying when it comes to Teams is that “Teams is designed from the ground up to work over the internet”. But how?

Behind the Teams client that we see and use everyday, is Microsoft’s biggest gun: the Azure network.

The Azure network is huge and powerful. It’s the 2nd biggest network in the world, just behind the internet. There are private dark fibres between all the datacentres that Microsoft own, and with peering with a long list of ISPs globally. It has WAN links with speeds up to 172Tbps and has POPs (Points of Presence) strategically placed around Microsoft datacentre regions to help bring the traffic back in, to bring the datacentre closer to the customers.

Specifically to Teams, there are Transport Relays spread all over the world in the Azure network. They are then connected to a mesh of Media Processors and Conference MCUs in regional main datacentres in North America, Europe, APAC and Japan.

When a Teams client tries to join a meeting, or a call, the first thing it does is to discover and locate a Microsoft Transport Relay that is the “closest” to the user endpoint. This could be geographic distance or the speed of response. Then the peering between ISPs and Microsoft means it’ll take fewer hops for the traffic to get to Microsoft. Once there, it’d be on the Microsoft highway to get to the MCU in the Azure network.

In comparison to Skype on-prem, although the traffic is still going over the internet the user endpoints don’t go across the big bad internet without any special treatment (peering) to get to a fixed location. Instead, they only need to get to their “nearest” Microsoft Transport Relay to get on the Microsoft highway, and relax. The network traffic to the MCU is much more efficient. And, therefore, deliver a better meeting quality in Teams.

There are so many other topics we could expand from here: Teams media path, codecs, quality of experience, corp network design, etc. etc. We’ll get to them in future posts.

Finally, before I let you go, I will leave you with a little tip – my personal favourite Teams meeting trick: Take the meeting with you on your mobile. (Although the voice quality won’t be the same even if you use the same certified headset. Want to know why? Read my other post here)