Home » Microsoft Teams (Page 3)

Category Archives: Microsoft Teams

Microsoft Teams CoExistence & Interop With Skype for Business

If you are thinking of introducing Microsoft Teams into your organization and you are currently using Skype for Business, then you will undoubtedly be wondering how these two distinctly different but similar apps interact. In this post, I hope to take a simpler approach to the Microsoft article to help explain the supported scenarios and where you may trip up if not careful.

Interop and coexistence when you have are 100% Skype for Business Online is pretty well established now and as long as you follow the rules of engagement, there shouldn’t be any issues. However, if you have an on-premises Lync or Skype for Business deployment, then things are a little more complicated if you want the users to use Teams as well.

Technically speaking right now, if your user is homed on-premises Skype for Business and is using Teams, this is not currently a supported scenario, although it may work to some degree, the likelihood of weird things happening is high. This is a scenario that will become supported in the near future though, so watch out!

There are a few things you need to do in order to get interop working between a Teams user and a Skype for Business on-premises user. First of all and most important, you must have Azure AD Connect deployed and syncing accounts to AzureAD. Within that sync you must make sure that you are syncing the attribute msRTCSIP-DeploymentLocator. This is so Skype for Business Online can properly detect your on-premises deployment.

Secondly, you must configure your Skype for Business on-premises deployment for hybrid with Skype for Business Online.


In fact, even if you as an organization are not moving to Teams and sticking with Skype for Business On-Premises, you must configure this if you want to continue to federate with partner organizations who are moving to Microsoft Teams!!

Now if you want to allow your users to use Microsoft Teams, you must first move them from your Skype for Business On-Premises to Online if your intention is to move them completely to Microsoft Teams. This will shorten in an upcoming CU for SfB 2015.

With hybrid configured your on-premises homed users can use Microsoft Teams in Islands mode, but will not be able to use Microsoft Teams to federate with external users, they must continue to use Skype for Business for that.  Furthermore they can only use Microsoft Teams to chat and call other internal users who are also using Microsoft Teams in islands or Teams only mode. They cannot use Teams to IM a Skype for Business internal user, they must continue to use Skype for Business for that.

A further note on federation, regardless of on-prem or online if the Teams user initiates a federated chat or call and the partner is in islands mode, the chat and call land in the partner’s SfB client, not Teams!

Skype for Business on-premises users cannot use Microsoft Teams for any phone system features, including direct routing or calling plans as they must be in Teams Only mode for these features.

However, Skype for Business on-premises users can use the Microsoft Teams Meeting features and Dial-in Conferencing should they wish (coming soon). Even though Microsoft say this is a Server 2019 feature, there is no dependency for on-premises software version for this to work.

To try and put this together as a quick reference I have put together the flows as a picture below

Hope this helps to keep clarity when working out what should and shouldn’t happen.



Microsoft Teams – Direct Routing High Availability

There are lots of guides on the Internet of how to configure Direct Routing with Microsoft Teams. However, whilst these are extremely useful for those looking to implement this technology, you may be looking for a little bit more information on how to extend this into a highly available and resilient solution for your telephony services.

In this blog, I will be discussing the principles of high availability and resilience using Ribbon /  Sonus technology as the context platform.

You will know that from the Microsoft Teams side of the configuration, Direct Routing is simple to set up, just pair your gateway, configure your PSTN usages, routes and routing policies. However, simply adding more PSTN Gateways to the PSTN Gateway table does not automatically give you High Availability or resilience.

I want to break this down into three focused elements:

  • Microsoft Teams Configuration
  • Direct Routing Configuration
  • PSTN Carrier Configuration

Microsoft Teams Configuration

The first element you will perform in Microsoft Teams is to pair your SBCs with Office 365. Basically this is an access control list that tells PSTNHUB to expect and allow SIP connectivity from the SBC FQDNs and SIP Ports. The rest of the magic is performed by Microsoft back end services. When you add these to the table, it is important that you ensure that you allow SIP OPTIONS to be sent from PSTNHUB, you will need this to determine your availability status when configuring your SBCs. Why? SIP OPTIONS is like the SIP version of TCP Ping test. This basically determines whether or not the SBCs in PSTNHUB are actually available at a basic SIP connectivity level.

Once you have added your SBCs, you are going to create PSTNUsages and then voice routes that include your SBCs as target destinations. The order in which you enter the SBCs into these routes matters in the same way as they would in Skype for Business. Each one will be tried in round robin subject to them reporting SIP OPTIONS to PSTNHUB within five minutes previous to the call being placed.

Direct Routing Configuration

If you where to connect each of your SBCs to Microsoft Teams Direct Routing independently and then to your PSTN trunk then you may think you have yourself covered? Well, the short answer is probably more like, maybe but it could be better.

Although Microsoft PSTNHUB should detect if a SIP trunk is down between itself and a particular SBC then it should not route a call to it and temporarily mark the trunk as inactive. But what if the SBC trunk between PSTNHUB and the SBC is working, but its the trunk between the SBC and your PSTN carrier or internal VoIP system that is down? PSTNHUB isn’t going to be aware of that, should under these circumstances potentially would route calls to that SBC assuming it will be routed.

In this case, what would happen is that the SBC would return a Q.850 cause code back to PSTNHUB to say that it cannot route the call (probably no circuit available, or temporarily down). In theory, PSTNHUB should re-route. So what’s the problem?

The user experience may suffer as a result and the user may hear the pre-dial tone of Teams for longer until they actually get Early 183 and a real dial tone. The thought of, this isn’t going well will enter their minds and in all liklihood the call could actually fail to establish.

To make this cleaner, on your SBC you can use that Q.850 code and re-route at the SBC to another so that the experience for the user is far more fluid and normal. 

The medium range of Sonus / Ribbon SBCs do not have any HA capabilities, but what they do have is re-routing capabilities. So when configuring them it is in my opinion best to create an interconnect SIP trunk between the SBCs you have and use cause code re-routing to redirect calls to the other SBC(s) in the event the target signalling group is inactive. 

PSTN Carrier Configuration

It is important that when you speak with your carrier that you fully describe your intentions and desires to them. You’ll want to make sure that your service and trunks support active / active and not active / passive or all calls inbound will be delivered to one SBC and then you’ll reach capacity issues potentially.

By employing active / active you are load balancing your calls across all your trunks. But again, what if the trunk to PSTNHUB is down on the SBC that gets offered the call? Much like what you’d do for Teams, you would do this side of the call too and use re-routing to get the SBC to send the call via the other SBC(s) in the site. 

When I get time, I will post how to guides and configuration snippets to make this happen. But for now, conceptually this should give you enough of an idea to implement using other blogs on Direct Routing as a reference point.

Clear the Microsoft Teams Client Cache

Microsoft Teams cache behaviour is a lot to be desired if I am honest. One thing for sure is that if you are deploying Teams you’ll quickly find that your admin controlled policy settings take a random amount of time to come into effect on the target machines.

Unlike Skype for Business Online where in-band policy changes took longest 30 minutes, with Teams we can be waiting days, and I mean that literally.

Upon talking with support the standard response is that it can take anything from 30 minutes to 3 days for policies to become effective. To me, this is unacceptable and Microsoft have acknowledged that at least. Hopefully we will see some improvements soon.

The problem though really centers around the client cache. So clearing the cache is the first step to troubleshooting. The trouble is, the cache for Teams isn’t in one place or even a single directory. It’s split in multiple directories and even Internet Explorer and Chrome cache locations. So when support as you to clear the cache, there are something like 13 different places you need to go in order to clean the machine.

These locations are:

  • %AppData%\Microsoft\teams\application cache\cache
  • %AppData%\Microsoft\teams\blob_storage
  • %AppData%\Microsoft\teams\databases
  • %AppData%\Microsoft\teams\cache
  • %AppData%\Microsoft\teams\gpucache
  • %AppData%\Microsoft\teams\Indexeddb
  • %AppData%\Microsoft\teams\Local Storage
  • %AppData%\Microsoft\teams\tmp
  • %LocalAppData%\Google\Chrome\User Data\Default\Cache
  • %LocalAppData%\Google\Chrome\User Data\Default\Cookies
  • %LocalAppData%\Google\Chrome\User Data\Default\Web Data
  • Internet Explorer Temporary Internet Files
  • Internet Explorer Cookies

Only after clearing these locations is it considered a clean start for the Teams app. Through pain of trial I have now given up and made a PowerShell script to do this for me, shared below.

$challenge = Read-Host "Are you sure you want to delete Teams Cache (Y/N)?"
$challenge = $challenge.ToUpper()
if ($challenge -eq "N"){
Stop-Process -Id $PID
}elseif ($challenge -eq "Y"){
Write-Host "Stopping Teams Process" -ForegroundColor Yellow
Get-Process -ProcessName Teams | Stop-Process -Force
Start-Sleep -Seconds 3
Write-Host "Teams Process Sucessfully Stopped" -ForegroundColor Green
echo $_
Write-Host "Clearing Teams Disk Cache" -ForegroundColor Yellow
Get-ChildItem -Path $env:APPDATA\"Microsoft\teams\application cache\cache" | Remove-Item -Confirm:$false
Get-ChildItem -Path $env:APPDATA\"Microsoft\teams\blob_storage" | Remove-Item -Confirm:$false
Get-ChildItem -Path $env:APPDATA\"Microsoft\teams\databases" | Remove-Item -Confirm:$false
Get-ChildItem -Path $env:APPDATA\"Microsoft\teams\cache" | Remove-Item -Confirm:$false
Get-ChildItem -Path $env:APPDATA\"Microsoft\teams\gpucache" | Remove-Item -Confirm:$false
Get-ChildItem -Path $env:APPDATA\"Microsoft\teams\Indexeddb" | Remove-Item -Confirm:$false
Get-ChildItem -Path $env:APPDATA\"Microsoft\teams\Local Storage" | Remove-Item -Confirm:$false
Get-ChildItem -Path $env:APPDATA\"Microsoft\teams\tmp" | Remove-Item -Confirm:$false
Write-Host "Teams Disk Cache Cleaned" -ForegroundColor Green
echo $_
Write-Host "Stopping Chrome Process" -ForegroundColor Yellow
Get-Process -ProcessName Chrome| Stop-Process -Force
Start-Sleep -Seconds 3
Write-Host "Chrome Process Sucessfully Stopped" -ForegroundColor Green
echo $_
Write-Host "Clearing Chrome Cache" -ForegroundColor Yellow
Get-ChildItem -Path $env:LOCALAPPDATA"\Google\Chrome\User Data\Default\Cache" | Remove-Item -Confirm:$false
Get-ChildItem -Path $env:LOCALAPPDATA"\Google\Chrome\User Data\Default\Cookies" -File | Remove-Item -Confirm:$false
Get-ChildItem -Path $env:LOCALAPPDATA"\Google\Chrome\User Data\Default\Web Data" -File | Remove-Item -Confirm:$false
Write-Host "Chrome Cleaned" -ForegroundColor Green
echo $_
Write-Host "Stopping IE Process" -ForegroundColor Yellow
Get-Process -ProcessName MicrosoftEdge | Stop-Process -Force
Get-Process -ProcessName IExplore | Stop-Process -Force
Write-Host "Internet Explorer and Edge Processes Sucessfully Stopped" -ForegroundColor Green
echo $_
Write-Host "Clearing IE Cache" -ForegroundColor Yellow
RunDll32.exe InetCpl.cpl, ClearMyTracksByProcess 8
RunDll32.exe InetCpl.cpl, ClearMyTracksByProcess 2
Write-Host "IE and Edge Cleaned" -ForegroundColor Green
echo $_
Write-Host "Cleanup Complete... Launching Teams" -ForegroundColor Green
Start-Process -FilePath $env:LOCALAPPDATA\Microsoft\Teams\current\Teams.exe
Stop-Process -Id $PID
Stop-Process -Id $PID

Microsoft Teams, STUN, TURN and NAT – Get Your Media Right

If you have used VoIP over internet solutions in the past then this will be no surprise. However, if you are new to Microsoft Teams with little or no UC heritage, then this post may be of value to you.

Even though Teams uses its own protocols over https to communicate, underneath the bonnet of these packets still uses the underlying protocols and principles of media connectivity over the internet. With Teams it is harder to see as the packets are encrypted with a certificate, but there are ways in which you can view this.

When I talk about media establishment over the internet, what I really mean is media connectivity when a client is behind NAT.

NAT is a problem when trying to connect two clients together over a third party network because we need a way of being able to transport the data packets from one peer to another and when behind a NAT firewall we cannot do this because both peer’s IP addresses change as they pass through the firewall.  For instance, Client A has an IP of and Client B has an IP of and they exist on completely different networks connected by a NAT firewall over the internet. Using their private IP addresses would result in a fail because they are not routable over the internet as the firewall would change the IP to the public IP of the firewall’s outside interface.

Before we solve this problem, its probably a good time to bring up the term ICE. No this is not In Car Entertainment, but Internet Connectivity Establishment. ICE is a protocol that VoIP clients use to establish media in any network, internal or external. ICE lives inside another protocol called Session Description Protocol, or SDP. SDP is responsible for ICE, client capabilities and codec negotiation during a call setup.

When we talk about ICE, you’ll hear the term ICE candidates. What this means is that in order to establish media, the client will send an invitation to a conversation to the peer that they are trying contact via a SIP Proxy that contains within its SDP a list of IP addresses and Ports that can be used to allow the peer to connect to it.

These IP addresses and Ports are called ICE Candidates. When looking at the SDP you’ll see something like this

Image result for ice candidates

The first thing that you will notice is that each ICE candidate has a pair of addresses and ports. Candidate 1 in a port pair is the IP address and Port the client has opened for receiving media, whilst the second is the IP address and Port the client has opened is for RTCP media quality monitoring. The IP addresses must match, but the ports should be different if using UDP (Preferred).

Candidate:1 will always be the private IP address of the local client and this is what is used when both clients are internal to each other, i.e. on the same network. The next Candidate pair will be the IP address and Ports opened over the internet and this is where I take a pause and return to STUN for a moment.

If you look at the Candidate:4 pair in the above example, we can see that the IP with the port 1230 and 1231 opened respectively. This IP address is the public IP of the firewall the client is routing over and the port the firewall has opened on the outbound interface for that connection. Natively, clients are not capable of discovering this IP and port on their own.

Instead they send out a discovery request to an external server to say “Hey tell me my public IP and Port please”. This request goes to a STUN server usually on UDP port 3478. The STUN Server will reply to the client with the public IP and Port opened on the firewall and this becomes whats called a server reflexive address (srflx) remote address (raddr). The firewall takes care of the NAT and the private IP of the client is the real destination and the remote port (rport) is 1230 and 1231 (ports open on the firewall).

So STUN is just the process of allowing the client to discovery its public IP and Port. However, in order for STUN to work properly, the firewall needs to support certain NAT types. In a nutshell STUN does not work with firewalls configured to enforce symmetric NAT. Other forms of NAT are OK e.g. full cone, restricted cone and port restricted cone NAT.

The reason why symmetric NAT does not work is because for each new request from the client a new port is opened for that connection, whereas other forms of NAT use the same connection already opened. If symmetric NAT is enforced, you will experience audio drop outs because the client will need to renegotiate and switch the connections each time the port changes.

Now assuming everything is as it should be, the ICE Candidates with the server reflexive address is used to attempt media negotiation between each clients. If the firewalls both sides pass connectivity checks then these candidates are used and media is established.

However, if media cannot be established using these ICE candidates, then we need another way to connect media. This is typically done using a media relay server, which is also referred to as a TURN server.

Going back to the SDP diagram we see another candidate pair with IP ports 59268 and 51695. This is the IP of the TURN server and the port assigned to the client for media traversal through the TURN server. We can tell this is a TURN server IP because the type is marked as relay. In this event the client will send media over its server reflexive address and port to the TURN server on the port assigned. The TURN server will accept the media and then relay it within itself to the peer connection also connected to the TURN server. The TURN server will then send out the media to the peer’s reflexive address which will hit the peer’s firewall, then NAT will take place to deliver the media to the client.

Putting this all together the media establishment process should look like this

Obviously you can go into more depth into this subject but at least this should give you a good baseline understanding on how Teams establishes media over NAT.

Changing the Display Name Format In Microsoft Teams From Last, First to First, Last

In Microsoft Teams, the name of your internal contacts is displayed in the format found in the displayName field in Azure AD. For some organizations this is never an issue. However, some larger and older organizations still use the Last name, First name as their display name format.

This format dates back to some perceived naming standard when application search was limited so ordering by surname meant that finding the right record was an easier task.

However, the modern day applications are now more capable in terms of searching and ordering of data, and applications are geared towards first name, last name formats as the new standard. This is especially the case where Microsoft Teams is concerned.

Why is this a problem in Teams?

The reason why last name, first name is not a great format for Teams is due to the way Teams interacts with you. Whilst in the application, you can forgive your name being shown as Jackson, Michael it is when you are not in Teams that potentially Teams becomes less friendly and more impersonal.

When you are not in Teams and someone sends you a chat, whether it is private or within a channel, you will get an email delivered to your inbox from Teams that will start Hi Jackson, Michael or in some cases I have seen just Hi Jackson,

Now to some users small things like this annoy them and cause unnecessary noise when you’re trying to deploy Teams and drive adoption. So its good practice to adopt the first name, last name standardization.

If you are synchronizing from your on-prem AD, then Azure is going to replicate your displayName format. Changing the format in on-prem AD puts most AD administrators off because they don’t want to screw up 200,000 accounts and work a long weekend restoring stuff. Understandable.

We also cannot do anything in AzureAD because the user accounts are synchronized and therefore editing in the cloud is prohibited.

So we have to do something in the middle.

We can do this using Synchronization Transformation Rules in AzureAD Connect. You can find this in your program start folder under Azure AD Connect

We want to use this to change the displayName format being sent from On-Premises AD to Azure AD

Using the filter, you can refine the transformation templates down to the user scope level out to AAD

This will give you a list of all the outbound rules for the user object to AzureAD. The one we are interested in is Out to AAD User Identity

Edit this rule. You will be given a warning saying this is a default rule and it is recommended to disable this and create a new one from it as a template. For Production, I recommend that you click yes as default rules may get reset each time AzureAD is updated. However, for the purpose of this demo, I clicked No to edit the default rule.

From the list of fields, we need to find the displayName. We need to change the flow type from DIRECT to Expression.

Then we want to add in the following expression

[givenName]&" "&[sn]

Save the rule.

After the rule has been saved, run the following PowerShell command to force a full synchronization

Start-AdSyncSyncCycle -PolicyType Initial

Once the new synchronization has completed, AzureAD will be updated in the new display name format

And in Teams their name will now be shown correctly

This will apply to all of Office 365 where the user’s display name is shown e.g. Exchange.

Microsoft Teams Prevent Automatic Startup

Today I was asked whether it is possible to stop the Teams desktop client from automatically loading on start-up once deployed to a user.

The reason we have to consider this is because IT need to control the deployment of the application and therefore we all know that deployment success rates are hard to achieve within a short window of time. Typically it can take anything from 10 to 30 days to reach 95% deployment coverage across devices. This is mainly due to device availability impacted by user connectivity and use.

Obviously the best way to enable Teams, is to ensure that users have the tools to use Teams from the moment they are enabled. It is frustrating to be told you are enabled for Teams, but you cannot find the client. Yes they can use the web version and yes they could probably download the client and install themselves, but there is such thing as application control policies in organizations.

This means that the Teams client is going to deployed ahead of time. And the default auto launch is just a frustration to users who are yet to be enabled.

We can’t get them to login and change the behaviour in the UI because they are not enabled yet for internal logistical reasons.

As there are no installation options for automatic silent deployment we have to add a post installation task to the SCCM deployment.

This task should remove the registry key made in the following location


and remove the string value:


Remove Via PowerShell

Remove-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Run -Name "com.squirrel.Teams.Teams"

Via Command Prompt

reg delete  HKCU:\Software\Microsoft\Windows\CurrentVersion\Run  /v "com.squirrel.Teams.Teams" /f

Microsoft Teams Is Not A Chainsaw!

OK, so you’re probably wondering what the title is all about? I do have a point let me explain…

Microsoft Teams, Microsoft Teams, Microsoft Teams. It seems that Microsoft Teams is everywhere at the moment, in all internet literature. Look how productive I am with Microsoft Teams, Look how I only look at my email twice a day since using Microsoft Teams, Microsoft Teams is the replacement to Yammer, to Outlook, Microsoft Teams is the answer to world hunger…

OK, funny sarcastic rant over..

Now let me state off the bat, Microsoft Teams deserves the publicity it is getting. It is changing the enterprise workplace for the better and I am genuinely excited by the possibilities Teams can introduce to an organization.

However, we need to be careful about how Teams is positioned. We all have a responsibility to ensure that this product is a success. Publishing articles, comments, podcasts etc. about how Teams can replace Yammer, or Outlook is not helpful to the Teams product.

The word that is inflammatory of course is “replace”. Teams is never intended to replace productivity solutions available in Office 365 like Outlook, Yammer, SharePoint etc. Instead Teams compliments or adds another dimension to these solutions to help users collaborate more seamlessly in their day to day collaborative tasks.

We all know and accept that Teams will replace Skype for Business Online at some point. Why would you have two UC clients? It makes no sense, so this replacement is rational. But that’s it as far as replacement goes.

However, there are faults with Teams as a UC solution to date. One of the biggest drawbacks on specifically Teams vs Skype as far as UC is concerned is screen space utilization.  In the Skype client, we can have a relatively small, tabbed conversation window that doesn’t take up all your working space, so you can chat and work independently.

In Teams the client is a full screen client, or rather takes up around 25% of screen space in order to be usable. This is too much for users working in other applications and makes app switching arduous compared to Skype.

The second drawback is that there is no concept of a UC Only mode in Teams. The perception is that everyone must want to use Team based collaboration within Teams. This pre-requisite is probably the number one issue that prevents the roll out of Teams to an organization at speed. It triggers all kinds of intra-business logistics before it can be released because we’ve never had to contemplate the concept before.

Putting these drawbacks to one side, I could argue that instead of designing the application to support legacy habitual usage, design the app for modern day working. However, you are not going to get users to flick from performing tasks in a certain way for the last 10 years to this new way over a weekend. There is going to be a transition phase, and if I am honest, Teams has missed this transition phase and gone straight for future state.

This has led to confusion in the market and some of the far out claims that it is a replacement to all sorts of things. When you strip Teams back, it is just a SharePoint Team site merged with Skype chat, stuff that has been around for years. But Teams glues them together and makes it sexy.

Teams is not a replacement for Yammer, and that comes from someone who does not like Yammer! As bad as Yammer seems, putting that into Teams would make a bad thing terrible. If you suggested that to an organization and implemented it, then you probably wouldn’t have any repeat business.

So how can I justify my opinion?

Firstly, you have to look at what it is you are trying to achieve by rolling out Teams in your organization. Do you know why you want it? Do you know how your business will use it? Do you know what return you’ll get from it?

Let’s take the first question, why do you want it?

Is it because it’s just new and you think you want it because everyone else seems to be talking about how great it is? Or is it because your organization lacks the ability to cohesively work together to extract experience and efficiencies within your team to reduce costs of going to market to find a consultancy to help you with a product design?

Do you know how your business will use it? Is it going to be something that is there but no one really knows what it is supposed to be used for? Or is it going to be the platform that is used to collaborate with internal and inter-organizational  users for the purpose of designing and improving route to market times for business products?

Do you know what return you’ll get from it? Is it just a perception that because you’ve spent X thousands implementing it, you’ll see a return, but not sure what it is? So when a team says they are ready to ship, you automatically assume that is ROI? Or is it measurable in employee welfare, speed to market and innovative material?

Until you know the answer to these questions then do not even think about deploying Teams. It is only going to end up in “just another failed IT project that cost a fortune and delivered nothing but problems”.

In the end these simple three questions are all that matter, the rest of the stuff out there about how Teams can replace X or Y is just unwanted noise and distracts you from the true purpose of Teams in your organization.

The use case for Yammer does not go away. Perhaps some of the use cases that you use Yammer for could see themselves pivot into Teams, but for organizational wide public forum, Yammer is still the number 1 Office 365 productivity tool for that purpose. In effect Yammer will turn into the corporate FaceBook. This doesn’t mean Yammer is being replaced by Teams.

If we look at the other common concept

Teams will replace Outlook

To debunk this claim we have to look at user habit, communication reach, and message intent.

Firstly an e-mail is globally accepted as an official medium. This means that emails can be transacted on because they represent official and authoritative instructions that can be tracked for authenticity. Chat based communication is much more fluid and lack the same presence as an e-mail. You cannot transact on a chat easily because people say things in conversation that perhaps should not be taken seriously. Chats can be easily misunderstood and they lack the same kind of controls as e-mail.

Chat is becoming more prevalent and preferred way to transact however, but only in specific cases.

So will e-mail disappear and we will all move into a instant chat only world? No, e-mail is here to stay.

Admittedly, e-mail based traffic may reduce, but it will not be replaced.

Also, people behave differently towards a chat vs and e-mail. Whether you notice this or not, you will do. I would bet that most people’s mind’s “hear” and e-mail more than a chat. An e-mail has a kind of formality about it in the same way as getting a letter through the post from the Police about your speeding incident. You read the e-mail, you have an action to complete and your mind creates a mental stamp that you must action something by a certain time.

With chat, because chat is conversational and less formal, your mind pays less attention to it. You get asked to do something in the middle of a conversation, your mind will not register its importance in the same way. That means unless you action that specific request within a short period of time (usually measured in minutes) you’ll forget and then be on the back foot when chased for it later on in the day.

Even if you remember “Oh John asked me to run that report for him, what was it about?” you now have the horrible task of trying to figure out the search string to type to return some results or scan through hundreds of conversation threads until you find the specific item you are looking for.

There is also communication prioritisation to consider. There is a perception that every communication needs to be instant, it does not. Using Teams for everything will end up hassling the person you’re trying to work with and actually have a negative impact on productivity. For non urgent or even semi urgent communication e-mail should be used leaving the instant channel available for more pressing tasks. This helps the user organize and prioritise their workload without you thinking about it.

This comes with the Outlook client.  Outlook is the go to application for email. Its incredibly good at what it does. It has search and categorisation capabilities that help users keep track of their emails and tasks in order of importance to them. This cannot be replicated for chat based communication in the same way. To port all of outlook functionality to the Teams client is not realistic for a number of reasons, but mainly, the Teams UI is not optimized for e-mail, it would take far to long to get feature parity and the road on that journey would dent the Teams brand as a whole and it would make Teams a huge application to deploy and use that could lead to performance issues all round.

In the same manner as Yammer, Teams will reduce the amount of mail traffic, we will see reductions in distribution list email or emails that attract discussion, BUT it will not replace Outlook or email.

My personal view is that if an email chain goes beyond three reply all’s then the conversation should either be in a Team if it is a small group or Yammer if its org wide. But Outlook will never get morphed into Teams completely.

What actually needs to happen is that both Yammer, Outlook etc. need to adopt Teams enabler features. What I mean by this can be described in this feature: Add a “Move to Teams” button to the email action buttons as well as reply and reply all. Have the ability to remove the reply all in favour of moving to Teams perhaps. The apps then encourage the usage change rather than users having to be the ogre and copy and paste the email conversation to Teams, then email a reply all saying “Moved to Teams”.

My point is this, Microsoft Teams is like the Swiss army knife for Office 365 and your organization. It has tools to achieve almost everything you need to survive, but it is not the best tool to complete a single specific task. For instance, if you had to chop a tree down every day of your life, you would probably choose a chainsaw instead…

In summary, Microsoft Teams gives you a lot of options to be productive. Not every option is going to be a good one for you. Ask yourself some grounding questions first, figure out how you want to use it and then work from there. Avoid cliche approaches and promises of replacing X and Y. Teams is not meant for that, Teams is meant to encourage, enrich and enlighten productivity options for your organization.


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.



Policy Synchronization with Microsoft Teams

This is just a quick post to cover off the mysteries of policy assignment with Microsoft Teams.

Whether you’re applying policies via the Teams admin console or via PowerShell you may be thinking it is a random act of chance as to when the policy will take effect on the target user’s client?

A lot of settings via policy are delivered to the client in-band. If you’re not familiar with this term, it essentially means that the client will receive configuration changes whilst being used and apply them without the user signing out and back in. However, when these configuration changes sync to the client is a bit of a lottery.

In most cases you can sign out and back in to bring in the new changes to force it if you cannot wait for in-band provisioning. However, even this seems to be somewhat of a lottery some times.

The old rule of on-premises was to wait for 15 minutes before attempting to sign back in. This rule derived from the typical AD Domain Controller replication time and had nothing to do with any other application replication. But the rule stuck for many applications due to their dependency on AD.

In respect to Microsoft Teams things are a little more complicated in the cloud. Its made up of lots of different micro services that all have to understand settings and parameters. In particular policies in Teams are driven from Skype for Business Online for UC based policies as well as AzureAD for group based restrictions. In order for the policy to take effect, these systems have to replicate between themselves and this can take a variable amount of time. Therefore, sometimes the 15 minute rule does not apply in this instance.

When you speak to Microsoft they invariably tell you to wait up to 30 minutes between change and test. Even though most of the time this will be more than sufficient there are times where the cloud goes a little bit wrong.

I was working with a premier support engineer on a Microsoft Teams policy issue and the feedback that was given by Product Group was that it can take up to 24 hours for a newly created policy to replicate properly through their cloud. As well as up to 24 hours for the user to become affected by the policy.

This seems an overly excessive amount of time. However, there are things that you can do to prove the theory on whether your tenant has policy sync issues.

The primary option would be to use the web client to validate policy restrictions in the first instance. Being a web app, you’re getting the settings directly from the tenant pre-loaded into the web interface and therefore not impacted by the desktop application cache. If it is not as expected in the web interface, then it is likely you haven’t waited long enough, or there are more issues that require a support ticket. If your settings have not come through on the web client within one hour, it is probably time to troubleshoot and consider a support case.

If you’re getting the settings in the web client but not in the desktop client then you can either wait for 24 hours for the cache to refresh itself (may be done sooner) or clear the Teams client cache.

You can do this by browsing in Windows Explorer to %appdata%\Microsoft\Teams and deleting the Application Cache and Cache folder and logging back into Teams


This will force the fresh retrieval of your policy settings from your tenant. If this still fails, then you will need to raise a ticket with Microsoft.

Microsoft Teams – Quality of Service

Being a Skype and Teams consultant I seem to spend my life talking about why it is important to implement Quality of Service even for cloud systems routed over the internet.

My mantra is simple, if you can do it and it’s going to make an improvement no matter how little the perception may be, then it’s probably better to do it.

Specifically with cloud there is always an argument that QoS implementation is not worth the effort because of the middle carrying network that is the internet. As we all know, the internet cannot perform QoS. So what is the point?

Firstly, this is a wrong assumption, that there is no point. The second incorrect assumption is that Quality of Service is only possible when you’ve implemented Office 365 Express Route.

The reason for my stance on this matter is because I look for different types of communication between different peers. I look at the intended media route over your network and calculate that a certain percentage of media will always be local to your network. With the implementation of Direct Routing, this percentage increases quite significantly.

As a result of these media paths remaining on your controlled network, you can apply traffic treatment policies to prioritise important data packets end to end and both ways. Your network may be geographically large with different types of inter site connections such as MPLS, Point to Point, or managed ethernet. As a result implementing QoS is no small feat. And for this reason alone I get the most push back on why QoS cannot be implemented at a customer. It’s not the technology, its either effort based, or the fact that the networks team have historically used other treatment methods and they don’t want to pivot away from that.

Once we get over the first hurdle on agreeing that it makes sense to deploy QoS for Microsoft Teams because 70% of the media is going to go end to end over the customer LAN, we then start talking about how this can be implemented.

First off LAN and WAN QoS are fundamentally the same, just different networks. And the endpoint for each of those networks may treat QoS differently. The most important thing from my perspective is that the traffic is treated in exactly the same way over each network regardless. Some WAN networks use accelerators and application inspection to classify data packets based on what the device has determined to be the application e.g. Microsoft Teams. The problem is that in order for these devices to determine the application type, they must inspect the data packet. As Teams transmits media in Secure Real Time Media (SRTP) the data payload is encapsulated in an encrypted packet. This means the device has to decrypt the data packet, inspect it, decide what to do with it and then re-encrypt it and send it on. This requires CPU and memory, but more importantly for us, increases latency and packet reordering and jitter. All bad where media quality is concerned. It is for this reason Microsoft do not support deep packet inspection for Microsoft Teams payloads.

The other challenge we have is WAN acceleration and packet reshaping. Network engineers will want to do this because it means that they can squash more data through the available bandwidth that otherwise would be possible. WAN accelerators basically compress the data packet and then send over the network. The problem with compression is that the data packet has already been compressed by the voice codec used in the SDP negotiation between endpoints, for the WAN to compress the packet again, you have double compression. This leads to data bits being lost and entire packets resulting is poor media quality. Again Microsoft do not support or recommend this for Microsoft Teams.

This leaves us with what needs to be done. Microsoft support policy based QoS using DSCP. Nothing new there. The LAN needs to be configured to transmit packets based on their DSCP classification, as does the WAN. Do not try to re-mark data packets between networks, for instance configuring EF for audio on the LAN but AF34 over the WAN. If you do that you are not gaining anything and contradicting the purpose of Quality of Service. Pick the classification and trust the packet end to end.

Microsoft publish their QoS recommended classifications for media types. For Teams, this is EF (46) for audio, AF41 (34) video and AF21 (18) for app sharing. It is an incorrect assumption that you must assign these values to Teams traffic for Quality of Service.

Yes, it would be nice to have, but the reality is often very different. Most enterprises have very strict controls over what type of application can use EF. For instance the most common entry criteria is that the application must have call admission control. Microsoft Teams does not have this ability.

EF is an expensive classification for them in the way that it operates as well as if they have a managed WAN then they are probably paying for a preset static amount of EF bandwidth. This bandwidth is precious to them as other business critical applications could be using this priortisation. If you go ahead and deploy Teams on EF then you could bring down several systems as a result.

The actual reality is that you are aiming for the best classification you can get in the AF band. You want the top classification that no other application is using so the data packet you are transmitting gets the best treatment and prioritisation possible. The net result is the almost the same experience as EF. In some ways it is better because like my last point around EF is expensive, by classifying in AF means you can use the general bandwidth available which would be much higher to your heart is content and get full prioritisation over it for no additional cost to your customer. Its a win win compromise.

Once you have this implemented at the network level, you need some way to mark the data packets accordingly. You do this today using group policy.


Don’t forget that if you are wanting to implement QoS then do it properly, it doesn’t just end with this GPO for Teams.exe. Where will these users be calling? Desk phones? Direct Routing SBCs?

You’ll need to ensure that these devices are configured themselves for QoS otherwise you are only getting QoS on the sending stream from the Teams client and potentially none on the receiving stream. The end result is 50% of the possible experience to each of the users.

You can test whether data packets are being correctly marked by using Wireshark to capture the data packets. You are looking for a UDP stream to the target endpoint on the source port within the media range


But remember, any packet that is destined to be transmitted over the internet will only be priortised on your network, up to your boundary. After that QoS does not come into play and the packet is sent like any other data packet.

The same is said from any inbound data packets from the internet. For instance, you receive a pstn call from Microsoft Phone System. The packet is being transmitted from Microsoft via the internet to your network. It is not prioritised and similarly any markings that were stamped by Microsoft’s media network for DSCP values are stripped by the internet routers. This means the inbound stream has a DSCP value of 0


Therefore, you are effectively only getting 25% of the total streams treated for Quality of Service i.e. Outbound stream client -> your boundary.

Network inefficiencies cannot be hidden from media traffic

If you’re going 100% cloud for calling and meetings, then you really should consider your internet breakout design, capacity and performance. It may be more cost effective to implement local breakouts at sites, rather than purchasing Express Route. But one thing is for sure, in an enterprise organisation, if you want enterprise grade voice quality then you need to guarantee your media quality end to end. Otherwise, there will be times where there are degraded experiences.

Lately, Microsoft have been rolling out meeting settings to the Teams admin portal and one of those settings is an enable Quality of Service markings for real time media.


You would assume that this setting would mark the traffic coming out of the Microsoft network and replace the need for group policy based QoS?

At the time of writing this appears not the case. Perhaps this feature has not yet made it to the client. The setting certainly suggests it should.

However, this setting will presumably apply the recommended DSCP markings to data packets and that could be in breach of your design. In this case, you would still rely on the GPO method.

From the testing I have done at the moment this setting does not actually mark any inbound or outbound data packet to the client.

In any case, when this feature is fully working it still is not going to solve your problems without you putting the effort in to support it. While you can be pretty consistent and controlled for LAN to LAN communication, you need to remember anything going to the cloud or coming from the cloud is not going to benefit from QoS, unless you have Express Route.

Deciding whether you need that or not depends on your usage prediction.

In summary, Quality of Service is still an important element of deploying a cloud voice solution, but you must understand your usage profile to weigh up the reward vs effort to implement. If you’re going 100% cloud then QoS will only play a meaningful role in internal P2P comms. You must focus your efforts in ensuring there is sufficient capacity and performance in your external network to support a good standard of quality albeit uncontrolled. If you want the best experience in this scenario, then Express Route may be a consideration for you, but not necessarily mandatory.

%d bloggers like this: