Home » Articles posted by Mark Vale (Page 4)

Author Archives: Mark Vale

Skype for Business 2019 Now GA WHEY!

So without much fan fare or fuss, Microsoft’s latest version of Skype for Business Server officially entered General Availability this week. Yes 2019 is officially launched alongside Office 2019, Exchange Server 2019 and SharePoint Server 2019.

It was somewhat of a damp squib event with very little song or dance on the twittiverse from both Microsoft themselves and MVPs. An official Microsoft blog limped up on Tech Community to make the announcement like Lewis Hamilton stepping up to the 3rd place podium at the US F1 Grand Prix knowing he and his team were out performed by Ferrari.

However, unlike Lewis, where he is still undoubtedly the current world’s best at what he does and another year at the top is almost as certain as night follows day, the same it seems cannot be said about Skype for Business Server 2019.

And this is no surprise really

Sure, Skype for Business 2019 comes with some useful enhancements for some customers who are on their cloud journey, like leveraging cloud voicemail, ability to collocate on-prem CDR and QoE data in the cloud so they can report through one pane of glass across all their hybrid estate, the ability to use Cloud Auto Attendant (quietly renamed from Organizational Auto Attendant), Ability to use Cloud hosted meeting and of course in built TLS 1.2 support. But for many others, this seems like Microsoft are doing it their way and making sure that the next jump customers take will be their cloud for UC and Enterprise Voice. Que this song..

While this is commendable and trail blazing it doesn’t suit all and some (including many I know personally) will not take the message in a positive way. Instead, they’ll receive the message more like this…

Putting feelings aside now, let’s look at the reasons as to why you would want to upgrade to Server 2019.

One thing Skype admins are going to have to watch out for is if their messaging team decide their strategic direction is to implement Exchange Online or Exchange Server 2019. If this is the case, then you’re probably going to be forced into an upgrade since Exchange 2019 lacks voicemail facilities and Exchange Online will soon follow suit. As of now, Skype for Business 2015 does not support Azure voicemail, the system preferred and used by Microsoft Teams.

You may be running Windows Server 2012 or even 2008 R2 base OS on your Skype for Business Server 2015 nodes and with 2012 especially entering extended support, combine that with SQL 2012 as well then you may choose to upgrade your servers to Server 2016 or even more recent 2019 to protect you on OS support. This may be a good time to future proof your on-prem deployment to 2019 if your cloud journey is not expected to finish by 2020.

Another actually quite valuable reason to upgrade is the ability for on-prem users to leverage cloud audio conferencing and meetings. Offloading your meeting capability to the cloud could potentially improve capacity and performance whilst extending availability and coverage you struggled with in the past. By using Microsoft global dial in capability and their global network this could actually be very advantageous to some customers over what they have today. Will it lead to cost saving?  Not sure, that depends on your situation.

One thing is abundantly clear though, Microsoft want you in Teams and they are doing everything they can to make that happen. Why? We have to look at the migration path from 2015 to 2019.

No in place upgrade, which was a welcome addition to 2015 that pleased a lot of customers because they could reuse their 2 or 3 year old servers and extract the ROI they projected from them. Now we have to go back to side by side and the hardware requirement has almost doubled in some areas e.g. RAM from 32GB to 64GB (thank god it wasn’t 256GB like was originally floated around the DLs).

Couple the new hardware with you now need Server 2016 at a minimum to install 2019 and your Wintel team may yet to be at the point of being able to support the image which could be challenging and make the project stretch further than originally budgeted.

The most shocking and inexcusable omission from 2019 is that it no longer supports SQL mirroring. When I questioned this, the response was that most organizations wanting HA will have SQL Enterprise Licensing. I have to say I have done many deployments over tens of thousands of seats with HA and only may be 3 had enterprise licensing for SQL. The average enterprise cannot afford that licensing model and use Standard. So now if you want 2019 and you want HA for your databases then your only option is SQL Always On and that comes with Enterprise. Yes Standard allows you one database in a AOAG, and that would make your XDS database highly available but not others like LIS or your back end pool databases which basically means its irrelevant to the cause.

Now take into account that pretty much all admin diagnostic tools are deprecated e.g. snooper being the biggest means that debugging and tracing issues with your deployment just got a lot harder. Why would you deploy it if you cannot support it?

So to me 2019 right now is expensive and that may make customers who were hesitant or ignorant to the cloud look more closely at their options. One thing is for sure, 2019 is now a stepping stone to the cloud more so that 2015 and the cloud is where the focus is right now. Could 2019 be the last on-prem version we see? Certainly seems that way right now.

However, it is not all doom and gloom. Yes SfB Server ends mainstream support in 2020, but it is still officially supported until 2025 in extended support, so now you can protect against Windows 2012 R2 exiting mainstream as of the 9th October 2018 and move to Server 2016 with a fraction of the investment it would take for 2019 and protect your business for another 6 years. Subject of course to the Exchange problem, but there are solutions out there that can be used.

Should we all protest at Redmond? Probably not. if we are sensible we would have seen the direction this was moving towards even before Teams was conceived, we knew the end game and it now appears closer than ever. The sooner people accept that the better because now you’ve a decision to make, adopt the Microsoft way forward which still has an incredible amount of value in the cloud or evaluate other solutions that fit more closely with your business needs.

Cloud maybe for everyone, or just some, whichever cloud (public or private) you choose it should be a free choice. This will probably be my last Skype for Business specific post because the organizations I work with today are all focused on moving towards Microsoft Teams.  I just wanted to give a balanced opinion on this version that both personalities can take away something of value from it.

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
try{
Get-Process -ProcessName Teams | Stop-Process -Force
Start-Sleep -Seconds 3
Write-Host "Teams Process Sucessfully Stopped" -ForegroundColor Green
}catch{
echo $_
}
Write-Host "Clearing Teams Disk Cache" -ForegroundColor Yellow
try{
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
}catch{
echo $_
}
Write-Host "Stopping Chrome Process" -ForegroundColor Yellow
try{
Get-Process -ProcessName Chrome| Stop-Process -Force
Start-Sleep -Seconds 3
Write-Host "Chrome Process Sucessfully Stopped" -ForegroundColor Green
}catch{
echo $_
}
Write-Host "Clearing Chrome Cache" -ForegroundColor Yellow
try{
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
}catch{
echo $_
}
Write-Host "Stopping IE Process" -ForegroundColor Yellow
try{
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
}catch{
echo $_
}
Write-Host "Clearing IE Cache" -ForegroundColor Yellow
try{
RunDll32.exe InetCpl.cpl, ClearMyTracksByProcess 8
RunDll32.exe InetCpl.cpl, ClearMyTracksByProcess 2
Write-Host "IE and Edge Cleaned" -ForegroundColor Green
}catch{
echo $_
}
Write-Host "Cleanup Complete... Launching Teams" -ForegroundColor Green
Start-Process -FilePath $env:LOCALAPPDATA\Microsoft\Teams\current\Teams.exe
Stop-Process -Id $PID
}else{
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 10.0.0.1 and Client B has an IP of 192.168.0.1 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 84.118.215.119 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 192.168.0.103 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 94.25.25.214 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

HKCU:\Software\Microsoft\Windows\CurrentVersion\Run

and remove the string value:

com.squirrel.Teams.Teams

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.

 

 

Microsoft Voicemail Just Got Expensive For Some

Well Skype for Business Server 2019 got released in Public Preview alongside Exchange and Sharepoint distros this week and there has been lots of noise about feature removals and quiet squeaks about feature additions.

It comes as no surprise really as Microsoft turns the cloud up to eleven and trail blaze into a seemingly cloud only model of subscription based services. The 2019 releases of the application packages that defined Microsoft as a software company have got people in a downer. It’s the first time in my history where I have witnessed the complete lack of enthusiasm towards a new product release from Microsoft. And although quite sad, I also have come to accept that on-prem is just not strategic enough anymore.

Although Skype for Business 2019 has removed features considered no longer relevant for 2020 onward, it has improved the integration between on-prem and cloud which is aimed at unlocking those blockers that customers have where cloud communications are concerned.

This of course assumes that every customer of Microsoft will want to use at least “some cloud”.

For these customers 2019 makes sense at the surface by allowing them to use Call Queues, OrgAA instead of response groups, use Azure voicemail, Teams for Group Chat and send their QoE statistics to the cloud and use Microsoft’s compute for reporting.

But all of this requires may require that the user is licensed for a cloud offering. At the very least they are going to need Skype for Business Online Plan 2 and Phone System. Licensing that an on-premises user never needed to have potentially.

Add into the mix that 2019 requires new hardware of increased specification, reliance on Windows Server 2016 and SQL 2016 Enterprise if you want HA on your CMS as mirroring has gone. Skype for Business 2019 is a really expensive update for customers vs feature offering without cloud.

The fact the cloud reduces hardware and licensing requirements for on-prem features like persistent chat, SQL data analysis and reporting is true, but I am not convinced that this has a monetary saving.

Of course, if you are that company, who is willing to leverage the cloud offerings for your users then it probably makes more sense for you to jump in to the cloud with both feet and migrate from 2015 to native cloud, whether that is Skype for Business Online first or straight to Teams.

One thing for sure, there really has to be a compelling reason to want to update from Skype for Business Server 2015 to 2019 at this moment. There will be a day where you will have to do something due to EOL of 2015, but that could make you look towards other solutions if Microsoft cloud and 2019 are not viable alternatives for you.

2019 for businesses who just will not go to the cloud because of the data at rest complexities and risk management will really have to consider their options. 2019 for them probably feels like Microsoft are alienating and penalizing them for not doing it the Microsoft way and using cloud or hybrid.

One thing 2019 will do though is force the hand and this is a high risk strategy or so it seems right now.

However, perhaps the biggest news and impact to customers is the drop of Unified Messaging from Exchange 2019. This affects not just Skype for Business server users but also the thousands of other 3rd party VoIP users out there. For 3rd party users who rely on UM for their voicemail this is a huge issue that isn’t just limited to Exchange 2019 server, but online also.

I know customers who have retired their Cisco Unity solution in favour of both on-prem and online UM to have that integration with the users mailbox. UM used to be free and inclusive in the user license for Exchange and now customers will need to look at other providers for voicemail and go back to the year 2006 before the days of UM.

Perhaps voicemail is old fashioned?

Perhaps this move by Microsoft is going to question the importance of voicemail in general. Is voicemail old fashioned? Should we care about it? I must admit that I rarely listen to voicemails even in Teams and I don’t even have it enabled on my landline. Is voicemail just a courtesy service that society just expects to have, but in reality serves very little purpose?

Personally when I want to call someone it is because I need to speak to them about something that is “in the moment” topical. If they didn’t answer I would either email them to ask the question, or find someone else who can service my query. I’d only leave a voicemail if I knew they were the only person that could answer my question and I knew that they would probably pick the voicemail up quicker than an email (friday afternoon for instance) and I needed an answer urgently.

In addition, today, most people have a mobile phone anyway, and the more savvy users would have configured simultaneous ringing anyway so the chances of hitting a user’s voicemail service is reduced. Plus with no answer, you’re probably going to hit the mobile service voicemail anyway.

When I think of it, do I personally care if I have no voicemail? No I don’t, I could quite happily live without it. Voicemails to me are like unwanted spam anyway.

But there will be customers out there that still require voicemail and those who do will probably be using some kind of call center service that should have its own voicemail capability anyway. Or there will be just users who think they need it just because they’ve always had it. The fact the last time they had a voicemail was 3 years ago doesn’t come into that decision making process lol 🙂

But anyway if you’re a 3rd party voip user now using Exchange UM in any flavour then you have a problem to solve if you want to maintain this service.

In short, Microsoft have a solution for you. If you want Microsoft Voicemail, then move to Microsoft Teams or Skype for Business 2019 or both! Alternatively, and most probably the default position would be to seek alternative solutions from your current voip provider. Then you have to factor in costs for hardware, software licensing and probably 6 years of lapsed unpaid support to get you current with them.

For Skype for Business server users, you’re pretty safe. Lync 2013 and Skype for Business 2015 users you can continue to use Exchange UM for as long as your messaging team allow you to keep 2013 – 2016 UM servers around. Skype for Business 2019 users can use the same or use Azure Voicemail.

As a said before, Azure voicemail requires a SfB Online and Phone System license so voicemail that used to be free and a value added service has now become a $7 a month per user service.

[Update] Clarification was received by Roy Kuntz from Microsoft who is in charge of the Voicemail direction which states the following:

For On-Prem Skype for Business users, cloud voicemail will be provided at no cost. The only requirement is that an Office 365 tenant exists with at least a Skype for Business Plan 2 or Teams license subscription on the tenant. This triggers the back end systems for configuration to allow the voicemail service for the tenant. All that is needed is AAD Connect and accounts synchronized. No Exchange or Skype for Business hybrid required. For those tenants without a Teams or SfBO subscription, a trial license can be obtained. When expired, Microsoft are issuing some promo codes available when in Public Preview.

In summary, start questioning your usage of voicemail before deciding that this is super critical for you and you go and spend a ton of cash on providing that service when the time comes. You probably have 1-3 years depending on whether you use Exchange Online or On-Prem to do something, so don’t panic too much yet.

 

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

2018-07-25_14-38-15

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.

%d bloggers like this: