Home » 2018

Yearly Archives: 2018

End The Working From Home vs Office Debate. It is Pointless!

For what seems to be an eternity, we in IT seem to be transfixed by the “Working from Home” is better than “Working from the Office” debate. We have argued over and over like politicians in the House of Commons over Brexit. The simple truth is, it’s a pointless argument that yields no actual result.

Personally, I think the debate is ill-founded on principles that bear no meaning towards working life. This debate takes many forms and in recent times over the past year or so been encapsulated in the “Productivity” form. It seems to have got caught up in the reasoning for using Cloud technology, most particularly Microsoft Teams. When you cut away the hype and fluff, you’ll realise this argument actually could have started way back in the early 2000’s. Back then, you could have worked from home to some degree by using VPN connectivity to save your documents, webmail / IMAP / POP to get your e-mail. Granted this experience compared to today would be somewhat basic and some would actually struggle to cope but the essence of being able to work from home existed irrefutably for some people.

Fast forward to the age of Cloud where technology and in particular communications enable you to work more effectively anywhere it is becoming difficult to always understand the boundary between work and home.

This argument over WFH vs WFO is being promoted as an excuse to adopt technology such as Microsoft Teams more so these days than ever before and it’s distracting from the true value of these technologies, creating tangent arguments that actually have zero impact on what you are trying to achieve in the first place.

The argument should not be about whether it is more productive to work from home over the office, but how this technology empowers your business and more importantly your employees to conduct business in a collectively more efficient manner.

I don’t see Microsoft Teams as Productivity tool. If I did, then I would assume incorrectly that by using Microsoft Teams I am by default going to be more productive as a result.

Microsoft Teams to me is an empowerment tool. It gives me the critical features I need to function in my job at my finger tips on any device I choose from mobile to desktop. It doesn’t matter to me where I am, if I have connectivity and a device to hand it means that most probably I can complete a task being asked of me, regardless of where I am.

I am empowered having this capability in my pocket. It means I don’t need to worry that I left customer site 7 minutes before this phone call, or that someone forgot to ask me a question before I left, I can just reach my phone, laptop or whatever, access what I need and complete a task that would have normally meant waiting until the morning.

You could confuse that with productivity, but it is different. Empowerment comes by having access to the capability that may assist you in being productive. Productivity is the decision you make to use that moment in time for your benefit.

In the above scenario, I was empowered because I have access to Microsoft Teams. I made a personal decision to use that moment in time to action a work related task. That decision was me choosing to direct my efforts towards a work related task and that can be seen as productive use of time towards work.

That said, equally I could have chosen to catch up on Narcos on Netflix whilst sitting on a train and I will deal with that request tomorrow. This is equally productive use of my time because I know getting home I wouldn’t be able to watch it. The fact I chose a different path for that moment of time other than work related, does not make me an unproductive person.

And this is why I believe productivity cannot be measured laterally across your workforce.

The real argument between WFH over WFO is down to lifestyle of your employee. Lets not beat around the bush.

My current role, the Office is 2 hours away from my home. I go to the Office 3 times a week. Each of those days I am up at 5am, in the car by 5.45am and in the Office by 8am. I work until 4pm and by the time I am home it is nearer 7pm. Just in time to give my 11 month old her night time bottle, put her to bed, then read my 4 year old a bedtime story, then say Hi to the Mrs, then have Dinner, take the dog for a walk and then go to bed.

On the 2 days I don’t go to the Office, I get up at 6:30am, have breakfast with my Kids, get them dressed, have a bit of a play, take the eldest to nursery. Sit down at my desk at home for 8:30am with a coffee and in my comfy pants and slippers. Break at 1pm, have lunch with my wife, go back to it, finish at 4:30pm pick eldest up from nursery, sit down as a family for dinner, have a relaxing evening.

The amount of work I do at home within working hours vs the office is more or less the same because I have the tools to do my job regardless of location.

I admit, I prefer working from home over the office because it suits me. It makes my life less stressful and I can balance my time better with the family, they see more of me and I am generally less tired.

I will say on the balance of my time as a whole work and pleasure I am more productive when WFH because I am given the time to be. By productive I mean the hours I save not having to travel to the office I can use better towards benefiting my family rather than hours lost to asphalt and brake lights.

So yes, I agree I am more productive at home overall. It does not mean I produce more bytes sitting at my desk at home vs my desk at the office, which some seem to think this is all about.

That said, there are people that want to come to the office as that’s where they work best. Some may not have dedicated home office space, their home life may be that hectic that coming to the office is the only way they can get stuff done.

Other times it is better to conduct work activities face to face. Even with video and digital whiteboarding, sometimes it cannot replace real human interaction.

How as a business / employer can you measure that as tangible outputs across each working habit? You can’t because it is beyond measurements. You can’t say that Jane is a better employee than Dave because she works from home, or indeed the other way around.

However, if you calculate in employee welfare and retention as a result of encouraging flexible working, then the tangible output from that is you may retain skilled staff making your business platform more stable and experienced which allows you to grow more efficiently as a result.

So WFH for me I see as a personal well being benefit. It doesn’t automatically make me more work-productive that when I am in the Office. In fact if I look at the activities I do in the Office vs at home then on balance stuff tends to happen quicker in the office because I can look the person in the eye and get a decision in a moment. Whereas at home I would probably have to first find that person on Teams, send a chat, arrange a meeting to get the decision.

Instead of the debate over which working strategy is best, cancel the debate it really doesn’t matter.

Instead your goals when deploying technology is all about empowerment to your users and business that gives you increased flexibility to conduct business in ways that perhaps before were harder to achieve.

This of course is my opinion. You don’t have to agree with it, you may have your own and that is fine. In fact it proves my point at the beginning of this post that it really doesn’t matter, because at the end of the day every one is different and what works for one, won’t for another. And if that is the case, how can you enforce that through your workforce? You can’t! All you can do is empower your employees to be as effective as they can be with as much flexibility as you can afford for mutual benefits.

Microsoft Teams, your employee communication and collaboration empowerment tool! ūüôā

#PowerToThePeople

 

 

 

Once upon a Time In Microsoft there was Teams, Yammer and Kaizala

Once upon a time there was a group of people sitting together at a canteen table eating their lunch. Not a word was spoken, until one of them looked up from their phone and noticed that the person sitting next to them was using a blue app to message someone. They look at the person sitting the other side of them and noticed that they were using a blurple app to message someone. They sat and thought for a moment “Hmm… one is using a blue app, the other a blurple which one should I use? ”

They finished their lunch and went back to their desk. They then whispered to the person sitting next to them “Hey I’ve got a great idea! At lunch I saw two people using apps to chat to their friends. We need an app to do that. What if we made an app that we could chat securely in where messages are encrypted? And if we can create groups as well we can have group chats. Maybe we can do video calls too that would be fun! and Oh yeah perhaps we can maybe share files or locations maybe?” Their buddy agreed “We should build that app, it’s a killer idea!”.

Fast forward a few dev months and their work is done, they have this app. Oh now we need to test it? I know the best place for this one said..

After a short test period and a few more dev cycles their app was free of bugs so they took it to their manager. “Hey Boss!” one said. “We have been working on this cool new app and want to show it to you, we think its going to be epic!”. The boss sits back in their chair and says “OK, sell it to me”.

PowerPoint loads their polished deck they’ve been working hard on for a week. “We’ve built this new app that you can chat in and chat in groups or 1 on 1″… “Hold On!” says the boss, “stop! you mean I have been paying you for 6 months and you’ve created a chat app? Didn’t you know we already have this? It’s called Microsoft Teams!”

“Is that the blurple app some people use?” asks one.

“YES!” says the boss. “Microsoft Teams is our collaboration platform for enterprises. It allows our users to chat to each other 1 to 1 using any device mobile or desktop, Mac or Windows. Users can call and do video and have meetings and conferences”.

“Ah, but we have the new concept of groups in our app” says one of the creators.

“Teams has Teams. Anyone can create a Team a team is like a group. where groups of users can chat, call, meet and collaborate on documents together in a secure virtual space” says the boss.

“Oh, our app only allows groups of users to chat, call and share files” says the other creator. “But, we are different as we are mobile only and our app is for instant and random chats between users that can quickly change topic and dimension. We aren’t trying to force collaboration because not everyone wants to collaborate all the time, they may just want to chat. Plus this Teams app you mention by the way you describe it seems to be very narrow focused to a concentrated circle of users. We want our users to be able to chat to anyone without restriction and discuss a wide variety of topics that can be answered by the larger community”.

“But we have Yammer for that” says the Boss. “Yammer is our social platform where you can join interesting groups and ask questions to the wider community, or get involved with conversations replying to group messages. Users can announce important information, share files and other content and also send a private message too”.

“Right….” says one creator. They both pause for a moment, look at each other with sweat starting to trickle down the side of their faces, when the boss pipes up and says “Don’t worry! Iet’s take it to our marketing department and get their feedback!”

A week later, the marketing team come back to them and say “We love it! We have this concept of inner loop and outer loop that we’ve been using to differentiate Teams from Yammer and when and why you’d choose one over the other. It looks a bit straightforward, we need some diversity, so we think this app can fit in this story and we’ve created a new loop. It’s called the open loop. This is where your app will be positioned”.

both the creators and the boss look at each other bemused, but collectively nod their heads. “So what is this loop thing you’re talking about?” one asks.

“well the inner loop we refer to is a bunch of people you work with closely day to day and have regular and purposeful conversations with and need to collaborate together to create something cool, like this app you’ve made. You 3 are a good example of an inner loop. The outer loop is when you want to reach out to your workforce peers and have open discussions about business related topics that may not be sensitive or require answers from people outside your immediate group or inner loop. We use this when you have a question you need answering, but you don’t know who to reach out to in a 1 to 1 conversation, so posting it on an open board allows you to get your answer quickly and more importantly it is probably going to be the right answer, and now you’ve made that connection you never had before

Now the open loop we’ve created for you this is for when the topic is neither fit for inner or outer loop. Its for you to communicate and coordinate across your value chain in a dynamic mobile first manner”.

The boss turns around and says “I get the inie outie loopie thing, but what you just said makes no sense, can you simplify it?”

“Sure!” says the marketing team. “Basically, its just to allow random chats between people in the organization, you know if you need to ask a spontaneous question to a colleague and they’re not online in Teams then you can use this to send them a message. Or if you’re organising a staff party you can create a group and organise it within your group. You know, conversations that probably have limited if no structure or longevity to them”.

“Got it!” says the boss, “So its WhatsApp for Office 365?”

“Yes, you got it!” says the marketing team.

“Today we proudly announce the availability of Kaizala, a mobile first chat and group messaging app for your enterprise”….


I write this in humour of course but I hope it’s made the point. When Kaizala was released I was sceptical as to why Microsoft saw fit to create basically a WhatsApp clone. Whilst I have heard good reports about the app I fear it has an uphill struggle to up seat WhatsApp usage for business communication.

I can see why this has been attempted. People taking potentially sensitive conversations away from corporate systems to WhatsApp even sharing documents etc. and that is a real concern for some businesses who are fighting hard to maintain compliance and control.

I can also see that trying to encourage adoption of apps like Teams and Yammer as alternative platforms to WhatsApp have their limitations and user experience issues for when you just want to send a message and this makes adoption a struggle.

At least with WhatsApp I can scroll my phone address book find the person I want and tap away. In these other apps, its slower in that i have to search and wait for a match etc. They do the job but the experience can be a turn off, so people revert to what is easiest. Its really easy to use, simple and does the job it’s meant for and that’s why people love it.

People think that well WhatsApp is encrypted so its an acceptable platform to talk business and share business documents on and this perception is built from not fully understanding legalities and compliance and control.

So I feel Kaizala is a “If we can’t beat em, join em” app that’s been created to try and unify all business communication under one single controlled and compliant system in Office 365 whereby users are happy they have the tools they want to use at their disposal and the freedom to communicate in the sphere they see fit, but the company maintains overall control and compliance and greatly reduce their attack surface for hackers or unintentional data breaches because someone sent the company financials to the wrong WhatsApp contact…

Evaluating Cloud Video Interop (CVI) Architectures with Microsoft Teams

If you’re like me then getting your hands on video conferencing scenarios is like your nan’s birthday. It comes around once a year and you spend two months trying to figure out what to get for a present. I am not ashamed to state that video is not my strong point especially where interoperability is, it’s just that the opportunities that have come my way have been more centered on enterprise voice than video interop.

Recently, I tried to fill that gap a bit and went on some Pexip training to see how this stuff is done. I don’t know why but I always thought it was more difficult than it turns out to be. Really the only thing different between voice and video is how the codecs behave, the architecture and protocols are fundamentally similar to voice and somehow I knew that, I just thought it was more difficult than it was. 

So at a basic level of understanding we have a device in a room, it does video conference stuff and we need to be able to join this device to another device on another platform that is also doing some video stuff but differently and we need some glue in the middle to make that happen. Enter, Video Interop.

Why can’t these devices just connect? I mean video is video right?

Well to answer than the answer is pretty much no. Remember Blu-ray and HD-DVD? They both are capable of digitally storing a movie but you need a special player to play either Blu-ray or HD-DVD. The same can be said for video conferencing. Each system generally offers the same functionality and delivers the same output, but invariably you need dedicated and vendor specific hardware to use it. What if you wanted to loan your Blu-ray copy of The Fifth Element to your friend who had a HD-DVD player? You can, but they would have to go to the store and buy a blu-ray player…

Of course, I am speaking generally, and HD-DVD never took off, but the point is valid. This is the problem in video conferencing world where you have some gear in your meeting rooms that you want to use inside a Microsoft Teams meeting. How do you get this stuff to work?

The first problem we have to understand is the Microsoft Teams meeting architecture. Fundamentally, this is a H.264 video meeting space which means that any endpoint wanting to use video inside a Teams meeting has to be capable of sending and receiving H.264 video streams.

The second problem is that the Microsoft Teams client is dedicated to the Microsoft Teams meeting ecosystem, meaning that unlike Skype for Business, it is incapable of joining a meeting space hosted by another platform.

The third problem is that your video conferencing endpoint is probably either using h323 or a variant of H.264 that Teams doesn’t understand.

The fourth problem is that Microsoft Teams doesn’t use SIP in the meeting context, so even if your video conferencing endpoint uses SIP, you still have an interop problem to solve.

So your organization is moving its meeting space to Microsoft Teams. How do we solve this problem? Cloud Video Interop (CVI)

Firstly, you need a product to act as a middle man, that is able to ingest the signaling protocol and video codec supported by your video conferencing endpoint and convert it into a Teams compatible signal and codec, send it to the Teams MCU and vice versa. There are 3 products on the market for this right now and they are Pexip, Polycom Real Connect or BlueJeans.

Whichever product you choose, one thing is consistent across all three products. The Microsoft Teams connector (the server that connects the systems transcoding servers to Microsoft Teams) must be installed in Microsoft Azure. The rest can be anywhere, but this connector cannot live anywhere else due to Microsoft certification requirements.

The question now becomes are you going for a SaaS CVI or On-Prem / Private Cloud CVI?

This post is not going to argue which one you should choose, but consider the impacts of the decision you’re about to make.

If you’re going with a SaaS solution, this of course is a faster route to delivery and the benefits of OPEX subscriptions means that within a short period of time the high level objective is achieved. However, one thing to be very conscious about is understanding the architecture and limitations of the SaaS product you have bought into.

The biggest considerations is understanding how interop works. To do this is down to how meetings are organized. If you’re using Microsoft Teams, the meeting space will always be held within Microsoft Teams and an Office 365 datacenter. This could be in the same datacenter as your tenant, or it could be in some other. However, that generally doesn’t matter too much because the Microsoft internal network for Office 365 and Azure is super efficient it almost becomes a moot point. The most important note is that it is Microsoft hosting the meeting.

So now your video conference endpoints need to join a Teams meeting. They do not actually join directly. In any interop scenario, they will register to your interop service and that will spin up it’s own conference of a kind that the video endpoint will join. The interop service will then connect it’s conference to the Microsoft Teams meeting via the Teams connector in Azure. Transcoding happens on the interop service not the connector. 

The next point when considering SaaS is the datacenter location of their transcoding and connector services. There is little point in signing up to a service that has one global point of presence the other side of the world to your video endpoint or tenant because that would introduce some massive latency, packet loss and jitter issues, which is generally considered bad for video and voice.

If the SaaS solution has sufficient global coverage, then maybe it still is a viable solution to consider, if your internet links are optimized with this service in mind.

The other option is to use an on-prem solution, or private cloud where you can control the media path more optimally. Generally speaking, it is better to perform transcoding locally than in the cloud and sending H.264SVC streams over the internet is preferred as its considered more tolerant to network impairments, but with data connections being better than what they used to be, the performance gap is reducing. 

With solutions that use distributed interop, on-prem can be really efficient in scenarios whereby you have multiple video conferencing endpoints wanting to join the same Teams meeting but from all over the world. In this scenario you can have internal transcoding servers located geographically closest to each of the video endpoints. Each endpoint would connect to the closest transcoding server to them, media between endpoints would then switch locally across your LAN & WAN whilst only sending the required media to the Teams conference so that users joined in by the Teams client can interact and participate. 

So on-prem can from an architectural perspective be more appealing in multi-endpoint scenarios and where SaaS doesn’t have the coverage it needs, but comes with the costs of hardware, which for video isn’t going to be cheap entry level server, but a mid to high powered performance server at least 5 figures per server.

In summary, there is no real definitive outcome as to what you should do. Financially it makes sense to look towards SaaS interop with Teams and as we know these days financial incentives tend to win the race. But this does come at a cost that is usually paid in reduced user experience if poorly implemented. For out and out performance, on-prem still wins the race and is the most optimal solution money can buy, but you have to have the money in the 1st place.

I’ll finish with a suggestive approach for you to consider. If your company are light users of video conferencing suites and your persona investigation has proved that device usage will reduce even further with the implementation of Microsoft Teams, then you’d probably want to consider SaaS as your primary solution for CVI.

If, however, your organization are heavy video conferencing users and this is to continue or increase with the implementation of Microsoft Teams, then you’d probably want to consider an On-Prem solution first over a SaaS.

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.

SUPER IMPORTANT NOTE:

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.

 

 

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
%d bloggers like this: